RNode Firmware and the open radio node you build yourself

A system spread across devices, not one product

The project is unusually explicit about what it is. An RNode is an open, free and unrestricted digital radio transceiver that lets anyone send and receive any kind of data over short and very long distances. What makes it different from a radio you buy is stated directly: RNode is not a product, and not any one specific device in particular. It is a system that is easy to replicate across space and time.

The system is primarily software, and that software transforms available hardware into a functional node. The repository shows a board in a 3D printed case made from readily available parts, and the documentation says the designs, guides and software stored within allow users to create more nodes, even to bootstrap entire communications networks, independently of existing infrastructure, or where infrastructure has become unreliable.

That is the audience in one line. The target reader is a builder who already thinks in terms of hardware, radios and long-range links, and who wants the freedom to change the node rather than accept what a vendor shipped. The topics carried by the repository are lora, mesh-networks and radio, which is the honest summary.

Coupled with Reticulum, the node provides encrypted and secure communications. On its own it is a low-power, extremely long-range digital radio that can be configured for local networking or for very long distances.

Radio drivers, board files and power management in C++

The repository root shows what the firmware is made of, and the file names are more informative than any summary would be. There are three radio driver pairs, sx126x.cpp and sx126x.h, sx127x.cpp and sx127x.h, and sx128x.cpp and sx128x.h, which is the clearest sign that the firmware supports several LoRa transceiver families rather than one.

Around them sit the device layer files: Boards.h for board definitions, Device.h, Config.h, Power.h for the power management path, Display.h and ST7789.h for the screen, Graphics.h and Fonts/ for the display assets, Input.h for the controls, Remote.h for the remote control path, and Console.h with a Console/ directory for the on-device console. Modem.h and Framing.h handle the radio protocol layer, ROM.h and Utilities.h hold shared code, and MD5.cpp and MD5.h provide a digest implementation. BLESerial.cpp and Bluetooth.h cover the Bluetooth serial path, which is how a phone talks to the node.

Two build entry points sit at the top level. RNode_Firmware.ino is the Arduino sketch, and the Python Module/ directory holds a Python interface to the device, which is consistent with the primary language listed for the project.

The radio characteristics are documented rather than left implicit. Nodes generally operate in the 433 MHz, 868 MHz, 915 MHz and 2.4 GHz bands, offer configurable on-air speeds from a few hundred bits per second up to a couple of megabits per second, and output between 17 dbm and 27 dbm depending on the transceiver and power amplifier setup.

Building with arduino-cli and the core versions in the Makefile

The build is driven by a Makefile and arduino-cli, and the toolchain versions are pinned in the file itself. Two Arduino ESP core versions are named, with a comment explaining the underlying ESP-IDF version each is based on:

ARDUINO_ESP_CORE_VER = 2.0.17

ARDUINO_ESP_CORE_VER = 3.2.0

The first is described as based on ESP-IDF v4.4.7 and the second on ESP-IDF v5.4.1, so the choice is really a choice of ESP-IDF generation. Whichever you pick, the Makefile installs it through arduino-cli with a configuration file, arduino-cli.yaml, that is tracked in the repository:

prep-avr:
	arduino-cli core update-index --config-file arduino-cli.yaml
	arduino-cli core install arduino:avr --config-file arduino-cli.yaml

The ESP32 target also pulls in the display and radio support libraries from the Arduino library index, including the crypto library the encrypted links depend on:

	arduino-cli lib install "Crypto"

There is a matching prep target for the SAMD boards, adafruit:samd, and one for nRF parts, and the top-level prep target runs the AVR, ESP32 and SAMD sets in sequence. The default target is release, and clean removes the build directory and the release artefacts under Release/.

The repository also tracks the things that make a release verifiable: a partition_hashes file, a release_hashes.py script, and a Release/ directory. For a firmware that is distributed as a binary to devices in the field, published hashes are part of the product.

The bootstrap console seeds the next node, offline

The most unusual claim in the documentation is the self-replication story. Every RNode contains the seeds necessary to reproduce the system, in the form of the RNode Bootstrap Console, which is hosted locally on every node and can be activated and accessed at any time with no Internet required.

The point is a node that can rebuild the ecosystem it belongs to. The designs, guides and software stored within allow users to create more RNodes and to bootstrap entire communications networks independently of existing infrastructure. The documentation makes the operational consequence plain: where there is no Internet, RNodes will still communicate.

This is why the on-device Console/ directory and the Console.h header matter more than they would in an ordinary embedded project. The console is not a debug shell, it is a distributed copy of the manufacturing instructions. The framing in the documentation is that the production of one particular device is not an end but the potential starting point of a new branch of devices on the tree of the RNode system.

For an evaluator, this is the differentiator. A commercial radio product gives you a device. This gives you a device plus the means to make the next one, which is a different kind of dependency to accept.

This repository is a mirror, and the warning at the top is about more than tone

The first line of the documentation says this repository is a public mirror and that all development is happening elsewhere. MIRROR.md in the root holds the pointer. That is a practical constraint for anyone planning to contribute: issues and pull requests raised here are not where the work is done.

The rest of the opening block is about something else, and it is unusual to see in a firmware repository. The maintainers warn that several hastily launched, incorrect and, in most cases, entirely LLM-generated fakes of RNode-based devices, tools, guides and documentation are being circulated and sold, and that these hoaxes violate the open source GPLv3 and Creative Commons licences the project was published under while claiming independent ownership. The documentation states that such claims are not legally valid, are not recognised by the RNode authors and copyright holders, and points to a reference on void grants for machine-generated code.

Two things follow for a reader. First, there is a clear licence position to verify, and the warning spells out that RNode and its documentation and resources were published under GPLv3 and Creative Commons terms, so a device that ships GPL firmware with a proprietary claim on the design is a problem you can now name. Second, the volume of impostor projects is itself a signal about the appeal of the design.

Many roles for one node, and the alternative of not building one

The list of roles an RNode can take is the strongest argument for the system, because each one changes what you need from the hardware. It works as a network adapter for Reticulum, for messaging with Sideband, for information sharing on Nomad Network, as a LoRa-based KISS-compatible amateur radio TNC, as a LoRa development platform, as a packet sniffer for LoRa networks, and as a long range Ethernet and IP network interface on Linux. The last two are the interesting ones for infrastructure work, because they turn a radio into something an operating system can route over.

The alternative to building an RNode is to buy a finished radio or a dedicated LoRa modem. The difference in approach is that a finished device gives you a fixed radio, a fixed antenna and a fixed firmware, while the RNode design is explicitly meant to be flexible and hackable, with the hardware chosen to suit the time, locale and environment it has to work in. The trade-off runs the other way too. A device you buy comes with a warranty, a datasheet and a support contact, and none of those exist here.

The third option, and the one most people in this space actually use, is a conventional mesh radio stack for local range with an Internet gateway. That is a different architecture with different failure behaviour, and the RNode's pitch is precisely the case where the infrastructure is unreliable or absent.

On versions, the latest release is 1.86, published on 2026-04-24, and it is installed through rnodeconf, which must be at least version 2.4.1, obtained by updating the rns package to at least version 1.1.9. The last push was on 2026-09-27, and the licence is GPL-3.0, which obliges you to publish modifications to the firmware and to keep the licence intact, with the Creative Commons terms covering the documentation and resources.

Editorial conclusion

RNode Firmware fits a builder who wants a radio node that is reproducible, repairable and independent of any vendor, and who is prepared to solder, flash and maintain the hardware themselves. It does not fit a team that needs a certified, supported product with a warranty behind it, and it is the wrong starting point if you have no interest in the hardware layer at all. Before you commit, read MIRROR.md to find where development actually happens, check that the arduino-cli core version in the Makefile matches the target you want to flash, and read the rnodeconf version requirement, since the firmware update path depends on it.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. markqvist/RNode_Firmware on GitHub
3. Project website
4. README
5. Releases