MeshGrid Node (Build 154)

This release contains the current node firmware. Encrypted mesh frame structures remain fully compatible with Build 147. Flash at 0x0 for full installation or 0x10000 for application-only updates.

Key Features and Enhancements:

• Priority Traffic Management: High-priority message queues are optimized for low-latency transmission, while overall channel airtime estimation continues to be tracked in diagnostics.

• Privacy & Quiet Logging: Production logs omit BLE passkeys, payload dumps, and exact GPS coordinates. Decoded frame logs are restricted to sender ID, type, and UID.

• Field Security Guard: Lab-only USB injection routines are disabled in this binary. Read-only diagnostics and single-bench testing features remain accessible.

• Low-Battery Power Management: Below the hard low-battery threshold, routine GPS broadcasts and relays are paused to conserve energy, while essential ACK and system alerts remain active.

• Concurrency & Synchronization: Sequence counters are thread-safe to prevent race conditions between phone and USB interfaces. The radio task priority is balanced above GPS and BLE processes.

• Autonomous GPS Operation: When disconnected from a phone, the node broadcasts fresh GPS fixes at standard intervals and suppresses stale positioning data.

• RF & Power Notification Stability: Live register polling on the receive path has been optimized to prevent RX starvation. Battery state notifications to connected phones are throttled to a maximum rate of once every 60 seconds.

MeshGrid Node (Build 151)

When the phone is not connected, the node publishes its own position on the mesh if it has a fresh fix. The broadcast uses the existing interval (45 seconds by default; the phone can set 30–3600 seconds). The position is sent as current, not as a cached fix.

While the phone is connected and has supplied a position for this interval, the node stays quiet. Disconnecting the phone drops that pending phone position without sending it. A fix older than the interval is not sent.

Install

• Preferred: flash MeshGrid_ESP32_BUILD151_flash0x0.bin at address 0x0.
• Application only: flash MeshGrid_ESP32_BUILD151_app_0x10000.bin at 0x10000. This leaves the bootloader, partitions, and usually the stored settings in place.
• After a full erase, provision the node before use.
• On boot, the log should show Build 151.

Encrypted mesh frames are unchanged versus Build 147.

MeshGrid Node (Build 149)

This is the current node firmware. It keeps the same encrypted mesh used with the phone app. Since the last published binary (Build 136), delivery on a busy channel, phone-link reporting, stored state, battery indication, radio recovery, and encryption memory safety were tightened. Ciphertext on the mesh is unchanged from Build 147.

Install

• Preferred: flash MeshGrid_ESP32_BUILD149_flash0x0.bin at address 0x0.
• Application only: flash MeshGrid_ESP32_BUILD149_app_0x10000.bin at 0x10000. This leaves the bootloader, partitions, and usually the stored settings in place.
• After a full erase, provision the node before use.
• On boot, the log should show Build 149.

What changed since Build 136

Mesh delivery

• Incoming bytes are handled before a send, and a send waits while a peer frame is still arriving.
• A full frame at the buffer limit is kept when more bytes are waiting, instead of being dropped.
• Boot leaves the installed radio profile as it is.
• A peer that restarts its message numbers is treated as a new session, not as a duplicate.
• Broadcast chat, alerts, and shapes stay broadcasts. They are no longer rewritten into a one-peer message from a small local neighbor list.
• A duplicate still cancels a pending relay.
• A message counts as on the air only after the radio accepts it, not when it is only queued.
• A signal probe must look like “#” plus digits. Ordinary numbered chat keeps normal acknowledgement and recovery.
• Automatic resend waits out a long broadcast hold and sends one copy, instead of stacking extra copies on top of a send that has not finished.
• Direct broadcasts can be acknowledged once. Replies are staggered by node so two nodes sending together are less likely to collide. That acknowledgement is not retried forever.
• A two-node mesh uses fixed, non-overlapping send slots.

Phone link

• The firmware build number is sent only after the phone has enabled notifications, and the phone can ask for it again.
• A notification counts as delivered only when notifications are enabled, the payload fits the negotiated size, and the stack reports success.

Stored state and identity

• Replay state, pending messages, and the boot epoch are marked saved only after the write commits. Failures are counted.
• Flash writes wait while a peer frame, airtime, or an acknowledgement is in progress.
• If a required task cannot start, the node resets instead of continuing half-initialized.
• A roster record is accepted only when it is complete.
• If key derivation fails, the node does not fall back to using the raw master secret as a traffic key.
• If a message id cannot be reserved, the send waits instead of inventing one.
• Replay ordering stays correct when the epoch counter wraps.

Power, health, and time

• Battery is sampled on a timer even when the phone is disconnected. The hard low-battery warning uses the calibrated reading. The displayed percent can rise again as the battery recovers.
• Disconnect duration is stored in seconds.
• The unused color status light is no longer driven.
• Recovery follows receive silence, not transmit activity. Separate clocks show transmit, raw receive, valid mesh receive, and peer acknowledgement.
• When a fresh UTC time fix is available, scheduled send slots share one clock, so nodes that booted at different moments stay in phase. Without a fresh time fix, slots stay on the local clock.

Encryption

• The authenticated encryption path was made memory-safe. Bytes on the mesh do not change versus Build 147.

MeshGrid Node (Build 136)

MeshGrid ESP32 — BUILD 136 (binary release, no source)

Firmware BUILD telemetry waits for NUS CCCD before send; phone may re-request with local status event 0x44.

Verify boot log: "BLE ready BUILD 136 node=..."

MeshGrid Node (Build 135)

MeshGrid ESP32 — BUILD 135 (binary release, no source)

Contents

MeshGrid_ESP32_BUILD135_flash0x0.bin
Full merged image (bootloader + partitions + otadata + app).
Flash at address 0x0. Recommended for GitHub Release / factory flash.

MeshGrid_ESP32_BUILD135_app_0x10000.bin
Application partition only. Flash at 0x10000.
Does not replace bootloader/partitions; NVS usually survives.

bootloader.bin @ 0x1000
partitions.bin @ 0x8000
boot_app0.bin @ 0xe000
(advanced / split flash)

Flash with esptool (example)

Full image (preferred):

esptool.py --chip esp32 --port PORT --baud 921600 write_flash -z 0x0 MeshGrid_ESP32_BUILD135_flash0x0.bin

App only:

esptool.py --chip esp32 --port PORT --baud 921600 write_flash -z 0x10000 MeshGrid_ESP32_BUILD135_app_0x10000.bin

Board: ESP32-D0WD, 4MB flash, DIO 40MHz (PlatformIO esp32dev defaults).
After erase / first boot: provision with provision.py (not included in this package).
Verify boot log: "BLE ready BUILD 135 node=..."