Procurement,
with reasons.
For the MVP field test: 2 hubs (one of them the gateway) + 3 endnodes. Every line item has a reason. Two rules set the whole list — which radio chip, and how many watts at the solar hub.
Got compatible hardware? Become a field tester.
zBRETT lives from everyday use. If you already own a suitable LoRa device, help us test the end-user experience — as an endnode in a real city network. We're looking for volunteers with nRF52840 + SX1262 on the 868 MHz band (EU868).
Not sure your device qualifies? Just send us the model — we'll tell you whether it's RNode-capable. ⚑ = interesting, but the firmware port is still in progress.
Sign up as a tester ↵The rule everything follows from
An RNode is a modem, not a computer. The Reticulum firmware on the board only does the radio. The real stack — RNS, LXMF, brettd and above all the DutyCycleInterface — runs on a host that talks to the modem over USB-serial (KISS).
| Role | Needs a host? | Why |
|---|---|---|
| Hub | Yes, mandatory | The DutyCycleInterface is an RNS interface. RNS doesn't run on the board. |
| Endnode | Yes — but the phone counts | Sideband on Android talks to the RNode over BLE/USB. |
| Gateway | Yes — plus IPFS | Kubo needs a Linux host anyway. |
Every hub is board + SBC.
This is the most important sentence on the page. Where an overview lists “RAK4631 / T-Beam,” it implies the board is the hub. It isn't — and that doubles the parts list per hub, which is why solar becomes a topic at all.
SX1262 only. No SX1276.
Two entries in older documents are wrong and get replaced. The SX1262 correction is strategic, not cosmetic.
| It says | The truth is | Why it matters |
|---|---|---|
| Endnode: “ESP32 + SX1276” | SX1262 (T-Deck, RAK4631) | SX1276 is the old generation. SX1262 has +22 dBm, lower draw — and Channel Activity Detection in hardware. |
| Hub: “RAK4631 / ESP32” | RAK4631 = nRF52840 | Cortex-M4F, 256 KB RAM. Not an ESP32. The B3 rationale (“no BLS crypto on ESP32”) doesn't apply here at all. |
Decision A1 (duty cycle instead of LBT) was made partly because LBT needs hardware that can do it. SX1262 can do CAD. The upgrade path to LBT/AFA — 10× the budget — stays open, provided nothing with SX1276 is bought.
Bill of materials
| Item | Part | Qty | Note |
|---|---|---|---|
| Radio | RAK4631 (WisBlock Core, 868 MHz) | 2 | nRF52840 + SX1262, 1 MB flash / 256 KB RAM |
| RAK5005-O baseboard | 2 | Carrier board for the RAK4631 | |
| Host | Raspberry Pi 4 (2 GB) or Pi Zero 2 W | 2 | Mandatory — carries RNS + DutyCycleInterface + brettd |
| microSD 32 GB, industrial | 2 | 24/7 operation; consumer SD dies on the write cycle | |
| Antenna | 868 MHz omni, ≥3 dBi, outdoor | 2 | The biggest range lever there is |
| Lightning / surge protection | 2 | Not optional for roof mounts | |
| Coax LMR-200/240, ≤3 m | 2 | Keep it short — cable loss eats transmit power | |
| Power | Solar 30–50 Wp · LiFePO4 12 V/20 Ah · MPPT · DC-DC 5 V | 2 | No Li-Ion. Sizing → §5 |
| Uplink | LTE stick or Wi-Fi range | 2 | The gateway role needs internet |
| Enclosure | IP65, UV-stable, cable glands | 2 |
The gateway isn't a separate device — it's hub #1 with an SSD and Kubo. The diagram draws it apart only for legibility.
LilyGO T-Deck Plus (868 MHz): ESP32-S3, SX1262, keyboard, display, 1400 mAh battery, GPS. For the MVP in RNode mode on a host — tests “will anyone carry it?”
RAK4631 + baseboard flashed as an RNode, plus Android with Sideband. Tests the standard LXMF path with no special firmware.
This item isn't an add-on — it's the first order.
2× RAK4631 + baseboard · 1–2× Raspberry Pi 4 or Linux laptop (rnsd with packet logging) · 2× 50 Ω/SMA dummy load · 2× 20–30 dB attenuators. M1 decides whether the architecture holds.
Why these parts
The deciding factor is the T-Beam's batch uncertainty: “SX1276/8 or SX1262” means you only know on unboxing. For devices meant to sit on roofs for years that's an unacceptable risk — it could wreck the LBT path. On top of that the nRF52840 draws ~2 µA asleep; on solar in a Berlin December every µA counts.
zBRETT uses Reticulum, not Meshtastic. The hardware overlaps, the firmware doesn't. A board is flashed to an RNode with rnodeconf — Meshtastic firmware is overwritten in the process.
A 24/7 solar node in Berlin does ~300 charge cycles/year and sees −10 °C. Li-Ion takes permanent damage when charged below 0 °C. LiFePO4 tolerates it, lasts 2000+ cycles and doesn't burn.
At a 1% duty cycle transmit power isn't the bottleneck — time is. A better antenna improves the link without costing a fraction of a second of airtime. The only range gain that takes nothing from the budget. Money into antenna and height, not PA modules. And: never transmit without an antenna — it destroys the PA permanently.
What's still to be calculated
Solar sizing, Berlin, December.
The critical month averages ~1 sun-hour/day. From the Pi 4 base load (~3 W) plus the RNode (~0.5 W) follows panel and battery need — plus reserve for a week of fog. The result could be that the Pi 4 is too hungry and a Pi Zero 2 W or an nRF-native approach is needed. A real architecture question, not a procurement one.
Site selection.
Two hubs with line of sight or ≤3 km. Berlin is flat enough, but roof access, power and lightning protection decide more than the straight-line distance.
Procurement order
Bench
2× RAK4631 + baseboard, 1× Pi/laptop, dummy loads. Now — M1 blocks everything.
Hub hardware
Rest of the hubs, antennas, solar. After M1.
Endnodes
T-Deck ×2. Before phase 4.
Gateway SSD
Before phase 5.
Stage 1 is the only one that should be ordered now. If M1 turns out badly, the whole governor approach may change — and with it whether hubs even need a Pi or something bigger.
Open items
Calculate solar sizing for Berlin December
Decides Pi 4 vs. Pi Zero 2 W.
Confirm two sites with roof access and ≤3 km
Roof access, power, lightning protection.
Lightning-protection concept for roof mounts
An insurance question — not optional.
Is an nRF-native brettd feasible?
Would halve power draw and parts list, but it's a substantial porting effort.