Have you ever found your model to be disarmed after coming back from a failsafe? If so, you could have been a victim of a failsafe disarm bug. This glitch is not an INAV bug. It is caused by the receiver flagging that the failsafe is over before all channel data has been reestablished.
So what happens with the failsafe disarm bug?
We’ve called this the failsafe disarm bug, but it actually is more than that. When this glitch occurs, half of the RC channels are output at 988μs. The other half are at the correct values output by the transmitter. The values stay incorrect, on average for 80ms.
In the image below, you can see the glitch happening. The failsafe method on this receiver is set to No Pulses. This can happen using Hold also.
- The top row (3075) shows the receiver in the failsafe state, sending out the no pulses values and the failsafe bit to the flight controller.
- Rows 3076 to 3083 show the 80ms when the glitch is occurring (with a blue background). The channels are 0 indexed, this means channel 1 is listed as RC0. Channels 1, 2, 3, 7, 8, 11, 13, and 14 are behaving correctly. But, channels 4, 5, 6, 9, 10, 12, 15, and 16 are glitching, remaining at 988μs.
- Rows 3084 & 3085 show the channels now outputting the correct values.
The problem is that rather than wait for the other channels to recover. The receiver tells the flight controller that the failsafe is over on line 3076 in this example. This causes the flight controller to use the channel values sent by the receiver; half of these being potentially incorrect at 988μs.
Don’t worry about the RSSI not starting to come back until line 3084. There is also a delay when the connection is lost. With this particular failsafe, RSSI started dropping 650ms before the channels lost their values. The flight controller is using the channel data from line 3076.
What does this mean for me?
This means that when your receiver recovers from a failsafe, you may experience a shift in channels. People first noticed this because they would come back from failsafe disarmed. But other symptoms could be that you notice the OSD flick between different presets, the model may twitch.
Other than arming, the next big problem could be if you fly waypoint missions disconnected from your transmitter. When you reestablish the RC link, the glitch could occur and knock you out of the waypoint mission and in to acro! So it is probably a good idea to either not do these missions, or when the model goes out of range, switch off your transmitter until you have a clear video. When you switch it back on, expect to have to fly it home. If you don’t and the mission continues, you have been lucky this time.
Check out a video of the issue and a method of stopping the disarms
We have a couple of videos to explain this issue. Darren’s video also shows a workaround, to ensure that you will not disarm in flight. This workaround will not eliminate the bug, so you may see glitches in other channels and on other switches. But, you will stay armed.
Darren Lines (Mr.D – RC) has a video explaining the issue in English.
Marc Hoffmann (B14ckyy) has a video explaining the problem in German.
Who does this affect?
At this point in time, we have only seen this on FrSky receivers. However, we would imagine that it will also affect clones, like the Jumper D16 based receivers. There is a chance that this could also affect Futaba FASST receivers, as this bug could be a part of SBUS or ACCST/ACCESS. If anyone has experienced this with Futaba, or could test this. Please get in contact.
This bug has occurred on every FrSky receiver tested so far. It has happened on ACCST v1, ACCST v2, and ACCESS transmission protocols, and with SBUS and F.Port protocols. This will also still happen if your failsafe method is set to No Pulses or Hold. Hold is slightly safer at this time. But when the glitch occurs, it will still drag the affected channels down to 988μs on Hold.
Is my Crossfire system safe from the failsafe bug?
Yes. This issue does not affect Crossfire.
So what is going to happen?
Firstly, we are in contact with FrSky, to show them the issue. Hopefully there will be a fix released so that everyone is safe. No matter what flight controller they are using.
The INAV developers are also implementing a workaround so that INAV will be safe from the glitch. That is scheduled to be part of the 2.6 release.
What do I need to do?
At the moment, there are only things we can recommend to do:
- Follow the instructions in Darren’s failsafe disarm bug video to make your arm switch safe. Don’t worry, it doesn’t matter if you arm towards yourself or away. There is an OpenTX workaround for both arming directions. As we explained earlier, the glitch still occurs, so you may notice OSDs flickering or modes briefly changing.
- Don’t fly to the limits of your range. If you don’t failsafe, this bug does not happen. So the absolute safest thing you can do until 2.6 is released is not push your range. Keep an eye of your RSSI or LQ, and keep within a safe level.
After that, there is little you can do until:
- Firstly, INAV 2.6 is released. Once the stable release is available, it would be worth updating. After that, you will have no issues due to this bug.
- Secondly, if and when FrSky release an update to fix this issue, update your firmware on your transmitter module and receivers. This will ensure that the bug will not affect you on other flight controllers.
Remember that we are here to help, and we have a great community of INAV pilots over at the INAV Fixed Wing Group on Facebook. Head over there for INAV discussions, tips, and advice.