examples/lorawan: add the possibility to use ABP activation procedure

[aabadie]

Contribution description

don't merge this PR: it is RFC and contains broken things

This PR splits the lorawan examples in 2 distinct applications:
one showing the OTAA join procedure (as before)
one showing the ABP join procudure

This PR adds the possibility to use ABP activation procedure to the existing application.

This PR also enables the low-power modes "manually". 2 different strategies are used depending on the activation procedure:

• OTAA: use STOP mode (well I'm targetting STM32 here) because it provides RAM retention while sleeping, keeping the loramac state when waking up.
• ABP: use STANDBY mode + EEPROM storage. This allows very low power consumption + no need for RAM retention since session keys and device address are already known.

With OTAA + STOP mode, I was expecting an issue with duty-cycle (which is managed internally by the MAC): when the device go to sleep, the duty-cycle timer is still running and when it wakes-up, the counter value is in the same state as it was just before going to sleep. This results in impossible sending, except if duty-cycle is disabled, which is possible but require modification in the mac adaption code.

For the moment, I have no idea of the real power consumption during the sleep phase: the CPU is sleeping for sure but maybe the radio must be shutdown manually as well to reach maximum power saving.

cc'ing @fjmolinas who might be interested by this.

Testing procedure

I did some functional testing with a b-l072z-lrwan1 on IoT-LAB without power consumption:

• Start an experiment on the testbed

$ iotlab-experiment submit -n lorawan -d 120 -l saclay,st-lrwan1,25
$ iotlab-experiment wait

• Ensure no previous LoRaWAN parameters are stored on the device:

$ make IOTLAB_NODE=auto-ssh -C tests/pkg_semtech-loramac/ flash term
> loramac erase

• Flash examples/lorawan_abp with your LoRaWAN device/application parameters (if using TTN, ensure your frame counters are reset before):

$ make DEVADDR=<your devaddr> NWKSKEY=<your nwkskey> APPSKEY=<your appskey> IOTLAB_NODE=auto-ssh -C examples/lorawan_abp flash term

You should see the device rebooting every 20 seconds and a message sent to the backend. In between each reboot, the device is going to STANDBY deep-sleep mode.

• Flash examples/lorawan_otaa with your LoRaWAN device/application parameters:

$ make DEVEUI=<your deveui> APPEUI=<your appeui> APPKEY=<your appkey> IOTLAB_NODE=auto-ssh -C examples/lorawan_otaa/ flash term

You can observe that the activation is successful, the first message is sent with success (and received). But then, each time after waking-up, you get the message: Cannot send message 'This is RIOT!', ret code: 11. Return code 11, corresponds to SEMTECH_LORAMAC_DUTYCYCLE_RESTRICTED.

Issues/PRs references

Based on #11221
This PR is now based on #11552 and #11541

Now based on #14547 and #14551

Now based on #17793

[smlng]

I would suggest to move this to the applications repo, not cluttering the examples anymore.

[jia200x]

hi @aabadie

Thanks for your efforts in LPM and LoRaWAN!

I have some comments about the fundamentals of this PR:

• The function of the MAC layer is the same regardless of the join method. In fact, the join procedure generates the nwkskey, appskey and devaddr from the OTAA params. So, we should aim to have one example that covers both cases
• There are MIB setters and getters that we could use for saving and restoring the MAC state after STANDBY mode.
• In fact, I just did a quick check and I think the whole MAC can be restored just with MLME_GET and MLME_SET requests.
• For LPM, we could update the internal duty cycle counter with the RTC sleep. A quick fix could be to add a new MIB. The more elegant solution would be to implement the LoRaWAN timers on top of RTC.

What do you think?

[aabadie]

There are MIB setters and getters that we could use for saving and restoring the MAC state after STANDBY mode.

Here you make the assumption that the board you are running provide non volatile storage which might not be the case all the time.
That's why I think OTAA is better suited for STOP low-power mode with RAM retention: the state of the MAC is kept in RAM after restart.

The more elegant solution would be to implement the LoRaWAN timers on top of RTC.

I think RTT would be more appropriate during TX and RX windows phases as it's more precise. And also when during STOP deep sleep phase (LPTIM is still active on STMs during STOP).
I already had a look at using RTT in replacement of xtimer but my problem was with multiple alarms running at the same time.

For STANDBY, using RTC is fine during the sleep phase, like it's already done in the example.

[jia200x]

Here you make the assumption that the board you are running provide non volatile storage which might not be the case all the time.

True. But in practice, boards in a real deployment should include non volatile retention mechanisms. Considering the consumption in STANDBY can be e.g 60% of STOP mode, IMO we should aim to have all LPM regardless of the activation mechanisms. If a board doesn't include a non-volatile storage, then it could still run with STOP mode. But I wouldn't block OTAA users if they want to run in STANDBY mode.

I think RTT would be more appropriate during TX and RX windows phases as it's more precise

Yes, indeed.

I already had a look at using RTT in replacement of xtimer but my problem was with multiple alarms running at the same time.

The MAC can in theory run with only one timer, but we would need to patch a little bit the OnMacStateChekTimer function. I think that could help us in this direction.

[kaspar030]

* keeping the loramac state when waking up.

How big is the state? If it is less then ~80 bytes in total, maybe #11369 can be used to store it in RTC?

[jia200x]

How big is the state? If it is less then ~80 bytes in total, maybe #11369 can be used to store it in RTC?

I would say around 60 bytes. So yes, it could be an option

[aabadie]

I removed the split in 2 separate applications and adapted the existing one to support ABP activation mode. This PR is also now based on #11310, #11359 and #11383.

maybe #11369 can be used to store it in RTC?

Note that RTC initialization already uses the BKPOR register on L0/L1 CPU to determine if it must be reset or not after a standby wake-up. That would need some adaption as well.

[aabadie]

Both dependencies are now merged so this PR is now ready for review again :)

[aabadie]

only enabling stop-mode seems like the best, and making the PM mode configurable in the example with a mention in the README to what should be taken into account for another CPU than STM32.

I adapted the PR. Now STOP mode (for STM32) is enabled. On samd21 that shouldn't change. And it's not configurable unless one edit the Makefile.
I also made the EEPROM logic available if it's provided by the board. This shows how to skip the join procedure if already joined and join state is stored on EEPROM.

[fjmolinas]

LGTM, do you remember what needed to be done on the b-l072-lrwan1 to measure current accureyly? Do some resistors need desoldering?

[aabadie]

do you remember what needed to be done on the b-l072-lrwan1 to measure current accureyly? Do some resistors need desoldering?

There are 2 pins to measure IDD and we were directly wiring up the multimeter on them.

[fjmolinas]

do you remember what needed to be done on the b-l072-lrwan1 to measure current accureyly? Do some resistors need desoldering?

There are 2 pins to measure IDD and we were directly wiring up the multimeter on them.

But if I recall you had desoldered some resistors on your BOARD with which you tested low-power

[aabadie]

you had desoldered some resistors on your BOARD with which you tested low-power

That was for when the board was running on the battery available on the back. To get low power in this case, on has to desolder a resistor between the programmer and the board otherwise there's current leak. But this makes it unflashable afterwards.

[jia200x]

That was for when the board was running on the battery available on the back. To get low power in this case, on has to desolder a resistor between the programmer and the board otherwise there's current leak. But this makes it unflashable afterwards.

We had to de-solder the resistors SB19, SB14 and SB17 and put some jumpers when not measuring current (otherwise you cannot flash the board). There we were able to get to low power.

I have the hardware with me but I cannot test it until next Monday due to an internal deadline. If it's OK to wait until next week I can post the results back.

[jia200x]

FYI:

Y-axis is current ([A]) and x-axis samples (@100khz).

The CPU goes to lpm, but the radio oscillator consumers ~1.9 mA (see #11237 (comment)). But I guess that's not related to this PR.

[fjmolinas]

ACK!

[aabadie]

Thanks for reviewing and testing @fjmolinas @jia200x ! This was one of my oldest opened PRs :)