LoRa parameters and hardware configuration

Mesh routing and payloads are agnostic to the modem, but nodes on the same RF network MUST share a Radio Profile: LoRa (or FSK) settings plus regional limits.

Where LoRa settings live

Storage	Contents
Device NVM (RadioProfile struct)	SF, BW, CR, preamble length, IQ inversion, explicit header, CRC on/off, sync word / network id for private networks.
Beacon / NODE_INFO	Advertises profileId and regionCode so a handheld can warn: “neighbor on different profile.”
Build-time defaults	Factory image may ship Profile 0 (community default).

LoRa settings are not inside every user payload — they are session configuration. Payloads carry application data; the radio driver maps Mesh PDU → PHY.

Recommended RadioProfile fields (normative for interop)

Field	Type	Notes
profileId	uint8	0–255; bump when SF/BW change
regionCode	uint8	0=UNSET, 1=US915, 2=EU868, …
sf	uint8	Spreading factor 5–12 (SX126x range product-dependent)
bwKhz	uint16	e.g. 125, 250, 500 — USA (FCC-targeted): 500 only — see FCC — USA
cr	uint8	Coding rate 1–4 representing 4/5 … 4/8
preambleSyms	uint16	Symbol count
iqInverted	bool	Must match across net
explicitHeader	bool	Usually true
crcEnabled	bool	Should be true → enables LoRa CRC16 at PHY
ldro	uint8	Low data rate optimize: auto/on/off
syncWord	uint16	Public vs private network discriminator (Semtech-style)
txPowerDbm	int8	Conducted power before antenna; combine with antennaGainDbi for EIRP
antennaGainDbi	int8	For link budget display only

Hardware block (pins / board)

Field	Type	Notes
boardId	uint16	PCB revision
radioKind	uint8	e.g. SX1262, LR1110
tcxoPpm	uint8	Optional; used for time error budget
hasLna	bool	RX noise figure improvement
defaultDioAsIrq	bool	Diagnostic

These hardware fields do not go on every packet — they appear in NODE_INFO and in USB HWCAP_GET.

Link budget (informative)

Per hop, an implementation can compute:

linkBudgetDb = txPowerDbm + txAntennaGain - pathLossModel
               + rxAntennaGain - noiseFloorDbm - requiredSnrDb

Path loss is not known exactly; use measured RSSI/SNR from last packet as empirical input (see Traceroute & link metrics).

Regional airtime and duty-cycle policy

Duty-cycle and airtime limits are enforced in the MAC scheduler, not in the Mesh PDU. Recommended runtime counters (RAM, reset per window):

Counter	Purpose
txAirtimeMsLastMinute	Originated TX airtime in the last 60 s
txAirtimeMsLastHour	Originated TX airtime in the last hour
relayAirtimeMsLastMinute	Third-party relay TX in the last 60 s
relayAirtimeMsLastHour	Third-party relay TX in the last hour

NVM / profile fields (see RadioProfile in Embedded storage):

Field	Meaning
regionalDutyCycleLimitPermille	Max TX duty in permille (1000 = 100%). Example: 100 ≈ 10% for EU-style caps. 0 = no regulatory duty cap.
regionalDutyCycleWindowSec	Rolling window for the limit (e.g. 3600).
relayAirtimeBudgetPermille	Reserved share of relay budget for own traffic (congestion fairness).
ownTrafficReservedPercent	Informative UI mirror of reserved own-traffic share (product-defined)

United States (FCC)

The USA profile focuses on US915 / FCC Part 15.247 behavior documented in FCC — USA. It does not impose a generic 10% duty-cycle rule like some EU bands. regionalDutyCycleLimitPermille MAY remain 0 while counters still track airtime for congestion control.

European Union and similar regions

Regional profiles MAY enforce duty-cycle limits (10% or lower per band/sub-band rules). Set regionalDutyCycleLimitPermille and regionalDutyCycleWindowSec accordingly.

Regions without formal duty-cycle caps

Counters MAY still be used for congestion control and fairness even when regionalDutyCycleLimitPermille == 0 — they are not regulatory limits in that case.

Expose regionCode in UI when users import profiles.

Regulatory (summary)

Sub-band hopping, max dwell time, and profile-specific limits complement the counters above. See FCC — USA for the documented US915 path.

Listen-before-talk (LBT) and randomized backoff

LowMesh does not mandate a specific radio chip, but it DOES require that implementations avoid “everyone transmits at once” collisions, especially during flood forwarding and broadcast beacons.

This section defines the MAC-layer behavior that sits between “the mesh wants to send frame X” and “bytes are handed to the LoRa modem”.

Goals

• Prevent synchronized rebroadcasts when many relays hear the same frame.
• Provide a defined baseline even if a vendor driver offers CAD (Channel Activity Detection) or hardware CSMA features.
• Keep the algorithm simple enough for low-power MCUs while remaining tunable per region/profile.

Required behavior (normative)

Before any transmission attempt (originated or forwarded), a node MUST apply:

• Randomized backoff for flood rebroadcasts (see Routing).
• Listen-before-talk where supported, using one of:
  • CAD-based LBT (Semtech-style Channel Activity Detection), or
  • RSSI-based clear channel assessment (CCA) if CAD is unavailable.

If the channel is assessed as busy, the node MUST defer by an additional randomized amount (bounded) rather than transmitting immediately.

Recommended default algorithm (CAD/LBT)

Definitions:

• attempt — starts at 0 for the first scheduled send; increments on each busy deferral.
• seed — deterministic per-frame/per-node seed (same as routing section).

Procedure at the scheduled transmit time:

1. Run CAD for nCad symbols (recommended: nCad = 2).

2. If CAD indicates activity, defer by:

   deferMs = U(backoffMinMs, backoffMaxMs) using (seed, attempt)

   where:

   • backoffMinMs = 60
   • backoffMaxMs = 520
   • attempt is capped at attemptMax = 4

3. If attempt > attemptMax, the node MAY drop the transmission (for flood rebroadcasts) to avoid persistent congestion loops. For originated unicast, implementations MAY keep retrying subject to regulatory limits and queue policy.

When CAD/LBT is not available

If CAD is not supported or unreliable on the selected PHY:

• Use RSSI threshold CCA (implementation-defined threshold per profile) and treat “RSSI above threshold” as busy.
• Apply the same bounded deferral and cap behavior as above.

Broadcast storms and beacons

For periodic broadcasts (e.g. NODE_ADVERT floods, beacons), implementations SHOULD add an additional slow jitter (seconds-scale) to the schedule so fleets do not drift into phase alignment (e.g. after reboot at the top of a minute).

Notes (informative)

• LBT does not guarantee collision-free operation on LoRa (hidden terminals exist), but it materially reduces synchronized self-interference in dense relay sets.
• Regions differ in formal LBT requirements; this spec’s algorithm is compatible with both duty-cycle and LBT regimes when paired with region enforcement in the scheduler.

United States (FCC)

LowMesh USA operation standardizes 500 kHz LoRa bandwidth for the documented Part 15.247 digital-modulation compliance path; firmware should treat regionCode = US915 as bwKhz = 500 unless the operator explicitly opts into a non-certified / experimental profile. Full discussion: FCC — USA.

Checksum relation

LoRa CRC covers the modem payload bytes (which equal Mesh PDU for transparent mode). All channelHash domains use AES-256-CCM-4 on the application tail (4-byte MIC after ciphertext), including 0x0000. See Packet layout.