Updates to disarm save delay and emergency rearm

[MrD-RC]

Initial changes

[MrD-RC]

This is looking to be working in HITL.

https://youtu.be/ACYA91211Zw

[MrD-RC]

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.

inav/src/main/fc/fc_msp.c

Lines 443 to 458 in c2b5d2e

	#if defined(USE_OSD) && defined(USE_MSP_OSD)
	bool armingBit = bitArrayGet(mspBoxModeFlags.bits, BOXARM);
	// If we are in emergency re-arm period and using MSP DisplayPort OSD, show that we are still Armed to prevent the VTX entering low power mode
	if (feature(FEATURE_OSD) && emergInflightRearmEnabled())
	bitArraySet(mspBoxModeFlags.bits, BOXARM);
	#endif
	sbufWriteU16(dst, averageSystemLoadPercent);
	sbufWriteU16(dst, armingFlags);
	sbufWriteU8(dst, accGetCalibrationAxisFlags());
	#if defined(USE_OSD) && defined(USE_MSP_OSD)
	if (armingBit)
	bitArraySet(mspBoxModeFlags.bits, BOXARM);
	else
	bitArrayClr(mspBoxModeFlags.bits, BOXARM);
	#endif

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.

[rmaia3d]

Thanks for your efforts in this!!