Skip to content

MeshCore 1.17.1.6 Dev - USA Cascade

This release builds the current keymindCascade source after repairing the unit-test regressions. Its firmware identifier is v1.17.1.6-halo-keymind-cascade-dev-<commit>. The recorded commit identifies the source for every firmware file; binaries from earlier releases are not reused.

Use the firmware picker to match the exact board, radio, display and flash variant. The Companion release is marked Latest. Supporting release pages retain the repeater-room-, utility-, logging-, lora-ota- and full-profiles- prefixes where those outputs exist, and remain development prereleases.

The build uses the USA/Canada radio preset and Cascade runtime defaults. Build records include the resolved radio settings; the offline USA Cascadia fallback is 910.525 MHz, BW62.5, SF7, CR5. Ordinary updates retain saved node settings.

Published matrix

The GitHub release contains 553 qualified firmware profiles across five release pages. The initial matrix completed all 565 attempts: 537 passed, 16 failed, and 12 standard ESP32 profiles exceeded the 1.25 MiB portable slot. All 16 failures have passing repair builds; all 12 portable exclusions have qualified expanded Full alternatives. Smaller profiles that fit remain available.

The initial firmware uses 306feebe, the 14 nRF52 repairs use 283acd27, and the two Tracker MQTT repairs use 1274956f. Each firmware filename and target manifest records its source. Existing firmware assets and release tags were preserved when the repairs were added.

See the failure and repair report and portable-profile exclusions. Full alternatives require their matching expanded partition layout; they do not fit a deployed 1.25 MiB slot.

Two LoRa profiles

radio2, tempradio2, radioat2 and tempradioat2 add a second profile to LoRa-equipped Companion, Repeater, Room Server, Sensor and terminal firmware. The second profile starts disabled. It supports receive-only or receive/transmit operation, separate retry ownership and backoff, and explicit off commands.

One transceiver alternates between at most two active profiles. Reception and transmission occupy that transceiver, so a packet on one profile interrupts listening on the other. This does not provide two simultaneous receivers.

By default, traffic can cross between two permanent profiles or two temporary profiles. A permanent/temporary pair stays isolated. radio2.cross auto|on|off controls this policy; receive-only still forbids transmission on profile 2. tempradio2 can carry LoRa OTA traffic while the primary profile remains available between packets. Use a firmware profile that supports the required OTA role.

Radio commands accept an optional trailing preamble, and their getters include the effective preamble. Automatic preambles round up in steps of eight. Paired with SF7/BW62.5/preamble 32, the automatic BW500 values are 48 symbols at SF9, 88 at SF8 and 120 at SF7. Configure transmitters with matching preambles too.

Dual-profile receive uses normal RX with the slower profile visited first. RX power saving and device sleep are suspended while scanning, then the saved settings apply again in single-profile mode. See the setup guide and command matrix and hardware measurements.

Other changes since 1.17.1.5

  • Restores set path.hash.mode 0|1|2 on infrastructure firmware, with CLI dispatch and get/set regression coverage. Unsupported extra.sf commands report an explicit error on radios without that capability.
  • Uses received MeshCore packets to feed the repeater RX watchdog. Fresh settings default to 24 hours; temporary primary-radio sessions lasting at least 12 hours use 12 hours, while shorter sessions disable that watchdog. Temporary-session adverts and watchdog settings revert when the session ends or the node reboots. See CLI commands.
  • Adds separate battery and USB display modes, with timeouts in seconds. Companion inbox settings distinguish retained history, pending delivery and the local unread count. Read previews remain browseable in Unread mode.
  • Includes native-USB sleep/wake corrections, nRF52 USB startup fixes, receive recovery and noise-calibration improvements, and the reviewed ExpressLRS board/power changes.
  • Consolidates redundant Full infrastructure builds while retaining useful smaller-slot variants. Full profiles and smaller portable images continue to require their matching partition and update method.

Feature switches and update commands are documented in feature switches by role, Full Companion features and the ESP-NOW bridge guide.

Validation and installation

The release is gated on the unit-test workflow for its source commit. CI repairs replace stale display assertions with compiled tests of bookmark saves across battery/USB transitions and message summaries in each inbox mode. The sleep harness checks both MQTT and dual-profile scanning.

The release packager checks each published profile's capability manifest, firmware-file hashes, native file pairs and runtime RAM budget. Infrastructure must have a verified wireless update path. The target manifests and exclusion report describe the actual published matrix; a build check is not a physical-board test.

Dual-profile timing was measured on a Heltec V4 with a XIAO ESP32-S3/Wio LoRa transmitter. Finite strong-signal tests and an OTA catalogue exchange passed; these tests do not establish weak-signal performance, simultaneous traffic reliability, a complete hardware OTA installation, or months of uptime.

ESP32 WiFi updates use the application .bin. The -merged.bin image includes boot and partition data for USB installation. nRF52 uses the board's .uf2 or native application DFU .zip; LoRa OTA also needs the exact destination package and a compatible OTAFIX bootloader. Check the per-profile capability manifest before choosing an update method.

Reproduce the release

Follow-up builds repair the constrained profiles without relaxing qualification:

  • nRF52 repeaters use -Os instead of -Ofast, retaining their sensor drivers and protocol features while reducing flash use.
  • T096 and T1 LoRa OTA repeaters retain their board-defined 50 neighbors and use 16 flood-rule slots. The complete rule engine, color display, GPS and OTA remain enabled. The T096's available startup heap rises from 72,492 to 81,468 bytes, and the T1's from 72,868 to 81,844 bytes. Required startup allocations fall from 88,410 to 79,010 bytes. These are linked capacity checks, not soak measurements. Full Companion capacities are unchanged.
  • Tracker v1.1 and v2 Full MQTT repeaters retain their board-defined 50 neighbors so the color display, MQTT/TLS and OTA fit in internal RAM. Their radio, display, sensor and update features remain enabled; ordinary Tracker repeater and Companion capacities are unchanged. Tracker v2's available startup heap rises from 184,640 to 222,992 bytes against the unchanged 190,386-byte requirement. Both corrected Tracker profiles pass.
  • Size-failure detection keeps its temporary output log outside PlatformIO's build tree, so SCons cleanup cannot erase the evidence needed by the measured size fallback. CI exercises cleanup, ordinary compiler failures and log errors.

Use a clean checkout of the release commit and a fresh output directory:

OUTPUT_DIR=.releases/1.17.1.6-halo-keymind-cascade-dev \
bash build.sh build-firmwares-logging-matrix \
  --firmware-version v1.17.1.6-halo-keymind-cascade-dev \
  --radio-preset usa-cascadia --profile cascade \
  --require-ota --skip-kiss --resume --background

Run only one PlatformIO process in that checkout. Let the matrix finish even when individual targets fail. The packager normally requires a successful full matrix. For an initial release with gaps, scripts/package_cascade_release.py accepts --allow-partial with --version 1.17.1.6, the original completed build status and source commit. It lists every failed attempt in BUILD-FAILURES.md and BUILD-FAILURES.json; each published file must still pass all qualification and memory checks. Repair the failures and add the corrected profiles afterward. PORTABLE-PROFILE-EXCLUSIONS.md and .json separately list standard ESP32 profiles that exceed the 1.25 MiB slot and are redirected to the expanded Full pass. Those size deferrals are not compiler failures. Qualified smaller images remain available; Full alternatives require their matching partition layout.