LoRa, MeshCore & LoRaWAN Protocol Architecture
LoRa transceivers encode data into continuous mathematical chirps, allowing signals to be pulled from 20 dB below the noise floor. But physical modulation is only step one: how your firmware frames packets, routes across hops, and manages airtime determines whether your network scales or collapses under packet collisions.
01 · Chirp Spread Spectrum (CSS) Physics & Spreading Factors
Standard FSK modulation requires an incoming signal to be at least +6 to +10 dB stronger than background thermal noise. LoRa uses Chirp Spread Spectrum (CSS), sweeping carrier frequency linearly across the channel bandwidth (up-chirps and down-chirps).
The Spreading Factor (SF) defines the number of chirps used to encode each individual symbol (2SF chirps per symbol). Higher spreading factors give receivers massive mathematical processing gain:
| Spreading Factor | SNR Threshold | Symbol Time (125 kHz) | 50-Byte Airtime | Raw Bitrate | Field Role & Battery Tradeoff |
|---|---|---|---|---|---|
| SF7 | -7.5 dB | 1.024 ms | 102 ms | 5.47 kbps | Fast sensor bursts, moving vehicles, battery conservation, high-density areas |
| SF8 | -10.0 dB | 2.048 ms | 184 ms | 3.13 kbps | Good balance for suburban nodes with moderate packet volume |
| SF9 | -12.5 dB | 4.096 ms | 328 ms | 1.76 kbps | Default for regional telemetry, MediumFast presets, and light mesh hops |
| SF10 | -15.0 dB | 8.192 ms | 616 ms | 0.98 kbps | Challenging links through dense timber, multiple buildings, or rolling terrain |
| SF11 | -17.5 dB | 16.384 ms | 1,150 ms | 0.54 kbps | Meshtastic LongFast default. Extreme range, but 1.15s on air per 50-byte burst |
| SF12 | -20.0 dB | 32.768 ms | 2,138 ms | 0.29 kbps | Maximum sensitivity. Burns 20x more battery than SF7; easily saturates airtime |
The Airtime Trap
Notice that moving from SF7 to SF12 increases packet airtime from 102 ms to over 2.1 seconds — a 20× increase in channel occupancy. A single sensor sending telemetry at SF12 every 30 seconds will completely jam the local channel for everyone else and deplete its 18650 lithium battery in a couple of weeks. Always default to SF7 or SF8, only stepping up when signal margin drops.
02 · Forward Error Correction & Sync Words
LoRa radios inject redundant parity bits into every transmission using Hamming Forward Error Correction (FEC). If electromagnetic interference flips a bit in transit, the receiver’s hardware decoder reconstructs the original symbol without requiring an airtime-wasting retransmission:
| Coding Rate | Packet Airtime Overhead | Error Correction Capability | Recommended Field Use |
|---|---|---|---|
| CR 4/5 | 1.25x (+25%) | Detects 2-bit errors, corrects 1-bit per nibble | Standard field telemetry with clean line-of-sight |
| CR 4/6 | 1.50x (+50%) | Higher error recovery margin | Fading channels and moderate multipath reflection |
| CR 4/7 | 1.75x (+75%) | Heavy redundancy | Industrial environments near high-voltage switching |
| CR 4/8 | 2.00x (+100%) | Maximum Hamming code protection | Mission-critical alarm packets through severe RF noise |
Hardware Sync Words
Immediately following the preamble, the transmitter emits a two-chirp hardware pattern called the Sync Word. If the sync word does not match what the receiver is programmed to expect, the radio frontend immediately aborts decoding at the silicon level:
0x12(Private / Default): Used by Meshtastic, MeshCore, Reticulum, and custom point-to-point firmware. Prevents private packets from triggering false interrupts on public gateways.0x34(Public LoRaWAN): Reserved for public networks (The Things Network, Helium, ChirpStack).
03 · MeshCore vs. Meshtastic: Flood vs. Structured Mesh
In off-grid communications, getting packets across hills and trees requires multi-hop relaying. Two primary philosophies dominate open-source LoRa development:
| Architectural Feature | Meshtastic (Flood-Based) | MeshCore (Structured Roles) |
|---|---|---|
| Routing Mechanism | Managed Flood Routing (Nodes repeat all heard packets up to hop limit) | Structured Multi-Hop Routing (Packets routed across dedicated backbone repeaters) |
| Client Device Role | Acts as both user terminal and active mesh repeater by default | Client nodes only send/receive; leaf clients never rebroadcast packets |
| Battery Conservation | Clients wake to repeat stranger packets, draining mobile batteries faster | Clients sleep between transmissions, preserving handheld/phone batteries |
| High-Density Scalability | Can experience channel saturation in dense urban areas due to packet cascades | Minimizes redundant transmissions; designed for scalable multi-tier network backbones |
| Offline Messaging | Real-time broadcast only; if recipient node is asleep or out of range, packet drops | Dedicated Room Server nodes store and forward messages when client reconnects |
| Packet Acknowledgments | Hop-by-hop duplicate suppression with optional end-to-end routing ACK | Built-in path-aware acknowledgments (ACKs) confirming delivery across nodes |
The MeshCore Node Role Model
MeshCore was engineered specifically to solve the “broadcast storm” problem of pure flood routing in dense population centers:
1. Client Node
A pocket radio or phone companion (paired via BLE). Clients send user text messages, telemetries, and ACK requests. They never repeat stranger packets, keeping power draw to microamps and leaving the spectrum quiet.
2. Repeater Node
Dedicated relay nodes mounted on towers, rooftops, or mountain ridges with solar panels. Repeaters listen on the backbone channel and forward packets across structured hops using path tables.
3. Room Server
Persistent mailbox nodes with flash storage. When a client goes out of range or powers down, messages addressed to group rooms are stored. When the client returns to RF range, it syncs missed history.
04 · Over-the-Air Packet Framing
Meshtastic Packet Header (16 Bytes)
| To (4B) | From (4B) | Packet ID (4B) | Flags (1B) | Channel (1B) | Next Hop (1B) | Relay Node (1B) | Payload (Var) |
|---|---|---|---|---|---|---|---|
| 0xFFFFFFFF (Broadcast) | Node ID (Hex) | Random 32-bit ID | HopLimit (3b) | WantACK | Hash of PSK | Routing byte | Relay byte | Protobuf + AES |
LoRaWAN Uplink MAC Frame Format
| MHDR (1B) | DevAddr (4B) | FCtrl (1B) | FCnt (2B) | FOpts (0–15B) | FPort (1B) | FRMPayload (Var) | MIC (4B) |
|---|---|---|---|---|---|---|---|
| MAC Header | Device Address | Frame Control | Frame Counter | MAC Commands | Port Index | AES-128 Payload | CMAC Integrity |
05 · Exact Airtime Calculation Formula
The total time a LoRa transmitter remains active over the air (Tpacket) is the sum of the preamble duration and the payload duration:
T_packet = T_preamble + T_payload
- Symbol Duration: Tsym = 2SF / BW (e.g. at SF7 and 125 kHz BW, Tsym = 1.024 ms).
- Preamble Duration: Tpreamble = (Npreamble + 4.25) × Tsym. For an 8-symbol preamble, that is 12.25 × 1.024 ms = 12.54 ms.
- Payload Duration: Calculated by the number of payload symbols multiplied by Tsym, accounting for payload bytes, header presence, and coding rate FEC expansion.