* RX task update rate to 22Hz, to improve 25Hz link stability
* modified Rx code
* add LQ to debug
* use max of frameAge or FrameDelta
* Require a dropouit of 200ms, not 100ms, before RXLOSS
* remove FrameAge, use 150ms timeout 50ms checks
* fix tests and tidy up the comments
* Handle NULL input as before, log frame time
* possible solutions to review comment about names
* Remove rxFrameTimeUs
- prepare for direct use of lastRcFrameTimeUs
- refactor rx_spi callback
* remove global currentRxRateHz
* simplify updateRcRefreshRate
* re-name to recheck interval, return frame time debug
* Calculate RxRate only once
* use rxReceivingSignal for consistency
* use signalReceived not rxDataReceived for consistency
* suggestions from review PL
* move defines, thanks K
* fixes from review, thanks MH
* review changes, undo task interval change
rename bool rxIsReceivingSignal to isRxReceivingSignal
thanks Steve for resolving that tasks changes are not needed
thanks PL for your feedback also
---------
Co-authored-by: Petr Ledvina <ledvinap@hp124.ekotip.cz>
Simpler GPS Rescue fix
100ms interval for signalReceived failure
Faster failsafe stick response
Update and confirm unit tests work correctly
Restore invalid flight channel ability to trigger failsafe with individual timers
Set default failsafe stage 1 delay to 1.5 seconds, approximately match previous delay of 1.6s when the user selected 1.0 seconds.
Update failsafe documentation for 4.3
Arming blocked soon after Rx initialisation
Unit test fix for previous commit
Editorial changes and typo fixes
Previously the task was always enabled and there's no reason for it to be running if there are no boxID associations.
Saves a few cycles by not running. But has a bigger effect on the scheduler by minimizing the number of active tasks when possible.
On bootup aux channels start out at default and allow sticky modes right away,
although they should only be allowed once they are actually not active.
_Legal disclaimer: I am making my contributions/submissions to this project solely in my personal capacity and am not conveying any rights to any intellectual property of any third parties._
The `failsafe_kill_switch` parameter has been renamed to
`failsafe_switch_mode` and it determines what happens
when the Failsafe mode is activated with an AUX switch.
It takes one of three values:
0 - simulates RC signal loss - thus activates Stage1 failsafe
(former behavior when kill switch option was OFF)
1 - disarms immediately
(former behavior when kill switch option was ON)
2 - activates the failsafe procedure (Stage2) immediately (new)
- Added failsafe flightmode and rc control box.
To make failsafe procedure a separate flight mode and make it possible
to trigger failsafe with an AUX switch.
- Failsafe mode is activated when failsafe is active.
RC link lost is simulated with the failsafe AUX switch.
When NOT armed: failsafe switch to failsafe mode is shown in GUI (mode
tab).
- Activate failsafe mode with AUX switch.
- Prevent arming when failsafe via AUX switch is active (safety issue).
- Make failsafe disarm if motors armed and throttle was LOW (2D & 3D)
for `failsafe_throttle_low_delay` time (__JustDisarmEvent__).
Applied code changes to effectively add pull request: Make failsafe
disarm if motors armed and throttle low #717.
- Use failsafeIsMonitoring() to actually start monitoring.
- Added `failsafe_kill_switch` to code.
When set to 1 (0 is default), the failsafe switch will instantly disarm
(__KillswitchEvent__) instead of executing the landings procedure.
Arming is NOT locked after
this, so the craft could be re-armed if needed.
This is intended for racing quads where damage and danger must be
minimized in case of a pilot error.
- Added `failsafe_throttle_low_delay`, adapted documentation.
Used to adjust the time throttle level must have been LOW
to _only disarm_ instead of _full failsafe procedure_
(__JustDisarmEvent__).
- Updated the failsafe documentation.
- Re-enable arming at end of failsafe procedure.
At the end of a handled failsafe event, that means: auto-landing,
__JustDisarmEvent__ or __KillswitchEvent__, the RX link is monitored for
valid data.
Monitoring is a part of the failsafe handling, which means the craft is
still in failsafe mode while this is done.
Arming is re-enabled (allowed) when there is a valid RX link for more
then XX seconds, where XX depends on the handled event like this:
1. XX = 30 seconds after auto landing.
2. XX = 3 seconds after __JustDisarmEvent__.
3. XX = 0 seconds after __KillswitchEvent__.
NOTE: When armed via an AUX switch, you will have to switch to the
disarmed position at the very end to be able to re-arm.
The failsafe mode will not end until you do.
- __KillswitchEvent__ has now priority over __JustDisarmEvent__
- Apply rxfail values instantly when failsafe switch is ON
- Added missing cases to display.c
Show M when failsafe is monitoring for RX recovery (AND disarming when
armed with a switch).
===
Reworked the code from counter-based to time-based.
- AUX failsafe switch now has identical behavior to RX loss.
- Added RX failure and RX recovery timing.
- __KillswitchEvent__ skips RX failure detection delay (direct disarm).
===
[UNIT TESTS]
Adapted failsafe related unittests from counter-based to time-based
- Added failsafeOnValidDataFailed() to some tests
- Removed duplicate test setup from rc_controls_unittest.cc
- Removed magic numbers from rx_ranges_unittest.cc and rx_rx_unittest.cc
- Reworked all test-cases for flight_failsafe_unittest.cc
