Design goals vs MeshCore™ and Meshtastic®

This page compares design intent, not specific vendor firmware versions. MeshCore™ and Meshtastic® are referenced as well-known anchors in the community.

What LowMesh borrows and extends

Idea	Typical source	LowMesh behavior
Backbone + internet gateway	MeshCore™-style	Gateway role repeats and bridges to IP; exposes bulletin board and IoT ACK services.
Ad-hoc extension of range	Meshtastic®-style	Client nodes are not always-on infrastructure relays. Standard Clients have Dynamic Repeater Mode enabled by default and may temporarily relay third-party traffic (TempRelay) when no stable Repeater or Gateway is available.
Channel separation	Both	Meshtastic®-like channelHash on the wire (derived from channel name + PSK); channelHash == 0x0000 is a default community domain with a fixed ROM PSK and AES-CCM-4 (not cleartext). MeshCore™-like explicit per-channel PSKs still fit naturally as “each (name,psk) is its own group.” Optional NMK can derive initial PSKs during provisioning (see Crypto keys).
Deep mesh	Various	Hop-budget (ttlRaw) with HASH_SIZE-aware ceilings; flood + optional strict on-wire routes; RAM duplicate suppression.

Differentiators

1. IoT sleep synchronized to gateway distance

Classical mesh stacks often force a worst-case listen window. LowMesh allows an IoT device to send toward a known gateway with a declared maximum hop count (hop budget). Gateways and intervening repeaters echo ACK timing hints so the device can sleep until the ACK window, and the ACK frame can carry downlink payload (configuration, OTA control bytes, sensor thresholds).

See IoT: hop budget & ACK downlinks — IoT Client Profile / Sensor Profile.

2. Fragmentation with explicit recovery

Large content uses messageId + fragment index/total. Receivers can request missing fragments instead of restarting an entire transfer. This applies to files and voice (clustered fragments).

See Fragmentation.

3. Bulletin board as an infrastructure service

Only stable infrastructure (Repeater, Gateway) hosts long-retention bulletin boards. Clients in temporary relay (Dynamic Repeater Mode) do not offer durable storage, which avoids flash wear and inconsistent caches on battery nodes.

See Bulletin board.

4. Unified hex API on USB and BLE

Debug, factory, and companion apps see the same frame bytes whether they arrive over USB CDC or BLE notifications. The API is documented as hex strings with optional length prefixes.

See USB & BLE hex API.

5. Firmware flexibility

• USB and BLE transport for updates.
• DFU (Nordic DFU / MCUboot-style) and UF2 drag-and-drop when the MCU is nRF52840 with a UF2 bootloader partition.

See Firmware.

Regulatory positioning (USA)

LowMesh documents an FCC-oriented US915 profile that requires 500 kHz LoRa bandwidth for the common 47 CFR § 15.247 digital-modulation compliance path. Many community stacks expose narrower channels that are convenient in other regions but problematic when mapped naively onto US 915 MHz operation without a validated hopping design — see FCC — USA.

Honest limitations

No protocol is “strictly better” on every metric. LowMesh optimizes for predictable IoT, rich payloads, and operational clarity. Networks that need massive parallel floods with minimal coordination may prefer simpler flood-only stacks; networks that need pure static star topologies might not need mesh at all. LowMesh targets general-purpose community and industrial meshes where both structure and resilience matter.