RFM69: a C++ radio library for the Semtech SX1231 and its four ready made boards

What the library covers and what the radio underneath does

The RFM69 library by Felix Rusu is written for the RFM69W, RFM69HW, RFM69CW and RFM69HCW boards, which are the Semtech SX1231 and SX1231H transceivers. The library itself is C++, and the repository is a flat set of source files: RFM69.cpp and RFM69.h for the core driver, RFM69_OTA.cpp and RFM69_OTA.h for the over the air packets, RFM69_ATC.cpp and RFM69_ATC.h for the automatic transmit control feature, and RFM69registers.h for the register definitions. There is also a datasheet PDF for the SX1231H in the root.

The feature list is compact and specific. There is an easy API with a few simple functions for basic use. The addressing scheme allows 1023 possible nodes on 256 possible networks. Messages are limited to 61 bytes, and the README is explicit about why, since the limit is there to support the hardware AES encryption. Transmit power is customisable across 32 levels for low power control, and there is a sleep function for power saving. Automatic acknowledgements are handled by the sendWithRetry() function, and hardware 128 bit AES encryption is done in the chip rather than in software.

The radio also handles the preamble, synchronisation recognition and CRC check in hardware, the digital RSSI can be read at any time with readRSSI(), and the whole thing is interrupt driven. There is a promiscuous mode that lets any node listen to any packet on the same network, which is what the range test examples and the listen mode examples in the repository rely on.

Two hardware variants with very different power draw

The reason the author wrote the library is stated in the README, and it explains a lot about the design priorities. The RFM69 was developed after long research into alternative transceivers for the RFM12B, which the README still calls an excellent transceiver but notes is much lower output power and has limited built in features that have to be implemented in firmware, listing the preamble, synchronisation, CRC, packet engine and encryption among them.

The goal was a transceiver that could stay small, be easy to use and have the longer range needed. That produced two variants with a significant gap between them. The RFM69W and RFM69CW are rated at 13 dBm and 45 mA during transmission. The RFM69HW and RFM69HCW are rated at 20 dBm and 130 mA. The README states plainly that they are not pin compatible, and that the RFM69HCW is generally recommended since it has the extra power when needed.

That 130 mA figure is the number that dominates the design of a battery powered node, and the README is direct about the consequence. The higher power units need more DC power when they transmit, so for battery powered motes you need to keep them powered down and transmit only periodically, using the sleep() function to put the radios into low power mode and the LowPower library to power down the Moteino itself. The Examples directory reflects that with dedicated DeepSleep, DeepSleep_usingLowPowerLibrary, Gateway_sleepMCU and ListenModeSleep examples.

The AT feature is the other power lever. The RFM69 ATC feature keeps transmit power only at the level required to achieve the desired RSSI at the receiving end, and the README points at the examples for its usage.

Range figures and their assumptions

The README gives concrete range numbers and is careful about where they come from. The author states that open air range has been tested on these transceivers in various combinations, and that a range of upwards of 400 metres can be achieved with the default settings provided in the library.

Beyond that, the figures come from users rather than from the author. Some users reported upwards of 500 metres by lowering the bitrate, and a forum user reported 1.5 miles at 1.2 Kbps, with the forum post and a blog page linked.

Those numbers are worth reading as a menu of trade-offs rather than as a specification. The distance scales with the bitrate, so a long range link costs you throughput, and the highest power variants cost you the current draw that a battery budget cannot absorb. The examples directory has a RangeTest_Gateway and a RangeTest_Transmitter pair, which is the shape of a tool for measuring this on your own site rather than trusting someone else's field report.

The caveat the README attaches to the higher power units is the one to carry into planning: they need more DC power when they transmit, and that is a hardware constraint you cannot design around with better code.

Installation paths and the platform it targets

The library is distributed as an Arduino library, and the Arduino IDE installation is a manual copy. You copy the content of the library into the Arduino/libraries/RFM69 folder, and the README says to find the Arduino folder through File and then Preferences in the IDE, with a link to the Arduino libraries tutorial.

For PlatformIO the README points at the PlatformIO registry entry for the library and says to see it for the latest installation details.

The platform the library is really tuned for is Moteino, which the README describes as the easiest way to get started with the well documented and supported microcontroller platform, easily programmable from the Arduino IDE. The family named is the Moteino, MoteinoUSB and MoteinoMEGA, and the README notes that RFM69 transceivers were extensively tested on Moteinos for the purpose of building internet of things devices that can be controlled wirelessly.

That platform link goes further than a hardware recommendation. There is a dedicated gateway page describing how these devices can interact with each other through a Raspberry Pi gateway interface, with three video overviews linked, and the examples directory contains a PiGateway and a PiGateway_Basic pair. The library is therefore designed for a specific network topology: nodes talking to a gateway, with the gateway bridging onward.

The examples list also shows the breadth of what people have built with it. There are sensor nodes for the DS18B20 and for the ultrasonic SonarMote, a doorbell and a garage door remote, a mailbox notifier, a pulse meter, a MightyHat and an IOShield board, an OLED display node, a motion sensor node, a random number generator, and a pair of examples demonstrating structured receive and send.

Two examples to read first

The README points at two examples as the place to start, and they are deliberately minimal.

The Gateway example listens for incoming data from remote nodes and responds to any ACK requests. The Node example is a loop that sends increasingly longer packets to the gateway and waits for an ACK each time. Together they are a complete working link, and the increasing packet length is a nice touch because it exercises the size handling rather than always sending the same fixed frame.

The ACK mechanism is the piece that makes this usable in practice. sendWithRetry() handles the acknowledgement automatically, so a node sends, waits for the ack and retries if it does not arrive, without the sketch implementing a timeout and a resend loop itself. Given that these are low power nodes that spend most of their time asleep, a reliable link without an explicit retry loop is what keeps the firmware readable.

Beyond the basics, the repository carries more examples that are added from time to time, and the README points at the examples directory, the LowPowerLab blog for news and projects and the forums for discussion. The MIT and GPL question does not apply to the examples separately, since the repository is covered as a whole.

The licence is the first thing to read

The README puts the licence before the features, and it is unusually explicit about what it means in practice.

The default license is GPL 3.0, and the README says to see the License.txt file for details and to be sure to include the same license with any fork or redistribution of the library. The wording on the reuse itself is that you are free to use the library for personal or commercial purposes, but you must adhere to its copyleft requirements, which means any modified or derivative work you distribute must also be licensed under GPL, and you must provide the source code to recipients.

That last distinction matters for an embedded project. Using the library unmodified in a device you sell is one thing. Forking it, changing the driver, or shipping it as part of a firmware image you distribute is a different thing, and that is where the copyleft obligation bites. A commercial product team needs to understand which side of that line it is on before it starts, and the README gives the escape hatch: for custom licensing arrangements where these terms are not acceptable, you have to contact the author directly or use the contact form on the vendor site.

The licence field on the repository is GPL-3.0, and the release history shows v1.6.0 in October 2025 with new features and misc fixes, after v1.5.2 in 2022 which added ISRCallback support and ESP8266 fixes, and v1.5.1 in 2022 with a minor setPowerDBm() fix. The gap between 2022 and 2025 is worth noticing: the project is active but it moved at the pace of a maintainer with a day job.

Editorial conclusion

RFM69 fits a maker building a wireless sensor network on Moteino boards or on custom hardware with an SX1231 radio, who wants AES in hardware, automatic retries and a sleep mode that fits a battery budget. It does not fit a commercial product you need to license permissively, because the library is GPL-3.0 and a derivative you distribute inherits that, and it does not fit a design that needs more than 61 bytes per message. Before adopting it, check the SX1231 variant your board uses, since the RFM69W and CW are 13 dBm while the HW and HCW are 20 dBm and are not pin compatible, read License.txt rather than relying on the summary, and pick the antenna and transmit power to match your range, because the documented range figures assume the default settings and the higher power units draw far more current when transmitting.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. LowPowerLab/RFM69 on GitHub
4. README
5. Releases