iNavFlight
Updates to disarm save delay and emergency rearm
Just for a little update.
@Jetrell found some inconsistent issues in #9681 that I did not find in HITL. I created this PR to try and address those issues before the deadline for 7.1. I'm at the stage now where I don't think that's going to happen, as there seems to be some issues deeper that are causing this. I have reverted #9681 and brought the changes from that branch in to this one.
As far as the testing goes. I did test in HITL and everything seemed fine. However, @Jetrell's testing with his quad always seemed to get different results to what I was seeing. Yesterday I was able to test on 2 aircraft and had different results on both aircraft!
| Component | AR.Wing (Test1) | Baby AR Wing Pro (Test2) |
|---|---|---|
| Flight Controller | Matek F405-STD | Matek F765WSE (SD card removed) |
| Video | Analogue | Walksnail |
| ESC protocol | DSHOT 150 | DSHOT 150 |
| RC Link | Crossfire | ELRS |
* I will be posting DVR later. I do not have my goggles with me at this time
Test 1 - AR.Wing
If I had only performed a test with this wing. The Lego dude would have been singing "Everything is awesome" on loop. Everything worked as expected.
- In flight
- Flicking the switch to disarmed showed the stats screens, with the re-arm timer
- If it had been longer than 10 seconds since arming, the
** WAITING TO SAVE **message would show - Within the 5 seconds, switching to arm would instantly arm, and the save would be aborted
- Longer than the 5 seconds, and the save would proceed. Lower the throttle and re-arm as in the old days
- On landing
- Waiting would disarm by landing and save
- Disarming by switch would show
** WAITING TO SAVE **briefly, while the landing detector ran it's checks. Then save
Everything worked perfectly.
Test 2 - Baby AR Wing Pro
This one ...not so much. At no point did it want to save. Stats has a 10 second after arming wait period. After that, it should request the save operation when you disarm. That never seemed to happen. This could be related to the last change I made before testing, but it seems highly unlikely.
https://github.com/iNavFlight/inav/blob/c2b5d2e7fb0235e8505f35d556ca71d94532464b/src/main/fc/fc_msp.c#L443-L458
I don't believe it's related, as statsOnDisarm() is called internally, not via MSP. However, that change also didn't have the desired affect of keeping the VTX in an "armed" state. It reverts the bitmask to the how it was after providing the data to the MSP device. So the arming flags before entering and after exiting the MSP function will be consistent.
It seems odd that these issues are possibly related to MSP DisplayPort. But, it is also consistent with @Jetrell's test platform. He is also using MSP DisplayPort, on and F405 based craft. That's also the main difference between my two test platforms. It's also worth noting that tests in HITL were with both types of OSD. Though I'm sure the actual data passed to HITL will just be the character locations for both.
I'm sure this can be resolved. But not before the 14th. If anyone has any ideas, please feel free to comment. I probably won't have a lot of time in, and leading up to, March.
