breadoven

Having said that surely if it's writing to eeprom it shouldn't be doing anything else should it, like try to process Rx signals ? @stronnag ?

Failsafe is suspended during eeprom save so it doesn't trigger when the Rx is suspended. The fact that Failsafe behaves erratically during this problem might indicate there is an issue...

Seems the Rx suspend during eeprom write is to do with https://github.com/iNavFlight/inav/commit/3a13edfdad83fb3eaeada195654fbadbe5acb495.

@vlamgat007 Can you try the attached firmware. It's the current master with Rx suspend time increased to 3 seconds. You'll need to use the latest 6.0 Configurator which can be...

@vlamgat007 Just remember the 6.0 firmware is dev standard so could have issues, not that I've had any problems. Other FC boards are fine on 5.1.0 if they work OK....

> @breadoven maybe because when disarming, the actual eeprom write is done first before the actual disarm happens. So all radio inputs are still expected to be valid during that...

Only thing I'd say about this is it's obviously more important to avoid false landing detection than failed landing detection, especially on multirotors. So this may improve landing detection reliability...

The `averageAbsGyroRates ` was a pretty basic method of checking for movement so anything that improves on it is welcome especially if it doesn't work for some multirotors. It worked...

The problem with this is it's all about detection safety margins which are currently set on the conservative side to avoid false detection. I've just tested the current detection but...

> @Jetrell Can you test this new commit? @JulioCesarMatias I'm not really sure why you decided to make all these changes which I assume you haven't tested because it's obvious...