Hi everyone - looking for some help on log analysis for a Holybro X500 frame build. I teach a university course where the students have built these and are now in the second semester of flying them. A student was flying the other day and from their secondhand account ( I wasn’t present ) they had some kind of RC failsafe and the aircraft fell from the sky, causing some broken parts. When I looked at the log, the simplest solution would be that to say that they accidentally disarmed the aircraft - RC5_OPTION =153 for use with ELRS. But because some radio failsafe concerns even before the crash happened, I’m not sure that it was a simple mid-air accidental disarm. The student also doesn’t think they did that, but memory can be fickle, especially in stressful scenarios. I thought I’d upload the log here and see if any forum members with more log analysis experience than me could see anything else going on in the log. The RSSI.RXRSSI parameter in the log seems to correspond with the failsafes, but I don’t have much experience with this particular parameter. Any help would be greatly appreciated! Thank you!
You don’t actually need to assign the autopilot arm/disarm function for ExpressLRS to work properly. Ch5 simply has to go high during flight. It can remain an unassigned channel as far as ArduPilot goes.
Alternatively, you can use the Arm/Emergency Stop function (165) that could be recoverable in a situation like this vs complete disarm.
In ExpressLRS 4+, you can even just use a switch (with no channel assigned at all) for transmitter arming alone and keep Ch5 for something else.
Thanks for taking a look, @Yuri_Rage and @dkemxr! I appreciate you lending your expertise here.
And thanks for the tips about Ch5 and ELRS, @Yuri_Rage . I plan to swap my gear over to ELRS4.0 after this semester ends and get more familiar with the new features. I’ve looked briefly at the Arm/Emergency Stop (165) function before, but not in depth. If we were to assign that(165) to a switch, would Disarm typically still remain on rudder/yaw axis (as long as that was still enabled)?
I use Arm/E-stop on all of my drones now. It will disarm after a few seconds on the ground with the e-stop engaged. You can still use rudder disarm if you want (but I don’t bother)
I have done this by mistake too, ‘phat fingers’. It’s better to use the "full down throttle to the right” arm/disarm then a switch as your less likely to hit it by mistake or a switch sequence in the radio.
Consider the FS throttle action too. “Always Land” could get you in trouble depending on where it is. Default “Always RTL” may be safer but that depends on the situation.
Sorry to revive this thread, but I am looking for some more advice on another crash of this same aircraft in a similar situation. (Log - X500_Crash_Log_2.bin) They still have Arm/Disarm on a switch (I know, I know, we should change that ), but I think? we may have something deeper here, as I realized this crash log and the initial post as well both actually have RC5 as well as RC8 (flight modes) go to extremely low values, 881us, very near the failsafe event.
The student is using an EdgeTX Radiomaster Boxer, which typically have a range of about 988 to 2011 or so on the gimbals, and they don’t believe they flipped both or either of those switches when this second crash occurred. They also have the unusual to me “Radio Failsafe - Disarming” message in the logs, which when I went poking around on the forums, actually found one of my own old posts Radio Failsafe - Disarming - Crash
This part of that old post seems especially relevant -
Of course we’ll do some in depth testing of the TX and RX and try to see what’s happening there, but my deeper question is - how/why would the TX/RX send those channels so low on a failsafe, specifically in this case (ELRS Mavlink)? I thought that the failsafe for this setup would just be “no pulses”?
This setup is using ELRS Mavlink v4.0. I don’t know of any way to set a failsafe value per channel when using ELRS in general, besides on their PWM receivers, which is not the receiver type that’s in use here. Are we possibly dealing with just a plain old “bad hardware” issue? Replace the RX?
Thanks for humoring me on trying to sort this out a bit more.
Yes, you should.
A few input channels went low including the arm/disarm channel. Arm/disarm (CH5), OptFlow Cal (CH6) and Flight Mode (CH8) all dropped at the same time.
The Radio FS was after the fact when it hit the ground.
It’s kinda sad, but my first reaction is “yeah, they hit the switch”. But in this case I’m pretty confident they didn’t. Too many things moved at once to fixed values that just aren’t realistic with manual inputs. So the students got bit by something else.
I just looked at one of my ELRS 4.0 setups and the only options are No Pulses or Hold Values. I didn’t dig further into the menu to see if I had selected Hold Values would I be able to set the values. It’s in the RX menu in the ELRS lua so it’s a quick thing to check on that quad in case somebody was clicking around.
My other thought would be to look at what packet rates are set on this hardware. You mentioned a RM Boxer. That is still using the “older” chipset and with Mavlink you can’t access some of the more data-friendly modes that the newer LR1121 chips can. When I first tried ELRS Mavlink on version 3.x I would get failsafes at really close distances. It was one of the reasons I stopped using it. (I haven’t had any on 4.0, but I’m also using LR1121 chips).
2026-04-04 15:11:28.402 Error: Subsys RADIO ECode RADIO_LATE_FRAME
2026-04-04 15:11:28.402 Error: Subsys FAILSAFE_RADIO ECode FAILSAFE_OCCURRED
2026-04-04 15:11:28.402 Radio Failsafe - Disarming
It looks to me like the radio system lost a packet and sent a false RC5 low signal, and the flight mode change. The radio failsafe data is after the drone has fallen and could be crash related.
My suggestions:
Switch to rudder arming.
If the radio is on latest EdgeTX then set a channel (or leave 5) to default to a high value so ELRS think’s it’s armed all the time. But don’t do anything in Ardupilot with this channel.
Experiment with different packet rates and antenna placements to see if these failsafes can be minimized.
I will definitely dig in to the TX/RX setup the student is using when I next see them and see if we can observe/reproduce any of this on the bench.
As a side note, how are each of you determining the time of impact? I’m looking at the Baro.Alt along with the VIBE graphs - is there a more precise/exact way?
@Allister I had no idea MavExplorer would give more messages/details than I can see in plot.ardupilot.org. I will be learning this tool and using it much more from now on. None of those RADIO_LATE_FRAME and other messages are present when I review the log in plot.ardupilot.org unless I’m missing some kind of setting. I only see the Radio Failsafe - Disarming, is all.
I believe the student is using 333Hz full packet rate, as that’s what I typically recommend and what I’ve been using on my 2.4Ghz ELRS Mavlink setups for at least a year or so now (all the older non-LR1121 chips) - I can’t recall ever having any issues with my setup, especially nothing like this, but I have yet to try ELRS 4.0 Mavlink in flight.
I’ll post here with what we find out - thanks again for the help!
I was more concerned with the time the motors stopped. The one thing to keep in mind here is things are happening so fast that some data might be delayed by the speed of the data logging. So I tried (sometimes not very well) to cross reference things.
With ELRS I found it’s not really a radio failsafe, as lost packets. Mavlink doesn’t like that at all. Thats why the new packet rates put so much effort into preventing that. Maybe try D500. or D250. See if those behave any better.
I don’t use the web log viewer. Tried it a few times, but just never got the work flow. MavExplorer just seemed to be user hostile enough that I felt compelled to push through. I’m a bit of a sucker that way.
Today we were trying some more flights and unfortunately I had a different student with a nearly identical build have his quad fall right out of the air in front of me. He has never had this kind of issue with the quad before. He didn’t disarm midair from what he told me/I observed, but unfortunately it looks like the log is missing data. However, the same error codes appear in his log as the other, in this case multiple times. The students have different receivers, but are both using ELRS Mavlink and have the same flight controllers, as well as very similar overall builds, other than probably having different peripherals attached to different serial ports.
I’m at a loss here as to what’s going on. Besides bad hardware, is there any other idea why these RADIO_LATE_FRAME messages occur? Because I have had this happen I think 3 times now, it seems somewhat reproducible? We also have Dronebridge onboard these aircraft and it was connected to a secondary GCS today, as well as the student’s ELRS Mavlink being connected to his own laptop GCS via Wifi. I’m wondering if there is something going on with Dronebridge that is interfering with the RC_OVERRIDE messages that the ELRS receiver normally sends to the FC in ELRS Mavlink mode?
Yes, I did notice that. I understand that there are better ways to arm/disarm, but I’m really trying to see if I can get to the bottom of why the channels are doing this in the first place. I’ve had many flights with ELRS Mavlink prior to this and never experienced this issue before.
), but I think? we may have something deeper here, as I realized this crash log and the initial post as well both actually have RC5 as well as RC8 (flight modes) go to extremely low values, 881us, very near the failsafe event.
