Universal wireless communication library for embedded devices
aprsarduinoax25cc1101esp32esp8266lorawanlr1110lr1120rfm69rfm96rttysi4432sstvsx1262sx1268sx1272sx1276sx1278sx1280
ab41bcac00
When using a blocking receive, I was getting non-sensical packet length and garbage data, whereas IRQ mode was working fine. This was happening despite what looked like a workaround for this in the code which would read the length twice. I tracked it down to the receive function trying to read the data too early, before the packet had even been received. The receive function would wait for the GDO0 pin to become low, then assume the packet was ready and read off the data. However, the GD0 pin is set by the `startReceive` as inverted and, according to the datasheet, in a mode which "asserts when sync word has been received, and de-asserts at the end of the packet". In other words, taking into account the inversion, GDO0 becomes low at the start of the packet and high at the end of it. Therefore the receive function would actually try to read the packet data as soon as the packet had started, rather than wait until the end, explaining the garbage data. I suspect that with a slow MCU and a fast transmission rate, the previous workaround of reading the length field twice may have delayed the data read just enough to allow the packet to be fully received, but this does not work in the general case. This commit updates the logic by first waiting for a low signal, followed by a high one. This is actually the exact same logic used in the blocking transmit implementation, but inverted to account for the INV flag set on GDO0. The commit also removes the past workaround, since it should not be necessary anymore. |
||
|---|---|---|
| .github | ||
| examples | ||
| extras | ||
| src | ||
| .gitignore | ||
| .gitmodules | ||
| CMakeLists.txt | ||
| CODE_OF_CONDUCT.md | ||
| CONTRIBUTING.md | ||
| Doxyfile | ||
| keywords.txt | ||
| library.json | ||
| library.properties | ||
| license.txt | ||
| README.md | ||
| SECURITY.md | ||
| uncrustify.cfg | ||
RadioLib 
One radio library to rule them all!
Universal wireless communication library for embedded devices
See the Wiki and FAQ for further information. See the GitHub Pages for detailed and up-to-date API reference.
RadioLib allows its users to integrate all sorts of different wireless communication modules, protocols and even digital modes into a single consistent system. Want to add a Bluetooth interface to your LoRa network? Sure thing! Do you just want to go really old-school and play around with radio teletype, slow-scan TV, or even Hellschreiber using nothing but a cheap radio module? Why not!
RadioLib natively supports Arduino, but can run in non-Arduino environments as well! See this Wiki page and examples/NonArduino.
RadioLib was originally created as a driver for RadioShield, but it can be used to control as many different wireless modules as you like - or at least as many as your microcontroller can handle!
Supported modules:
- CC1101 FSK radio module
- LLCC68 LoRa module
- nRF24L01 2.4 GHz module
- RF69 FSK/OOK radio module
- RFM2x series FSK modules (RFM22, RM23)
- RFM9x series LoRa modules (RFM95, RM96, RFM97, RFM98)
- Si443x series FSK modules (Si4430, Si4431, Si4432)
- STM32WL integrated microcontroller/LoRa module
- SX126x series LoRa modules (SX1261, SX1262, SX1268)
- SX127x series LoRa modules (SX1272, SX1273, SX1276, SX1277, SX1278, SX1279)
- SX128x series LoRa/GFSK/BLE/FLRC modules (SX1280, SX1281, SX1282)
- SX123x FSK/OOK radio modules (SX1231, SX1233)
Supported protocols and digital modes:
- AX.25 using 2-FSK or AFSK for modules:
SX127x, RFM9x, SX126x, RF69, SX1231, CC1101, RFM2x and Si443x - RTTY using 2-FSK or AFSK for modules:
SX127x, RFM9x, SX126x, RF69, SX1231, CC1101, nRF24L01, RFM2x, Si443x and SX128x - Morse Code using 2-FSK or AFSK for modules:
SX127x, RFM9x, SX126x, RF69, SX1231, CC1101, nRF24L01, RFM2x, Si443x and SX128x - SSTV using 2-FSK or AFSK for modules:
SX127x, RFM9x, SX126x, RF69, SX1231, CC1101, RFM2x and Si443x - Hellschreiber using 2-FSK or AFSK for modules:
SX127x, RFM9x, SX126x, RF69, SX1231, CC1101, nRF24L01, RFM2x, Si443x and SX128x - APRS using AFSK for modules:
SX127x, RFM9x, SX126x, RF69, SX1231, CC1101, nRF24L01, RFM2x, Si443x and SX128x - POCSAG using 2-FSK for modules:
SX127x, RFM9x, RF69, SX1231, CC1101, nRF24L01, RFM2x and Si443x - LoRaWAN using LoRa for modules:
SX127x, RFM9x, SX126x and SX128x- NOTE: LoRaWAN support is currently in beta, feedback via Issues and Discussions is appreciated!
Supported Arduino platforms:
-
Arduino
-
Adafruit
-
Espressif
-
Intel
- Curie - Arduino 101
-
SparkFun
- Apollo3 - Sparkfun Artemis Redboard
-
ST Microelectronics
- STM32 (official core) - STM32 Nucleo, Discovery, Maple, BluePill, BlackPill etc.
- STM32 (unofficial core) - STM32F1 and STM32F4-based boards
-
MCUdude
-
Raspberry Pi
- RP2040 (official core) - Raspberry Pi Pico and Arduino Nano RP2040 Connect
- RP2040 (unofficial core) - Raspberry Pi Pico/RP2040-based boards
- Raspberry Pi - Arduino framework for RaspberryPI
-
Heltec
- CubeCell - ASR650X series (CubeCell-Board, CubeCell-Capsule, CubeCell-Module etc.)
-
PJRC
- Teensy - Teensy 2.x, 3.x and 4.x boards
The list above is by no means exhaustive - RadioLib code is independent of the used platform! Compilation of all examples is tested for all platforms officially supported prior to releasing new version. In addition, RadioLib includes an internal hardware abstraction layer, which allows it to be easily ported even to non-Arduino environments.