mwp - Page 23 - RC Groups
Shop our Airplanes Products Drone Products Sales
Thread Tools
This thread is privately moderated by stronnag, who may elect to delete unwanted replies.
Jun 01, 2018, 04:46 PM
Registered User
So I've made a bit of progress today- I have the crossfire tx connected via bluetooth in mwp and use the --forward-to command and add my tracker's bluetooth address, but i couldn't recieve any telemetry on my tracker, so i connected the bluetooth to a usb ftdi adapter and opened up a serial monitor, i'm getting a connection, but i get alot of strange characters- i assume a baud rate problem, but every baud rate i've tried to connect with i get the same results. might you have any ideas as to where to check next? This is the bluetooth module I have on my tracker i'm trying to forward to. http://hacker.instanet.net/Bluetooth/a7-pb-eb301.pdf

I've had a look at Issue #35 on github, and when i try to use rfcomm, i get a permission is denied message when i try to connect
Last edited by jbgrcfreak; Jun 02, 2018 at 01:01 AM.
Sign up now
to remove ads between posts
Jun 02, 2018, 02:15 AM
sweet dreams & flying machines
stronnag's Avatar
Quote:
Originally Posted by jbgrcfreak
So I've made a bit of progress today- I have the crossfire tx connected via bluetooth in mwp and use the --forward-to command and add my tracker's bluetooth address, but i couldn't recieve any telemetry on my tracker, so i connected the bluetooth to a usb ftdi adapter and opened up a serial monitor, i'm getting a connection, but i get alot of strange characters- i assume a baud rate problem, but every baud rate i've tried to connect with i get the same results. might you have any ideas as to where to check next? This is the bluetooth module I have on my tracker i'm trying to forward to. http://hacker.instanet.net/Bluetooth/a7-pb-eb301.pdf

I've had a look at Issue #35 on github, and when i try to use rfcomm, i get a permission is denied message when i try to connect
There a few things at least to go wrong, notably that BT devices usually need to have their baud rate set on the device. It's also the case that all the telemetry protocols are binary (non-ASCII), so even if it's working you'll get mainly garbage in a serial monitor. Can you capture the data stream from the forward and let me see it? If necessary there's a capture program in mwptools:
Code:
cd samples/ttycap
make
./ttycap -d /dev/XXXXXX --baudrate=nnnn > capture.dat
^C
# ^C to stop (or --duration=sec to record for a set time)
Do it at various baud rates if it helps and post the files, either here or in a new Github issue.
Jun 02, 2018, 02:33 AM
Registered User
on 19200 i get one long line in a serial monitor that looks like this. i tried other bauds but they all look similar unless i go far way high or low then it's just the same character. also, i'm only getting data this data when i use "full" as forwarding option. when i try minMAV i get nothing on any baud.
Jun 02, 2018, 06:10 AM
sweet dreams & flying machines
stronnag's Avatar
Quote:
Originally Posted by jbgrcfreak
on 19200 i get one long line in a serial monitor that looks like this. i tried other bauds but they all look similar unless i go far way high or low then it's just the same character. also, i'm only getting data this data when i use "full" as forwarding option. when i try minMAV i get nothing on any baud.
Please just post the raw files if you want assistance. A screenshot is useless, I'm not going to transcribe it by hand.
Jun 02, 2018, 02:18 PM
sweet dreams & flying machines
stronnag's Avatar
This (rant) is not directed at anyone is particular, it's just to make the point that failing to provide adepquate information (or just providing non-processable, obfuscated information) means that solving your complex issue becomes impossible.

So, it happens that message forwaring is working just fine here, here's an example how it's tested and of the sort of information that is helpful is solving such matters.

General Description

UAV with telemetry over 3DR radios to a ground station '3DR to BT bridge' into mwp. mwp forwarding is enabled to a second BT device; that second BT is connected to a HC-12 radio link. The HC12 - HC12 radio link remote side terminates in a USB-TTY device. The attached diagram shows the setup.

iNav setup

Here's the serial stanza, showing that telemetry (LTM) is enabled, shared with MSP (unarmed MSP, armed LTM).

Code:
serial 0 17 115200 38400 115200 115200
mwp forwarding
mwp invoked as:
Code:
$ mwp --forward-to 30:14:12:02:16:64 # this is the HC-12 bridge 
# mwp serial device is  00:14:03:11:35:16, the 3dr-bridge
mwp forwarding data setting
Code:
$ gsettings get org.mwptools.planner forward
'all'
Mwp's status log

mwp_stderr_YYYY-MM-DD.txt if invoked from a desktop launcher, stderr if run from a terminal command line.

Code:
2018-06-02T18:42:52+0100 Try connect 00:14:03:11:35:16 3dr-bridge
2018-06-02T18:42:52+0100 Connected 00:14:03:11:35:16 3dr-bridge
2018-06-02T18:42:56+0100 set forwarder 30:14:12:02:16:64
2018-06-02T18:42:56+0100 Serial ready
From that log, we can see that mwp is able to (a) connect to the telemetry (BT) serial device 00:14:03:11:35:16 (the 3DR bridge) and to BT 30:14:12:02:16:64 (the HC-12 bridge), both raw BT addresses.

As I don't have a antenna tracker, on the remote end of the forwarded radio link I'm running a message logger (mwptools/samples/cliterm/msp-msg-test) to show the forwarded messages. Note this tool is currently only in the development branch.
Code:
./msp-msg-test -b 9600 /dev/ttyUSB0
where the /dev/ttyUSB endpoint is the remote side of the forwarded link.

In this log at the end of the forwarder chain, when not armed, I see forwarded MSP
Code:
2018-06-02T18:54:31+0100 MSP_CMDS_COMP_GPS 5 bytes
2018-06-02T18:54:31+0100 MSP_CMDS_ATTITUDE 6 bytes
2018-06-02T18:54:31+0100 MSP_CMDS_ALTITUDE 10 bytes
2018-06-02T18:54:31+0100 MSP_CMDS_INAV_STATUS 21 bytes
2018-06-02T18:54:32+0100 MSP_CMDS_NAV_STATUS 7 bytes
2018-06-02T18:54:32+0100 MSP_CMDS_RAW_GPS 18 bytes
2018-06-02T18:54:32+0100 MSP_CMDS_COMP_GPS 5 bytes
and when armed, LTM
Code:
2018-06-02T18:56:39+0100 MSP_CMDS_TG_FRAME 14 bytes
2018-06-02T18:56:39+0100 MSP_CMDS_TA_FRAME 6 bytes
2018-06-02T18:56:39+0100 MSP_CMDS_TS_FRAME 7 bytes
2018-06-02T18:56:40+0100 MSP_CMDS_TN_FRAME 6 bytes
2018-06-02T18:56:40+0100 MSP_CMDS_TA_FRAME 6 bytes
2018-06-02T18:56:40+0100 MSP_CMDS_TG_FRAME 14 bytes
2018-06-02T18:56:40+0100 MSP_CMDS_TA_FRAME 6 bytes
2018-06-02T18:56:40+0100 MSP_CMDS_TX_FRAME 6 bytes
2018-06-02T18:56:40+0100 MSP_CMDS_TS_FRAME 7 bytes
2018-06-02T18:56:40+0100 MSP_CMDS_TA_FRAME 6 bytes
2018-06-02T18:56:40+0100 MSP_CMDS_TG_FRAME 14 bytes
2018-06-02T18:56:40+0100 MSP_CMDS_TA_FRAME 6 bytes
2018-06-02T18:56:40+0100 MSP_CMDS_TS_FRAME 7 bytes
2018-06-02T18:56:40+0100 MSP_CMDS_TN_FRAME 6 bytes
If I set up iNav to use MAVLINK instead of LTM:
Code:
serial 0 257 115200 38400 115200 115200
Then in the logger I see when armed (for example)
Code:
2018-06-02T19:38:32+0100 MSP_CMDS_MAVLINK_MSG_ID_SYS_STATUS 31 bytes
2018-06-02T19:38:32+0100 MSP_CMDS_MAVLINK_MSG_RC_CHANNELS_RAW 22 bytes
2018-06-02T19:38:32+0100 MSP_CMDS_MAVLINK_MSG_GPS_RAW_INT 30 bytes
2018-06-02T19:38:32+0100 MSP_CMDS_MAVLINK_MSG_GPS_GLOBAL_INT 28 bytes
2018-06-02T19:38:32+0100 MSP_CMDS_MAVLINK_MSG_GPS_GLOBAL_ORIGIN 12 bytes
2018-06-02T19:38:33+0100 MSP_CMDS_MAVLINK_MSG_ATTITUDE 28 bytes
2018-06-02T19:38:33+0100 MSP_CMDS_MAVLINK_MSG_VFR_HUD 20 bytes
Note: Running live MALINK over 9600 (my forwarder radio) is not recommended, at some stage you'll get data loss / corruption), 19200 is the minimum for MAV.

Summary
So here we have mwp telemetry forwarding via four radio links:

UAV => 3DR <-> 3DR <=> BT <=> mwp => BT => HC-12 -> HC-12 -> USB -> msp-msg-test

And multiple baud rate transitions (115200 - 64000 - 115200 - 9600). There is suffiicent buffering and bandwidth to allow this to work.

Conclusions
  • Well documented setups make debugging easier
  • Using BT addresses rather than /dev/rfcommX masks BT baud rates (which are somewhat articifial anyway); however you still have to have the TTY side of the BT set correctly.
  • Forwarding works fine over multiple radio links and baud rate transitions
Jun 05, 2018, 02:23 AM
Registered User
I'm trying a new Bluetooth dongle, but can't get ubuntu to ask for a pin for my crossfire. so i connected to it with bluetoothctl, but when i try to connect in MWP i get permission denied needing to be part of UUCP or dialout groups. i've added both but still get the same error when i try to connect now.
if anything is there a way around the "should not run this as root" when trying to start mwp as a root user? i could probably get away with the permission denied error if i can run everything as root
Last edited by jbgrcfreak; Jun 07, 2018 at 05:58 PM.
Jun 08, 2018, 01:23 AM
sweet dreams & flying machines
stronnag's Avatar
Quote:
Originally Posted by jbgrcfreak
I'm trying a new Bluetooth dongle, but can't get ubuntu to ask for a pin for my crossfire. so i connected to it with bluetoothctl, but when i try to connect in MWP i get permission denied needing to be part of UUCP or dialout groups. i've added both but still get the same error when i try to connect now.
if anything is there a way around the "should not run this as root" when trying to start mwp as a root user? i could probably get away with the permission denied error if i can run everything as root
Code:
$ mwp --help
you may find there find the magic invocation you require.
Jun 11, 2018, 08:51 PM
Registered User
Three bluetooth dongles later- I've got tracking.
Jun 12, 2018, 04:00 PM
sweet dreams & flying machines
stronnag's Avatar

mwp news 2018-06-12


Couple of small changes:
  • The comms timeout resolution is changed from 500ms to 100ms (in order to better support faster telemetry radios). Note that in order to retain the default 1 second MSP poll timeout is is necessary to make a configuration change:
    Code:
    gsettings set org.mwptools.planner poll-timeout  900
    Otherwise the old default (500) will give 600ms timeout (which may not be noticeable).
    900 is the default for new installations.
  • GPS Statistics. There is a GPS Statistics widget that displays similar info to the configurator. This may be helpful in understanding 'Nav Unsafe' disarm status or failure to engage WP or RTH when there appears to be sufficient satellites (but in fact EPH/EPV exceed the CLI limit `inav_max_eph_epv`).
Jun 13, 2018, 09:04 PM
Registered User
Quote:
Originally Posted by stronnag
Couple of small changes:
  • The comms timeout resolution is changed from 500ms to 100ms (in order to better support faster telemetry radios). Note that in order to retain the default 1 second MSP poll timeout is is necessary to make a configuration change:
    Code:
    gsettings set org.mwptools.planner poll-timeout  900
    Otherwise the old default (500) will give 600ms timeout (which may not be noticeable).
    900 is the default for new installations.
  • GPS Statistics. There is a GPS Statistics widget that displays similar info to the configurator. This may be helpful in understanding 'Nav Unsafe' disarm status or failure to engage WP or RTH when there appears to be sufficient satellites (but in fact EPH/EPV exceed the CLI limit `inav_max_eph_epv`).
After entering the command "git pull && make && sudo make install"
I am encountering the following error using Linux Mint 18.3.
I believe I have all the dependencies installed as listed in ubuntu-deps.txt.
This would previously build with many warnings as documented but with no errors.


mwp.vala:4235.63-4235.63: error: syntax error, expected identifier
inav_max_eph_epv = (uint16)(*((float *)&ift));

Compilation failed: 1 error(s), 0 warning(s)
Makefile:52: recipe for target 'mwp' failed
make[1]: *** [mwp] Error 1
make[1]: Leaving directory '/home/mint/Github/mwptools/mwp'
Makefile:8: recipe for target 'mwp' failed
make: *** [mwp] Error 2
Last edited by mrcurtis2; Jun 13, 2018 at 09:25 PM. Reason: Add image of error
Jun 14, 2018, 01:34 AM
sweet dreams & flying machines
stronnag's Avatar
Quote:
Originally Posted by mrcurtis2
After entering the command "git pull && make && sudo make install"
I am encountering the following error using Linux Mint 18.3.
I believe I have all the dependencies installed as listed in ubuntu-deps.txt.
This would previously build with many warnings as documented but with no errors.


mwp.vala:4235.63-4235.63: error: syntax error, expected identifier
inav_max_eph_epv = (uint16)(*((float *)&ift));

Compilation failed: 1 error(s), 0 warning(s)
Makefile:52: recipe for target 'mwp' failed
make[1]: *** [mwp] Error 1
make[1]: Leaving directory '/home/mint/Github/mwptools/mwp'
Makefile:8: recipe for target 'mwp' failed
make: *** [mwp] Error 2
Damn it, I must stop assuming that Mint (and Ubuntu and friends) ship usable compilers. I'll fix it later today. Thanks for letting me know.

Should build again on older compilers. Time to up the minimum OS release level ....
Last edited by stronnag; Jun 14, 2018 at 11:53 AM.
Jun 14, 2018, 08:38 PM
Registered User
Quote:
Originally Posted by stronnag
Damn it, I must stop assuming that Mint (and Ubuntu and friends) ship usable compilers. I'll fix it later today. Thanks for letting me know.

Should build again on older compilers. Time to up the minimum OS release level ....
That did fix the problem I was having and builds as expected.
Thanks for the quick fix!
Jun 21, 2018, 06:10 PM
DroneBridge developer
seeul8er's Avatar

ESP32 modules for mwptools


Hi,

I have written a firmware for the popular and cheap ESP32 modules that supports mwptools out of the box. Compared to serial bridges and other firmware projects it parses the MSP/LTM stream and is able to forward it packet wise.

You can check it out here



It features a web interface that can be used to configure the software. Use it to upload & monitor missions or as a pure telemetry link downlink.
It can be set into transparent mode and therefore be used in combination with any other protocols like MAVLink etc.

It is out of the box compatible with the DroneBridge android app. The app can be used to monitor missions (mission creation is WIP)


BTW. Thanks for helping me out on the "timeout issue". I'll be testing it in the near future and report back on github.


Quick Reply
Message:
Thread Tools