ELRS not triggering RC Failsafe until its too late

I’ve recently had two quads run into an issue where the RC inputs go to a seemingly random flat value.

First quad: Log ELRS_Aug18.bin

Second quad: ELRS_Sept22.bin

In both cases this flat-lining of the RC values cause the arming switch to go to low causing the quads to disarm in the air. In both cases the RC failsafe was eventually recognised (Radio_late_Frame) but not before a planet got in the way of the descent.

Both drones were using RM Nomad/TX16s transmitters and Matek R24-D receivers. One was on ELRS 4.0 and the other on 4.0.1. Both drones had Matek H743-Wlite controllers run AC 4.6.3. RC failsafe was set to No-pulses on both. Both ran in “normal” (not Mavlink)

The first drone was a “fresh” build that a colleague was using for practice. The second was an existing build we use for training and had over 30 flights in this RC configuration in the last two weeks.

Does anyone have any ideas for what’s going on? Why did the RC signals flat line without a failsafe? Any suggestions for where to look for a fault?

In the mean time I’ll be disabling the arming switch in favour of rudder arming/disarm.

Edit: Might have just figured out my own problem: [4.0 Back Port] Separate FIFO locations for TX & RX on SX1280 by pkendall64 · Pull Request #3623 · ExpressLRS/ExpressLRS · GitHub

Wow, I feel really foolish right now - I really thought I had circled back to this post and reported the result on this. @Allister I’m fairly certain the PR you found is related to the issue as I faced exactly the same thing here Holybro X500 Crash and the PR you found was the end result of some testing that I and some others did along with of course the ELRS developers. I think we had sorted a lot of it via Discord, but I should’ve reported back on the other forum thread for others to find the solution too.

Some of the testing on that PR with Ardupilot is visible in the log screenshots here. Separate FIFO locations for TX & RX on SX1280 by pkendall64 · Pull Request #3620 · ExpressLRS/ExpressLRS · GitHub

So sorry again that I didn’t circle back and post the solution. Might’ve saved you from a crash. :confused:

I’m going to check my hardware. I thought at least one was already on 4.0.1, but I’m wondering if that was just the TX and the RX might still be 4.0.0. Either way, everything is getting upgraded to 4.1 tomorrow and we’ll see how it goes.

Luckily the second quad had minor damage and should live to fly another day. The first one… not so much.

Now I feel like a bit of a fool. I read that old post and I had completely forgot about that. Looks like exactly the same issue. Darn. I wish I remembered that and it might have saved me a bit of trouble. Can’t win 'em all I guess.

Out of curiosity, why use no pulses instead of using failsafe bit in CRSF?

Reading through this with fresh eyes - @Allister I noticed that you experienced the same behavior even though you were not in Mavlink mode, while in my case we were using Mavlink mode, and the PR seems specifically related to Mavlink mode. That being said, your logs look very similar to what I saw with what I was dealing with last spring in the other post. Hopefully ELRS v4.1 fixes things overall - I haven’t heard anything to the contrary.

Only options in the ELRS lua are Hold or no-pulses. Or am I missing something?

About 1h20m of flying, 10 take offs/power cycles. No faults. Every thing is now on 4.1.0 so hopefully that’s the trick.

Ah, I hope so too! Glad to hear it’s working for you now.

Oh, I thought any reasonable protocol would have information about fail state, but apparently CRSF doesn’t :clown_face:.