vierfuffzig@DESKTOP-GNQDSSL:~$ mavproxy.py --master=udp:0.0.0.0:14550
Connect udp:0.0.0.0:14550 source_system=255
Log Directory:
Telemetry log: mav.tlog
Waiting for heartbeat from 0.0.0.0:14550
MAV> online system 1
ARMED
Mode(0x000000c0)> Mode Mode(0x000000c0)
Arming checks disabled
module load console
Mode(0x000000c0)> Loaded module console
link 1 OK (56 packets, 1055 bytes, 0.00s delay, 30 lost, 53.6% loss, rate:33B/s)
Great youâve got it working!
âŚand you can ignore those numbers, they are just debug info that will be removed from release versions!
1 Like
Doesnât look very promising
i had expected WSL vs windows network issues and / or inherent crsf connection issues, so i actually went to bed pretty happily. i might be biased because i had a great day of flying yesterday.
thereâs a link, thereâs a set of messages, itâs just some values missingâŚ
1 Like
I can reproduce your experience now - it was the MAVLink setting getting dropped that had me confused. It looks like we get an initial message of the right types but after that only the GPS gets updated.
@andyp1per reading the CRSF manual more clesely i do come to the conclusion that GPS data only when using MAVLink emulation might be intended behaviour actually:
this would mean itâs not my individual intellectual shortcomings that keep me from getting attitude messages over MAVemu, which is great news for me again, a little less delightful with regard to our functional expectations thoughâŚ
Iâm a little bit irritated⌠what exactly is the sense in emulating Mavlink from csfr, when a full mavlink telemetry is available? Do I miss the point?
@fingadar it was OT actually, sorry for that, just checking which of the crossfireâs features work to what extend. afaik on the microTx, the full MAVLink option just doesnât work sufficiently well right now.
I updated all released files to test version 0.7:
release notes:
- Horus widget updated to show TX ppower
- CRSF native telemetry always enabled
- CRSF custom telemetry uses frame ID 0x7F as suggested by TBS
- CRSF custom telemetry in RF mode 1 uses a single big frame every couple seconds to pack all passthrough frames as an array. This leaves enough bandwidth for native CRSF telemetry, status text messages and passtrough, the only side effect is the artificial horizon is unusable while in RF mode 1 but everything else is updated every 3 seconds on average.
Rates in RF Mode 2:
- native GPS 3Hz
- native BATTERY 1Hz
- native ATTITUDE 1Hz
- native FLIGHT_MODE 0.5Hz
- native HEARTBEAT 0.2Hz
- custom STATUSTEXT 2Hz
- custom PASSTHROUGH 20 Hz
Rates in RF mode 1:
- native GPS 1Hz
- native BATTERY 1Hz
- native ATTITUDE 1Hz
- native FLIGHT_MODE 0.5Hz
- native HEARTBEAT 0.2Hz
- custom STATUS_TEXT 0.5Hz
- custom PASSTHROUGH 0.5Hz (1 frame with all passthrough packets as an array)
Downloading and testing (latest is version 0.7)
2 Likes
I got it working on the full size TX - looks great!
A few small issues I noticed:
- If you have not set RC_OPTIONS then the widget says there is no telemetry/no GPS in big flashing letters even though there is clearly GPS telemetry visible on the widget
- I get periodic âswitched to RF mode 2â messages even though I am sitting right next to the RX. Maybe there is something glitchy there
- Losing the RC connection takes a few seconds to register - Iâm surprised there is not a more direct way to tell since the TX already knows as soon as you unplug
Hi Andy, thanks for testing.
I noticed a periodic bouncing between mode 1 and 2 even without my patches but as soon as I put some distance between tx and rx the bouncing stops (my patches simply added the mode switch detection code to ardupilot)
The widget expects custom telemetry data i.e. passthrough telemetry data pushed from opentx to lua, so if you do not enable rc_options bit 8 the widget has no way to tell custom telemetry is enabled.
GPS is pushed as a regular sensor so having GPS data is not enough to tell telemetry is working because sensor data is cached and I can read it from lua even when telemetry is off.
Open to ideas here, the problem is I can send a passthrough packet every couple seconds only while in mode 1.
As for the last point, I need to double check, my widget uses opentx and I might be tied to a built in 2 seconds timeout for telemetry data, telemetry and RC have different timeouts in OpenTX
@yaapu thanks for keeping up your great work! first of all: that map widget is insanely awesome.
test results (MicroTXV2, NanoRX @4.05, Radiomaster TX16S, MatekF405-Wing):
- working great when using USART1 on both RFMD2 and 1
- stallig in RFMD2 when using any other UART, working with expected latency when forcing RFMD1 though
- occasional messages about RFMD switches to 2 when itâs already in 2 (INF)
- occasional No RC Receiver messages (CRT) while control uplink is doing fine
@vierfuffzig thanks, it turned out quite well 
I really donât understand whatâs going on with UART performance.
With GPS @230k baud + crsf @400k baud + mavlink on USB I can see a slowdown of the telemetry rate, I canât stall it myself, but if I disconnect USB it gets better and improves by disconnecting GPS and this on master as well, my code adds some delay when I enable custom telemetry but the expected performance should be like what you get on UART1, what I mean is that the issue was there before my patches no idea why we didnât spot it before 
Unexplained RFMD switches from mode 2 to mode 2 Iâm inclined to think they were detected but you didnât get the message via CRSF telemetry for some reason (we only have a 5 message buffer), if you have a tlog of the flight I bet they are there.
Occasional No RC Receiver reported via my widget is a text conversion of the MAV_SYS_STATUS_SENSOR bitmask that the telemetry library checks before sending each telemetry frame (so around 20Hz), if one of the status bits is triggered is it rendered as a specific status text message but only by the telemetry library, no mavlink message is ever created and thatâs the reason why you only see this messages while using my widget, the code is here so again youâve always had this events, my guess is they went undetected because your ground station did not render the SYS_STATUS error bitmask mavlink message.
1 Like
@yaapu thanks a lot for that comprehensive explanation. canât fully wrap my head around that sensor flag yet to be honest, some more reading might help.
Short update:
Got the latest version V07 working on omnibusF4Pro with Frsky xLite (on the bench).
More tests to do.
@vierfuffzig Can remember the appearance of the odd âno RC receiverâ messages as wel when I switched from Plane3.9.9stable to Plane4.0.5stable using the Frsky Passthrough. Maybe itâs related to the scheduler change mentioned by Alex above. From my (limited) understanding the newer PT scheduler was merged in between 3.9.9 and 4.0.5.
Hi Sasha,
I wrote the new passthrough scheduler to better handle frsky telemetry, it has nothing to do with RC code, all it does is a better allocation of the telemetry bandwidth, in fact you can get a No RC Receiver even if you disconnect sport.
I saw âNo RC receiverâ on arduplane without triggering failsafe which is odd since from what I can tell thereâs no grace period in plane for no rc signal, but I might be wrong
@vierfuffzig can you check if you can still stall telemetry with this version, it should have a faster telemetry response arduplane_matekf405wing.zip (631.1 KB)
if i read plane handling correctly we get that flag set when no valid RC for > 200 MS, but failsafe wonât kick in until > 1000 MS
thanks a lot, will do asap.
Thank you very much for the explanations. I have to dig further.