MWP --forward-to second bluetooth device appears in-op TBS Crossfire source, GhettoStation receiver. #35
Comments
|
mwp doesn't forward MAVLINK (but MSP and LTM). It could do; due to the way that mwp does forwarding (it rewrites each message) it will need a bit of thought,but it's easily doable. I'll have a look at the MAVLink that Ghettostation consumes, and see what would be useful to forward. 2 CRCs / second is more that I'd expect, but not catastrophic. Leave it with me. |
|
And mwp doesn't know about MAVlink message 147, and MAVlink has a specific CRC seed for each message;so it's not surprising that it errors each 147. So really the error rate is acceptably low. I'll sort that out too. Any chance you can capture a stream of mavlink off the CRSF to see exactly that it's outputting ? |
|
Hex dump. CRSF BT set to MAVemu. GPS not receiving signal. 0000000 7f17 09fe 3389 6d44 0000 0000 a1b6 0002 |
|
Perfect, thanks. |
|
As of now there's a test branch with (mwpid 1.036.603, commit bcdcbab) that works if you use /dev/rfcommX. Damn, I need to pay attention when you tell me stuff doesn't work, you can't currently use BT addresses. Now, here I have /dev/rfcomm2 is bridged to a HC-12 radio Computer 2 has a USB connected HC-12 radio. Same picture on both computers, via four radios. |
|
Forwarding to a BT address is now disabled; device nodes (/dev/rfcommX) work OK. In order to forward Mavlink, it is necesary to set the forward key to either 'all' or 'minMav' (currently synonymous) I'm not convinced that 9600 is fast enough for Mavlink; I see data loss / backlog on the final screen in the above chain (the 3DR is 19200, the HC-12 is 9600), whereas with a faster forward link, the two screens update simultaneously (this is using iNav's Mavlink telemetry as the source). Also, in your sample, there is > 15% data loss whereas at 19200 I got just one CRC error in more than an hour's testing. From your sample: |
|
merged into development ... so you should use that |
|
Stronnag - Thanks for this. I have to pause testing the GhettoStation setup because I seem to have trashed yet another HC05 serial bluetooth device. Another pile is on order. I did manage to get output transferred to my second computer before the HC05 died. Those devices are so finicky. |
|
I found my old stash of HC05s. I really need to clean up my shop. I verified that I am indeed getting connectivity via the --forward-to. BT baud rate set at 19200 and used --forward-to /dev/rfcommx@19200 switch. Set gsettings org.mwptools.planner forward all. Ghettostation TM input rate set at 19200. Tried all applicable protocols, multiwii, lighttelemetry and mavlink. No joy on connecting. Same setup was previously working when receiving LTM data via 3DR radio. Looks like either the "MAVEmu" data packets aren't quite Mavlink or something is happening in the MWP forwarding? |
|
Please try the latest development commit. A few improvement, including BT forwarding working with BT addresses as well as /dev/rfcommX device nodes, tolerance of the forward device failing / not keeping up and retrying opening the forwarding device if it fails. btw: your earlier note that using a BT address for forwarding caused mwp to lock up or slow down was most likely a symptom of the the link being too slow and blocking everything, which is now fixed. If you're still having problems with 1.037.686 (023080b) or later, please post the mwp console output here. |
|
Also, as of 1.037.686 (023080b), gsettings forward 'minMav' only sends the mavlink understood by ghetto-station, while 'all' will forward everything. |
|
'minMAV' did the trick. Works like a champ. In summary - ground station running a tinkerboard w/tinker OS. Receives telemetry data from short range bridge (fancy term for bluetooth) on the TBS Crossfire. TBS Crossfire is configured to output MAVemu data. This is on /dev/rfcomm0. BT baud rate is set to 19200. Ghettostation antenna with HC05 BT adapter is connected to the groundstation via /dev/rfcomm1. mwp --forward-to /dev/rfcomm2 command line. As long as I have Crossfire connectivity, I have valid gps position data being fed to the tracker. Recommend close. Thanks Stronnag! |
|
closing, as the specific dev branch is now merged into master |
Data Source - Taranis 9XD with Crossfire transmitter. Bluetooth device on CRSF is set to MAVEmu. MWP ground station is connected to CRSF via bluetooth device (/dev/rfcomm0). MWP receives and interprets the mavlink data perfectly. "Forward-To" appears to connect to GhettoStation BT device (/dev/rfcomm1) OK, but it appears that no data is forwarded. BT device was checked outside of the data-loop for proper serial link via serial monitor using "echo and cat." BT link is 9600 baud. Multiple baud rates and settings were attempted via changes to the BT device (HC-05). Tried gsettings set org.mwptools.planner forward "minLTM." When run, logging similar to the following is output. Again, MWP receives and processes the info OK.
2018-02-04T16:55:32-0500 Connected /dev/rfcomm0
2018-02-04T16:55:32-0500 set forwarder /dev/rfcomm1
2018-02-04T16:55:32-0500 LTM/Mavlink mode
2018-02-04T16:55:32-0500 Comm error count 5
2018-02-04T16:55:32-0500 MAVCRC Fail, got b58a != 8121 [1 c8] (cmd=147, len=36)
2018-02-04T16:55:32-0500 init icon 0
2018-02-04T16:55:32-0500 Armed 0
2018-02-04T16:55:32-0500 Using espeak for speech
2018-02-04T16:55:32-0500 Comm error count 6
2018-02-04T16:55:32-0500 MAVCRC Fail, got 5709 != eced [33 44] (cmd=109, len=9)
2018-02-04T16:55:32-0500 Comm error count 7
2018-02-04T16:55:32-0500 MAVCRC Fail, got 985e != acf5 [1 c8] (cmd=147, len=36)
2018-02-04T16:55:33-0500 Comm error count 8
2018-02-04T16:55:33-0500 MAVCRC Fail, got be62 != 8ac9 [1 c8] (cmd=147, len=36)
2018-02-04T16:55:34-0500 Comm error count 9
2018-02-04T16:55:34-0500 MAVCRC Fail, got 38de != c75 [1 c8] (cmd=147, len=36)
2018-02-04T16:55:34-0500 Comm error count 10
2018-02-04T16:55:34-0500 MAVCRC Fail, got 3511 != 1ba [1 c8] (cmd=147, len=36)
2018-02-04T16:55:35-0500 Comm error count 11
2018-02-04T16:55:35-0500
The text was updated successfully, but these errors were encountered: