# RadioLib: one C++ radio library across fourteen module families and a shelf of amateur digital modes > A portable C++ library that puts LoRa, FSK and OOK hardware behind a consistent API, and layers APRS, AX.25, RTTY, SSTV, Morse, LoRaWAN and other modes on top. **jgromes/RadioLib** — Universal wireless communication library for embedded devices - Repository: https://github.com/jgromes/RadioLib - Website: https://jgromes.github.io/RadioLib/ - Stars: 2,586 · Forks: 596 - Language: C++ - License: MIT - Published: 2026-10-07 · Updated: 2026-10-07 · Language: en - Canonical page: https://hysenlabs.com/projects/jgromes-radiolib ## The README opens with a dare about mixing protocols and radios The pitch is two sentences long and slightly cheeky. The README asks whether you want to add a Bluetooth interface to a LoRa network and answers that you can, then asks whether you just want to play with radio teletype, slow-scan TV or Hellschreiber on a cheap module and answers that too. Then it tells you how many modules you can control: as many as your microcontroller can handle. That is the actual design claim, and the repository supports it. The library is C++, MIT licensed, with 2,586 stars, 596 forks and only 20 open issues. The last push was 2026-09-24, and the topic list is more informative than a feature list would be, naming aprs, ax25, rtty, sstv, lorawan and specific part families such as sx1276, sx1262, sx1280, lr1110 and rfm96. RadioLib grew out of a driver for RadioShield, which the README mentions in passing, and grew from there into a general library. It supports Arduino natively and also runs outside Arduino, with a wiki page on porting to non-Arduino platforms and an `examples/NonArduino` directory to point at. ## Fourteen module families behind one interface The supported module list is the clearest statement of the project's scope. It covers the CC1101 FSK module, the LLCC68 LoRa module, the LR11x0 series with LR1110, LR1120 and LR1121, the LR2021 series adding LR-FHSS, FLRC and OOK, the nRF24L01 at 2.4 GHz, RF69, the RFM2x and RFM9x families, the Si443x series, the STM32WL integrated microcontroller and LoRa module, the SX126x, SX127x and SX128x series, and the SX123x FSK and OOK parts. Two entries in that list are structurally different from the rest. The STM32WL is a microcontroller with a radio built in, so the boundary between the library and your firmware moves. And the nRF24L01 is 2.4 GHz, a different band entirely from the sub-GHz parts around it, which tells you the abstraction is genuinely about a radio interface rather than about one frequency plan. The plugin structure is visible in the tree too. Alongside `src/` and `examples/` sit `extras/` and `library.json`, `library.properties` and `idf_component.yml`, which are the three packaging manifests for PlatformIO, the Arduino library manager and the ESP-IDF component registry respectively. There is also an `uncrustify.cfg` at the root, which is a small tell that formatting is enforced rather than aspirational. ## Protocols and digital modes stacked on top of the radio layer Where the module list stops, the protocol list begins, and it is longer. AX.25 packet radio is listed for eleven module families using 2-FSK or AFSK. RTTY and Morse code cover the same broad set plus the nRF24L01. SSTV is narrower at eight families. Hellschreiber covers ten. APRS runs on AFSK across nine. POCSAG is FSK only across eight. LoRaWAN is the one entry that uses LoRa rather than FSK, and it covers six families including the LR and SX128x parts. The README attaches a sigidwiki link to each protocol, which is a good sign about the audience: these are the names ham radio operators already use, and the library is aimed at people who know what a preamble sounds like. Two details stand out. ADS-B reception using OOK is listed as supported only for the LR2021, which is a much narrower claim than the rest of the list. And LoRaWAN comes with specifics: Class A and Class C are supported, multicast over Class C works, and the project describes itself as pre-certified for Class A. Pre-certified is a strong word for a library and it deserves a careful read of the linked notes before you rely on it for a deployed device. ## Platform support with an honest warning about small AVR parts The Arduino platform list runs long: the official AVR core, mbed, megaAVR, SAM, SAMD, Renesas, Adafruit's SAMD and nRF52 cores, Espressif's ESP32 and ESP8266, Intel Curie, SparkFun's Apollo3, ST's official and unofficial STM32 cores, MCUdude's MegaCoreX and MegaCore, Raspberry Pi's RP2040 cores and a Raspberry Pi port, and Heltec's CubeCell. Embedded in that list is the most useful sentence in the README for anyone choosing hardware. Boards based on the ATmega328, meaning Uno, Pro Mini and Nano, and anything smaller, are not recommended, because the microcontroller is very constrained in program and memory size and the library will end up taking most of the space available. That is not a soft warning about debugging difficulty, it is a statement that the thing will not fit. The LoRa module support still lists those parts, which is not a contradiction so much as a scope statement: the library can drive the radio, but you may not have room for it. Outside Arduino, the non-Arduino wiki page and the `examples/NonArduino` directory are the documented route, which matters for anyone on a bare RTOS or on an ESP-IDF project without the Arduino layer. ## Breaking changes queued for 8.0.0 and the LoRaWAN state that carries it The release notes are where the maintenance story lives, and 7.7.0 is the one to read. It announces a new set of `radio.begin` methods that take a single configuration structure, `ConfigLoRa_t` and `ConfigFSK_t` among them, instead of a parameter list. The old methods are kept but marked deprecated, and the note says plainly they will be removed in the next major release, 8.0.0. That is a two-release window on a library with 596 forks, which means code written against RadioLib today may need a mechanical change later. It is a well-signposted change and the discussion is linked, but it belongs in the adoption calculation. The 7.7.1 patch is a security fix rather than a feature: an out-of-bounds read and memory leak in LoRaWAN `parseDownlink`. Worth noting that the current release line is 7.7.1 from 2026-05-31 while the last push is 2026-09-24, so the working tree is ahead of the published tags. 7.6.0 removed `getDataRate()` outright, which is a useful reminder that the API surface here does move. The same release added LR2021 support and fixed a null dereference in the SX128x driver, and it lists contributions attributed to named outside contributors. ## Where the actual documentation lives, and why the README is a signpost The README is structured as a quick link list rather than a guide, and the links are the point. The wiki holds general usage information and a FAQ, an API reference is generated from the source at jgromes.github.io/RadioLib, and two standalone web tools sit alongside it: a status code decoder for the integers RadioLib methods return, and a debug log decoder for its SPI debug output. Those two decoders deserve credit. A library that returns integer status codes and logs raw SPI traffic has made two things hard on the user, and shipping decoders for both removes most of the friction of the first debugging session. The examples directory is the third pillar, and it is organised by feature rather than by module: ADSB, AFSK, APRS, AX25, BellModem, CC1101, FSK4, Hellschreiber, LR11x0, LR2021, LoRaWAN, Morse, NonArduino, Pager, PhysicalLayer, RF69, RTTY, SSTV, STM32WLx, SX123x, SX126x, SX127x, SX128x, Si443x and Stream. That mapping tells you the library is used by starting from the behaviour you want rather than the part you have bought. The repository also carries a CODE_OF_CONDUCT and a SECURITY policy, which for a library that other people link into firmware is the minimum you would want. ## Conclusion RadioLib's value is not any single protocol but the fact that one object model survives across fourteen radio families, so a LoRaWAN node and a POCSAG pager can share code that would otherwise be rewritten per vendor. The two costs are honest ones. The API is mid-migration, with `radio.begin` moving to configuration structs before 8.0.0 removes the old signatures, and AVR-class microcontrollers are explicitly not recommended because the library is large relative to the flash available. For ESP32, RP2040 or STM32 targets the trade is easy. Start from the wiki rather than the README, pick the example closest to your radio and module, and read the status code decoder when something returns an integer instead of throwing. ## FAQ ### What radio modules does RadioLib support? Fourteen families are listed, including the CC1101, LLCC68, LR11x0 and LR2021 series, RF69, the RFM2x and RFM9x families, Si443x, the STM32WL, the SX126x, SX127x and SX128x series, the SX123x parts, and the 2.4 GHz nRF24L01. The project puts the limit at however many modules your microcontroller can handle. ### Can RadioLib drive an Arduino Uno? It can drive the radio, but the README explicitly does not recommend it. Boards on the ATmega328 and smaller are very constrained in program and memory size, and the library takes most of the space available. The supported list covers the larger cores, so an ESP32, RP2040 or STM32 board is the sensible target. ### Does RadioLib work outside the Arduino framework? Yes. The README states that it runs in non-Arduino environments as well, and points at both a wiki page on porting to non-Arduino platforms and an `examples/NonArduino` directory in the repository. ### What protocols can RadioLib implement on top of the radio? The README lists AX.25, RTTY, Morse code, SSTV, Hellschreiber, APRS, POCSAG, LoRaWAN and ADS-B receive using OOK, each annotated with the module families it works on. LoRaWAN covers Class A and Class C, with multicast over Class C and pre-certification stated for Class A. ### Is the RadioLib API about to change? The 7.7.0 release introduced new `radio.begin` overloads that take a configuration struct such as `ConfigLoRa_t` instead of a parameter list. The old signatures still work but are deprecated, and the release notes say they will be removed in 8.0.0. ### Where can I look up what a RadioLib return code means? The README links a hosted status code decoder built for the integers that RadioLib methods return, plus a separate decoder for its SPI debug logs. A full API reference generated from the source is hosted as well, alongside a wiki with usage information and a FAQ. ## Sources - [jgromes/RadioLib on GitHub](https://github.com/jgromes/RadioLib) - [License: MIT](https://github.com/jgromes/RadioLib/blob/master/LICENSE) - [Project website](https://jgromes.github.io/RadioLib/) - [README](https://github.com/jgromes/RadioLib/blob/master/README.md) - [Releases](https://github.com/jgromes/RadioLib/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/jgromes-radiolib