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 A(a): Pi Zero W setup

You screwed up and ordered a “Pi Zero” instead of the “Pi Zero 2″… It’s okay. It’ll still work for our testing as we learn more about RNS. For what it is worth and if it makes you feel any better, I too initially ordered a “Pi Zero” by mistake and had to go back and order the correct device. So, you’re not alone in your predicament. But that fact is that we can still use it. It’ll just be noticeably slower than the preferred “Pi Zero 2” hardware. But since that is what we have… Let’s go!

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

Raspberry Pi Imager → Choose Device: Pi Zero W → Raspberry Pi OS Lite (32-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.

This device has the same wrinkle specific to the “Zeros” in that 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-dev python3-pip python3-venv python3-full build-essential libffi-dev libssl-dev git rustc cargo
python3 -m venv ~/rns-env --system-site-packages
source ~/rns-env/bin/activate
pip install --upgrade pip setuptools wheel
pip install rns --upgrade
sudo usermod -a -G dialout $USER
sudo reboot

The “cargo” and “rustc” entries are worth explaining. Newer versions of the “cryptography” package have a Rust-based backend. On ARMv6 where no pre-built wheel exists, pip will attempt to compile it using Rust. Without Rust installed this fails. Installing it now prevents a confusing mid-process install error later.

Identical to Chapter 3. The Pi Zero W is slower than the Pi 3 and the Pi Zero 2 W, so I give each step a little more time.
The “full-upgrade” in particular can take a lot longer on the Zero.

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*
source ~/rns-env/bin/activate
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:

source ~/rns-env/bin/activate
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 = Yes

[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: Test

Time to test the connectivity of the Pi Zero to the Heltec device

rnsd -v

Step 6: 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.