Skip to content

Fix coding rate on Short and Medium presets, add LongTurbo#44

Merged
KMX415 merged 1 commit into
mainfrom
fix/preset-coding-rate
May 4, 2026
Merged

Fix coding rate on Short and Medium presets, add LongTurbo#44
KMX415 merged 1 commit into
mainfrom
fix/preset-coding-rate

Conversation

@KMX415
Copy link
Copy Markdown
Owner

@KMX415 KMX415 commented May 3, 2026

Summary

The preset table in src/radio/presets.py shipped with coding_rate=4/8 on ShortFast, ShortSlow, MediumFast, and MediumSlow. Per the Meshtastic Radio Settings spec (and RadioInterface.cpp in upstream firmware), 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. RX is unaffected since the SX1302 reads CR from the LoRa header.

Changes

  • src/radio/presets.py corrects CR to 4/5 on the four Short and Medium presets, and adds the missing LONG_TURBO (SF11 / BW500 / CR 4/8).
  • src/transmit/tx_service.py adds (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 dataclass-default fix (4/8 -> 4/5); default.yaml was already correct so this only affects code-readers and direct RadioConfig() 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.py adds test_longturbo and expands the test_all_presets_present expected set.
  • docs/COMMON-ERRORS.md documents the symptom and the dashboard re-pick / yaml edit fix path for existing installs.

No version bump

src/version.py stays at 0.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 edits local.yaml. This change folds into the v0.7.2 web-auth release blurb when that ships.

Test plan

  • Local: python -m pytest tests/ -q — 277 passed
  • Local: ruff check src/ tests/ — clean
  • CI on this PR (Ubuntu 3.12 ruff + pytest)
  • Hardware on RAK V2 .141:
    • sudo git fetch origin && sudo git checkout fix/preset-coding-rate && sudo systemctl restart meshpoint
    • Open dashboard, switch preset to MediumSlow (or any of the four corrected presets), confirm CR readout shows 4/5 (was 4/8)
    • Save Radio, apply restart, confirm local.yaml now has coding_rate: "4/5"
    • Watch the next NodeInfo broadcast log line for the lower expected airtime
    • Switch to LongTurbo, confirm it appears in the dropdown with BW500 / SF11 / CR 4/8 readout
  • Restore .141 to main after merge

Reported by Chiumanfu on Discord while setting up a Vancouver Meshpoint on MediumSlow.

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.
@KMX415 KMX415 merged commit 1779b66 into main May 4, 2026
1 check passed
@KMX415 KMX415 deleted the fix/preset-coding-rate branch May 4, 2026 05:08
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant