What this chapter means to me

Everything up to this point has been preparation — flashing firmware, writing config files, installing software, making decisions about hardware. Chapter 8 is where I find out if any of it actually works. This is the moment I’ve been building toward: two independent Reticulum nodes, each with their own RNode radio interface, seeing each other over the air for the first time. I’m keeping both nodes physically close for now (both still accessible, both easy to troubleshoot) because proving the link works on the bench before deploying anything remotely is the right order of operations.

My setup going into this test

At this point I have two independent machines running:

• Pi 3 running rnsd with Node 1’s Heltec on /dev/ttyACM0
• Pi Zero 2 W running rnsd with Node 2’s Heltec on /dev/ttyACM0

I have two SSH sessions open, one to each Pi, so I can watch both sides simultaneously. This dual-window view is important: a lot of what I’m looking for in this chapter is activity on both sides at once, and flipping between a single window would make that harder to follow.

Step 1: Start rnsd in verbose mode on both machines

On Pi 3 (Node 1):

source ~/rns-env/bin/activate
rnsd -v

On Pi Zero 2 W (Node 2):

source ~/rns-env/bin/activate
rnsd -v

The “-v” flag is important here, without it, rnsd runs fairly quietly and I won’t see the packet-level activity I’m looking for. With verbose logging on, I can watch individual interface events as they happen. I leave both running in their respective SSH windows and open additional sessions for the diagnostic commands that follow.

Step 2: Watch the startup output carefully

Before I even run any diagnostic tools, the “rnsd -v” output itself tells me a lot. On each Pi I’m looking for:

• The RNode interface reporting as online with its firmware version listed
• The configured frequency showing 869.525 MHz
• No error messages about the port being unavailable or the device not responding

If either node throws errors here, I know immediately whether it’s a config issue (wrong port path, syntax error) or a hardware issue (cable, device not recognized). Catching this at startup means that I’m not chasing phantom problems later.

Step 3: Check interface status with rnstatus

In a third SSH session to Pi 3, with the venv active:

rnstatus -a

This gives me a real-time view of interface status — online/offline state, TX/RX packet counts, current airtime usage, and bitrate. Right after startup with nothing transmitting yet, I expect to see my RNode interface showing as online with airtime near zero. I run the same command in a fourth session on the Pi Zero 2 W to confirm Node 2’s interface independently.

What I’m specifically checking here: both interfaces showing online, not error or initialising. If either shows offline at this point, something is wrong with the USB connection or the config before I even get to the radio test.

Step 4: Watch for the first over-the-air contact

This is the part I find genuinely exciting. I don’t need to trigger anything manually — Reticulum nodes announce themselves periodically by design. Within a minute or two of both rnsd instances being up and running, I should start seeing activity in the verbose log windows that looks something like incoming packet events referencing the RNode interface name.

What I’m watching for on each side is log lines indicating received data on the RNode interface — not just outgoing transmissions, but actual incoming packets from the other node. When I see that on both sides, that’s my first confirmation of a genuine two-way over-the-air link. Two radios, a few centimetres apart on my bench, talking to each other through Reticulum for the first time.

I’ll be honest — when I see those first mutual receive events in the logs, that’s a satisfying moment. A lot of work went into getting here.

Step 5: Check the path table with rnpath

Once some announce traffic has flowed between the nodes:

rnpath -t

This shows all destination paths Reticulum has learned and remembers. Early on, shortly after first startup, this table may still be sparse — path learning takes a little time as announces propagate. But as the nodes run and exchange announces, I should start seeing entries appear. Once Chapter 9’s application layer is running and generating real named destinations, this table becomes much more meaningful — for now it’s a useful indicator that routing information is actually being exchanged.

Step 6: The rnprobe caveat — and why I’m saving it for Chapter 9

I want to use “rnprobe” for a proper ping-style round-trip test, but there’s an important nuance: probes only get answered if the destination is configured to send delivery proofs back. A bare rnsd with no application running on top of it doesn’t present a probeable destination by default; So running rnprobe right now against Node 2 would likely time out, not because the link is broken but because there’s nothing on the other end to answer it.

Once I install Nomad Network in Chapter 9, its LXMF endpoints do respond to probes — which is when rnprobe becomes the clean, meaningful round-trip test I want. I’m flagging this now so I don’t waste time troubleshooting a “failed” probe that isn’t actually a failure.

Troubleshooting — if I see nothing

If after a few minutes neither side is logging any sign of the other, here’s my checklist in order:

Check frequency first. Both configs must show exactly “869525000”. A single digit typo here means the radios are on different channels and will never hear each other regardless of everything else being perfect. I double-check both config files rather than assuming I got it right.

Check antennas. Both firmly attached? It sounds obvious but it’s worth physically confirming — a finger-tight connection that worked itself loose is easy to miss.

Consider proximity desensitisation. If both radios are very close together — same desk, antennas almost touching — at 14dBm I might actually be overloading the receivers with too strong a signal rather than too weak. Counterintuitive but real. My fix: temporarily drop txpower to 2 or 3 in both configs and restart rnsd. If the nodes suddenly see each other at lower power, I know proximity was the issue. I’ll raise it back to 14 before any real deployment.

Check rnstatus airtime. If I see TX events registering on one side but no corresponding RX on the other, the config is probably fine and it’s an RF or physical issue. If I see no TX events at all on either side, something is wrong earlier in the stack — interface not coming up, wrong port, or a config error I missed.

What success looks like

I’m calling this chapter done when I see:

• Both “rnsd -v” windows showing incoming packet activity from the other node
• “rnstatus -a” on both sides showing non-zero RX counts
• “rnpath -t” beginning to populate with learned path entries

That’s a proven, working, two-way radio link between two independent Reticulum nodes. Everything from here builds on top of this moment.

---

The link works. Two nodes, two machines, one mesh. In Chapter 9 I’ll install Nomad Network on both machines and send an actual encrypted message across this link — turning a proven radio connection into a working communications system, and finally getting rnprobe to give me the clean round-trip data I’ve been saving it for.

Making a remote node…

Both nodes are still sitting on my bench plugged into the Pi 3, and everything is working. Now I need to start thinking seriously about what “remote” actually means for Node 2 — because unplugging it from the Pi and moving it somewhere else means it needs its own brain. As I covered back in Chapter 1, the Heltec running RNode firmware has no intelligence of its own. It’s a radio modem. Something has to run rnsd wherever Node 2 physically lives, otherwise it’s just a very expensive antenna.

I’ll apologize up front, as this chapter ended up being more nuanced than I had anticpated, because my plan to use an iPhone as Node 2’s compute ran into some real-world limitations worth being honest about. I’ll walk through the full picture.

The options I considered for Node 2’s compute

Before landing on a decision, I mapped out my realistic options were:

Option A — Second Raspberry Pi or similar SBC The most consistent choice and the most directly parallel to what I’ve already built. A Pi Zero 2 W, Pi 3, or any similar board running rnsd with the Heltec attached via USB. Everything I’ve learned so far applies directly, and it becomes a proper second site with full capability. This is the path I’m going to take.

Option B — Old laptop or always-on desktop Exactly the same software pattern as the Pi — install Python, pip install rns, attach the Heltec, run rnsd. Less elegant for a permanent low-power installation but zero additional cost if the hardware is already sitting around. A completely valid short-term option while waiting for a Pi to arrive.

Option C — Android phone running Sideband via USB-OTG Sideband is a full Reticulum messaging app that can talk directly to an RNode over USB-OTG from an Android phone, no separate Linux box needed. Good for a mobile or temporary node, less ideal as fixed always-on infrastructure since it ties up a phone permanently.

Option D — iPhone running Sideband via Bluetooth This was my original plan, and it’s where I hit a wall worth being transparent about.

The honest state of iOS support

I went into this assuming iPhone support would be straightforward since Sideband exists on iOS. The reality is more nuanced. RNode firmware does support Bluetooth LE, and iOS devices can discover and connect to an RNode over BLE. A TestFlight beta of Sideband for iOS exists and is actively developed. But at this time, feature-wise, it is behind the Android and desktop experience in a few important ways:

iOS connects over Bluetooth only, there’s no USB path available on iPhone the way USB-OTG works on Android. The BLE pairing process involves an out-of-band PIN verification step, with the pairing PIN shown on the RNode’s OLED display, which adds friction to initial setup. And the iOS app has been in active beta development for a while, it works, but it has rough edges that a stable shipped product likely wouldn’t have.

I’m not abandoning the iPhone idea. I actually think it’s genuinely exciting once it works, since it means my phone becomes a standalone mesh client without needing any other compute nearby. But I’ve decided not to make it my primary path to a working remote node, because it adds too many unknowns on top of everything else that’s still new to me. My plan is to get the Pi Zero 2 W working solidly first, then layer in the iOS BLE connection as a parallel experiment once the core mesh is proven.

My decision: Pi Zero 2 W as primary, iOS BLE as parallel experiment

I’ve ordered a Pi Zero 2 W for Node 2’s permanent compute. In the meantime, Node 2 stays on the Pi 3 for all the testing in Chapter 8. Once the Zero arrives I’ll set it up properly, and I’ll pursue the iOS TestFlight path alongside that as a second, optional way to reach the mesh.

---

Track A: Pi Zero 2 W setup

Step 1: Flash the OS — same process as Chapter 3, one wrinkle

Raspberry Pi Imager → Choose Device: Pi Zero 2 W → Raspberry Pi OS Lite (64-bit) → Bookworm (same Trixie/WiFi caveat from Chapter 3 applies here too) → Advanced Options to configure hostname (rns-pi-zero), username/password, WiFi credentials and country, enable SSH → write and verify.

The one wrinkle specific to the Pi Zero 2 W: it has a single micro-USB data port and a separate micro-USB power port. I need to make sure I’m using the correct port — labelled “USB” not “PWR” — for connecting the Heltec, and that I have a micro-USB to USB-C data cable, not a charge-only one. Same cable quality rule as everywhere else in this build.

Step 2: First boot and software install

ssh myusername@rns-pi-zero.local
sudo apt update && sudo apt full-upgrade -y
sudo reboot

Then after reconnecting:

sudo apt install -y python3-pip python3-venv python3-full git
python3 -m venv ~/rns-env
source ~/rns-env/bin/activate
pip install rns --upgrade
sudo usermod -a -G dialout $USER
sudo reboot

Identical to Chapter 3. The Pi Zero 2 W is slower than the Pi 3 so I give each step a little more time — full-upgrade in particular can take a while on the Zero’s single-core-equivalent performance.

Step 3: Move Node 2’s Heltec over

Once the Pi Zero 2 W is set up, I unplug Node 2 from the Pi 3 and connect it to the Pi Zero 2 W instead. The antenna stays on — I never remove it between moves. I verify the Pi Zero sees it:

ls /dev/ttyACM*
rnodeconf /dev/ttyACM0 --info

The firmware I flashed in Chapter 5 is stored on the Heltec itself — nothing needs to be reflashed just because I’ve moved it to a different computer. The --info command should report EU 868MHz firmware exactly as it did before.

Step 4: Configure Reticulum on the Pi Zero 2 W

Generate the default config:

rnsd &
sleep 3
kill %1
nano ~/.reticulum/config

This config only needs one RNode interface — Node 2’s — plus Transport mode enabled so this site can relay for future nodes as the mesh grows:

[reticulum]
  enable_transport = True
  share_instance = True

[interfaces]
  [[RNode Node2]]
    type = RNodeInterface
    interface_enabled = true
    port = /dev/ttyACM0
    frequency = 869525000
    bandwidth = 125000
    txpower = 14
    spreadingfactor = 9
    codingrate = 5
    airtime_limit_long = 10
    airtime_limit_short = 25

Identical radio parameters to what I set on the Pi 3 in Chapter 6. The frequency must match exactly — that’s what lets Node 1 and Node 2 hear each other across the RF link.

Step 5: Keep it nearby for now

I’m resisting the urge to immediately deploy the Pi Zero + Node 2 somewhere interesting. The smarter move is to prove the link works first — both machines within reach, both accessible over SSH, both easy to troubleshoot — and only move Node 2 to its final remote location once Chapter 8 has given me confidence everything is solid. Deploy first, debug remotely later is the harder path. I’ve learned this lesson before on other projects.

---

Track B: iOS Sideband BLE (parallel experiment)

Step 1: Get Sideband via TestFlight

On my iPhone I open TestFlight — installing it first from the App Store if needed — then search for the current Sideband beta link. The TestFlight links for beta apps rotate periodically so I’d recommend searching “Sideband Reticulum TestFlight” to find the current active link rather than me providing one that may have expired by the time you’re reading this.

Step 2: A note on which RNode to use for BLE

BLE and USB-serial can interfere with each other on the same RNode, so I wouldn’t enable BLE on Node 1 or Node 2 while they’re actively serving as my main mesh interfaces. Honestly, this is a good excuse to pick up a third Heltec V4 for BLE experimentation — which aligns with my longer-term plan of growing to 3+ nodes anyway. A third board means I can experiment with BLE without touching the working mesh infrastructure.

Step 3: Enable Bluetooth on the RNode

With the third Heltec connected via USB:

rnodeconf /dev/ttyACM2 --bluetooth on

Step 4: Pair from the iPhone

Open Sideband on the iPhone → navigate to the RNode connection settings → it should discover the RNode broadcasting over BLE → confirm the pairing PIN shown on the Heltec’s OLED display matches what appears on the iPhone → complete pairing.

Step 5: Set matching radio parameters in Sideband

Once paired, Sideband lets me configure the radio parameters directly — I set them to match my mesh exactly: 869.525MHz, 125kHz bandwidth, SF9, 14dBm TX power. This is what lets the iPhone-connected RNode actually participate in the same mesh as Node 1 and Node 2 rather than being on its own isolated channel.

My expectations for this track

I’m going into the iOS BLE path with realistic expectations — this is exploratory, not production. I expect rough edges, possibly some BLE connection drops, maybe app crashes here and there. That’s fine for the “learning and experimenting” goal I set out with at the beginning. The point isn’t a polished experience right now, it’s understanding what’s possible and where the technology is heading.

---

Where I am now

I have a clear two-track plan: Pi Zero 2 W as Node 2’s permanent dedicated compute (ordered, arriving soon), and iOS Sideband BLE as a parallel experiment using a third Heltec. Node 2 stays on the Pi 3 until the Zero arrives and everything is verified. In Chapter 8 I’ll prove the actual radio link between Node 1 and Node 2 works — the most satisfying milestone in the whole build so far.

Bringing Reticulum to life

Both of my Heltec devices are flashed and sitting on the Pi’s USB ports. Right now, they’re just radio modems — verified hardware with firmware on them, but nothing is actually using them – yet. This chapter is where I bring Reticulum to life: creating the config file that tells rnsd about both RNode interfaces, setting the EU-compliant radio parameters I worked out in Chapter 2, and enabling Transport mode so this Pi becomes genuine mesh infrastructure rather than just an endpoint. Getting this config right is probably the most consequential step in the whole build — everything from here depends on it.

Step 1: Generate the default config

Reticulum creates its config directory and a default config file the first time rnsd runs. I’ll start it briefly just to generate that file, then stop it:

source ~/rns-env/bin/activate
rnsd &
sleep 3
kill %1

Now the config exists and I can open it:

nano ~/.reticulum/config

What I see is a default config with a “[reticulum]” section at the top and an “[interfaces]” section below it containing a default “AutoInterface” entry — that’s a LAN multicast interface that’s harmless to leave in place, it just won’t find anything useful in my setup right now. I’ll leave it and add my RNode interfaces alongside it.

Step 2: Enable Transport mode

At the top of the file I find the “[reticulum]” section. I want to set two things here:

[reticulum]
  enable_transport = True
  share_instance = Yes

enable_transport = True — is what promotes this Pi from a simple endpoint into a proper Transport Node. Meaning that it will actively forward traffic between its interfaces on behalf of other nodes, which is the foundation of everything in Chapter 11’s growth plan. Without this, my Pi can only send and receive its own traffic, not relay for others.

share_instance = Yes — means multiple local programs (rnsd, Nomad Network, diagnostic tools) can all share the same running Reticulum instance rather than fighting over the interfaces. This will matter more in Chapter 9 when I add Nomad Network on top.

Step 3: Add the RNode interface for Node 1

Inside the “[interfaces]” section I add my first RNode block:

  [[RNode Node1]]
    type = RNodeInterface
    interface_enabled = true
    port = /dev/ttyACM0
    frequency = 869525000
    bandwidth = 125000
    txpower = 14
    spreadingfactor = 9
    codingrate = 5
    airtime_limit_long = 10
    airtime_limit_short = 25

Let me walk through each setting and why I’ve chosen it, because these aren’t arbitrary numbers — they each connect back to decisions I made earlier:

frequency = 869525000 — 869.525MHz, sitting in the P sub-band (869.4–869.65MHz). I chose this in Chapter 2 specifically because the P sub-band gives me a 10% duty cycle allowance instead of the 1% limit on the crowded M sub-band channels around 868MHz. More breathing room for mesh traffic.

bandwidth = 125000 — 125kHz is the standard LoRa bandwidth and a good balance of range versus data rate. I’m starting here and will tune later if needed.

txpower = 14 — 14dBm works out to roughly 25mW, matching the ≤25mW ERP carrier power limit I noted in Chapter 2. I’m starting at the legal ceiling rather than below it to give myself the best possible link margin, especially once the nodes are physically separated.

spreadingfactor = 9 — SF9 is my chosen middle ground. SF7 or SF8 would be faster and use less airtime, but shorter range. SF11 or SF12 would be extremely long range but painfully slow and very airtime-hungry given my duty cycle budget. SF9 feels like the right starting point for two nodes that aren’t many kilometers apart yet — I can always tune this once I know what the actual RF environment looks like.

codingrate = 5 — the most efficient forward error correction setting. I’m not fighting heavy interference right now, so there’s no reason to use a more conservative (slower) coding rate yet.

airtime_limit_long = 10 and airtime_limit_short = 25 — these are the settings I’m genuinely glad exist. The long-term limit enforces my legal 10% P-band duty cycle over a rolling 60-minute window, and the short-term limit manages brief burst behavior over roughly a 15-second window. What I appreciate about these settings is that they make the firmware itself enforce my legal duty cycle limits regardless of what the application layer tries to send — it’s a practical safety net built into the config, not just something I have to remember to respect manually.

Step 4: Add the RNode interface for Node 2

Same block, different name and port — but, and this is critical, they are set to use the identical frequency and radio parameters:

  [[RNode Node2]]
    type = RNodeInterface
    interface_enabled = true
    port = /dev/ttyACM1
    frequency = 869525000
    bandwidth = 125000
    txpower = 14
    spreadingfactor = 9
    codingrate = 5
    airtime_limit_long = 10
    airtime_limit_short = 25

The frequency must match exactly between both nodes, that’s non-negotiable, or else they won’t hear each other. Everything else (power, SF, airtime limits) should also match for predictable, symmetric behavior across the link, though strictly speaking only frequency and bandwidth need to be identical for basic communication.

One thing I’m conscious of right now: both radios are physically sitting a few centimeters apart on my bench, transmitting at 14dBm. That’s actually fine for testing — an overly strong signal up close doesn’t cause the kind of problems a weak signal does, and I’ll see the real link behavior once the nodes are separated. What I won’t do is crank the power up too high while they’re side by side; that tells me nothing useful and wastes airtime budget.

Step 5: Save and do a live syntax check

I save the file (Ctrl+O, Enter, Ctrl+X in nano) and then start rnsd in the foreground so I can watch the output directly:

rnsd

I’m watching for both RNode interfaces to initialize cleanly. The output should show each one coming online, reporting its detected hardware, firmware version, and frequency. If there’s a config syntax error or a wrong port path, rnsd will usually say so clearly right here rather than failing silently. This is the moment I find out if I’ve made any typos.

If both interfaces show as online without errors, I leave rnsd running in this terminal and open a second SSH session to the Pi for any further work — I don’t want to kill the running daemon just to run a command.

Successful initialization example:

Unsuccessful initialization example:

Where I am now

Both RNode interfaces are configured with EU-compliant, duty-cycle-enforced settings. The Pi is running as a Transport Node with rnsd active and both radios online. What I have at this point is a properly configured Reticulum backbone — two radio interfaces, legal parameters, automatic duty cycle enforcement, and Transport mode enabled. In Chapter 7 I’ll work through deploying Node 2 to its eventual remote location and what compute it needs to run Reticulum independently once it’s no longer plugged into this Pi.

Rinse & Repeat…

Node 1 is sitting on my bench, flashed and verified. Now I need to do the same for Node 2 — the board that will eventually live at a remote location. The flashing process is identical to Chapter 4, but there are a few extra things to think about when two boards are connected to the same Pi simultaneously, and this is also the chapter where I start making decisions about how Node 2 will eventually be deployed. I’ll work through all of that here.

Step 1: Antenna first — same rule, no exceptions

Before I touch the USB cable, the 868MHz antenna goes on Node 2. Same rule as Chapter 2 and Chapter 4 — antenna on before power, every single time. Once it’s attached, I connect Node 2 to a second USB port on the Pi 3.

Step 2: Confirm both devices are visible

With both Heltecs now connected, I check what the Pi sees:

ls /dev/ttyUSB* /dev/ttyACM*

I should now see two device paths — typically /dev/ttyACM0 and /dev/ttyACM1. The important thing here is knowing which path belongs to which board. My method: unplug Node 2, run the ls command, note what’s there — that’s Node 1’s path. Plug Node 2 back in, run ls again, note what’s new — that’s Node 2’s path. Takes thirty seconds and removes all ambiguity.

Step 3: Target the autoinstaller at the correct port

Since both boards are plugged in, I want to be explicit about which one I’m flashing rather than relying on the tool’s auto-scan to pick the right one. I target Node 2’s port directly:

source ~/rns-env/bin/activate
rnodeconf /dev/ttyACM1 --autoinstall

Substituting whichever path I confirmed in Step 2 belongs to Node 2. Being explicit here means there’s zero chance I accidentally reflash Node 1.

I ran into an issue with specifying the /dev/ttyACM1 and getting the node to flash. I ended up just unplugging the first device and then running the command below with only the second device connected: rnodeconf --autoinstall
Then I unplugged both devices and plugged them back in the order that I flashed them. so their /dev/ttyACM* number would match up to what I wanted.

Step 4: Walk through the same prompts as Chapter 4

The sequence is identical — board selection (Heltec V4), experimental warning (hit Enter), frequency/region (868MHz EU — same as Node 1, because both radios need to be on the same channel to hear each other), confirmation screen, flash. If the shutdown step hangs at the end, same fix: press the physical reset button on Node 2 and watch its OLED.

Step 5: Verify from the Pi

rnodeconf /dev/ttyACM1 --info

I’m checking the same things as Chapter 4: firmware version confirmed, frequency showing 868MHz, EU region set. Both boards should now report identical firmware and region configuration — the only difference between them is which USB port they’re on and the label I put on them.

Step 6: Label it immediately

Node 2 gets a piece of tape too: “Node 2 / Remote”. They’re physically identical boards and I do not want to discover I’ve been working on the wrong one an hour from now.

Step 7: A decision I’m flagging now for later

Both nodes are flashed and both are currently sitting on the Pi’s USB ports. Eventually Node 2 needs to move to its permanent remote location — but before I worry about that, I want to prove the radio link actually works with both boards close at hand where I can troubleshoot easily. Deploying first and debugging remotely is the harder path, so I’m deliberately keeping both on the bench until Chapter 8 gives me confidence the link is solid.

When Node 2 does move, it needs its own compute running Reticulum — as I covered in Chapter 1, the Heltec itself has no intelligence without something running rnsd alongside it. My plan, which I’ll work through properly in Chapter 7, is a Pi Zero 2 W as Node 2’s dedicated compute. That’s on order. In the meantime, both boards stay on the Pi 3 for everything through Chapter 8.

One option I’m also curious about exploring later — once I’m comfortable with the standard RNode setup — is standalone bridge firmware for the Heltec that can connect a LoRa network directly to a WiFi/TCP backbone without needing a separate compute at all. I’m treating that as a future experiment rather than part of this initial build, but it’s worth knowing the option exists.

Where I am now

Both Heltec V4 boards are flashed with EU 868MHz RNode firmware, both verified from the Pi, both labelled. Node 1 is on /dev/ttyACM0, Node 2 is on /dev/ttyACM1, and both OLEDs are showing RNode status. In Chapter 6 I’ll configure Reticulum on the Pi — setting up both RNode interfaces with EU-compliant radio parameters and enabling Transport mode — which is where these two radios actually become part of a working mesh rather than just individually flashed modems.

This is where things get real

I’m going to plug in the first Heltec V4, flash it with RNode firmware using rnodeconf, and confirm it comes up correctly as a proper LoRa modem that Reticulum can talk to. Up until now everything has been software preparation. This is the first moment where hardware and software meet.

Step 1: Antenna on, then plug in

I’m following my own rule from Chapter 2 without exception: 868MHz antenna screwed firmly onto the Heltec before the USB-C cable goes anywhere near it. Antenna first, every time. Once it’s on, I connect the USB-C data cable from the Heltec to the Pi 3.

A reminder worth repeating here: if the Pi doesn’t see the device in the next step, the first thing I’ll check is the cable. Charge-only USB-C cables are everywhere and look identical to data cables — swapping the cable has saved me more debugging time than almost anything else.

Step 2: Confirm the Pi sees the device

SSH into the Pi, activate the venv, then check what’s appeared on the USB bus:

source ~/rns-env/bin/activate
ls /dev/ttyUSB* /dev/ttyACM*

The Heltec V4’s ESP32-S3 typically shows up as /dev/ttyACM0 rather than /dev/ttyUSB0 — it uses native USB CDC rather than a separate USB-to-serial chip. Take note whichever path appears, because we’ll need it in a moment.

If nothing shows up at all, my checklist is: try a different cable first, then try a different USB port on the Pi, then check that the dialout group fix from Chapter 3 Step 7 actually took effect (groups should show dialout).

Step 3: Launch the autoinstaller

rnodeconf --autoinstall

This launches an interactive wizard that walks me through everything — device detection, board selection, firmware download, and flashing. I don’t need to know the exact firmware version or download anything manually; rnodeconf handles all of that.

Step 4: Walk through the prompts

This is the part where I need to pay attention rather than just hitting Enter through everything. Here’s what to expect and what to actually select at each prompt:

Port scan — the tool scans for connected serial devices and should find /dev/ttyACM0. If it lists multiple ports (it shouldn’t, since only one Heltec is connected right now), select the one that appeared in Step 2.

Device selection — a numbered list of supported boards appears. I’m looking for the Heltec V4 / Heltec LoRa32 V4 entry. The exact number in the list can shift between firmware releases, so I read the list carefully rather than assuming a number — I select whichever entry matches my hardware.

Experimental warning — the tool may flag Heltec V4 support as experimental since it’s a relatively recent addition. I just hit Enter to continue; this is expected and the firmware works fine in practice.

Frequency/region selection — this is the most important prompt in the whole process. I select 868MHz / EU without hesitation. Not 915MHz, not 923MHz — those are for other regions and would put me outside my legal operating parameters immediately. This is the setting that ties directly back to the Chapter 2 regulatory groundwork.

Confirmation screen — before writing anything, the tool shows me a summary of everything I’ve selected. I read through it carefully, confirm the board type and frequency region are correct, then proceed.

Flash and provision — rnodeconf downloads the firmware and writes it to the board. This takes a minute or two. I leave it alone and let it finish without interrupting the USB connection.

The shutdown step quirk — at the end of the flash process, a scripted shutdown step may appear to hang or throw an error. This is a known cosmetic issue, not a real failure. If it happens, I just press the physical reset button on the Heltec board and watch the OLED display.

Step 5: Confirm success on the OLED

Once flashing completes, the Heltec’s OLED display should show RNode firmware status information — not the stock Heltec boot logo, not a Meshtastic splash screen, but RNode’s own status readout. Seeing that on the screen is my first visual confirmation that the flash worked.

Step 6: Verify from the Pi

I run a non-destructive info query to confirm the firmware and settings from the Pi’s side:

rnodeconf /dev/ttyACM0 --info

This should report back the firmware version, the configured frequency, and hardware details. The thing I’m specifically checking here is that the frequency shows 868MHz and the region is set to EU — that’s the detail most worth confirming before I go any further, because a misconfigured frequency here means two nodes that will never hear each other no matter how good the rest of the setup is.

Step 7: Label it

This sounds trivial and I nearly skipped it the first time — don’t. I put a small piece of tape on this board and write “Node 1 / Pi” on it. Since the boards look identical, once I have two flashed Heltecs sitting on my bench, I’ll be grateful they are labeled.

---

Node 1 is flashed, verified, and labelled. The OLED is showing RNode status, rnodeconf –info confirms the EU 868MHz configuration, and the Pi can see it cleanly over USB. In Chapter 5 I’ll do the exact same process for the second Heltec — the one that will eventually live at the remote site — and then I’ll have both boards ready to configure together.

Where I’m starting from

My Pi 3 is sitting in front of me with a blank SD card — nothing on it yet. I’ll be accessing it headlessly over SSH from my main computer, so I need to get the OS imaged and SSH configured before the Pi even boots for the first time. This chapter is purely software and setup — no Heltec hardware involved yet.

Step 1: Flashing the OS with Raspberry Pi Imager

I downloaded Raspberry Pi Imager from raspberrypi.com/software onto my main computer. The process is straightforward but there are a couple of choices worth making deliberately rather than just accepting defaults.

Insert the SD card, open Imager, then:

1. Choose Device → Raspberry Pi 3
2. Choose OS → Raspberry Pi OS (Other) → Raspberry Pi OS Lite (64-bit)

I’m going with Lite deliberately — I don’t need a desktop environment on a headless node, and keeping it lean means more CPU and RAM available for rnsd and mesh traffic later. Less cruft, more performance.

⚠️ NOTICE: as of late 2025, the newest Raspberry Pi OS images based on Debian Trixie have WiFi issues that can prevent headless setup from working on first boot. I’m sticking with the Bookworm image. If Imager only offers you Trixie and your Pi will be on Ethernet rather than WiFi, this doesn’t apply — but for a WiFi-based headless setup like mine, Bookworm is the safer choice right now.

3. Click the gear/settings icon (Advanced Options) before writing — this is the crucial step for headless setup. Here I configure:
   • Hostname: rns-pi
   • Username and password
   • WiFi SSID and password, plus WiFi country (important — set this to your actual country)
   • Timezone and locale
   • Enable SSH (password authentication is fine to start)
4. Write the image and wait for verification to complete before ejecting.

Step 2: First boot

SD card in the Pi, power it on, and wait about 90 seconds — it does an automatic first-boot resize and reboot cycle before settling. Then from my main computer:

ssh myusername@rns-pi.local

If .local hostname resolution fails (some routers block mDNS), I can find the Pi’s IP address from my router’s admin interface and SSH directly to that instead. Once I’m in, I know the hard part of headless setup is done.

Alternatively, you could just use an app like PuTTY if you already have it installed on your computer.

Step 3: Update everything first

Before installing anything, I want the system fully current. So let’s update and upgrade everything:

sudo apt update && sudo apt full-upgrade -y
sudo reboot

Reconnect via SSH after the reboot. This takes a few minutes on a Pi 3 — worth being patient rather than rushing past it.

Step 4: Install Python prerequisites

Raspberry Pi OS Bookworm ships with Python 3 already, but I need pip, venv tools, and a couple of extras:

python3 --version
sudo apt install -y python3-pip python3-venv python3-full git

Step 5: Set up a virtual environment

Here’s something that caught me out initially: Raspberry Pi OS Bookworm enforces PEP 668, which means a bare pip install at the system level gets refused. The clean solution is a Python virtual environment dedicated to Reticulum — it also means everything stays tidy and isolated from any other Python tools I might add later.

python3 -m venv ~/rns-env
source ~/rns-env/bin/activate

I’ll need to run that source command at the start of any new terminal session where I want to use these tools. It’s a small habit to build — and in Chapter 10 when I set up systemd services, the always-on daemon side of things handles this automatically anyway, so it only matters for interactive sessions.

Step 6: Install Reticulum and rnodeconf

With the venv active:

pip install rns --upgrade

This single command installs the full Reticulum Python package, which includes everything I need:

• the Reticulum daemon itself — rnsd
• the RNode firmware flashing and configuration tool I’ll use in Chapter 4 — rnodeconf
• the diagnostic tools I’ll lean on heavily in Chapter 8 — rnstatus rnpath rnprobe

Let me verify both key tools installed correctly:

rnsd --version
rnodeconf --version

If both return version numbers without errors, I’m in good shape.

NOTE: At the time of writing this post and stepping through everything, rnsd = v1.3.5, and rnodeconf = v2.5.0.
Parts of this write-up may be different if there is a large delta between the versions what I am using here and future builds.

Step 7: Sort out USB serial permissions

This is a small but important step that’s easy to forget and causes confusing errors later. My user account needs permission to access serial ports (/dev/ttyACM0 etc.) without requiring sudo every time:

sudo usermod -a -G dialout $USER

This group change doesn’t take effect in the current session — I need to log out and back in, or just reboot:

sudo reboot

Reconnect via SSH after reboot and confirm the group is applied:

groups

I should see dialout in the list. If it’s there, the Pi is fully prepped.

Where I am now

At this point my Pi 3 is updated, has a clean Python venv with Reticulum installed, and has serial port permissions sorted. Nothing is physically connected to it yet — the Heltec boards are still sitting on my bench with their antennas attached, waiting for Chapter 4 where I’ll plug the first one in and flash it with RNode firmware.

Getting my hardware sorted

Before I plugged anything in or installed a single package, I wanted to make sure I had everything I needed on the bench and that I understood the legal framework I’m operating within. Running LoRa in the EU isn’t complicated, but there are real limits I need to respect — and getting them wrong doesn’t just risk a fine, it directly affects whether my mesh actually works well in practice.

Here’s what I’m working with:

Item	Notes
2× Heltec WiFi LoRa 32 V4 boards	Confirm they’re the standard V4, not the Expansion Kit or Touch variant — those are different flash targets
2× antennas (868MHz!)	Must match the actual frequency I’m using. A 915MHz US antenna won’t perform correctly here
2× USB-C cables	Must be data-capable, not charge-only cables. This trips people up constantly — cheap cables often carry power only and the Pi simply won’t see the device
Raspberry Pi 3	With its usual PSU, SD card, and case. You could use a newer model.
(Later) Pi Zero 2 W + power supply	For the remote node compute — not needed yet, just on order

The antenna rule I’m treating as non-negotiable

The very first thing I learned about these boards: always attach the antenna before powering on. Transmitting into an open port with no antenna can destroy the SX1262 RF frontend almost instantly — it’s not a maybe, it’s a when. So my rule is simple: antenna on, every single time, before any USB plug-in or power-up. I’m making this a reflex now so it never becomes a mistake later.

EU 868MHz — what I actually need to know

This is where it gets interesting from a regulatory standpoint, and as someone interested in RF I actually wanted to understand this properly rather than just copy settings from a tutorial. The 863–870MHz band we’re operating in isn’t technically an ISM band in the ITU sense — it’s a Short Range Device (SRD) band, governed by EC regulation with ETSI EN 300 220 as the harmonised technical standard. Two limits matter for my build:

Transmit power: carrier power is capped at ≤25mW ERP on the relevant sub-bands. The Heltec V4 is technically capable of much higher output at the chip level — I must not run it at full power on a licence-free EU channel. 25mW ERP works out to roughly 14dBm, which becomes my target TX power setting when I get to Chapter 6.

Duty cycle: the band is divided into sub-bands with different duty cycle limits. The two I care about are:

Sub-band	Frequency range	Duty cycle	My take
M	868.0–868.6MHz	1%	Home to the three standard channels (868.1, 868.3, 868.5MHz) — heavily used, only 36 seconds of TX per rolling hour
P	869.4–869.65MHz	10%	Less crowded, 6 minutes of TX per rolling hour — much more breathing room for a mesh

I’ve decided to run on 869.525MHz (P sub-band) for exactly this reason. The 10% duty cycle gives my mesh room to actually function — periodic announces, message traffic, and the occasional file transfer — without constantly bumping into the legal ceiling. On a 1% channel, a busy mesh starts throttling itself into near-uselessness surprisingly quickly.

Why this isn’t just a legal checkbox

This is the part I find genuinely important to understand: getting the duty cycle configuration wrong isn’t just a regulatory problem, it’s a practical one. RNode firmware enforces duty cycle limits in software once I tell it the correct region and parameters. If I configure things incorrectly — say, too aggressive an announce interval on a 1% channel — the firmware will throttle my own transmissions and the mesh will feel sluggish or drop packets entirely. Setting this right in Chapter 6 directly determines whether my network performs well, not just whether it’s legal.

One thing worth noting: some EU member states have national variations on top of the ETSI baseline. Since I’m in Germany, the Bundesnetzagentur is the relevant authority — but for the power and duty cycle limits above, the ETSI EN 300 220 baseline keeps me safe and compliant. Worth a quick check against your own national regulator if you’re following along from elsewhere in the EU.

---

Hardware is on the bench, antenna rule is locked in, and I understand the regulatory framework I’m operating within. In Chapter 3, I’ll start getting the Raspberry Pi 3 ready — OS, Python, and installing the Reticulum tools I’ll need before anything gets plugged in.

What Reticulum actually is

Before I touch a single piece of hardware, I wanted to make sure I actually understood what the Reticulum Network Stack (RNS) is — and what makes it different from the other mesh networking tools I’d come across. The short answer is that Reticulum isn’t a mesh radio protocol like LoRaWAN or Meshtastic. It’s a full networking stack — think of it as a replacement for the whole TCP/IP suite — that’s completely transport-agnostic. It can run over LoRa, packet radio, WiFi, TCP/IP, serial cables, even data-over-audio. The same Reticulum identity and the same application can move seamlessly across any combination of these at once. The LoRa nodes I’m building are just one interface type Reticulum can use, which is part of what makes this so interesting.

Three ideas make this stack genuinely different from typical networking, and I think they’re worth understanding before diving into the hardware:

• Identity, not address. Every node and every user has a cryptographic identity — a keypair. You don’t route to an IP address, you route to a destination hash derived from a public key. This means encryption and addressing are unified from the ground up, with no central authority handing anything out.
• No central authority. No DNS, no IP allocation, no certificate authority. Nodes discover each other and build routing tables organically through announcements. Nothing about this network depends on any external service staying online.
• Initiative-based routing. Nodes announce themselves periodically. Other nodes hear those announcements, remember the path, and that’s how packets get routed later. There’s no constant polling or handshaking overhead — which matters enormously on slow LoRa links where every transmission costs airtime.

The four logical layers in my build

When I mapped out what I’m actually building, it breaks down into four layers sitting on top of each other:

[ Application ]   Nomad Network / Sideband / custom scripts
        |
[ Reticulum (RNS) ]  rnsd daemon — routing, encryption, transport logic
        |
[ Interface ]     RNode firmware — turns LoRa radio into a packet modem
        |
[ Radio (PHY) ]   Heltec V4 + SX1262 chip, 868MHz EU ISM band

My Raspberry Pi 3 runs the middle two as a single process: rnsd (the Reticulum daemon) talks out over USB serial to the Heltec, which is running RNode firmware and only deals with the radio physics. The Heltec itself doesn’t know anything about identities, encryption, or routing — it just shuttles KISS-framed packets between USB and RF. All the intelligence lives in rnsd on the Pi. That clean separation is one of the things I find elegant about this design.

Why this matters for my plan

Right now my plan is: Pi (with RNode #1 on USB) ↔ RF ↔ standalone RNode #2. But for Node 2 to be useful, something needs to run Reticulum on the other end — otherwise it’s just a radio with no brain. My real options, which I’ll work through properly in Chapters 5 and 7, are:

1. Second compute near Node 2 — another Pi, a laptop, a phone running Sideband — attached to the Heltec via USB, giving me a second full site with complete app capability.
2. TCP/WiFi bridge firmware on the remote Heltec — bridges LoRa to a WiFi/TCP backbone without needing separate compute, but it’s a different, less mature firmware path I’ll explore later once I understand the basics.
3. Single Pi, two RNode interfaces — both Heltecs plugged into the same Pi via USB, which is actually the smartest way to start: prove everything works on the bench before deploying anything remotely.

Given where I’m starting, my plan is to validate everything with both Heltecs plugged into the Pi first, then physically separate them once I’m confident the radio link and configuration are solid.

The Transport concept — important for where this is going

One concept I want to flag early because it shapes everything that follows: a Reticulum node can be configured as a Transport Node, meaning it actively forwards traffic for others, not just sends and receives its own. My Pi 3, sitting at a fixed location with reliable power, is the natural candidate to become a Transport Node as I scale to 3+ nodes. This is what turns “two devices that can talk to each other” into actual mesh infrastructure — and it’s something I’ll enable in Chapter 6 and revisit properly when we get to Chapter 11.

---

That’s the conceptual foundation I’m working from. In Chapter 2, I’ll get into the physical hardware and the EU radio regulations I need to respect before anything gets powered on — including some rules around duty cycle and transmit power that will directly affect how I configure everything later.

• Chapter 0 — Introduction to Reticulum
• Chapter 1 — Concepts & Architecture
• Chapter 2 — Hardware & Legal Prep
• Chapter 3 — Prep the Raspberry Pi 3
• Chapter 4 — Flash RNode Firmware onto Heltec V4 (Node #1, attached to Pi)
• Chapter 5 — Flash the Second Heltec V4 (Remote Node)
• Chapter 6 — Configure Reticulum on the Pi
• Chapter 7 — Deploy the Remote Node
• Chapter 8 — First Contact: Testing the Link
• Chapter 9 — Running an Application
• Chapter 10 — Running rnsd as a Service
• Chapter 11 — Growing to 3+ Nodes & Next Steps
• Chapter 12 — Adding a Cloud Node
• Chapter 13 — Adding a Nomad Network Propagation Node

So, what exactly is Reticulum? Pronounced Reh-TIK-yoo-lum, it comes from Latin, meaning “small net” or “little network” — which is a pretty perfect name for what it does. Reticulum is a networking stack built for the real world — the one where you are operating from a hilltop, a remote cabin, or the back of a vehicle, and the internet is either unavailable, unreliable, or simply not something you want to depend on. It is designed to run across whatever physical links you have available: LoRa radio, packet radio, WiFi, serial cables, or even audio tones over a soundcard. Unlike conventional networking, which assumes stable connections and centralised infrastructure, Reticulum treats those things as a luxury rather than a requirement. The same application, the same identity, and the same encrypted conversation can move across all of those link types simultaneously — the network figures out the best path on its own.

For those familiar with packet radio, Reticulum will feel conceptually familiar in some ways: it uses KISS framing over radio links, supports multi-hop routing, and is built around the idea that nodes should be able to find and communicate with each other without any central coordination. But it goes considerably further. Rather than assigning addresses from a central authority, every node and user on a Reticulum network is identified by a cryptographic keypair — your address is your public key, and encryption is built into the addressing system from the ground up. There is no network administrator handing out addresses, no DNS server to look up, and no single point of failure. Nodes announce themselves periodically, others hear those announcements and build routing tables from what they actually receive, and the mesh grows organically from there.

For the LoRa and IT community, Reticulum offers something that most LoRa platforms do not: a full, general-purpose networking stack rather than a purpose-built application. Platforms like Meshtastic are excellent for what they do, but they are largely fixed-purpose messaging systems. Reticulum is a foundation you can build anything on — messaging, file transfer, remote monitoring, custom applications — while remaining transport-agnostic underneath. Low-cost hardware like the Heltec WiFi LoRa 32 V4, flashed with open-source RNode firmware, becomes a capable radio modem that a Raspberry Pi can use as one interface among many, routing traffic intelligently across whatever links are available.

In the chapters that follow, I invite you to join me as I dive step by step into building my own Reticulum network from scratch — two LoRa nodes, a Raspberry Pi as a persistent routing node, EU-compliant radio configuration, and a growing mesh I plan to expand over time to include a cloud node. This is not a polished how-to from someone who has done it a hundred times — it is a genuine exploration of what is possible, documented as I go. Whether your interest is emergency communications, off-grid connectivity, decentralised networking, or simply seeing what capable radio hardware and thoughtful software can do together, I hope you will find something here worth taking back to your own shack.

DISCLAIMER: Laws change over time. Useable radio frequencies vary by region and country. Ability to transmit encrypted signals can also vary by region and country. Make sure you have looked up, read, and understand what is allowed and acceptable where you are. Remember that YOU are responsible for what you transmit.

Reticulum outline of what I will be covering…

Chapter 0 — Reticulum Network Stack
Introduction to RNS

Chapter 1 — Concepts & Architecture
What Reticulum actually is, how RNode/Pi/app pieces fit together, and how your 2-node topology will grow.

Chapter 2 — Hardware & Legal Prep
Heltec V4 unboxing/antenna safety, USB cables, EU 868MHz duty-cycle/power rules you must respect.

Chapter 3 — Prep the Raspberry Pi 3
OS, Python, drivers, installing Reticulum (rns) and rnodeconf.

Chapter 4 — Flash RNode Firmware onto Heltec V4 (Node #1, attached to Pi)
Using rnodeconf –autoinstall, selecting Heltec V4, setting EU 868MHz region.

Chapter 5 — Flash the Second Heltec V4 (Remote Node)
Same process, plus deciding if it’ll be USB-tethered to a second compute, battery-powered standalone, etc.

Chapter 6 — Configure Reticulum on the Pi (~/.reticulum/config)
Defining the RNode interface, frequency/bandwidth/spreading factor/power settings, enabling Transport mode.

Chapter 7 — Deploy the Remote Node
How the second node connects to the mesh — same Pi via second RNode, separate compute, or standalone via WiFi/TCP bridge.

Chapter 8 — First Contact: Testing the Link
Using rnstatus, rnpath, ping tools to confirm the two nodes see each other.

*** COMING SOON — STAY TUNED ***

Chapter 9 — Running an Application
Install Nomad Network (or Sideband) on the Pi/phone, send a real message across the mesh.

Chapter 10 — Running rnsd as a Service
Making the Pi a persistent always-on Transport node (systemd), so it’s real infrastructure, not just a foreground process.

Chapter 11 — Growing to 3+ Nodes & Next Steps
Multi-hop considerations, Transport nodes, propagation nodes, planning antenna placement.

Chapter 12 — Adding a Cloud Node
Making a permanent, internet-reachable rendezvous point with a static IP

Chapter 13 — Adding a Nomad Network Propagation Node
Adding “Store-and-Forward” mesh capability to the cloud node