Fix coding rate on Short and Medium presets, add LongTurbo#44
Merged
Conversation
The preset table in src/radio/presets.py shipped with coding_rate=4/8 on ShortFast, ShortSlow, MediumFast, and MediumSlow. Per the upstream Meshtastic spec (RadioInterface.cpp), only the Long Range presets and the deprecated VeryLongSlow use 4/8. The other six all use 4/5. The wrong value cascaded through the dashboard preset dropdown into local.yaml on every Meshpoint that picked one of the affected presets, and from there into every TX (NodeInfo broadcasts, DM ACKs, relay). 4/8 is roughly 60% more airtime per byte than 4/5, so fleet members on those presets were paying a notable airtime tax for no benefit. Changes: - src/radio/presets.py: corrected CR to 4/5 on the four Short and Medium presets. Added LongTurbo (SF11 / BW500 / CR 4/8) which was missing from the table entirely. - src/transmit/tx_service.py: added (11, 500) -> "LongTurbo" to PRESET_DISPLAY_NAMES so MQTT topics and the channel-name resolver label LongTurbo consistently instead of falling through to "Custom". - src/config.py: cosmetic fix to the RadioConfig dataclass default (4/8 -> 4/5). default.yaml is already correct so this only affects code-readers and tests that instantiate RadioConfig() directly. - tests/test_radio_presets_canonical.py: new file locking every preset's (sf, bw, cr) tuple to the upstream spec so this never regresses silently. - tests/test_tx_service.py: added test_longturbo, expanded the test_all_presets_present expected set. - docs/COMMON-ERRORS.md: entry under Concentrator and radio documenting the symptom, the airtime impact, and the dashboard re-pick or yaml edit fix path for existing installs. No version bump. Existing installs keep their cached CR until the user re-picks the preset on the dashboard or edits local.yaml. RX is unaffected since the SX1302 reads CR from the LoRa header. Reported by Chiumanfu on Discord while setting up a Vancouver Meshpoint on MediumSlow.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
The preset table in
src/radio/presets.pyshipped withcoding_rate=4/8onShortFast,ShortSlow,MediumFast, andMediumSlow. Per the Meshtastic Radio Settings spec (andRadioInterface.cppin upstream firmware), only the Long Range presets and the deprecatedVeryLongSlowuse4/8. The other six all use4/5.The wrong value cascaded through the dashboard preset dropdown into
local.yamlon every Meshpoint that picked one of the affected presets, and from there into every TX (NodeInfo broadcasts, DM ACKs, relay). 4/8 is roughly 60% more airtime per byte than 4/5. RX is unaffected since the SX1302 reads CR from the LoRa header.Changes
src/radio/presets.pycorrects CR to 4/5 on the four Short and Medium presets, and adds the missingLONG_TURBO(SF11 / BW500 / CR 4/8).src/transmit/tx_service.pyadds(11, 500) -> "LongTurbo"toPRESET_DISPLAY_NAMESso MQTT topics and the channel-name resolver label LongTurbo consistently instead of falling through toCustom.src/config.pycosmetic dataclass-default fix (4/8 -> 4/5);default.yamlwas already correct so this only affects code-readers and directRadioConfig()instantiations in tests.tests/test_radio_presets_canonical.py(new) locks every preset's(sf, bw, cr)tuple to the upstream spec so this never regresses silently.tests/test_tx_service.pyaddstest_longturboand expands thetest_all_presets_presentexpected set.docs/COMMON-ERRORS.mddocuments the symptom and the dashboard re-pick / yaml edit fix path for existing installs.No version bump
src/version.pystays at0.7.1. The orange-triangle update indicator does not fire. Existing installs keep their cached CR until the user re-picks the preset on the dashboard or editslocal.yaml. This change folds into the v0.7.2 web-auth release blurb when that ships.Test plan
python -m pytest tests/ -q— 277 passedruff check src/ tests/— cleansudo git fetch origin && sudo git checkout fix/preset-coding-rate && sudo systemctl restart meshpointlocal.yamlnow hascoding_rate: "4/5"mainafter mergeReported by Chiumanfu on Discord while setting up a Vancouver Meshpoint on MediumSlow.