Commit Graph
53 Commits
Author SHA1 Message Date
mikecarper 69ded9d6c7 feat: add Bluetooth-controlled LoRa OTA
Add the framed BLE mOTA transport and companion control path, complete the full-profile build and runtime fixes, and document and test the OTA workflow.
2026-08-27 01:22:18 -07:00
mikecarper bd3a94bddb fix: harden firmware builds and runtime reliability 2026-08-26 15:42:12 -07:00
mikecarper c512f4036e feat: retain INA monitors in reduced RAK repeaters 2026-08-25 20:24:17 -07:00
mikecarper ba2170d21b feat: add capability-aware firmware build profiles 2026-08-25 20:07:09 -07:00
mikecarper 5938cbe614 feat: complete Cascade Indicator companion support
Add native-resolution Indicator UI, touch navigation, SD-backed pixel and emoji fonts, LoRa radio support, dual-slot WiFi Companion provisioning, and mesh clock fallback. Harden radio recovery and build defaults, normalize ESP32 setup-AP protocols, and document/test the operator workflows.
2026-08-25 18:37:17 -07:00
mikecarper e7433abb80 Make RXPS preamble adaptive for fast radio settings 2026-08-24 20:42:54 -07:00
mikecarper 1a43123d2c Expand and harden full companion profiles 2026-08-24 01:57:38 -07:00
mikecarper 5362d36ac7 Unify full firmware profiles and add dual USB logging 2026-08-23 19:22:45 -07:00
mikecarper 9ed9e9d746 Add secure host CLI bridge and harden OTA workflows
Expose the Full Companion terminal over TCP and add an authenticated, replay-resistant host command service with documented CPU temperature, reboot, and allowlisted program examples.\n\nImprove LoRa OTA diagnostics and persistent CLI handling, reduce clock correction drift to ten minutes, and make mOTA stream flush behavior an explicit transport policy with regression coverage.
2026-08-23 15:29:30 -07:00
mikecarper 4d5ccbdd98 Retain GPS in RAK nRF52 OTA repeaters
Firmware Builder / create-release (push) Canceled after 0s
Firmware Builder / build (push) Canceled after 0s
Firmware Builder / generate-build-matrix (push) Canceled after 0s
Build Repeater Firmwares / build-repeater-firmwares (push) Canceled after 0s
2026-08-22 13:27:01 -07:00
mikecarper d9f5dfa8a2 Harden signed SD and bootloader OTA 2026-08-21 12:15:54 -07:00
mikecarper 3d78d9c846 Add MeshTower SD bootloader updates over LoRa 2026-08-21 09:55:15 -07:00
mikecarper 177eb06745 Add shared-slot nRF52 bootloader updates 2026-08-21 00:55:01 -07:00
mikecarper 75a2b8f002 Add signed XIAO bootloader updates over LoRa 2026-08-20 22:05:11 -07:00
mikecarper 72a9fd765b Wait for QSPI flash operations to complete 2026-08-20 18:48:03 -07:00
mikecarper 509f831442 Add external QSPI staging for nRF52 OTA 2026-08-20 17:51:52 -07:00
mikecarper 0f64b293f8 Restore OTA deployment tuning 2026-08-19 12:37:23 -07:00
mikecarper d37fefc204 Avoid legacy OTA proof collisions 2026-08-19 11:43:25 -07:00
mikecarper 425e8c81f3 Harden and qualify compact RAK3401 OTA updates 2026-08-19 11:17:22 -07:00
mikecarper e742333a0e Update MeshCore features and OTA layout handling 2026-08-18 23:17:42 -07:00
mikecarper 7a4da3ccfb Fix Cascade power saving, USB Companion, and mOTA flows 2026-08-18 14:02:10 -07:00
mikecarper 772607eba1 Complete v1.17.1.1 release matrix support 2026-08-14 21:09:14 -07:00
mikecarper 94a0ea2d7a Support subdivided nRF52 MOTA bridges 2026-08-14 19:57:13 -07:00
mikecarper a09127fefb Publish accelerated RAK3401 mOTA chain 2026-08-14 04:25:44 -07:00
mikecarper 8c5262c6f8 Accelerate adaptive LoRa OTA transfers 2026-08-14 03:00:36 -07:00
mikecarper 7372ad6c26 Probe OTA readiness after reboot 2026-08-13 23:58:32 -07:00
mikecarper b4096901eb Finalize tested RAK3401 v1.17.01 mOTA release 2026-08-13 23:48:14 -07:00
mikecarper 20bbfc33e4 Pin refreshed 29-step RAK3401 mOTA chain 2026-08-13 18:33:11 -07:00
mikecarper cd824765b4 Prioritize and pace private TempRadio OTA 2026-08-13 17:53:33 -07:00
mikecarper f7c2d382c3 Speed up and harden LoRa OTA transfers 2026-08-13 14:43:59 -07:00
mikecarper 4a3d86ef98 Add guarded nRF52 OTA rescue and SF5 test mode 2026-08-13 09:31:26 -07:00
mikecarper 710a6e02c5 Replace unsafe RAK3401 step 15 bridge 2026-08-13 01:26:07 -07:00
mikecarper 451130acbf Harden resumed LoRa OTA chain runs 2026-08-13 00:52:22 -07:00
mikecarper 38333e02f0 Add corrected RAK3401 mOTA chain runner 2026-08-12 20:03:25 -07:00
mikecarper 00a67c34b1 Fix nRF52 full Companion packaging 2026-08-11 15:30:21 -07:00
mikecarper 88ba5b26cb Add full Companion OTA source builds 2026-08-10 12:39:07 -07:00
mikecarper b85fa75a43 Harden terminal retries and OTA cleanup 2026-08-08 15:28:34 -07:00
mikecarper e47e028b6d Harden LoRa OTA automation retries 2026-08-07 23:22:36 -07:00
mikecarper bf62afa240 Add companion terminal mode and LoRa OTA tooling 2026-08-07 19:19:44 -07:00
mikecarper 4ed3307c6c Add MeshTower V2 SD-backed LoRa OTA 2026-08-03 12:49:36 -07:00
mikecarper 7abb5fb95b Add portable LoRa OTA repeater builds 2026-07-22 10:05:52 -07:00
mikecarper 371d86c4b1 Normalize tracked text to ASCII 2026-07-22 00:43:38 -07:00
mikecarper 710790b81d Enable LoRa OTA for nRF52 repeaters 2026-07-15 09:49:40 -07:00
mikecarper 28afb0cd2c Exclude oversized RAK4631 repeater from LoRa OTA 2026-07-15 08:29:33 -07:00
mikecarper 11aa4bc191 Harden LoRa OTA and enable unattended targets 2026-07-14 15:24:35 -07:00
Valentin Kivachuk Burda 872413231d ota: extract the motatool CLI to its own repo (github.com/vk496/motatool)
The host-side build/verify/inspect/serve CLI now lives as a standalone Rust
project at https://github.com/vk496/motatool. Remove the in-tree C++ copy
(tools/motatool/) and repoint the docs (ota_protocol.md, ota_user_guide.md,
tools/mota/README.md) at the standalone repo.

No cross-dependency either direction: MeshCore's firmware build never invoked
motatool (only tools/mota/ Python glue runs in the build), and motatool depends
only on the shared .mota wire spec in docs/ota_protocol.md. tools/mota/
(pio_endf.py EndF hook, motalib.py reference lib, gen_targets.py) is unchanged.
2026-07-11 14:47:11 +02:00
Valentin Kivachuk Burda 0319a81d69 ota: stamp the real FIRMWARE_VERSION into the EndF trailer (was v0.0.0)
The EndF post-build stamper read the version via _cppdef('FIRMWARE_VERSION'), which only sees -D build flags — but MeshCore authors FIRMWARE_VERSION as a header #define in each example, so the stamper found nothing and defaulted fw_version to 0. Every .mota / OTA advert then reported v0.0.0 while `ver` (which reads the header at runtime) showed the real version.

Read the header value as a fallback WITHOUT moving where MeshCore authors it: honor a -D override first (the header's #ifndef guard invites it, for release builds), else read the #define from the example this env builds (via build_src_filter), falling back to the repo-wide value when unambiguous. Purely additive to our own EndF tooling — no MeshCore source changed.

HW-verified: RAK4631 now reports `fw v1.17.0` in ota stats/ls (was v0.0.0), matching `ver`.
2026-07-03 08:02:59 +02:00
Valentin Kivachuk Burda 8953214761 ota: fragment-level want_mask requests (anti-burst) + warm-start leaf-diff capture
Protocol: OTA_REQ and OTA_GET_MANIFEST now carry a want_mask bitmap, so a fetcher asks for specific fragments (all on the first request, only the still-missing holes on a retry) instead of a whole block/manifest window. The WANT_MANIFEST and FETCHING retry loops re-ask only on a no-progress tick, so a lost fragment costs one fragment to recover and a re-request can't collide with an in-flight multi-fragment burst on half-duplex radios.

Warm-start (motatool folder-capture only): new OTA_GET_LEAVES/OTA_LEAVES let `ota pull <#> folder validate` bulk-fetch the target's merkle leaves, authenticate them against the manifest root, diff a similar seed build already staged in the destination, and pull DATA over LoRa only for the blocks that differ. Leaves are bitmap-fragmented + no-progress retry-gated like the manifest, capped at OTA_DIFF_MAX_BLOCKS so the want_mask stays a fixed uint16, and the diff runs a bounded batch per loop tick so it never starves the mesh loop. motatool `serve --seed <build.mota>` injects the seed payload into the destination .part on OP_BEGIN.
2026-07-02 19:03:28 +02:00
Valentin Kivachuk Burda 49820b57aa docs: pull a firmware .mota off the mesh into a motatool folder
Document `ota pull <#> <dest>` (flash|folder, destination mandatory), the folder
pull that captures a device's exact firmware to the host as <mid>.mota (for
delta-building), the paused/resume-on-reconnect behaviour, and that a `motatool
serve` link doubles as the pull-to-folder store. (protocol §10, user guide,
motatool README)
2026-07-02 08:52:40 +02:00
Valentin Kivachuk Burda bd2ecb80a7 ota: seeder storage protocol (pull-to-folder) + motatool serve storage handlers
Add the device->host WRITE half of the mota-seeder link so a device can capture
a .mota it is fetching off-mesh into the host folder (the same --dir used for
serving), stored as <mid>.mota — e.g. to grab an exact copy of a device's
firmware to build a delta against firmware you don't otherwise have.

- MotaSeederProto: OP_STAT / OP_BEGIN / OP_WRITE / OP_SREAD / OP_FIN (keyed by
  mid). Resume needs no host bookkeeping: BEGIN 0xFF-fills the file; on reconnect
  the device SREADs the leaves and re-requests only missing blocks (same as flash
  resume). Partial = <midhex>.mota.part, published to <midhex>.mota on FIN.
- motatool `serve --dir <folder>` now also handles the storage ops on the same
  folder/connection (SeederCore gains the store dir; serve_loop frames the
  variable-length WRITE). Host round-trip test added.

Firmware side (FolderMotaStore + `ota pull <#> <dest>` + pause/resume) follows.
2026-07-02 08:32:00 +02:00