[ALIGNMENT]: Raise the coding rate while a modem preset is in use

[NomDeTom]

Decision

Clients let the user raise the coding rate while use_preset is true. The preset keeps setting bandwidth and spreading factor, and a coding rate above the preset's own value replaces it. Choosing a coding rate at or below the preset's value means "use the preset's".

Context

LoRaConfig.coding_rate is the denominator of the LoRa coding rate, 5 to 8 for 4/5 to 4/8. Clients currently hide it or grey it out whenever use_preset is on, and the proto comment on modem_preset says the preset replaces it.

Firmware already supports this. Since meshtastic/firmware#9155 (2.7.18), RadioInterface::applyModemConfig() takes the preset's bandwidth and spreading factor and uses coding_rate in place of the preset's value when it is valid and higher. A lower or unset value falls back to the preset. The change is on the client side only.

A higher coding rate does not split the mesh. Meshtastic sends the coding rate in the explicit LoRa header, so nodes on the same preset still receive each other in both directions. The frequency slot and the channel hash are also unaffected, because they come from the preset name and the channel name.

What the user gets is more forward error correction in exchange for airtime. The payload section of a packet sent at 4/8 takes 60% longer on air than at 4/5 with the same bandwidth and spreading factor, and that counts against the duty cycle and channel utilisation limits.

Required Client Behavior

1. Show the coding rate control while use_preset is true, labelled as an override of the preset, for example "Coding rate (preset: 4/5)".

2. Offer only the values above the preset's coding rate, up to 4/8, plus "Preset default". A lower value would be ignored by firmware, so the client must not offer it.

3. Write "Preset default" as coding_rate = 0. Any value at or below the preset's is stored as 0 too, so nothing misleading is left in the config.

4. Show the coding rate the radio is actually using wherever the client shows the preset's radio parameters, not the preset's nominal value.

5. Say near the control that a higher coding rate lengthens every transmission and uses more of the duty cycle and channel utilisation budget.

6. When the user switches presets, keep the override only while it is still above the new preset's coding rate, and reset it to "Preset default" otherwise.

7. Leave the custom-settings path (use_preset false) unchanged.

Acceptance Criteria

With use_preset on and a preset with a 4/5 coding rate, picking 4/8 writes coding_rate = 8, the radio reports 4/8, and the node still exchanges messages with an unmodified node on the same preset.

With use_preset on, no value below the preset's coding rate is offered, and "Preset default" writes 0.

Switching to a preset whose coding rate is equal to or above the stored override resets the control to "Preset default".

Firmware older than 2.7.18 ignores coding_rate while a preset is on, so clients hide the control on it.

Platform Tracking

• Android:
• Apple: shipped in Add LoRa coding rate preset override controls Meshtastic-Apple#1929; firmware gate and cost note in Hide the coding rate override on firmware that ignores it Meshtastic-Apple#2548
• Web:
• Firmware: out of scope, already implemented in Add custom coding rate configuration for LoRa firmware#9155
• Device UI:

[NomDeTom]

@jamesarich

[garthvh]

Apple already does this. It shipped in Meshtastic-Apple#1929 in June, a few months after 2.7.18, so the behavior described here is what the app does today.

Against the required behavior:

1. Shown under a preset as an override — yes. A "Follow Preset Coding Rate" toggle with a readout that reads "Preset Default (4/5)".
2. Only values above the preset's, plus "Preset default" — yes. The option set is [0] + (5...8).filter { $0 > presetDefault }, and the slider starts at the preset's value plus one. A preset already at 4/8 says so instead of offering a control.
3. "Preset default" writes 0 — yes, and anything at or below the preset's is normalized to 0 before saving.
4. Show the rate actually in use — yes. It is the only place in the app that displays the preset's radio parameters.
5. Say what it costs — this had regressed when the screen moved to the metadata-driven form, and is restored in Hide the coding rate override on firmware that ignores it Meshtastic-Apple#2548.
6. Reset on preset switch — yes, the value is renormalized when the preset changes.
7. Custom path unchanged — yes.

The one thing missing was the firmware gate. The app supports radios from 2.5.14, so on anything older than 2.7.18 the control was offered, the value saved, and the radio went on using the preset's rate with nothing saying so. meshtastic/Meshtastic-Apple#2548 hides the override below 2.7.18 and shows the rate the radio is actually using.

Two notes for the other clients:

Android has not done it. Coding rate lives in ManualModemSettings in LoRaConfigItemList.kt, which renders only in the else of if (use_preset), and CODING_RATE_RANGE = 5..8 rejects 0, so it cannot write "preset default" even if the control were shown.

The schema disagrees with the firmware. coding_rate carries no description and its comment is still just "The denominator of the coding rate", while use_preset and modem_preset both describe the preset as replacing it. A client implementing this from the protobufs alone would reach the opposite conclusion. meshtastic/protobufs#1117 writes down the actual rule, including that 0 means "use the preset's" and why no min/max is stated (5–8 with a preset off, 0 plus anything above the preset's with one on).

Worth noting for whoever writes the Android side: there is no since_firmware attribute in FieldMetadata, so the 2.7.18 gate cannot come from the schema and each client hardcodes it.