fix(AFHDS3): Sync UI with Flysky AFHDS3 module stored settings

[richardclli]

Fixes #3491, fixes #3477 (reworked), fixes #3682

Summary of changes:

• UI change receiverID -> TX get config -> refresh UI
• UI change options -> TX set config
• model load -> TX get config -> refresh UI
• receiver connected -> options that is only changeable in bind will be disabled for edit

[philmoz]

It would need some way to reset the flag otherwise the UI will keep updating.

It think it would be better to just store the get_tmr10ms() when a change is made to the module that needs a UI update.
Then the UI code can use this to see if a refresh is needed, and no reset is needed (the UI code just compares the last refresh time to the last module changed time).

[philmoz]

PR #3502 has code to update the module window if the module refresh time changes. You should be able to merge that PR into your branch.

Note: I have no way to test this so I can't guarantee it will work.

Also, to avoid unnecessary updates, the module code should take care to only update the 'lastModuleUpdatedTime' value when the underlying module data has actually changed.

[richardclli]

Thank you, I will check and see later when I have access to my radios.

[pfeerick]

This appears to be working for EL18 - changing receiver ID now triggers a UI refresh when different receivers have different settings, which also means the RF mode (Fast 8Ch, Routine 18Ch etc) is updating to correctly reflect different receiver profiles.

[richardclli]

This appears to be working for EL18 - changing receiver ID now triggers a UI refresh when different receivers have different settings, which also means the RF mode (Fast 8Ch, Routine 18Ch etc) is updating to correctly reflect different receiver profiles.

Nice, now need to check how the change of options can update a connected receiver.

[pfeerick]

Nice, now need to check how the change of options can update a connected receiver.

If it truely is runtime, and you refer to the options like servo frequency, purpose of the NP# ports, etc, that update action could perhaps be triggered as you exit the screen - which I think is similar to how R9M Access, ISRM, etc do it.

[richardclli]

Nice, now need to check how the change of options can update a connected receiver.

If it truely is runtime, and you refer to the options like servo frequency, purpose of the NP# ports, etc, that update action could perhaps be triggered as you exit the screen - which I think is similar to how R9M Access, ISRM, etc do it.

I think I will try to add hooks to the UI that will mark the config as dirty and update the config during normal operation cycles.

[richardclli]

@philmoz seems the refreahing logic will stop other modules from refreshing properly, e.g. MPM

[philmoz]

seems the refreahing logic will stop other modules from refreshing properly, e.g. MPM

I don't understand - can you provide more details on what is happening.

[richardclli]

seems the refreahing logic will stop other modules from refreshing properly, e.g. MPM

I don't understand - can you provide more details on what is happening.

The MPM status is not refreshed with this change i.e. MPM version no. is not shown, just white.

I found that MPM has timestamp to control the refresh.

https://github.com/EdgeTX/edgetx/blob/main/radio/src/telemetry/multi.cpp#L254-L257

Let me check the code of other modules first. I think we need a unified mechanism to control options refresh in UI.

[richardclli]

@philmoz I finally got it right. Overriding checkEvents need to call super class method otherwise there will be something missing for the children.

edgetx/radio/src/gui/colorlcd/flysky_settings.cpp

Lines 94 to 99 in 764ec3e

	void FlySkySettings::checkEvents() {
	if (afhds3::getConfig(moduleIdx)->others.lastUpdated > lastRefresh) {
	update();
	}
	FormGroup::checkEvents();
	}

Thanks for your code that enlighten me.

[richardclli]

Now the settings can change online. Need some time for people to test. Flysky will help to test as well.

[richardclli]

@raphaelcoeffic I have change some state flow in the AFHDS3 state machine, please help me to review to see if there maybe any loop holes.

[richardclli]

@raphaelcoeffic @philmoz Any more reviews and comments?

BTW, I have delivered firmware with this PR for users in China. Up to now, it seems the changes works well and stable.

[philmoz]

Nothing obvious leaps out at me.

[pfeerick]

It seems like I did something right there 😁 Before Companion, and after Companion

[pfeerick]

There is more work to be done for AFHDS2/3, but this PR seems to do what it says on the tin ;) Settings saved to file now also survive a read/write pass through Companion. They cannot be fully configured with Companion yet, as it seems we need to purge FRM302 related entries before we can fully match the FRM303 in Companion... but one problem at a time.