Ten Kilometres Starts with a Link Budget, Not Maximum TX Power
The desire for multi-kilometre range could easily turn into a single-variable question about how many dBm the radio can transmit.
The desire for multi-kilometre range could easily turn into a single-variable question about how many dBm the radio can transmit.
The USB-visible ESP32-C6 bridge made it easy to confuse the bridge MCU with the ESP32-S3/LR1121 radio target behind it.
The interesting architecture is not choosing radio or IP; it is letting Reticulum use different interfaces for different reachability conditions.
Changing one LoRa parameter to chase range can quietly change airtime, sensitivity and compatibility elsewhere.
The same Reticulum instance needed to bridge local IP-connected peers and radio-connected peers without pretending TCP and LoRa were the same medium.
A successful point-to-point packet is necessary but insufficient evidence for a useful multi-node transport network.
Over-air configuration cannot recover a remote module whose stored mode/profile is unknown if that unknown state prevents the OTA command itself.
A high-power remote module made it tempting to run both nodes at maximum output during bench debugging.
Auto-scanning many SF/BW combinations helped discover compatibility clues but could not replace an agreed production PHY.
The lab used both 433-class LR1121/E22 work and an 867.2 MHz RNode profile, which could easily be mixed in memory.
Frequency, bandwidth, SF, coding rate and device mapping were being changed during experiments and could easily become undocumented shell history.
Having only a 2.4 GHz antenna available created pressure to use it for sub-GHz experiments just to continue testing.
Long automatic scans produced hundreds of lines that were hard to compare across runs.
A long-running rnsd process could appear healthy while its RNode device disappeared or the interface failed.
The E22 AUX pin changed around transmissions, but the remote EWM still returned no bytes.
Silence from the EWM looked like a hardware failure but the observation did not isolate which half of the wireless path was wrong.
Having multiple radio boards powered and visible created a false sense that a multi-node Reticulum network already existed.
A receiver can detect energy or even preamble-like activity while rejecting the packet format expected by the application.
Different EBYTE operating modes made it possible for both devices to be powered and configured yet unable to execute the intended over-air management transaction.
Linux services can probe new serial devices and interfere with a host-controlled radio before Reticulum starts.
Raw host tty names leak host enumeration details into Reticulum configuration and make migration harder.
A working RNode can disappear after reboot if the host binds to a transient tty name that changes when USB devices reorder.
Generic transparent traffic could fail for many reasons, so the investigation needed one manufacturer-documented transaction with a predictable reply.
A scan could fail to decode a packet yet still reveal that one PHY was closer to the transmitter than all the others.
Once identity, addressing and transport were layered over LoRa, the experiment stopped being just two radios sending bytes.
Early experiments were tempting to interpret as radio-range evidence even when the nodes did not yet have confirmed band-appropriate antennas.
Two healthy RNodes can be mutually deaf when frequency, bandwidth, spreading factor or coding rate differ.
Flashing through the bridge looked ambiguous because the USB side and target side were different MCUs.
Turning on Reticulum transport was more than a logging preference because it changed how the host participates in forwarding.
Docker made RNS reproducible, but the radio still existed as a physical character device outside the container.
The name LoRa is often used as if it describes an entire network. But the way information is represented over the radio and the rules for operating a multi-device network are different layers. LoRa and LoRaWAN are a useful example of that boundary.
Repeated no-response behavior at different physical setups did not prove a pure propagation problem because the remote device mode/profile was still uncertain.
The local module read and configured correctly, creating a strong temptation to declare the radio side healthy.