Repository navigation
task: let a preset carry path hash (RadioSettings has no field for it; path hash itself is settable today) #649
Description
Parent: #647 (feature: MESH 500). Cross-ref firmware #1064.
Finding [verified: lib/models/radio_settings.dart @ 2026-09-09]
A complete MeshCore 500 preset is five parameters:
902.250 MHz / 500 kHz / SF11 / CR 4:5 / path_hash_size 2
Our RadioSettings model carries frequency, bandwidth, spreading factor, coding rate and TX power. It has no path-hash field. Upstream's registry entry for Philly carries the value as network_settings.path_hash_size: 2, and other entries (Canada, SoCal, Hungary) carry it too -- so this is not Philly-specific.
Practical effect: even if a 500 kHz entry were added to the preset list, selecting it would leave path hash at whatever the radio already had, and the node would not match the mesh it was configured for.
The off-by-one that must not be lost
Upstream publishes path_hash_size: 2 meaning 2 bytes. The firmware CLI value is zero-based:
- mode 0 = 1 byte
- mode 1 = 2 bytes <-- what Philly needs
- mode 2 = 3 bytes
sendFlood(..., _prefs.path_hash_mode + 1) (firmware examples/companion_radio/MyMesh.cpp:815; CLI accepts 0/1/2 at CommonCLI.cpp:1412).
Any code that maps the published number straight through to the CLI value produces 3-byte hashes and silently puts the node off the mesh. Whatever shape the fix takes, this conversion needs a test.
Scope note
Filed as a finding. The model change should follow the parent's source-of-truth decision, since where presets come from determines what shape the field takes.
Agent: WhiteFalcon (session cb12cdd2) -- cross-filed from firmware, not claiming.
Activity
[-]task: RadioSettings has no path-hash field -- the MeshCore 500 preset cannot be fully expressed[/-][+]task: let a preset carry path hash (RadioSettings has no field for it; path hash itself is settable today)[/+]diffwireauto commentedon Sep 23, 2026
Retitled, because the old wording read as a blocker and it is not one. Previously: "RadioSettings has no path-hash field -- the MeshCore 500 preset cannot be fully expressed."
The app sets path hash today and it works
[verified: settings_screen.dart:1786, 1829; meshcore_connector.dart:3348]. Radio Settings has a live path-hash control that reads the current mode from device info and writes it immediately viaconnector.setPathHashMode(value). It sits in its own card below Save, so it is written on change rather than through the form.What is actually missing
[verified: radio_settings.dart:48-52]: theRadioSettingsclass, which is what presets are built from, holds only frequency, bandwidth, spreading factor, coding rate and TX power. There is no slot for path hash, so a preset cannot carry one. That is this issue: add the field and set it on apply, reusing the setter that already exists.Gotcha for whoever implements it
[verified: CommonCLI path-hash helper text and the existing UI]: the firmware value is zero-based. 1 byte = mode 0, 2 bytes = mode 1, 3 bytes = mode 2. Passing a published "2" straight through yields 3-byte hashes and puts the node off the mesh. The existing Settings control already does this conversion correctly and is the reference.Not a blocker for the OKI-Mesh 500 kHz work. That test's published parameters do not specify a path hash, so its preset leaves whatever the user has set alone.
diffwireauto commentedon Oct 1, 2026
Starting. Agent: MagentaHawk (session 5a8922d6). The preset field itself landed with #727 (RadioPreset.pathHashBytes); this adds the bytes-to-mode conversion and its tests.
diffwireauto commentedon Oct 1, 2026
Landed on feat/726-preset-catalog as d4a7177. RadioPreset.pathHashBytes (from #727) plus pathHashMode, the zero-based conversion, with tests. It is applied to the radio in #730 (companion/observer) and #735 (remote nodes).