4.1.2 RTL disarm in the air

I just upgraded to 4.1.2 on a PixHawk mini clone. I see in the logs that just after takeoff there were many messages about radio failsafe, I’ve now just seen the reports on here about the bug in radio detection on these boards, which Tridge has now fixed in 4.1.3-rc2.

Anyway, because of the radio failsafe the copter went into RTL. But it disarmed pretty much right where where it was, about 2m off the ground. I’ve flown this copter a lot on previous firmwares (mostly 4.1 beta) and it’s never had a problem with landing detection before.

2021-12-23 12:28:41.365 Radio Failsafe
2021-12-23 12:28:42.375 Error: Subsys FAILSAFE_RADIO ECode 0 
2021-12-23 12:28:42.375 Radio Failsafe Cleared
2021-12-23 12:28:42.657 Event: DATA_DISARMED
2021-12-23 12:28:42.657 Event: DATA_LAND_COMPLETE
2021-12-23 12:28:42.657 Event: DATA_LAND_COMPLETE_MAYBE
2021-12-23 12:28:42.659 Event: DATA_MOTORS_INTERLOCK_DISABLED
2021-12-23 12:28:42.924 Error: Subsys RADIO ECode 2 
2021-12-23 12:28:42.924 Error: Subsys FAILSAFE_RADIO ECode 1 
2021-12-23 12:28:42.924 Radio Failsafe - Disarming

Full log (700kB):

Best regards.

Your situation is similar to what he described.https://discuss.ardupilot.org/t/motor-shutdown-in-air/79743/5

@Qiotek dont believe that’s related, it was on a traditional helicopter and had collective set up in a way that it thought was idle.
@tridge is this related to the mini pixhawk rc in?

No, they are similar. They all appear (Landing_gear_deployed land_ complete land_ complete_ maybe) in the log then throttle turned off in the air. @geofrancis

1 Like

what is really strange is that he had control when it was getting radio failsafe errors, the channels didnt flatline stop like I would expect during a proper radio failsafe they look like connection was getting lost and regained about once a second. that being said it should still not have disarmed before it was on the ground and unfortunately there isnt a way to override and hold it out of RTL.


That may be. But in this case, the aircraft disarmed in flight before land complete. In fact, it declared land complete because it was disarmed.

The in flight motor shutdown for the heli was different. Due to the collective being lower than H_COL_MID, the autopilot thought it was landed and that cause the land_complete flag to be set which then initiated the automated shutdown process.

These two cases are not related.


sorry to say it shows the machine disarmed using the disarm switch on channel 7.
My guess is that because it was rapidly going in and out of failsafe so fast that you never got control back for long enough to make it move. I think If you had manually set the flightmode to rtl it would have probably landed on its own since it wouldnt be trying to change between modes. But the reason the motors stopped was the arm/disarm switch being switched quickly off and back on again.


RCx_OPTION 41 could be renamed “Rapid Return To Earth” Mode. I use it on my Rover…

As @geofrancis says, this log shows the disarm was caused by the arming switch on channel 7 going low:

This is not at all related to the issue seen on heli
You can tell what caused a disarm using the ARM message:
2021-12-23 12:28:42.657 ARM {TimeUS : 72017808, ArmState : 0, ArmChecks : 0, Forced : 0, Method : 2}

in this case it has Method 2, which you can lookup here:

that shows method 2 is AUXSWITCH, which is disarm using a user controlled switch.

@tridge what are the radio error number codes? I can’t find where they are listed?

in this log we see:
2021-12-23 12:28:54.395 Error: Subsys RADIO ECode 2

that is RADIO_LATE_FRAME, from here:

that happens when we haven’t received valid RC input for 0.5s (FS_RADIO_TIMEOUT_MS is 500)

1 Like

@Brodo what RC receiver are you using?

@tridge yes but if you look at the rc channels it doesn’t look like they ever actually stopped moving. it went into failsafe 6 or 7 times in 10 seconds. radio issues?

Hi all. Thanks for looking into this. Sorry I have been offline for the last 1.5 weeks. Happy new year to you all.

Yes it was odd, I did have partial control, initially I was still trying to convince it to climb and trying to figure out what was going on, before the crash.

@geofrancis It is a Futaba R6202SBW receiver.

@tridge Regarding me hitting the disarm switch… I don’t think I did this (I know, that’s what they all say, right!). The only thing I can offer by way of evidence is that there are step changes in the RC3 throttle input which are exactly coincident with the RC7 transitioning low and also back high again. My RC7 and RC3 are both operated by the same hand and I am not quick enough to release the throttle and toggle the switch in one time quantum nor back the other way a second later. Perhaps garbage SBUS frames were somehow admitted during all the shaninigans?

In any case this copter is now running 4.1.3.


I had the same problem with Futaba 6202SB receiver on an APM and a pixhawk. Changing to futaba 7008SB as well as to Frsky TFR4SB solved the problem. Must be an issue with that receiver.



ArduCopter 4.1.4 has support for non-standard SBUS timing that might fix this issue
It should allow you to even use non standard compliant receivers.