View this page on MeshCore Docs.
MeshCore 1.17.1.9 USA Cascade
Firmware source: 88c85108005a30a730fa7b78b2899b210754f3be.
Release packages and their public assets passed validation. Hardware
observations below retain the exact source and installation route tested.
USA Cascade defaults are 910.525 MHz, 62.5 kHz bandwidth, SF7 and CR5. Saved radio settings take precedence. Match the exact board, role and storage layout before installing an image.
Changes since 1.17.1.8
- ESP32 native USB recipes now use hardware CDC where the chip supports it. Classic ESP32 and explicit UART transports keep their UART path. nRF52, RP2040 and STM32 USB backends are unchanged by this migration.
- Heltec V4 and V4 R8 user buttons wake CPU light sleep when power saving is enabled. Button debounce and click deadlines remain awake so the display can process the press. Explicit display-off mode still suppresses screen wake.
- ESP32 USB output is bounded so a stopped reader cannot indefinitely hold the radio loop. The G2 preserves complete serial packet-log lines under congestion. This supports unmodified Cisien meshcoretomqtt; congested diagnostic output can still be dropped.
- ESP32-S3 hardware CDC startup reclaims TinyUSB PHY ownership retained across a software restart. KISS clears incomplete host frames on a USB session reset while preserving active radio work.
- Browser OTA uploads allow 30 seconds of body inactivity after admission. An upload error stays attached to its HTTP request and stops further flash writes. Error callbacks avoid raw USB printing that could block the shared network task when a connected host stops reading.
- Browser OTA applies the expected MD5 after opening the update, so checksum verification survives updater initialization. It commits an application only after the complete HTTP POST finishes. A rejected second file or an interrupted multipart request cannot finalize the first file as an update. The successful response is sent before the deferred restart.
- On ESP32 infrastructure,
start otastarts WiFi as needed, stops WebConfig to release its HTTP port, and reports the address and network to use.start ota apcan replace a running LAN uploader with the node'sMeshCore-OTAaccess point. Run the handoff from USB, Bluetooth or LoRa; WebConfig tells its terminal users that the portal will close. - Setup and OTA access points use ordinary b/g/n WiFi. Firmware rejects AP startup while a conflicting long-range ESP-NOW transport is active, and defers that transport while the AP is running. MQTT and Companion station recovery leave an active setup/OTA AP available.
- Infrastructure WebConfig retries its saved WiFi when MQTT has no running worker. Ownership follows the actual worker state while canonical WiFi credentials and 64-hex password support remain independent of that state. Companion's manual WiFi startup behavior is preserved.
- ESP32 infrastructure MQTT builds with WebConfig use the same saved WiFi credentials for browser setup, CLI configuration, startup and reconnects. A fresh browser-only setup can now start MQTT. Raw 64-hex PSKs are supported without changing the observer preferences file layout. Failed saves retain the committed pair or block an incomplete pair; runtime credentials remain fixed until the bridge restarts. See WiFi setup.
- Compact 1.14.1 preference images retain a saved RX boosted gain of on when a newer board profile defaults it to off. Newer appended gain values remain authoritative. The old off byte is indistinguishable from padding used by earlier versions, so those zero-filled legacy images retain board defaults.
- Companion packet streaming supports stock serial MQTT consumers. Text CLI and Binary Companion handoff and reply deadlines are covered against the official app's protocol behavior.
- Access Control replies fit the encrypted LoRa route budget and the Companion frame envelope. Large ACL listings use bounded pages. ESP32 ACL persistence avoids repeated metadata opens while retaining recovery checks.
- Companion requests skip recently used reply tags. A login reply whose server timestamp matches the next client timestamp no longer causes an immediate status or ACL request to fail locally. Stale replies remain blocked, and tag selection does not change the radio's wall clock.
- nRF52 keeps its 8 KiB loop stack. Crypto, contact CRC and background storage work reduce peak stack use and long pauses. OTA metadata is cached after verification instead of repeatedly reopening storage for status displays.
- T096 and T1 repeater profiles reserve four flood-rule entries to fit the complete sensor profile with the existing 8 KiB loop stack, 50 neighbors, color framebuffer and OTA arena. Their capability manifests record this capacity limit; heap qualification margins are unchanged.
- The RAK3401 unified repeater reserves 47 flood-rule entries so its full sensor profile, 8 KiB loop stack, 50 neighbors and internal/QSPI OTA stores fit the runtime RAM requirement. Full and reduced sensor images use the same table capacity; the capability reports record this limit.
- Flood-policy upgrades accept inactive trailing rows from larger tables. If active rules exceed an image's capacity, the stored file is preserved and policy saves are blocked. The CLI reports the capacity mismatch; install firmware with enough rule slots to recover the complete policy.
- ESP32 filesystem buffer checks cover the pinned Arduino 3 frameworks used by RC32 and C6 targets and continue rejecting unhonored buffer allocations.
- ESP32 Full LoRa repeater images combine supported ESP-NOW and RS-232 bridge modes behind runtime controls. Separate ESP-NOW images remain where a combined profile cannot meet the existing memory and flash guards. Full Heltec V3, WSL3 and RAK3112 MQTT profiles retain independent RS-232 controls alongside MQTT and ESP-NOW; see the bridge controls.
- MeshTower V2 uses its SD-card-capable image as the canonical combined repeater. With the matching combined OTAFIX bootloader, its runtime storage policy keeps SD primary and allows internal-flash signed application deltas when no usable card is available; see MeshTower storage.
- Supported T-Beam AXP192/AXP2101 boards can configure and persist the charger's exact supported voltage targets, with hardware readback. Neither PMU supports 3.65 V. Heltec Mesh Solar's charger voltage remains a hardware setting; see charge voltage.
- Generic ESP-NOW Full Companion retains all Full transports and 100 contacts with a 224-frame offline queue to meet the unchanged runtime RAM requirement.
- Wio-E5 Mini Companion uses smaller generated code while preserving its filesystem allocation, contacts, channels and physical-button controls. CI compiles its actual Cascade release profile with the full version string.
- Mesh America preserves download-only installation for hardware cards that require it, including their Full and reduced sensor profiles.
Firmware profiles
Choose the exact hardware variant and role in the firmware picker. Full includes the transports and optional sensors supported by that board's qualified recipe; it does not add peripherals that the hardware cannot support. Runtime controls select USB logging, power saving and included bridge modes without a separate image.
ESP32 normally has one public Full image per board and role. A migration ZIP may contain a different required target identity; use its supplied Full image for that migration. Station G2's ordinary Full image retains an Observer-named OTA identity, even though it is the combined Full profile.
nRF52 Repeater, Room Server and Sensor provide both Reduced sensors + LoRa OTA and Full supported sensors + LoRa OTA. Pick Full when its supported optional sensors are needed. Both keep the exact board/role/storage identity and need the matching OTAFIX bootloader. Full Companion remains the combined Companion choice. See profile details.
Installation
An ESP32 merged .bin installs bootloader, partitions and application over
USB. An app-only .bin requires a compatible existing layout. Partition
expansion requires the exact board and role migration ZIP from this release
family's utility page, or the matching merged image over USB. Follow the ZIP's
README and use its supplied Full application. get storage.layout reports
the live layout on firmware that supports it.
For the measured ESP32 upgrade route and examples, read Upgrading from 1.17.1.8 over WiFi. Download the selected image before joining the node's update access point.
Check the image's flood-rule capacity before updating a repeater. Move active rules into the supported slots and save them before installing a smaller table. An over-capacity policy is retained on storage but remains inactive until compatible firmware is installed.
Switching from TinyUSB to native hardware CDC changes the USB product name and
Linux /dev/serial/by-id path. Update serial consumers to the new device path
after the first upgrade.
Hardware CDC descriptors are fixed in silicon; firmware cannot retain a custom
TinyUSB product name. Do not identify a radio solely by a changing /dev/ttyACM
number. See Espressif's explanation.
nRF52 application UF2 and DFU ZIP files do not install a bootloader. Use the exact board/storage OTAFIX mapping in the firmware picker. See the role controls, Full Companion guide, and USB web console.
Verification scope
The completed release contains 463 qualified firmware profiles
across 5 stable release groups with 1988 verified public assets.
All 114 nRF52 Full/Reduced sensor pairs and 94 exact ESP32
board/role migration packages passed checksum, capability, memory, identity
and layout checks for firmware source 88c851080. Public asset digests and
the exact release family marked GitHub Latest were independently verified.
Download the 1.17.1.9 USA Cascade family and its migration utilities. These verified releases supply the firmware picker and Mesh America catalogs.
Production-code host regressions cover the official configuration GUI's five-second command deadline, app protocol and ACL replies, USB lifecycle, OTA admission/MD5/completion/error handling, shared WiFi credentials, AP and MQTT ownership, and legacy RX-gain loading. Synthetic peripheral tests cover boards unavailable for physical testing. They do not establish every board's physical USB, radio, WiFi or power behavior.
The latest-source G2 ordinary Full Observer passed a separate USB application installation with complete application readback, exact normal runtime and EndF identity, and unchanged checked boot/partition/NVS/OTA-data/filesystem regions. Its read-only post-boot check matched the original identity, passwords, two Admin ACLs, all 22 common settings, seven supported bridge fields and saved extras. Core error flags were zero. MQTT was running with valid effective configuration; broker connectivity was not tested. Original TTY settings, three host services and the Pi network were restored.
The legacy stock 1.14.1 G2 WiFi-only migration is not qualified end to end.
The earlier 1e421ff4 trial completed partition expansion and the supplied
Full application's WiFi upload, but its final network check reached the
client/DHCP deadline without
a verified G2 client or any HTTP request. Final image/layout/identity/settings
verification through HTTP remains unproven. The successful latest-source USB
maintenance above does not qualify that cable-free path. Plan for USB recovery
when starting from this stock image; do not rely on the migration trial as a
verified LoRa or WiFi recovery procedure.
A published 1.17.1.8 Full V4 installed newer applications over its node AP and
a controlled LAN on an already-expanded layout. Its old uploader could miss
HTTP completion despite installation and restart; check ver before retrying
an apparently stalled page. Current-source physical V4 testing was unavailable.
Earlier V4/G2 AP uploads and quiet USB tests remain evidence for their recorded
revisions. A bridge-setting command also missed its five-second deadline;
later healthy uptime and readback did not turn that timeout into a pass.
The detailed browser OTA and release-candidate report retains the complete source-specific results, failures and recoveries. See also the native V4 console report, Linux Web Serial report, and USB backpressure results. These checks do not measure fleet reliability, MCU sleep/current draw, stack high-water or sustained RF throughput, or qualify every browser, phone, operating system, bootloader or starting firmware version.