Future: RNode Radio Layer — Dynamic LoRa Modulation & Passive EW

Status: Future implementation guidance. Not actionable until styrene RNode firmware work begins.

Audience: Agents and developers implementing styrene’s RNode radio integration, firmware flashing, and LoRa parameter management.

Context

Styrene’s pub/sub event system (beacon + pull model) operates over LoRa via RNode interfaces on Reticulum. LoRa uses shared ISM band spectrum — the electromagnetic field is an inherently shared medium. Any actor with a $20 module can transmit on the same frequencies.

The protocol-layer mitigations (cryptographic channel authentication, airtime budgeting, subscriber-side rate limiting) handle application-level spam. What they cannot handle is RF-layer saturation — deliberate or incidental.

This document captures the design intent for dynamic LoRa parameter modulation as a form of passive electronic warfare — not jamming or attacking, but intelligently seeking unsaturated portions of the spectrum to maintain communication under adverse conditions.

Design Philosophy: Graceful Oppositional Defiance

The same graceful degradation principle that governs the rest of the styrene stack applies here, adapted for a contested medium:

Nominal — default LoRa parameters, optimal balance of range/throughput/airtime
Degraded — detected interference or saturation on current parameters, dynamically shift to maintain connectivity at reduced performance
Contested — active saturation across multiple configurations, minimize transmission footprint, maximize receive sensitivity, accept high latency

The system should never engage in active jamming or interference. It seeks clear spectrum, not denial of spectrum to others. “Oppositional defiance” means refusing to be silenced by adapting, not by fighting.

LoRa Parameters Available for Dynamic Modulation

RNode exposes full control over LoRa PHY parameters. Each is a knob for spectrum agility:

Parameter	Range	Effect of Change
Frequency	ISM band dependent (e.g., 902-928 MHz US)	Move to less saturated channel within legal band
Spreading Factor	SF5–SF12	Higher SF = more range, more airtime, harder to interfere with (processing gain). Lower SF = faster, less airtime, more vulnerable to noise
Bandwidth	7.8 kHz – 500 kHz	Narrower BW = better sensitivity, less spectrum used, slower. Wider BW = faster but occupies more spectrum
Coding Rate	4/5 – 4/8	Higher CR = more FEC redundancy, survives more interference, costs airtime
TX Power	-4 to +22 dBm (hardware dependent)	Lower power = shorter range but less detectable. Higher power = more range, more interference to others
Preamble Length	6–65535 symbols	Longer preamble = easier synchronization in noisy environments

Scenarios for Dynamic Modulation

Scenario 1: Channel Saturation (Unintentional)

Dense Meshtastic deployment on the same frequency. High noise floor.

Response: Shift frequency within ISM band. Increase SF for processing gain. Narrow bandwidth.
Degradation: Reduced throughput, increased latency. Connectivity maintained.

Scenario 2: Targeted Interference

Sustained transmission on known styrene frequencies.

Response: Frequency hop to pre-agreed alternate channels. Increase coding rate for FEC. Reduce TX power to minimize intercept signature.
Degradation: Latency increases significantly. Beacon rate drops. Pull requests may require multiple attempts.

Scenario 3: Broadband Noise Floor Elevation

Wideband interference across the entire ISM band.

Response: Maximum spreading factor (SF12) for maximum processing gain. Minimum bandwidth. Maximum coding rate. Accept extremely low throughput.
Degradation: May take minutes to transmit a single beacon. Emergency broadcasts only. Routine events deferred to IP backhaul if available.

Implementation Guidance

Spectrum Sensing

RNode hardware can report RSSI and SNR per received packet
Implement a channel quality estimator that tracks noise floor, packet loss rate, and retry frequency per LoRa configuration
Use this to drive automated parameter selection

Pre-Agreed Channel Plans

Subscriber and hub should share a channel plan — an ordered list of frequency/SF/BW combinations to try
Channel plan is distributed as part of the subscription handshake (styrene wire protocol)
Both sides walk the plan independently when the current channel degrades, enabling rendezvous without coordination traffic

Coordination with Duty Cycle

Dynamic modulation must respect legal duty cycle limits (region-dependent)
Higher SF and lower BW dramatically increase airtime per message — the airtime budget constrains how aggressively we can trade throughput for resilience
The system should calculate airtime cost before parameter changes and reject configurations that would exceed limits

Firmware Requirements

RNode firmware must support runtime parameter changes without radio restart (check current RNode firmware capabilities when implementing)
Parameter changes should be atomic — no partial reconfiguration states
Logging of all parameter changes for post-incident analysis

Relationship to Styrene Pub/Sub

The beacon + pull model is already airtime-efficient. Dynamic modulation makes it resilient:

Beacons are small — they survive even at SF12/minimum bandwidth
Pull requests are on-demand — they can be deferred until channel conditions improve
Emergency broadcasts justify the airtime cost of high-resilience LoRa parameters
The graceful degradation from push (emergency) → beacon+pull (normal) → pull-only (degraded) → IP-backhaul-only (contested) is a single continuum

References

RNode interface configuration: https://reticulum.network/manual/interfaces.html
LoRa modulation parameters: Semtech AN1200.22 (LoRa Modem Design Guide)
ISM band regulations: FCC Part 15.247 (US), ETSI EN 300.220 (EU)
Reticulum CSMA implementation: RNS source, RNodeInterface class
Link coordination protocol: rnode-link-coordination.md
OSINT platform architecture: ../../misc/osint/docs/architecture.md (pub/sub protocol, event flow, deployment topology)