Passthrough telemetry over CRSF (crossfire)

Development Team
112

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

113

@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

image
image800×455 214 KB

114

@vierfuffzig thanks, it turned out quite well :+1:

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 :thinking:

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
115

@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.

116

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.

117

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

118

@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)

119

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

120

thanks a lot, will do asap.

121

Thank you very much for the explanations. I have to dig further.

122

thanks @vierfuffzig , that explains why you only get the warning and we do not enter failsafe, found the code here, should have looked better :slight_smile:

/*
  return true if throttle level is below throttle failsafe threshold
  or RC input is invalid
 */
bool Plane::rc_failsafe_active(void) const
{
    if (!rc_throttle_value_ok()) {
        return true;
    }
    if (millis() - failsafe.last_valid_rc_ms > 1000) {
        // we haven't had a valid RC frame for 1 seconds
        return true;
    }
    return false;
}
123

@yaapu tested latest code, basically the same behaviour as before. can’t wrap my head around the performance discrepancy on USART1 vs other UARTS

  • USART1: constant rate of 150 no matter what
  • other UARTs: basic rate of ~10 - 15, increasing to ~ 50 when USB connected (just plugged into PC, no active MAVLink connection). stalling to ~ 2 over time
  • intermittend No RC Receiver flags and unmotivated RMFD switching

my individual guess is that this is a melange of ardupilot UART handling and CRSF bandwidth saturation issues. without any profound insight, i don’t think we should lose valid RC Input for more than 200 ms unless intentionally choosing a low update rate.

two more points i noticed while testing:

  • the (dis-)armed panel consumes a noticeable amount of your insanely awesome map widget.

  • passthrough sensor_status_flags information is pretty verbose and cautious regarding severity level rating where the base-code is a bit more tolerant. i’ve noticed constant "CRT: Bad AHRS" flags, likely due to using_gps being flagged on my no-compass setup until EKF yaw gets aligned to GPS velocity vector. quite some effort has gone into avoiding the “Bad” label on an expected process. might be an option to use the “healthy” flag here instead.

124

Hi @vierfuffzig , one more version to test, this one should be much better, I relaxed a constraint that should not be necessary on full duplex link (discussed this with @andyp1per)
arduplane_matekf405wing_v2.zip (631.1 KB)

1 Like
125

did you actually arm the vehicle? that huge disarm dialog goes away ad only comes back on next disarm, it never bothered me but since it’s pretty big I can understand that could disturb :slight_smile:

Those “verbose” errors are there from the original authors of the library, it might be time to refresh them with updated messages

126

@yaapu yes, i did arm, honestly i expected the disarm panel to go away when armed, but it didn’t. i’m a try again, maybe i just was too impatient :wink:

will try new version asap, thanks for your constant effort on this!!!

127

@yaapu ok, the panel goes away when is_flying :+1:

1 Like
128

@yaapu aaaaaand MASSIVE improvement on last version!

  • USART1: packet rate ~ 160, no issues
  • UART3: packet rate ~60
  • no stalling
  • no change with USB connected
  • no relevant performance decrease compared to 160 frames on USART1
  • no more RC Input flags

on a sidenote DBG reports RFMD 2 though CRSF is in RFMD 1 (tested at distance with low output power / force telemetry mode)

awesome, thanks a lot!!!

129

finally good news, perhaps we have a version to fly :slight_smile:

mhmm, what does the widget display on the top bar RS:[rssi]/[rfmode] ??

130

crsf direct, ardupilot crsf and passthrough tlm (script link panel) report RFMD1, only DBG seems to always report RFMD2

…additionally, further testing revealed that the CRSF NanoRXes signal pins are not 5V-tolerant :boom:

131

ok @vierfuffzig , I’ll try to reproduce it