Implement module multiplexing

[Smeat]

This implements multiplexing and fixes #49
Another way too large one, sorry! It might still contains a few unrelated changes, which need to be removed.

The most notable change is, that we have to differentiate between pilots and modules.
All active pilots are pushed into a queue and if there is a pilot in the queue it gets assigned to a module if:

• The module hasn't switched in MULTIPLEX_STAY_TIME_US + MIN_TUNE_TIME_US
• The waiting client has been without a module for at least MULTIPLEX_STAY_TIME_US + MIN_TUNE_TIME_US
  • The intention is, that with 4 modules and 5 pilots we prevent switching of all modules

If no multiplexing is needed the queue is empty and only the initial assignment will occur.

This also powers down all unused modules if the number of activated pilots is less than the number of modules and allows any pilot combination to be activated with minimal module usage (for example enabling pilot 2 and 5 only powers module 1 and 2):
By default it enables as many pilots as modules are configured, so the default shouldn't change.

I experimented a little bit with filtering (like dynamically adjust the dt or use the average sampling rate), but I had the best result with just using the normal sampling frequency and just ignore the tune time.
In my first tests there was only a very minor difference when using a 2nd order bessel lowpass in comparison to a 1st order lowpass.

As my other modules are still on the way I was only able to test it with a single module installed.

[JyeSmith]

Any reason for MULTIPLEX_STAY_TIME_US being 5 ms and not switch to a new freq after a single RSSI measurement?

For a 2 person race with 1 Rx the switching period is 35ms and it could be 31,

[Smeat]

No specific reason, I just set it to 5ms in the beginning and forgot experimenting with it.
Having just one sample is definitely not enough I'd say. Seeing we sometimes randomly read a very high value, differentiating between noise and a lap would be very difficult, since we might only get a single sample for a lap. But I'll do some further testing.

This is me covering/uncovering the antenna
5ms (~30 samples):

1 sample (when being as fast as in the first picture I often only get a single sample):

[Smeat]

Updated the PR. Hadn't had the chance to test it yet on real hardware. I will do that tomorrow . Looked good on a bare esp32 board though.

I've been using that code for the last year and it works like a charm.
One problem this might have: It reports MAX_NUM_PILOTS as the number of modules. So if a client doesn't support v6 of the protocol and doesn't send activate/deactivate messages. multiplexing might never get activated and the client doesn't receive any RSSI/laps for the extra pilots

[swampmonster]

LastADCcall looks like it's not used anymore.

[swampmonster]

airplaneMode in TimerWebServer.cpp also came back here :)

[swampmonster]

Updated the PR. Hadn't had the chance to test it yet on real hardware. I will do that tomorrow . Looked good on a bare esp32 board though.

I've been using that code for the last year and it works like a charm.
One problem this might have: It reports MAX_NUM_PILOTS as the number of modules. So if a client doesn't support v6 of the protocol and doesn't send activate/deactivate messages. multiplexing might never get activated and the client doesn't receive any RSSI/laps for the extra pilots

There's not really a way to check which API version the clients supports right?

[Smeat]

All those rebase errors :/ Will fix them tomorrow and go through all changes again.

We could add a setting to enable multiplexing with the default set to disabled. This way nothing changes for existing users and users who opt-in can be warned about that/can manually enable/disable the pilots if needed

[swampmonster]

All those rebase errors :/ Will fix them tomorrow and go through all changes again.

We could add a setting to enable multiplexing with the default set to disabled. This way nothing changes for existing users and users who opt-in can be warned about that/can manually enable/disable the pilots if needed

That sounds like a pretty solid approach to me.

[Smeat]

Updated to include a compile time switch to enable multiplexing. Will probably changed to a runtime configuration in the future once we have the extended commands merged.

Seemed to work on a bare bone esp32 just fine. Will test on real hardware in the next few days

Edit: Bench tested. Still would like to have some more test results. Calibration is mandatory with multiplexing!

board_default_multiplex.zip

[swampmonster]

I'll see if i can do a bench test during the week and report back.

[swampmonster]

Tested on the bench and im getting resonable readings from two drones with only one rx configured. Can't really do any more involved testing right now but it looks good!

[swampmonster]

This could use another rebase to make it easier to figure out what's going on

[Smeat]

Rebased. If anything is unclear feel free to ask, so I can update/add some comments ;)