lora-rs / lora-rs Goto Github PK

LoRa and LoRaWAN crates for End Devices

License: MIT License

Rust 100.00%

embedded-rust embedded-systems iot iot-device lora lorawan lorawan-device rust

lora-rs's Introduction

lora-rs

This repository aims to provide a set of compatible crates for implementing LoRa end devices in Rust. As a general rule, all crates are nostd and designed to be friendly for embedded projects.

Crates

lora-modulation: LoRa modulation characteristics and a utility for calculating time on air
lora-phy: LoRa radio drivers which provide a PHY layer implementation
lorawan-encoding: encoding and decoding LoRaWAN packets
lorawan-device: a LoRaWAN device stack with non-blocking and async implementations

Contributing

Please read the contributing guidelines.

lora-rs's People

Contributors

Stargazers

Watchers

lora-rs's Issues

Handling of region-specific power limits

Now that support for PhyRxTx has gained support for limiting maximum power and dealing with board-specific antenna gain via #159, region-specific transmission power limits should be revisited (see also #150).
Also, all drivers in lora-phy have been fixed to clamp output power between supported values instead of raising Err(InvalidOutputPower).

Values for maximum transmission power for each region have been pulled from RP002-1.0.3 Regional Parameters.

Dynamic Channel plans (currently, the maximum EIRP value ( Region::get_dbm()) is 14dBm):

AS923: +16dBm
EU433: +12dBm
EU863-870: +16dBm
IN865-867: +30dBm

Fixed channel plans:

AU915-928: +30dBm - currently 21dBm
US902-928: +30dBm (?) - currently 21dBm

Unimplemented regions:

CN779-787: +12dBm
CN470-510: +19dBm
KR920-923: (depends on frequency: +12dBm if f < 922MHz), otherwise +14dBm
RU864-870: +16dBm

Migrate to external radio traits

Are there any plans to replace the internal PhyRxTx and Timings traits with ones from a trait crate, similar to embedded-hal but for radios? There is a radio-hal crate for this purpose, and its traits are already implemented for sx127x and sx128x lora transceivers.

I'm not sure if it is currently complete enough to support all functionality necessary here, but I would be willing to contribute to both projects if necessary.

Fragmenting into Types more

Hi @ivajloip

Thanks for putting this project together. I got to spend a full day with it today trying to actually do something and there's something that I think I can help improving but I wanted to get your opinion on it first.

I think GenericPhyPayload could be more of a builder type or it might even just be a public function that returns some MType. The reason is I think it's best to avoid functions like decrypted_payload that only apply to certain MTypes; if you transformed the data into a type you could use that to make sure the inapplicable function doesn't get called.

In addition, you may want to consider enriching either expanding the MTypes to have an Encrypted/Decrypted variant when applicable. Or they could have a payload field which can is an enum of Encrypted([u8]) vs Decrypted([u8]). Then you could take an encrypted packet and either transform the type itself from Encrypted to Decrypted or match on the state of the subfield and do the transformation.

Anyway, these are just initial thoughts. Let me know what you think.

Best,
Louis

Support setting of a non-default RX2 frequency and DR

As documented in the description of RXParamSetupAns, the frequency for RX2 windows can be changed. This does not appear to be supported for some of the regional settings right now.

Drop `boost` from tx functionality (mainly prepare_for_tx) in favor of configurable RF routing

We currently hardcode boost_if_possible as False in LorawanRadio:tx(...), but this should be handled via "board configuration" as it depends on the board layout and disabled boost might mean no output at all on some boards:

lora-rs/lora-phy/src/lorawan_radio.rs

Lines 87 to 89 in 2bd4c3d

 // TODO: 3rd argument (boost_if_possible) shouldn't be exposed, as it depends 

 // on physical board layout. Needs to be eventually handled from lora-phy side. 

 self.lora.prepare_for_tx(&mdltn_params, config.pw.into(), false).await?;

sx1261 and sx1262 do not require any changes as there's no separate physical RF output pin.
sx1272 has two physical outputs (RFO and PA_BOOST) for TX which can be configured exclusively of eachother, but it's up to board designer whether both SFO and PA_BOOST are wired to antenna or one of them:
sx1276 (and possibly sx1277, sx1278, sx1279) support additional frequency regions, where only lower-bands can be boosted:

Release of lorawan-device and lorawan-encoding

Could we create a release to crates.io of lorawan-device and lorawan-encoding? Depending on git revisions prevents releasing crates that depend on these.

I'm happy to do it for lorawan-device since it's never released before (and I can add you both as owners), but I think I'd need to be added as owner on crates.io for lorawan-encoding.

@ivajloip @lthiery ^^

FOpts Bug

This will probably be solved with your current refactor, but I came across a bug today that can be exposed with the following unit test:

#[test]
fn test_mac_command_in_downlink() {
    let raw_data = [0x60, 0x5F, 0x3B, 0xD7, 0x4E, 0xA, 0x0, 0x0, 0x3, 0x0, 0x0,
    0x0, 0x70, 0x3, 0x0, 0xFF, 0x0, 0x30, 0xCD, 0xDB, 0x22, 0xEE];
    let packet = GenericPhyPayload::new(raw_data).unwrap();

    assert_eq!(packet.mhdr().mtype(), MType::UnconfirmedDataDown);

    match packet.mac_payload() {
        MacPayload::Data(data) => {
            let fhdr = data.fhdr();
            let fopts = fhdr.fopts().unwrap();

            // there should only be one fopts
            assert_eq!(fopts.len(), 1);

            match fopts[0] {
                MacCommand::LinkADRReq(_) => (),
                _ => assert!(false),
            }
        }
        _ => {
            assert!(false)
        }
    }
}

Instead of parsing as LinkADRReq, the MacCommand is parsed as LinkADRAns. This tells me that the MAC Command parsing isn't distinguishing behind a downlink and uplink packet properly. As you can see with the first assert, it is identified as a UnconfirmedDataDown yet LinkADRAns is a uplink MAC.

Hardcoded RX2 Datarate for regions

It is troublesome that there is a hidden hard-coded RX2 windows data-rate. I don't know if my network provider is odd but it answers on the rx2 window at the same datarate as the message was sent so this line gives me trouble.

https://github.com/ivajloip/rust-lorawan/blob/d9544e35c4a61326230589fb36266b242fea1094/device/src/region/eu868/mod.rs#L96

I am trying to dig in to this and it seems like Semtech also does this:
https://stackforce.github.io/LoRaMac-doc/LoRaMac-doc-v4.4.7/group___r_e_g_i_o_n_e_u868.html#ga291302a83db2690d26b2659853262abe

Should this be configurable or is it just easier if the user just implements its own "region" to fix this? If it is not region specific then should this even be in the region code?

Start keeping a changelog

Small suggestion, but I think it would benefit the project to keep a changelog.

Avoid RX1 cancellation during RF reception

3.3.1 Receiver activity during receive windows
If a preamble is detected during one of the receive windows, the radio receiver SHOULD stay
active until the downlink frame is demodulated. If a frame was detected and subsequently
demodulated during the first receive window, and the frame was intended for this end-device
after address and MIC (message integrity code) checks, the end-device SHALL NOT open
the second receive window.

The code here should handle radio::Response::Rxing appropriately.

Payload is wrong after 16 bytes

Somehow bytes after byte 16 appear to be corrupt.

The following FRM payload (hex): 44232700018d2a0020000001e40001a30200000000

with the session keys:

	Newskey: AES128([26, C0, 7D, F9, 16, 69, F7, B2, FD, 67, E5, 6B, 53, E9, 6D, BF])
	Appskey: AES128([3C, 23, 2D, 71, 18, 1C, FE, 34, 6C, E7, 54, 39, 37, 23, F5, 30])

Becomes the following base64 PhyPayload: gCYCAEgAGAACYMbhumG/XnwtUwxnGPPe4CuawEsYOjRtKg==

When I use this online decoder resource to parse it, I get the following response:

  FRMPayload = 60C6E1BA61BF5E7C2D530C6718F3DEE02B9AC04B18 (from packet, encrypted)
                        = 44232700018D2A0020000001E40001A33A032FF09B (decrypted)

As you can see, after byte 16, it's wrong. The payload does seem to roundtrip properly within the rust-lorawan though.

I'll try to find a minute to write a unit test about this today, but I thought I'd log it for now and maybe you know where to look for the fix @ivajloip

Allow use of external mut memory for phy payload creators

Sometimes it is important to be able to use externally provided memory for the payload creators. This issue tracks that need.

`get_tx_datarate` should also provide channel

In US915 and AU915, for example, data rate on transmit is dependent on which uplink channel is used.

Remove dependency on std

Please refer to #6 for more information.

embedded-hal-async-1.0.0-rc.1 `#![feature]` may not be used on the stable release channel

Hi,

I'm a bit of a rust newbie, but I'm trying to figure out how to resolve an issue coming from one of your dependencies

error[E0554]: `#![feature]` may not be used on the stable release channel
 --> $HOME/.cargo/registry/src/index.crates.io-6f17d22bba15001f/embedded-hal-async-1.0.0-rc.1/src/lib.rs:4:1
  |
4 | #![feature(async_fn_in_trait, impl_trait_projections)]
  | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  |
  = help: the feature `impl_trait_projections` has been stable since `1.74.0` and no longer requires an attribute to enable

I've tried adding embedded-hal-async = "1.0.0-rc.2" into my Cargo.toml because they seem to have fixed this issue in that version, but cargo gives me a dependecy conflict:

error: failed to select a version for `embedded-hal-async`.
    ... required by package `meshtastic-rs v0.1.0 (.../meshtastic-rs)`
versions that meet the requirements `^1.0.0-rc.2` are: 1.0.0, 1.0.0-rc.3, 1.0.0-rc.2

all possible versions conflict with previously selected packages.

  previously selected package `embedded-hal-async v1.0.0-rc.1`
    ... which satisfies dependency `embedded-hal-async = "=1.0.0-rc.1"` of package `lora-phy v2.1.2`
    ... which satisfies dependency `lora-phy = "^2.1.2"` of package `meshtastic-rs v0.1.0 (.../meshtastic-rs)`

failed to select a version for `embedded-hal-async` which could resolve this conflict

I can't find where the embedded-hal-async is actually being pinned?? but lib.rs reports the same, this is the only dep that is pinned to the rc.

I'm still learning this stuff, but would y'all be able to loosen restrictions a bit so that embedded-hal-async-1.0.0-rc.2 (and potentially future rcs) can be pulled in?

Status of crate?

Hello,

I was wondering if you'll continue with the development of this crate. I'll soon be working with some Lora radios and I want to do it in Rust. If you are not continuing this library, I might take over myself. Can we discuss the direction of the crate somewhere?

Cheers.

examples: Better documentation for stm32wl examples

Apparently there are two official Nucleo devboards from STM (as of 2024.04) for stm32wl with different frequency ranges:

Improve README for this example with a table for suggested frequencies for different regions these boards support.

nostd support

Thanks for providing the library!

I'm looking for codec support in nostd environments, specifically so that I can target embedded devices. Any plans or thoughts there?

error[E0706]: functions in traits cannot be declared `async`

Steps to reproduce:
Add this to Cargo.toml:

lorawan-device = "^0.11.0"
lora-modulation = "^0.1.3"
#lora-phy = "^2.1.2"
# crates release of `lora-phy` is no longer maintained, but the GH is.
#lora-phy = { git = "https://github.com/lora-rs/lora-rs/tree/main/lora-phy" }
lora-phy = { git = "https://github.com/lora-rs/lora-rs" }

On compile:

error[E0706]: functions in traits cannot be declared `async`
  --> C:\Users\the_a\.cargo\registry\src\index.crates.io-6f17d22bba15001f\embedded-hal-async-1.0.0-rc.2\src\delay.rs:22:5
   |
22 |     async fn delay_ms(&mut self, mut ms: u32) {
   |     -----^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   |     |
   |     `async` because of this
   |
   = note: `async` trait functions are not currently supported
   = note: consider using the `async-trait` crate: https://crates.io/crates/async-trait
   = note: see issue #91611 <https://github.com/rust-lang/rust/issues/91611> for more information

Times ~50-100. Any ideas? Ty! I just got a board in with SX1262 wired to STM32, and am trying it!

Out of range panic while decoding packet

thread 'main' panicked at 'range end index 13 out of range for slice of length 12', /home/cbjamo/.cargo/git/checkouts/rust-lorawan-d3dc04aa7aafaad5/956bde4/encoding/src/parser.rs:565:14
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

I had some debug logging running at the time, but unfortunately not RUST_BACKTRACE. Note that I'm a little behind the latest git, so the error is on line parser.rs#L566 in the current source.

I believe the core issue is that when the device is parsing a packet (See async and state machine) to get the frame count to pass to the validate_mic function. We pass through the DataHeader trait's .fhdr() function, which, via the fhdr_length function, assumes the length field in the header is good.

So I got a bad downlink here, pulled some garbage out of the packet, and indexed out of bounds. I'm not sure what the cleanest way to fix this is. My gut says make the validate_mic function find the frame count on it's own, rather than passing through the trait's functions.

async_device not exposed in the documentation on docs.rs?

Some of the examples (embassy's LoRaWAN examples) utilize imports from lorawan_device::async_device (see below) but there is currently no documentation about these on https://docs.rs/lorawan-device/0.11.0/lorawan_device/all.html

use lorawan_device::async_device::lora_radio::LoRaRadio;
use lorawan_device::async_device::{region, Device, JoinMode};

Async device timing

In rx_with_timeout, the delay times are being calculated as if they were offsets from some zero time, rather than a duration for delay_ms. This makes both windows too long, and RX2 late. For example, with a join request, RX1 will open at 5s from tx done, but will stay open for the window + 5s, then RX2 will open 6s after RX1 closes, and be open for the window + 6s.

I hacked around and have working code, but frankly it's ugly and the math is convoluted. The offsets math is much easier to understand. Because of that I think it would be better to extend the timers to also accept a start and offset time. In my case that's trivial as I'm in userland and the timer I'm using already supports both after/duration and at/instant timers. I'm not sure how hard this change would be to make in the no_std/embedded world. If that's too big a task I can clean up my code and open a PR.

Implement lorawan 1.1 spec

Task list

New header parsing and field renaming
New key derivation helper functions
New MAC Commands

Other considerations

Be able to support only 1.0, or both
Reuse as much code as possible

deprecate use of GenericArray

With const generics, it should be possible now. I think we use GenericArray because it impls Default though. I'm not sure what we need to use instead @lulf

eg:

let mut phy: DataPayloadCreator<[u8; 255], C> = DataPayloadCreator::default();
    |                                                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^ the trait `core::default::Default` is not implemented for `[u8; 255]`

Allow async radio implementations

With async-await rust gaining more usage in embedded, and mechanisms for async traits being feature complete on nightly, it's not too long before stable rust will support it. There are now async SPI implementations, which in turn will allow async radio drivers. The advantages of that would be to use less power awaiting radio irqs, polling for busy signals (on some radios) without explicitly handling those peripheral-specific states at the "link layer".

I'd like to sketch up a proposal for an AsyncPhyRxTx trait, supported in nightly rust configured using a Cargo feature. The code that calls into the radio would need to be async as well, so I was thinking to introduce a new API/types for that, but keep the internals mostly shared apart from the radio interaction.

Wdyt @ivajloip @lthiery ?

RUSTSEC-2016-0005

https://rustsec.org/advisories/RUSTSEC-2016-0005.html

please switch to modern alternative AES library, without a std lib dependency.

stm32wl55

Plans to au915 ?

create a simple lora crate here?

There has been previous discussion of how to encourage interoperability with other Rust Lora projects.

I think one thing that might help is if there was a simple crate to define the modulation's characteristics (ie: Bandwidth, CodingRate, and SpreadingFactor). We have it in here already, but perhaps we define a third-standalone crate that device can depend on? That would make it easy for projects to import those enums while avoiding any other cruft.

Potentially, different methods for calculating time-on-air could be included as well. Any thoughts?

Investigate Cmac::new_varkey performance implications

After a quick benchmark it appears that significant portion of the parsing of a packet is spend in transformation from keys::AES128 to Cmac::<Aes128>. That needs to be confirmed with additional tests and a way to perform this operation only once if possible should be found.

P2P mode?

Apologies for opening an issue for what could be a mostly code-free discussion, but: based on my read of the async_device module it looks at least plausible that I could (mis)use the Device#send_recv method to do direct P2P comms between devices using this driver. (I.e., I want to send and receive raw datagrams, without any LoRaWAN handshake, crypto, or IP overlay.)

Is that something that y'all would expect to more or less work? If so, would it be safe to build on it as a low-level API?

If there's work to be done to clean up the interface or increase the odds of P2P mode "just working" I'm happy to dig in. I just don't want to spend a substantial amount of time working with the direct send/recv path only to have the methods I used get removed or refactored away soon.

Likewise, I don't want to pull against the direction of the project if you're disinterested in supporting any kind of P2P operation. I get that LoRaWAN is like 99% of what people mean when they say "LoRa" and my application is kind of weird for eschewing it.

Make rx1 delay and ack timeout configurable

After migrating from The Things Network V2 -> V3 with rust-lorawan, we found that we needed to tune rx1 delay from 1 second to 5 seconds. Currently this value is hardcoded to 1 second in region/constants.rs

We could make this another timings parameter in the Timings trait, as I don't think it has anything to do with regions. But it seems that is a hard needle to pass through. Maybe allow setting this on the Configuration would make sense?

@lthiery @ivajloip Wdyt?

RX2 downlink handling in case RX1 frame was detected but not intended for the end-device

Handle following edge-case:

Listen for RX1 downlink and start receiving frame...
Hook into HeaderReceived (or any other possible mechanism) and validate MIC and check whether packet is intended for current end-device...
...if not, handle RX2 window if timing still allows it.

Insufficient number of bytes error

I'm using the encoding module in the lorawan-sniffer library as you may know and I've come across a parsing error on some "real live bytes". It could very well be that these are from LoRaWAN v1.1, but I wanted to log a few of the errors here for reference:

error: insufficient number of bytes, with bytes: [65, 67, 77, 73, 58, 57, 48, 58, 50]
error: can not build EncryptedDataPayload from the provided data, with bytes: [117, 30, 247, 224, 134, 94, error: can not build EncryptedDataPayload from the provided data, with bytes: [150, 211, 198, 243, 46, 141, 87, 243, 227, 91, 114, 194, 94, 45, 95, 39, 0, 0, 18]

Anyway, I'll try to loop back and analyze this when I have a moment but I wanted to share the datapoints.

Crypto algorithms can be changed by users

Devices might have bindings to hardware implementation of the cryptography. It should be possible those to be used with the library instead of the default one.

Improve resource utilization

As this library is intended to be used in devices or network servers where memory and CPU utilization could be highly beneficial in terms of time or energy consumption, it makes sense to make the library as lightweight as reasonably possible. This task is intended to track this. The areas envisioned are:

Parsing.
Payload creation.

DBM values in Australia and America block usage of low-power ChipType::SX1261

AU_DBM and US_DBM are set to 21, which is beyond the 15 dBm maximum when using ChipType::SX1261, including STM32WLxx configured for the Low-Power Amplifier. Calling lora_phy's set_pa_config when ChipType::SX1261 and the Australia or US regions returns a result of Err(RadioError::InvalidOutputPower).

Need a way to pass in a different value, or change the default value when using ChipType::SX1261.

Example code for stm32wl only works in release mode

When I run the lora_p2p_send on a NUCLEO-WL55JC1 in unoptimized mode, it doesn't work:

PS C:\Users\pragu\Documents\electronics\nucleo> cargo r
    Finished dev [unoptimized + debuginfo] target(s) in 2.41s
     Running `probe-rs run --chip STM32WLE5JCIx target\thumbv7em-none-eabi\debug\nucleo`
      Erasing ✔ [00:00:02] [##############################################################################################################################################################################################################################################] 142.00 KiB/142.00 KiB @ 60.51 KiB/s (eta 0s )
  Programming ✔ [00:00:03] [##############################################################################################################################################################################################################################################] 141.00 KiB/141.00 KiB @ 38.85 KiB/s (eta 0s )    Finished in 5.992s
0.000000 TRACE BDCR ok: 00008200
└─ embassy_stm32::rcc::bd::{impl#3}::init @ C:\Users\pragu\.cargo\registry\src\index.crates.io-6f17d22bba15001f\embassy-stm32-0.1.0\src\fmt.rs:117 
0.000000 DEBUG rcc: Clocks { sys: Hertz(48000000), pclk1: Hertz(48000000), pclk1_tim: Hertz(48000000), pclk2: Hertz(48000000), pclk2_tim: Hertz(48000000), pclk3: Hertz(48000000), hclk1: Hertz(48000000), hclk2: Hertz(48000000), hclk3: Hertz(48000000), rtc: Some(Hertz(32000)) }
└─ embassy_stm32::rcc::set_freqs @ C:\Users\pragu\.cargo\registry\src\index.crates.io-6f17d22bba15001f\embassy-stm32-0.1.0\src\fmt.rs:130

Switching to release mode does:

PS C:\Users\pragu\Documents\electronics\nucleo> cargo r -r
    Finished release [optimized + debuginfo] target(s) in 1.49s
     Running `probe-rs run --chip STM32WLE5JCIx target\thumbv7em-none-eabi\release\nucleo`
      Erasing ✔ [00:00:00] [################################################################################################################################################################################################################################################] 48.00 KiB/48.00 KiB @ 59.29 KiB/s (eta 0s )
  Programming ✔ [00:00:01] [################################################################################################################################################################################################################################################] 48.00 KiB/48.00 KiB @ 38.28 KiB/s (eta 0s )    Finished in 2.079s
0.104125 TRACE read: addr=[12], len=2, status=e2, buf=[00, 00]
└─ lora_phy::interface::{impl#0}::read_with_status::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\interface.rs:86  
0.104220 TRACE write: [02, 00, 00]
└─ lora_phy::interface::{impl#0}::write::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\interface.rs:24  
0.104267 DEBUG process_irq satisfied: irq_flags = 0x0 in radio mode Transmit
└─ lora_phy::sx1261_2::{impl#1}::process_irq::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\sx1261_2\mod.rs:882 
0.104319 DEBUG process_irq loop entered
└─ lora_phy::sx1261_2::{impl#1}::process_irq::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\sx1261_2\mod.rs:857 
0.104407 TRACE read: addr=[12], len=2, status=e2, buf=[00, 00]
└─ lora_phy::interface::{impl#0}::read_with_status::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\interface.rs:86  
0.104501 TRACE write: [02, 00, 00]
└─ lora_phy::interface::{impl#0}::write::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\interface.rs:24  
0.104549 DEBUG process_irq satisfied: irq_flags = 0x0 in radio mode Transmit
└─ lora_phy::sx1261_2::{impl#1}::process_irq::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\sx1261_2\mod.rs:882
0.104600 DEBUG process_irq loop entered
└─ lora_phy::sx1261_2::{impl#1}::process_irq::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\sx1261_2\mod.rs:857
0.104688 TRACE read: addr=[12], len=2, status=e2, buf=[00, 00]
└─ lora_phy::interface::{impl#0}::read_with_status::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\interface.rs:86
0.104783 TRACE write: [02, 00, 00]
└─ lora_phy::interface::{impl#0}::write::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\interface.rs:24
0.104830 DEBUG process_irq satisfied: irq_flags = 0x0 in radio mode Transmit
└─ lora_phy::sx1261_2::{impl#1}::process_irq::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\sx1261_2\mod.rs:882
0.104882 DEBUG process_irq loop entered
└─ lora_phy::sx1261_2::{impl#1}::process_irq::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\sx1261_2\mod.rs:857
0.104970 TRACE read: addr=[12], len=2, status=e2, buf=[00, 00]
└─ lora_phy::interface::{impl#0}::read_with_status::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\interface.rs:86
0.105065 TRACE write: [02, 00, 00]
└─ lora_phy::interface::{impl#0}::write::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\interface.rs:24
0.105112 DEBUG process_irq satisfied: irq_flags = 0x0 in radio mode Transmit
└─ lora_phy::sx1261_2::{impl#1}::process_irq::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\sx1261_2\mod.rs:882
0.105164 DEBUG process_irq loop entered
└─ lora_phy::sx1261_2::{impl#1}::process_irq::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\sx1261_2\mod.rs:857
0.105252 TRACE read: addr=[12], len=2, status=e2, buf=[00, 00]
└─ lora_phy::interface::{impl#0}::read_with_status::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\interface.rs:86
0.105346 TRACE write: [02, 00, 00]
└─ lora_phy::interface::{impl#0}::write::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\interface.rs:24  
0.105394 DEBUG process_irq satisfied: irq_flags = 0x0 in radio mode Transmit
└─ lora_phy::sx1261_2::{impl#1}::process_irq::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\sx1261_2\mod.rs:882
0.105445 DEBUG process_irq loop entered
└─ lora_phy::sx1261_2::{impl#1}::process_irq::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\sx1261_2\mod.rs:857
0.105533 TRACE read: addr=[12], len=2, status=e2, buf=[00, 00]
└─ lora_phy::interface::{impl#0}::read_with_status::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\interface.rs:86
0.105628 TRACE write: [02, 00, 00]
└─ lora_phy::interface::{impl#0}::write::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\interface.rs:24
0.105675 DEBUG process_irq satisfied: irq_flags = 0x0 in radio mode Transmit
└─ lora_phy::sx1261_2::{impl#1}::process_irq::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\sx1261_2\mod.rs:882
0.105727 DEBUG process_irq loop entered
└─ lora_phy::sx1261_2::{impl#1}::process_irq::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\sx1261_2\mod.rs:857
0.105815 TRACE read: addr=[12], len=2, status=e2, buf=[00, 00]
└─ lora_phy::interface::{impl#0}::read_with_status::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\interface.rs:86
0.105910 TRACE write: [02, 00, 00]
└─ lora_phy::interface::{impl#0}::write::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\interface.rs:24
0.105957 DEBUG process_irq satisfied: irq_flags = 0x0 in radio mode Transmit
└─ lora_phy::sx1261_2::{impl#1}::process_irq::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\sx1261_2\mod.rs:882
0.106009 DEBUG process_irq loop entered
└─ lora_phy::sx1261_2::{impl#1}::process_irq::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\sx1261_2\mod.rs:857
0.106097 TRACE read: addr=[12], len=2, status=e2, buf=[00, 00]
└─ lora_phy::interface::{impl#0}::read_with_status::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\interface.rs:86
0.106191 TRACE write: [02, 00, 00]
└─ lora_phy::interface::{impl#0}::write::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\interface.rs:24
0.106239 DEBUG process_irq satisfied: irq_flags = 0x0 in radio mode Transmit
└─ lora_phy::sx1261_2::{impl#1}::process_irq::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\sx1261_2\mod.rs:882
0.106290 DEBUG process_irq loop entered
└─ lora_phy::sx1261_2::{impl#1}::process_irq::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\sx1261_2\mod.rs:857
0.106378 TRACE read: addr=[12], len=2, status=e2, buf=[00, 00]
└─ lora_phy::interface::{impl#0}::read_with_status::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\interface.rs:86
0.106473 TRACE write: [02, 00, 00]
└─ lora_phy::interface::{impl#0}::write::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\interface.rs:24
0.106520 DEBUG process_irq satisfied: irq_flags = 0x0 in radio mode Transmit
└─ lora_phy::sx1261_2::{impl#1}::process_irq::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\sx1261_2\mod.rs:882
0.106572 DEBUG process_irq loop entered
└─ lora_phy::sx1261_2::{impl#1}::process_irq::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\sx1261_2\mod.rs:857
0.106660 TRACE read: addr=[12], len=2, status=e2, buf=[00, 00]
└─ lora_phy::interface::{impl#0}::read_with_status::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\interface.rs:86
0.106755 TRACE write: [02, 00, 00]
└─ lora_phy::interface::{impl#0}::write::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\interface.rs:24
0.106802 DEBUG process_irq satisfied: irq_flags = 0x0 in radio mode Transmit
└─ lora_phy::sx1261_2::{impl#1}::process_irq::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\sx1261_2\mod.rs:882
0.106854 DEBUG process_irq loop entered
└─ lora_phy::sx1261_2::{impl#1}::process_irq::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\sx1261_2\mod.rs:857
0.106942 TRACE read: addr=[12], len=2, status=e2, buf=[00, 00]
└─ lora_phy::interface::{impl#0}::read_with_status::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\interface.rs:86
0.107036 TRACE write: [02, 00, 00]
└─ lora_phy::interface::{impl#0}::write::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\interface.rs:24
0.107084 DEBUG process_irq satisfied: irq_flags = 0x0 in radio mode Transmit
└─ lora_phy::sx1261_2::{impl#1}::process_irq::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\sx1261_2\mod.rs:882
0.107135 DEBUG process_irq loop entered
└─ lora_phy::sx1261_2::{impl#1}::process_irq::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\sx1261_2\mod.rs:857
0.107223 TRACE read: addr=[12], len=2, status=e2, buf=[00, 00]
└─ lora_phy::interface::{impl#0}::read_with_status::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\interface.rs:86
0.107318 TRACE write: [02, 00, 00]
└─ lora_phy::interface::{impl#0}::write::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\interface.rs:24
0.107365 DEBUG process_irq satisfied: irq_flags = 0x0 in radio mode Transmit
└─ lora_phy::sx1261_2::{impl#1}::process_irq::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\sx1261_2\mod.rs:882
0.107417 DEBUG process_irq loop entered
└─ lora_phy::sx1261_2::{impl#1}::process_irq::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\sx1261_2\mod.rs:857
0.107505 TRACE read: addr=[12], len=2, status=e2, buf=[00, 00]
└─ lora_phy::interface::{impl#0}::read_with_status::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\interface.rs:86
0.107600 TRACE write: [02, 00, 00]
└─ lora_phy::interface::{impl#0}::write::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\interface.rs:24
0.107647 DEBUG process_irq satisfied: irq_flags = 0x0 in radio mode Transmit
└─ lora_phy::sx1261_2::{impl#1}::process_irq::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\sx1261_2\mod.rs:882
0.107699 DEBUG process_irq loop entered
└─ lora_phy::sx1261_2::{impl#1}::process_irq::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\sx1261_2\mod.rs:857
0.107787 TRACE read: addr=[12], len=2, status=e2, buf=[00, 00]
└─ lora_phy::interface::{impl#0}::read_with_status::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\interface.rs:86
0.107881 TRACE write: [02, 00, 00]
└─ lora_phy::interface::{impl#0}::write::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\interface.rs:24
0.107929 DEBUG process_irq satisfied: irq_flags = 0x0 in radio mode Transmit
└─ lora_phy::sx1261_2::{impl#1}::process_irq::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\sx1261_2\mod.rs:882
0.107980 DEBUG process_irq loop entered
└─ lora_phy::sx1261_2::{impl#1}::process_irq::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\sx1261_2\mod.rs:857
0.108068 TRACE read: addr=[12], len=2, status=e2, buf=[00, 00]
└─ lora_phy::interface::{impl#0}::read_with_status::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\interface.rs:86
0.108163 TRACE write: [02, 00, 00]
└─ lora_phy::interface::{impl#0}::write::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\interface.rs:24
0.108210 DEBUG process_irq satisfied: irq_flags = 0x0 in radio mode Transmit
└─ lora_phy::sx1261_2::{impl#1}::process_irq::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\sx1261_2\mod.rs:882
0.108262 DEBUG process_irq loop entered
└─ lora_phy::sx1261_2::{impl#1}::process_irq::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\sx1261_2\mod.rs:857
0.108350 TRACE read: addr=[12], len=2, status=e2, buf=[00, 00]
└─ lora_phy::interface::{impl#0}::read_with_status::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\interface.rs:86
0.108445 TRACE write: [02, 00, 00]
└─ lora_phy::interface::{impl#0}::write::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\interface.rs:24
0.108492 DEBUG process_irq satisfied: irq_flags = 0x0 in radio mode Transmit
└─ lora_phy::sx1261_2::{impl#1}::process_irq::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\sx1261_2\mod.rs:882
0.108544 DEBUG process_irq loop entered
└─ lora_phy::sx1261_2::{impl#1}::process_irq::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\sx1261_2\mod.rs:857
0.115203 TRACE write: [02, 00, 00]
└─ lora_phy::interface::{impl#0}::write::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\interface.rs:24
0.115250 DEBUG process_irq satisfied: irq_flags = 0x0 in radio mode Transmit
└─ lora_phy::sx1261_2::{impl#1}::process_irq::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\sx1261_2\mod.rs:882
0.115302 DEBUG process_irq loop entered
└─ lora_phy::sx1261_2::{impl#1}::process_irq::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\sx1261_2\mod.rs:857
0.115390 TRACE read: addr=[12], len=2, status=e2, buf=[00, 00]
└─ lora_phy::interface::{impl#0}::read_with_status::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\interface.rs:86
0.115484 TRACE write: [02, 00, 00]
└─ lora_phy::interface::{impl#0}::write::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\interface.rs:24
0.115532 DEBUG process_irq satisfied: irq_flags = 0x0 in radio mode Transmit
└─ lora_phy::sx1261_2::{impl#1}::process_irq::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\sx1261_2\mod.rs:882
0.115583 DEBUG process_irq loop entered
└─ lora_phy::sx1261_2::{impl#1}::process_irq::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\sx1261_2\mod.rs:857
0.115671 TRACE read: addr=[12], len=2, status=e2, buf=[00, 00]
└─ lora_phy::interface::{impl#0}::read_with_status::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\interface.rs:86
0.115766 TRACE write: [02, 00, 00]
└─ lora_phy::interface::{impl#0}::write::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\interface.rs:24
0.115813 DEBUG process_irq satisfied: irq_flags = 0x0 in radio mode Transmit
└─ lora_phy::sx1261_2::{impl#1}::process_irq::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\sx1261_2\mod.rs:882
0.115865 DEBUG process_irq loop entered
└─ lora_phy::sx1261_2::{impl#1}::process_irq::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\sx1261_2\mod.rs:857
0.115953 TRACE read: addr=[12], len=2, status=e2, buf=[00, 00]
└─ lora_phy::interface::{impl#0}::read_with_status::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\interface.rs:86
0.116048 TRACE write: [02, 00, 00]
└─ lora_phy::interface::{impl#0}::write::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\interface.rs:24
0.116095 DEBUG process_irq satisfied: irq_flags = 0x0 in radio mode Transmit
└─ lora_phy::sx1261_2::{impl#1}::process_irq::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\sx1261_2\mod.rs:882
0.116147 DEBUG process_irq loop entered
└─ lora_phy::sx1261_2::{impl#1}::process_irq::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\sx1261_2\mod.rs:857
0.116235 TRACE read: addr=[12], len=2, status=e2, buf=[00, 00]
└─ lora_phy::interface::{impl#0}::read_with_status::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\interface.rs:86
0.116329 TRACE write: [02, 00, 00]
└─ lora_phy::interface::{impl#0}::write::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\interface.rs:24
0.116377 DEBUG process_irq satisfied: irq_flags = 0x0 in radio mode Transmit
└─ lora_phy::sx1261_2::{impl#1}::process_irq::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\sx1261_2\mod.rs:882
0.116428 DEBUG process_irq loop entered
└─ lora_phy::sx1261_2::{impl#1}::process_irq::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\sx1261_2\mod.rs:857
0.116516 TRACE read: addr=[12], len=2, status=e2, buf=[00, 00]
└─ lora_phy::interface::{impl#0}::read_with_status::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\interface.rs:86
0.116611 TRACE write: [02, 00, 00]
└─ lora_phy::interface::{impl#0}::write::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\interface.rs:24
0.116658 DEBUG process_irq satisfied: irq_flags = 0x0 in radio mode Transmit
└─ lora_phy::sx1261_2::{impl#1}::process_irq::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\sx1261_2\mod.rs:882
0.116710 DEBUG process_irq loop entered
└─ lora_phy::sx1261_2::{impl#1}::process_irq::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\sx1261_2\mod.rs:857
0.116798 TRACE read: addr=[12], len=2, status=e2, buf=[00, 00]
└─ lora_phy::interface::{impl#0}::read_with_status::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\interface.rs:86
0.116893 TRACE write: [02, 00, 00]
└─ lora_phy::interface::{impl#0}::write::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\interface.rs:24
0.116940 DEBUG process_irq satisfied: irq_flags = 0x0 in radio mode Transmit
└─ lora_phy::sx1261_2::{impl#1}::process_irq::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\sx1261_2\mod.rs:882
0.116992 DEBUG process_irq loop entered
└─ lora_phy::sx1261_2::{impl#1}::process_irq::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\sx1261_2\mod.rs:857
0.117077 TRACE read: addr=[12], len=2, status=e2, buf=[00, 00]
└─ lora_phy::interface::{impl#0}::read_with_status::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\interface.rs:86
0.117172 TRACE write: [02, 00, 00]
└─ lora_phy::interface::{impl#0}::write::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\interface.rs:24
0.117219 DEBUG process_irq satisfied: irq_flags = 0x0 in radio mode Transmit
└─ lora_phy::sx1261_2::{impl#1}::process_irq::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\sx1261_2\mod.rs:882
0.117271 DEBUG process_irq loop entered
└─ lora_phy::sx1261_2::{impl#1}::process_irq::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\sx1261_2\mod.rs:857
0.117359 TRACE read: addr=[12], len=2, status=e2, buf=[00, 00]
└─ lora_phy::interface::{impl#0}::read_with_status::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\interface.rs:86
0.117454 TRACE write: [02, 00, 00]
└─ lora_phy::interface::{impl#0}::write::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\interface.rs:24
0.117501 DEBUG process_irq satisfied: irq_flags = 0x0 in radio mode Transmit
└─ lora_phy::sx1261_2::{impl#1}::process_irq::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\sx1261_2\mod.rs:882
0.117553 DEBUG process_irq loop entered
└─ lora_phy::sx1261_2::{impl#1}::process_irq::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\sx1261_2\mod.rs:857
0.117641 TRACE read: addr=[12], len=2, status=e2, buf=[00, 00]
└─ lora_phy::interface::{impl#0}::read_with_status::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\interface.rs:86
0.117735 TRACE write: [02, 00, 00]
└─ lora_phy::interface::{impl#0}::write::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\interface.rs:24
0.117783 DEBUG process_irq satisfied: irq_flags = 0x0 in radio mode Transmit
└─ lora_phy::sx1261_2::{impl#1}::process_irq::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\sx1261_2\mod.rs:882
0.117834 DEBUG process_irq loop entered
└─ lora_phy::sx1261_2::{impl#1}::process_irq::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\sx1261_2\mod.rs:857
0.117922 TRACE read: addr=[12], len=2, status=e2, buf=[00, 00]
└─ lora_phy::interface::{impl#0}::read_with_status::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\interface.rs:86
0.118017 TRACE write: [02, 00, 00]
└─ lora_phy::interface::{impl#0}::write::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\interface.rs:24
0.118064 DEBUG process_irq satisfied: irq_flags = 0x0 in radio mode Transmit
└─ lora_phy::sx1261_2::{impl#1}::process_irq::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\sx1261_2\mod.rs:882
0.118116 DEBUG process_irq loop entered
└─ lora_phy::sx1261_2::{impl#1}::process_irq::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\sx1261_2\mod.rs:857
0.118204 TRACE read: addr=[12], len=2, status=e2, buf=[00, 00]
└─ lora_phy::interface::{impl#0}::read_with_status::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\interface.rs:86
0.118299 TRACE write: [02, 00, 00]
└─ lora_phy::interface::{impl#0}::write::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\interface.rs:24
0.118346 DEBUG process_irq satisfied: irq_flags = 0x0 in radio mode Transmit
└─ lora_phy::sx1261_2::{impl#1}::process_irq::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\sx1261_2\mod.rs:882
0.118398 DEBUG process_irq loop entered
└─ lora_phy::sx1261_2::{impl#1}::process_irq::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\sx1261_2\mod.rs:857
0.118486 TRACE read: addr=[12], len=2, status=e2, buf=[00, 00]
└─ lora_phy::interface::{impl#0}::read_with_status::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\interface.rs:86
0.118580 TRACE write: [02, 00, 00]
└─ lora_phy::interface::{impl#0}::write::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\interface.rs:24
0.118628 DEBUG process_irq satisfied: irq_flags = 0x0 in radio mode Transmit
└─ lora_phy::sx1261_2::{impl#1}::process_irq::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\sx1261_2\mod.rs:882
0.118679 DEBUG process_irq loop entered
└─ lora_phy::sx1261_2::{impl#1}::process_irq::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\sx1261_2\mod.rs:857
0.118767 TRACE read: addr=[12], len=2, status=e2, buf=[00, 00]
└─ lora_phy::interface::{impl#0}::read_with_status::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\interface.rs:86
0.118862 TRACE write: [02, 00, 00]
└─ lora_phy::interface::{impl#0}::write::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\interface.rs:24
0.118909 DEBUG process_irq satisfied: irq_flags = 0x0 in radio mode Transmit
└─ lora_phy::sx1261_2::{impl#1}::process_irq::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\sx1261_2\mod.rs:882
0.118961 DEBUG process_irq loop entered
└─ lora_phy::sx1261_2::{impl#1}::process_irq::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\sx1261_2\mod.rs:857
0.119049 TRACE read: addr=[12], len=2, status=e2, buf=[00, 00]
└─ lora_phy::interface::{impl#0}::read_with_status::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\interface.rs:86
0.119144 TRACE write: [02, 00, 00]
└─ lora_phy::interface::{impl#0}::write::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\interface.rs:24
0.119191 DEBUG process_irq satisfied: irq_flags = 0x0 in radio mode Transmit
└─ lora_phy::sx1261_2::{impl#1}::process_irq::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\sx1261_2\mod.rs:882
0.119243 DEBUG process_irq loop entered
└─ lora_phy::sx1261_2::{impl#1}::process_irq::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\sx1261_2\mod.rs:857
0.119331 TRACE read: addr=[12], len=2, status=e2, buf=[00, 00]
└─ lora_phy::interface::{impl#0}::read_with_status::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\interface.rs:86
0.119425 TRACE write: [02, 00, 00]
└─ lora_phy::interface::{impl#0}::write::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\interface.rs:24
0.119473 DEBUG process_irq satisfied: irq_flags = 0x0 in radio mode Transmit
└─ lora_phy::sx1261_2::{impl#1}::process_irq::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\sx1261_2\mod.rs:882
0.119524 DEBUG process_irq loop entered
└─ lora_phy::sx1261_2::{impl#1}::process_irq::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\sx1261_2\mod.rs:857
0.126089 TRACE read: addr=[12], len=2, status=e2, buf=[00, 00]
└─ lora_phy::interface::{impl#0}::read_with_status::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\interface.rs:86
0.126183 TRACE write: [02, 00, 00]
└─ lora_phy::interface::{impl#0}::write::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\interface.rs:24
0.126231 DEBUG process_irq satisfied: irq_flags = 0x0 in radio mode Transmit
└─ lora_phy::sx1261_2::{impl#1}::process_irq::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\sx1261_2\mod.rs:882
0.126282 DEBUG process_irq loop entered
└─ lora_phy::sx1261_2::{impl#1}::process_irq::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\sx1261_2\mod.rs:857
0.126370 TRACE read: addr=[12], len=2, status=e2, buf=[00, 00]
└─ lora_phy::interface::{impl#0}::read_with_status::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\interface.rs:86
0.126465 TRACE write: [02, 00, 00]
└─ lora_phy::interface::{impl#0}::write::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\interface.rs:24
0.126512 DEBUG process_irq satisfied: irq_flags = 0x0 in radio mode Transmit
└─ lora_phy::sx1261_2::{impl#1}::process_irq::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\sx1261_2\mod.rs:882
0.126564 DEBUG process_irq loop entered
└─ lora_phy::sx1261_2::{impl#1}::process_irq::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\sx1261_2\mod.rs:857
0.126652 TRACE read: addr=[12], len=2, status=e2, buf=[00, 00]
└─ lora_phy::interface::{impl#0}::read_with_status::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\interface.rs:86
0.126747 TRACE write: [02, 00, 00]
└─ lora_phy::interface::{impl#0}::write::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\interface.rs:24
0.126794 DEBUG process_irq satisfied: irq_flags = 0x0 in radio mode Transmit
└─ lora_phy::sx1261_2::{impl#1}::process_irq::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\sx1261_2\mod.rs:882
0.126846 DEBUG process_irq loop entered
└─ lora_phy::sx1261_2::{impl#1}::process_irq::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\sx1261_2\mod.rs:857
0.126934 TRACE read: addr=[12], len=2, status=e2, buf=[00, 00]
└─ lora_phy::interface::{impl#0}::read_with_status::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\interface.rs:86
0.127028 TRACE write: [02, 00, 00]
└─ lora_phy::interface::{impl#0}::write::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\interface.rs:24
0.127076 DEBUG process_irq satisfied: irq_flags = 0x0 in radio mode Transmit
└─ lora_phy::sx1261_2::{impl#1}::process_irq::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\sx1261_2\mod.rs:882
0.127127 DEBUG process_irq loop entered
└─ lora_phy::sx1261_2::{impl#1}::process_irq::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\sx1261_2\mod.rs:857
0.127215 TRACE read: addr=[12], len=2, status=e2, buf=[00, 00]
└─ lora_phy::interface::{impl#0}::read_with_status::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\interface.rs:86
0.127310 TRACE write: [02, 00, 00]
└─ lora_phy::interface::{impl#0}::write::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\interface.rs:24
0.127357 DEBUG process_irq satisfied: irq_flags = 0x0 in radio mode Transmit
└─ lora_phy::sx1261_2::{impl#1}::process_irq::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\sx1261_2\mod.rs:882
0.127409 DEBUG process_irq loop entered
└─ lora_phy::sx1261_2::{impl#1}::process_irq::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\sx1261_2\mod.rs:857
0.127497 TRACE read: addr=[12], len=2, status=e2, buf=[00, 00]
└─ lora_phy::interface::{impl#0}::read_with_status::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\interface.rs:86
0.127592 TRACE write: [02, 00, 00]
└─ lora_phy::interface::{impl#0}::write::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\interface.rs:24
0.127639 DEBUG process_irq satisfied: irq_flags = 0x0 in radio mode Transmit
└─ lora_phy::sx1261_2::{impl#1}::process_irq::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\sx1261_2\mod.rs:882
0.127691 DEBUG process_irq loop entered
└─ lora_phy::sx1261_2::{impl#1}::process_irq::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\sx1261_2\mod.rs:857
0.127779 TRACE read: addr=[12], len=2, status=ac, buf=[00, 01]
└─ lora_phy::interface::{impl#0}::read_with_status::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\interface.rs:86
0.127876 TRACE write: [02, 00, 01]
└─ lora_phy::interface::{impl#0}::write::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\interface.rs:24
0.127925 DEBUG process_irq satisfied: irq_flags = 0x1 in radio mode Transmit
└─ lora_phy::sx1261_2::{impl#1}::process_irq::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\sx1261_2\mod.rs:882
0.127979 DEBUG TxDone in radio mode Transmit
└─ lora_phy::sx1261_2::{impl#1}::process_irq::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\sx1261_2\mod.rs:899
0.128022 INFO  TX DONE
└─ nucleo::____embassy_main_task::{async_fn#0} @ src\main.rs:103
0.128072 TRACE write: [84, 00]
└─ lora_phy::interface::{impl#0}::write::{async_fn#0} @ C:\Users\pragu\.cargo\git\checkouts\lora-rs-9ebdb91068f5935a\fabb564\lora-phy\src\interface.rs:24
0.130131 INFO  Sleep successful
└─ nucleo::____embassy_main_task::{async_fn#0} @ src\main.rs:112

I'm using the git source in my Cargo.toml, since the crates.io version isn't updated yet to the new update of embedded-hal-async.

channel_enabled appears to index ChannelMask incorrectly

Hi,

I have been having a look at implementing LinkADRReq for AU915 and have noticed that the channel_enabled appears to index the ChannelMask incorrectly.

LoRaMAC-node stores channel masks directly from the LinkADRReq MAC command and when setting the 1st sub band using a ChMaskCtrl of 5 they write to the right most bits of the ChannelMask. Link to example.

Currently channel_enabled indexes as though index 0 stores the lowest channels of the mask.

I have implemented a potential fix for this here

Drop bundled trallocator in favor of existing crate?

Based on git history, I can assume that trallocator was bundled due to lack of published crate? Now that there is one, could we drop the bundled code in favor of this crate?

cc: @ivajloip

[edit]: Current trallocator code probably originates from this thread from reddit: https://www.reddit.com/r/rust/comments/8z83wc/is_there_any_way_to_benchmark_memory_usage_in_rust/

Use a specific subband when the network's subband is unknown

Is there a way to make a device use a specific subband when the network's (or gateway's) operating subband is unknown before joining? For example in the US915 region, if no subband is specified (US915::new()), then the device will randomly hop across the 64 available channels.

Here is an interesting use case: when first attempting to join, the device tries an OTAA join request on random channels until one is accepted. Is there a way to then restrict the device to then only use the subband on which it successfully joined? Or at least manually change the region/subband of a created Device?

Forgive my ignorance; I'm pretty new to LoRaWAN. Is it common for networks to all operate on the same subband, or are gateways allowed to operate on different subbands?

Add functions to calculate air time for packets

It could be useful for user of the library to have an easy way to calculate the time it takes for a packet to be transmitted.

Fix DataPayloadCreator to unwritten bytes are set to 0. Consider other creators

I ran into an interesting issue when building some downlinks for tests.

The following builder does not construct a good packet if you don't zero out the buffer:

rx_buffer.iter_mut().for_each(|x| *x = 0);
let mut phy = lorawan::creator::DataPayloadCreator::with_options(
    rx_buffer,
    DefaultFactory::default(),
)
.unwrap();
phy.set_confirmed(uplink.is_confirmed());
phy.set_dev_addr(&[0; 4]);
phy.set_uplink(false);
phy.set_fcnt(1);
let finished = phy.build(&[], &[], &AES128(get_key()), &AES128(get_key())).unwrap();

This is almost a null packet, with no FOpts or FRMPayload (just a confirmation bit set high if needed). But what's interesting is the builder does not zero out the byte in index 5, so anything sitting in the buffer from before will remain there.

I think this code here is the area of interest.

I didn't have time to fix it so I just zero out the buffer. But I wanted to open this issue for tracking. I'm not even sure if the API is assuming the buffer must be zero'ed out. It would be cool if it did not, IMO, but then we need to fix this creator to zero out the d[5] under the right conditions. I tried the following and while it "fixed" my issue, it broke some unit tests in encoding:

// Set FOptsLen if present
if !has_fport_zero && mac_cmds_len > 0 {
        d[5] |= mac_cmds_len as u8 & 0x0f;
        maccommandcreator::build_mac_commands(
            cmds,
            &mut d[last_filled..last_filled + mac_cmds_len],
        )
        .unwrap();
        last_filled += mac_cmds_len;
} else {
      d[5]=0; 
}

Including more fields in session data

To be able to delete the device for power saving we need to save the session data. This was achieved a while back but we should add more stuff to the sessiondata to be able to resume when we re-create the device.

Mainly we need dl_settings but maybe also some more fields.

Here is a snippet from the join process.
https://github.com/ivajloip/rust-lorawan/blob/44c1f4bd6d173e7c4cd767acca470d535756c886/device/src/async_device/mod.rs#L146-L154

I would suggest (after talking with @lulf ) that we add the fields to JoinAccept and return it from self.region.process_join_accept. Then we could even pass JoinAccept or the needed fields to SessionData::derive_new and move the derive code for the different fields out of DecryptedJoinAcceptPayload.

With "fields" I mean these (dlsettings, RxDelay...):
https://www.thethingsnetwork.org/docs/lorawan/message-types/#calculating-the-message-integrity-code-mic

Is this a good approach? Is there something I am missing?

MSB/LSB first?

Hey, I'm trying to get an rfm9x to work with sx127x library and rust-lorawan. I'm trying to send data to TTN.
The MISO data line looks reasonable and apparently my tiva board can talk to the lora chip.

So far the data doesn't make it to TTN. So, I'm trying to narrow down the problem. This is my lorawan configuraiton:

    lora.set_tx_power(20, 1).unwrap(); //Using PA_BOOST. See your board for correct pin.

    let dev_eui = &[0x70, 0xB3, 0xD5, 0x7E, 0xD0, 0x05, 0x01, 0x3A];
    let app_eui = &[0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00];  # this can be all 0, right?
    let app_key = [0x80, 0x5D,.. total of 16 hex copy poste from TTN ];

    let mut data = [0; 23];  # take from a test I think. Do I have to set data here?
    let mut phy = JoinRequestCreator::with_options(&mut data[..], DefaultFactory).unwrap();
    let key = AES128(app_key);
    phy.set_app_eui(app_eui)
        .set_dev_eui(dev_eui)
        .set_dev_nonce(&[0x28, 0x10]);             # this can be any nonce right? So I randomly chose these two byte.

    let payload = phy.build(&key).unwrap();

Apart from the inline comments I'm wonderin if rust-lorawan expects dev_eui, app_eui and app_key as msb or lsb first?

Best regards and thanks in advance!
Marius

Support chips with integrated RNG

There are many microcontrollers which don't have an onboard TRNG. On the other hand, some LoRa chips (eg, SX1262) can be used to generate random numbers. It would be nice to leverage that functionality and give the user the option of using either the microcrontroller (if it exists) or the LoRa chip's.

async_device RX windows may be disturbed by noise

There's a bit of a problem in the call logic where the timing and windows are managed in rx_with_timeout. Any received radio data on the proper channel at the proper time will essentially lead us to executing lorawan_parse on the data. The problem lies in the fact that if it's unsuccessful, we don't continue to listen at all and the whole listening and receive context is long gone.

Use specific DevEui, AppEui, AppKey, NewSKey, AppSKey, DevAddr Types in Encoding

It's currently inconsistent in its use of AES128 type:

pub enum JoinMode {
    OTAA { deveui: [u8; 8], appeui: [u8; 8], appkey: [u8; 16] },
    ABP { newskey: AES128, appskey: AES128, devaddr: DevAddr<[u8; 4]> },
}

It's generally preferable to have specialized types, so OTAA should adopt AES128 as well.

We probably want to make special types for DevEui and AppEui as well?

Handle RXParamSetupReq

While reviewing #81 and preparing a followup pr for IN865 and AS923 I found out that TTN uses a non-standard datarate for RX2 in the EU[1]. The TTN docs claim that the OTAA process should configure this, but I don't believe that's being handled at the moment. Missing RX2 windows probably isn't a huge issue (I don't think I've ever seen a RX2 downlink, though I'm not in the EU), and I think this can wait till someone has time to refactor the region code.

[1] https://www.thethingsnetwork.org/docs/lorawan/frequency-plans/

examples: Create device <-> radio matrix in the README

We currently have bunch of device-specific examples, but we should also advertise these in top-level README.

Also, create some kind of matrix which maps radio to chip, for example, our nrf52840 examples target sx1261 chips and rp example is a Rpi Pico (RP2040) add-on board from Waveshare with sx1262 chip.

nrf52840
rp
stm32l0
stm32wl

Recommend Projects

React

A declarative, efficient, and flexible JavaScript library for building user interfaces.
Vue.js

🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript

TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
TensorFlow

An Open Source Machine Learning Framework for Everyone
Django

The Web framework for perfectionists with deadlines.
Laravel

A PHP framework for web artisans
D3

Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

javascript

JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
web

Some thing interesting about web. New door for the world.
server

A server is a program made to process requests and deliver data to clients.
Machine learning

Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Visualization

Some thing interesting about visualization, use data art
Game

Some thing interesting about game, make everyone happy.

Recommend Org

Facebook

We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft

Open source projects and samples from Microsoft.
Google

Google ❤️ Open Source for everyone.
Alibaba

Alibaba Open Source for everyone
D3

Data-Driven Documents codes.
Tencent

China tencent open source team.

	// TODO: 3rd argument (boost_if_possible) shouldn't be exposed, as it depends
	// on physical board layout. Needs to be eventually handled from lora-phy side.
	self.lora.prepare_for_tx(&mdltn_params, config.pw.into(), false).await?;