#lora #radio #embedded-hal-async #iot #semtech

nightly no-std lora-phy

A LoRa physical layer implementation enabling utilization of a range of MCU/LoRa board combinations within embedded frameworks supporting embedded-hal-async

10 stable releases

new 2.1.2 Sep 25, 2023
2.1.1 Sep 14, 2023
2.1.0 Jul 8, 2023
2.0.0 Jun 26, 2023
1.0.2 Apr 26, 2023

#82 in Embedded development

Download history 68/week @ 2023-06-05 84/week @ 2023-06-12 81/week @ 2023-06-19 128/week @ 2023-06-26 108/week @ 2023-07-03 24/week @ 2023-07-10 32/week @ 2023-07-17 110/week @ 2023-07-24 116/week @ 2023-07-31 108/week @ 2023-08-07 60/week @ 2023-08-14 10/week @ 2023-08-21 21/week @ 2023-08-28 77/week @ 2023-09-04 87/week @ 2023-09-11 39/week @ 2023-09-18

224 downloads per month
Used in 2 crates


2.5K SLoC

LoRa physical layer (the rustaceous radio)



  • provide one straight-forward LoRa physical layer API which supports both LoRaWAN and point-to-point (P2P) use cases;
  • support a variety of microcontroller unit (MCU) and LoRa chip combinations behind one API;
  • enable LoRa features for any embedded framework which supports embedded-hal-async for the desired MCU/LoRa chip combination.


  • separate out modulation parameters and packet parameters as separate concerns to address the nuances in LoRa chip support and to allow flexible specification of various LoRaWAN and P2P send/receive channels, even in the same use case;
  • allow the user to specify a LoRa chip kind (for example, Sx1261/2) and specific LoRa board type (for example, Stm32wlSx1262) and hide the control of that LoRa board behind the LoRa physical layer API;
  • provide a minimal trait which must be implemented for each desired embedded framework/MCU type/LoRa chip type to allow this crate to interface to the LoRa chip within the embedded framework.


  • while the current examples use the Embassy embedded framework, nrf52840, rp pico, stm32l0, and stm32wl MCUs, and Sx127x/Sx126x chips, this crate provides a path forward for other embedded frameworks, MCU types, and LoRa chips in a Rust development environment.

LoRa physical layer API

For users wishing to implement a LoRaWAN or P2P solution, the following implementation files provide the necessary context for lora-phy version 2.

Examples of API usage:

Embedded framework/MCU support

For embedded framework developers wishing to add LoRa support as a feature for one or more MCU/LoRa chip combinations:

  • the InterfaceVariant trait, which enables this lora-phy crate to interface to a specific embedded framework/MCU/LoRa chip combination.

Example InterfaceVariant implementations:

LoRa chip support

For developers wishing to add support for new LoRa chips or enhance support for existing chips:

  • the RadioKind trait, which must be implemented for each kind of LoRa chip for access through the lora-phy crate API;
  • the interface implementation, which captures the three key read/write operations allowing control of the LoRa chip from this crate through either opcode or register operations.

Example RadioKind implementations and ancillary information:

LoRa board-specific support

LoRa boards use LoRa chip features differently. To suppport these variations within a radio kind implementation, BoardType and ChipType are available:

One can add a LoRa board (the board name includes the chip type in case the board may include a range of chip types) and the ChipType, then modify the radio kind processing to support board-specific features. The ChipType is used for generic checks, alleviating the need to add a new board type check in places where a generic check will do. BoardType checks only need to be implemented where the specificity is board-related. There are examples of each type of check here:


A public chat on LoRa/LoRaWAN topics using Rust is here:


~29K SLoC