rnode¶
RNode, Reticulum's LoRa transceiver firmware, on the LilyGO, Heltec and RAK boards it supports
Vendor: various (LilyGO, Heltec Automation, RAK Wireless, unsigned.io, Liberated Embedded Systems) · class: badgelife
Status: untested — catalogued from documented sources, not yet proven here.
Not maintainer-verified: nobody on this project has run this hardware yet. The two facts are recorded separately on purpose (D-027) — a correct recipe and a tested device are different claims.
What it is¶
A LoRa radio modem for Reticulum: an open design and firmware (upstream's RNode_Firmware, GPL-3.0) that turns a common LoRa development board into a serial or Bluetooth device Reticulum can use as a network interface. It is not one product from one vendor. Reticulum's manual lists fifteen supported boards (LilyGO T-Beam, T-Beam Supreme, T3S3, LoRa32, T-Deck and T-Echo, the RAK4631 boards, Heltec LoRa32 and T114, the OpenCom XL, unsigned.io's RNode v2) and says RNode uses raw LoRa modulation and has nothing to do with LoRaWAN.
What you can do with it¶
Carry Reticulum over kilometres of radio with no infrastructure: attach the board, add an RNodeInterface to ~/.reticulum/config with a frequency, bandwidth, spreading factor and transmit power, and every Reticulum program (NomadNet, rnsh, rncp) reaches whoever else is on that channel. An RNode is a different network from Meshtastic's and the two do not talk.
Setup¶
Install the mesh profile (hammunition install mesh), which brings rnodeconf with rns; add yourself to dialout and log out and back in. Attach the board and run rnodeconf --autoinstall as Reticulum's manual describes, then add the interface; docs/guides/mesh-and-reticulum.md section 6 has the stanza and the options. Nothing here has been run against a board.
Known problems¶
Frequency and power are yours to get right. Radio spectrum is regulated and varies by country; upstream's manual says so beside every radio interface. Two things to know before you transmit on an amateur band, stated as disclosure and not as a ruling: Reticulum encrypts every packet, and in the United States Part 97 forbids messages encoded to obscure their meaning on amateur frequencies, so whether a given link is lawful is for you to establish, not for this catalog to say; and upstream's manual says RNodes most commonly use LoRa in the common ISM bands, which have their own power and duty-cycle rules (upstream's RNodeInterface has airtime_limit_long and airtime_limit_short, and id_callsign and id_interval for identification). A serial port that is parked or that you cannot open is the same dialout and parked-device story as any other board. The board lists above are upstream's as read on 2026-10-03, not a claim about which boards work.
What is not yet known¶
RNode is firmware, so it has no USB identifier of its own, and upstream's board list (Boards.h in RNode_Firmware, and Reticulum's manual) names boards but no VID:PID, so no identifier can be taken from it without a capture. A board presents the identifiers of its base module, which the badgelife class and the meshtastic entry already carry as ambiguous. What no source records is what a provisioned RNode reports in its manufacturer and product strings, which is the only thing that could make a per-board rule safe.
Who can close it: nobody on this project owns one — an operator who does can close it with one lsusb (how).
Access and permissions¶
Group membership required: dialout, plugdev — added at install, applies at next login.
Firmware modes¶
- vendor_tool — tooling:
rnsrnodeconf(installed by thernsunit) identifies, flashes, provisions and configures an RNode;rnodeconf --autoinstallwalks through it. It fetches firmware from upstream itself unless told otherwise. Where it fetches from and whether it verifies the download were not measured. Firmware that runs on the board is upstream's, not something this project installs (D-026).