First packet across real air: Reticulum over a dictyon carrier
Two Heltec V3 radios, one evening, and a round-trip time predicted before it was measured. What the first real-RF runs of Dictyon-net taught me about honest arithmetic.
For months, Dictyon-net lived in simulations and loopback tests — 598 of them, no network, no radio, about five seconds to run. On the night of September 27th it met real air.
Two Heltec WiFi LoRa 32 V3 boards (ESP32-S3 plus an SX1262 radio) running RNode firmware, both plugged into one laptop, about 30 cm apart, at 914.875 MHz and 0 dBm. The first full exchange — announce, path discovery, handshake, delivered message — took six seconds, on the first attempt.
The pivot that made it matter
Dictyon-net started as a competing network stack: its own addressing, handshakes, routing and transport. All of it ran. It was still the wrong thing to build, for one reason that outweighs the rest: that code had never had a security review, and hand-written cryptography in a stack meant for people in difficult situations isn't something to ship on optimism. Reticulum's crypto has had years of people trying to break it.
Measured honestly, the network layer was 34% of the codebase and the least differentiated part. The part with no equivalent elsewhere was the carrier layer — the code that knows what a physical medium actually costs. So that became the product: a DictyonInterface that gives Reticulum media it doesn't model today.
| Reticulum interfaces | dictyon carriers | |
|---|---|---|
| Duty cycle | Trusted to the operator | Enforced — a token bucket refuses to transmit and holds the frame |
| Airtime | Estimated from bitrate | Exact, per Semtech AN1200.22 |
| Cost to open a medium | Assumed zero | Modelled — a phone call costs ~27 s before a byte moves |
| Receive-only media | Awkward | First-class: send() raises |
The number that makes the case
At SF12/125 kHz, LoRa's nominal bitrate is 183 bps. Once the preamble is paid for, you get 115. An interface that reports the label makes everything above it pace the slowest link in the world as if it were half again faster.
When Reticulum ran over a dictyon carrier, it reported exactly what the carrier told it:
DictyonInterface[Dictyon LoRa]
Status : Up
Rate : 10.19 kbps, MTU 222MTU 222 is the carrier's, not Reticulum's default of 500. 10.19 kbps is the effective rate against 10.94 nominal. An rnpath broadcast then produced ↑51 B ↓51 B on both interfaces — matching byte counts in both directions, meaning each frame crossed the air whole.
The 117 ms nobody had counted
The airtime formula is exact about how long a frame occupies the channel. It says nothing about the USB serial round trip, the RNode firmware's queueing or the host's poll loop. The first run's log measured it: about 117 ms per frame, fixed — 1.5× the airtime itself at SF7.
That one number turned out to be enough to predict the next experiment.
Predicting the round trip before measuring it
The following run used two fully independent Reticulum nodes — separate identities, one radio each. Before looking at the results, the round trip for a signed probe was predicted from first principles:
RTT = airtime(131 B probe) + airtime(83 B proof) + 2 × 117 ms
= 108 ms + 74 ms + 234 ms
≈ 416 ms (range 374–480 from the measured overhead spread)Twelve probes, twelve valid signed replies, 0% loss. Mean 437 ms, all twelve inside the predicted range. Nothing was fitted after the fact.
What I took from it
- Report the effective number, not the label. Every honest property of a medium compounds into something you can predict.
- Measure the overhead you didn't model. The 117 ms wasn't in any formula; it came from a log, and it made the next result predictable.
- Stop competing where someone else is better. Handing identity, routing and crypto to Reticulum was the best decision the project made.
What isn't done yet is just as important: range, loss and multi-hop behaviour on real RF are unmeasured, and nothing has had a security review. Two radios on one desk is a beginning, not a deployment.