Triggered by the issue reported by Colin (@yak-54) I did some investigation on how the schedulers perform in low bandwidth.
I simulated a setup where 1 to 4 extra frsky sensors are connected to the s.port bus and measured the scheduler performance.
This table summarizes the results
notes
- S1 is the default scheduler
- S2 is my new experimental scheduler
- columns marked with an M at the top refer to bandwidth while sending messages
- cells in red show packets that the scheduler is dropping (packets that are not sent)
So this pretty much confirms what Colin is experiencing, with 4 extra frsky sensors the S1 scheduler drops a lot of packets, in particular it’s dropping 0x800 GPS frames.
The S2 scheduler never drops a packet and scales linearly but with such a low bandwidth it probably needs a non linear behaviour.