Heck yeah! Way to jump in with a great solution before I even had to think about it and then working for several hours to make sure we got all the edge cases. 💪

For testing, I first found a value that could be represented in the 7 bit version and not in 6 (CRSF=254) and forced channel 12 (AUX8 to this value) on v3.5.4:

diff --git a/src/lib/OTA/OTA.cpp b/src/lib/OTA/OTA.cpp
index 219b9941..1ce78725 100644
--- a/src/lib/OTA/OTA.cpp
+++ b/src/lib/OTA/OTA.cpp
@@ -163,6 +163,8 @@ void ICACHE_RAM_ATTR GenerateChannelDataHybrid8(OTA_Packet_s * const otaPktPtr,
 static uint8_t ICACHE_RAM_ATTR HybridWideSwitchToOta(const uint32_t *channelData, uint8_t const switchIdx, bool const lowRes)
 {
     uint16_t ch = channelData[switchIdx + 4];
+    if (switchIdx + 4 == 11)
+        ch = 254;
     uint8_t binCount = (lowRes) ? 64 : 128;
     ch = CRSF_to_N(ch, binCount);
     if (lowRes)

Switching between 1:8 and 1:4 reported different values to Betaflight, 1039us and 1031us respectively. Then, when loading the ELRS lua (which triggers TlmBurst mode) in Std telemetry, you can see the channel start at 1039, change to 1031 as the lua loads, then go back to 1039 after burst ends. After applying this PR, the value stays the same as the lua loads, indicating no change in resolution during burst mode. Also tested in fixed rates of 1:!28, 64, 32, 16, and 8. Tlm Ratio=Off still does not enable telemetry when the lua loads as expected.

Also tested in 1:4 and 1:2 TLM ratios, and the RX's lua config definitely loads significantly faster in these modes compared to Std (1:8 burst), but the channel value stays 1031us as expected.

Testing RACE telemetry mode, the link goes to 1:8 while disarmed during burst as expected, but still does not send OOB data while armed. This is because there are no SYNC packets when armed to switch the telemetry back on, and I think this is still the expected behavior. Regardless, the channel value does not change in RACE telemetry mode while armed or disarmed during tlm burst where it does change without this patch.

Finally just to be sure nothing was being masked by only observing the channel value, I also compiled the RX with DEBUG_LOG and watched the TLM ratio reported by the RX and it always maintains the proper ratio to prevent passing the threshold.

Question

When TlmRatio = Off, does the telemetry turn on when using one of these Lua scripts that users are using that triggered this problem? We have special code that prevents burst mode when our Lua loads (DEVICE_INFO packet is not queued if the RX is in "disconnected" state) but that would not prevent other luas from queueing MSP packets. We need to make sure these still perform as expected with telemetry off. I believe they would force the link into 1:8 mode all the time, but I do not think we should prevent that on our side. If the user wants no telemetry but is running a telemetry script, god speed little MSP packet.

Damn, you guys had a big chat about this while I was all tucked up in bed!

That's why we have round the clock shifts! 💪 Thanks also to @schugabe for tagging me in the conversation since this is all my fault and I'm happy to help fix it.

Thanks for the quick fix!

We (Rotorflight) would like to offer a simplified workaround for people who are not tech-literate.
Currently considering to advice them to change the telem ratio to 1:4. Regardless if it is needed or otherwise. Until they can ask someone to check their config and possibly update the rx firmware.

For techies, we will give all the details and explain what the options are.

Eventually everybody should update the firmware, but that may take until the end of 2025, if not longer.

Does it sound ok to you?

Thank you ELRS and RF team for working together on this and nailing it so quickly. Amazing cross team work!

We (Rotorflight) would like to offer a simplified workaround for people who are not tech-literate. Currently considering to advice them to change the telem ratio to 1:4. Regardless if it is needed or otherwise. Until they can ask someone to check their config and possibly update the rx firmware.

Either that or just update their Rotorflight config to have it not change the thing that is causing the problem when this bug happens.

Is the issue that when the bit depth of the channel switches, it changes modes or something in Rotorflight? If that's the case then can't the mode be defined in a way that encompasses both possible values? e.g. (from Betaflight)

EDIT: This wouldn't resolve the issue if the SYNC packets are lost due to non-100% LQ, as the value will change by up to 512us and therefore likely cross any mode region boundary.