Prioritize module with higher update rates

[mha1]

This is the reanimated version of #2920 which was nuked by the great serial/module API rework. It implements enhancement proposal #2919.

Summary of changes:

If both modules are active the one with the higher update rate drives the mixer task and hence also receives the perk of being synced. The slower module will be updated at an integer fraction (divider) of the higher rate module. The divider is calculated such that the resulting update rate for the slower module will be as close as possible to its requested rate but doesn’t exceed it. It doesn’t matter if the higher update rate module is internal or external. The higher update rate module will always drive the mixer task, the slower one will follow.

Example: TX16s external ELRS module and internal MPM (requests 7000us update period):
500Hz ELRS /143Hz MPM-> 500Hz sync/125Hz no sync (divider 4)
333Hz ELRS/143Hz MPM -> 333Hz sync/111Hz no sync (divider 3)
100Hz ELRS/143Hz MPM -> 71Hz no sync (divider 2)/143Hz sync

Telemetry data of both modules will be received and is discoverable.

This PR also contains a change to the Radio Version Modules/RX version pop-up to show the real update rates for the internal and external module.

[JyeSmith]

I like the idea of using the module with the highest packet rate to drive the mixer. But question if its required to reduce the mixer rate for the slower module.

With the current implementations of reducing the update rate to below the modules packet rate, this will mean the module transmits double sends. It will be better to maintain an update rate higher than the packet rate to remove the double sends.

Maintaining a higher rate (or the original high mixer rate) will also mean the stick data the slower module receives will be more recent.

[mha1]

The mixer rate is not reduced. The rate of sending data to the module is reduced. Example: if you run an ELRS module at 500Hz together with a MPM the mixer is running at 500Hz no matter what because the ELRS 500Hz request beats the MPM's 143Hz request. Being the slower module serial data for the MPM is sent at a slave rate of 125Hz (divider 4) meaning every 4th mixer iteration is used to drive the MPM.

[JyeSmith]

143Hz request. Being the slower module serial data for the MPM is sent at a slave rate of 125Hz (divider 4) meaning every 4th mixer iteration is used to drive the MPM.

The problem is that with this reduced rate to the MPM it will now send a double packet OTA 14% of the time. It will be much better to supply the module with data at a higher rate.

[mha1]

That is true assuming the MPM is actually sampling at 7ms rate. You'd have to go for a more complex implementation that makes sending stick data of the slave module independent of the mixer rate. Just an idea - we could experiment with a software timer set at the requested slave rate sending out the most recent mixer data to the slave module (still unsynced of course).

[raphaelcoeffic]

It is probably sufficient to compute the divisor such that the update rate is higher than what it is supposed to be for the second module.

[mha1]

Choosing close to but no more than the requested rate was more of a precautionary measure. My reasoning is while it might be ok for the MPM a generic module might not be able to keep up or be overwhelmed if syncing internal processing to the incoming data.

[3djc]

MPM should handle 1ms sync (redpine protocol is the fastest update rate)

[raphaelcoeffic]

Choosing close to but no more than the requested rate was more of a precautionary measure

This is probably not really needed. The pulse/USART code is protected against sending a new pulse train before the old one is finished. I believe all modules should handle a higher update frequency (at least we know FrSky modules do; others would need to be tested). So far we're syncing on the internal module, which may or may not lead to a higher update frequency without reported side effects (so far).

[mha1]

Update: if requested rate of slave module can not be provided the slave module will run at the faster next integer "divider".

Example ELRS module at 500Hz, MPM at 143Hz. ELRS will run at synced 500Hz, MPM as slave at 167Hz (divider 3).

[mha1]

Should I close this one?

[raphaelcoeffic]

Should I close this one?

Actually, I was hoping to have some feedback from ELRS guys and try to work something out with them, but it seems the dual-module scenario is not yet quite popular enough now.

[mha1]

It's not all about dual ELRS modules. I'm running this in an experimental redundant MPM 2.4GHz / 900 MHz ELRS setup

[richardclli]

Choosing close to but no more than the requested rate was more of a precautionary measure

This is probably not really needed. The pulse/USART code is protected against sending a new pulse train before the old one is finished. I believe all modules should handle a higher update frequency (at least we know FrSky modules do; others would need to be tested). So far we're syncing on the internal module, which may or may not lead to a higher update frequency without reported side effects (so far).

@raphaelcoeffic This is not true, with EdgeTX 2.10.x firmware and when the radio is capable with hardware serial, a new train will take over the old train and cause MPM to report no input is detected.

[mha1]

Should I close this one? (Nov 2023)

Oct 2024: Do you want me to close this PR?