Skip to content

Conversation

@CapnBry
Copy link
Member

@CapnBry CapnBry commented Aug 4, 2025

Removes the 7-bit mode for Wide switches when running at low telemetry ratios, making the Wide switches always 6-bit. This also returns TLMBoost to the original 1:2, removing the triage fix from #3210 that limited it to 1:8 to prevent it from crossing the boundary.

I feel like this is less confusing and returns the telemetry boost performance lost. REGRESSION: users may be upset about the lower resolution of the channels, making them maybe unsuitable for some control surfaces or head tracking.

Question

Should I also revert the TLMBoost request/active code that was added in #3222? The advantage to keeping it is slight and it does add minor code complexity.

  • Downside to keeping it: TLMBoost usually lasts around 2x sync cycles which is a waste if there's only a small amount of downlink data to send
  • Downside to removing it: TLMBoost may run for less than 1x complete cycle which could be insufficient downlink bandwidth.

Also tagged For Discussion because if we want to keep the terrible TLMBoost bandwidth and keep 7-bit Wide switches, I'm cool with that and just closing this PR.

@pkendall64
Copy link
Collaborator

Personally I think that changing the interpretation of the OTA data based on the TLM ratio is. a very bad idea, so I'm in support of 6-bit all the time in wide mode.

w.r.t the TLMBoost, I'm ok with keeping the way it is now (i.e. with the new code).

We could calculate where we are in the hopping sequence and if we are less that half way to a sync, then wait for 2 syncs otherwise wait for 1 sync. That way we boost for 1/2 to 1-1/2 periods. But this would introduce more complexity.

@CapnBry
Copy link
Member Author

CapnBry commented Aug 8, 2025

Thanks, PK. You're definitely correct that changing the OTA format based on the TLM ratio was a bad idea right from the get-go; I should have recognized the problem with it when I created it.

We can optimize the boost duration after 4.0 if we feel like it is excessive using something like you described if we find that it is not meeting our performance needs. Just gotta lock in that always 6-bit OTA format right now.

Copy link
Contributor

@mha1 mha1 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm all for it. Reduces complexity, brings back 1:2 boost and gets rid of the 1:8 workaround. And if there's wide mode users in need of more resolution there's always the full modes.

Copy link
Contributor

@SunjunKim SunjunKim left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1 for this, for the sake of simplicity.

@SunjunKim
Copy link
Contributor

SunjunKim commented Aug 13, 2025

REGRESSION: users may be upset about the lower resolution of the channels, making them maybe unsuitable for some control surfaces or head tracking.

ps. Who use non-Full modes for control surfaces? They stuck on Full mode (including ch5!)

@CapnBry CapnBry merged commit 9f8c4c3 into ExpressLRS:master Aug 17, 2025
22 checks passed
@CapnBry CapnBry deleted the wide-6-bit branch October 25, 2025 21:00
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants