examples/lorawan: add autonomous lorawan class A device example by aabadie · Pull Request #8789 · RIOT-OS/RIOT

aabadie · 2018-03-16T09:48:50Z

Contribution description

This PR adds a simple example of use of RIOT with LoRaWAN. The example shows several concepts:

OTAA join procedure and sending of messages with a LoRaWAN class A device
low-power mode: the device go to STOP mode between each send
RTC: the device wakes up every 20s for a new send using RTC.

I had to slightly change the loramac pkg code to better handle caller thread pid: in this application each send is done by a sender thread which is different from the main thread, used for the join procedure.

Issues/PRs references

Now based on #8798

aabadie · 2018-03-16T09:52:15Z

Side comment: I'm unsure if the pm management is used like it should, same for the RTC. Comments are very welcome on those specific parts.

aabadie · 2018-03-16T10:53:14Z

Finally fixed the CI. Maybe this PR could also interest @jia200x and @dylad.

jia200x · 2018-03-16T10:56:05Z

Thanks @aabadie!
I guess also @paula75 and @fjmolinas will be interested.

I will give it a closer look

dylad

Looks interesting ! But I don't see any call to pm_set(). You should put the device to sleep after the init I guess.

dylad · 2018-03-16T10:55:00Z

examples/lorawan/main.c

+        time.tm_sec -= 60;
+    }
+    while (time.tm_min > 60) {
+        time.tm_hour++;


You should also add a guard to ensure tm_hour doesn't reach 25 hours.

dylad · 2018-03-16T10:55:29Z

examples/lorawan/main.c

+{
+#ifdef MODULE_PM_LAYERED
+    /* Ensure the low-power mode is blocked during initialization phase */
+    pm_block(PM_MODE);


no call to pm_unblock after initialization.

it is not needed because it's done at the end of the send function.

aabadie · 2018-03-16T11:26:38Z

But I don't see any call to pm_set().

This is the part I'm unsure. I thought that when all threads are blocked, the system falls in the idle thread that itself calls pm_set_lowest(). Normally, the pm_set_lowest used is in sys/pm_layered/pm.c and this function should call pm_set. @kaspar030 am I right ?

vincent-d · 2018-03-16T11:59:52Z

Actually, you should not call any pm_* function from app code. @kaspar030 will correct me if I'm wrong, but the goal of pm_layered is that only periph drivers blocks pm mode. But there are still a lot of parts missing in RIOT to have all this in place (xtimer and shell for instance are almost incompatible with this approach if they stay as-is).

dylad · 2018-03-24T21:12:47Z

pkg/semtech-loramac/contrib/semtech_loramac_getset.c

+    semtech_loramac_channel_params_t params;
+    params.frequency = freq;
+    params.datarate = p.Datarate;
+    semtech_loramac_set_rx2_params(mac, params);


Just wondering, isn't it a problem to call this function which will re-call mutex_lock(&mac->lock) before we unlock it ?

Yes it is. Good finding. I admit I didn't test this function. If you try semtech_loramac_set_rx2_freq or semtech_loramac_set_rx2_dr from the shell application, I think the command will just hang.

dylad · 2018-03-24T22:26:21Z

pkg/semtech-loramac/contrib/semtech_loramac_timer.c

    }

-    obj->timeout = (value - 50) * 1000;
+    obj->timeout = (value - 20) * 1000;


BTW what sorcery is this number?

This comes from the specs: the RX windows start RX_DELAY seconds after the TX with +/-20ms error, so anticipating the RX window with 20ms should ensure that a message from the gateway is not missed.
The initial port was not very accurate : the RX windows were starting is little too late - probably because of thread switching overheads - and then were missing the gateway message preamble, that's why I anticipated them a little more (hence the arbitrary 50ms value). But with this PR, it behaves as expected, and it works with 20ms.

Could you add a little comment above this line to explain it please ? I don't think it is a good idea to have hardcoded number in the wild without any tips.

Could you add a little comment above this line to explain it please ?

that's a good idea (and practice), I'll change that.

dylad · 2018-04-19T13:16:19Z

I took a look at RIOT's PM and I think @vincent-d is right. You must not call any pm_* function here. The idle must select the best PM mode by itself.
Otherwise this PR looks good and should be good to go :)

aabadie · 2018-04-19T14:09:56Z

You must not call any pm_* function here. The idle must select the best PM mode by itself.

I know but the problem is that in this case it doesn't stop the MCU as I would expect. I'm testing with the b-l072z-lrwan1 board which is STM32L0 based.
Calling pm_set() seems to work, the MCU mode is set correctly, although power consumption seems higher than expected: I see almost no difference with the normal mode in stop mode (around 5mA).

dylad · 2018-04-19T14:16:13Z

Calling pm_set() seems to work, the MCU mode is set correctly

I understand what you means but this is something that must be handle at driver and board level not at application level. There is still a lot of work that need to be done in order to have a working and wonderful PM management ;)

aabadie · 2018-04-19T14:41:39Z

I removed the use of pm_set from the example.

dylad · 2018-04-19T14:47:56Z

examples/lorawan/main.c

+#include "semtech_loramac.h"
+
+/* Use the STOP mode to ensure memory retention between each send */
+#define PM_MODE             (1)


Not needed anymore

Indeed, fixed !

fjmolinas · 2018-04-19T14:48:48Z

I see almost no difference with the normal mode in stop mode (around 5mA).

Although this doesn't have to do with the general discussion here, @aabadie in my experience working with pm modes for L0 and L1, there's a lot of stuff you have to do with peripherals and gpio's to reach the datasheet power modes consumption. Whats is implemented right now for L0 isn't enough, the biggest part is switching unused GPIO's to AIN and the driver part @dylad mentioned (I had a PR on this a long time ago, you can see #8403 to have an idea of what I mean).

dylad · 2018-04-19T14:57:45Z

there's a lot of stuff you have to do with peripherals and gpio's to reach the datasheet power modes consumption

+1 , I had to hack so much part of RIOT to get a sleep consumption around 20 uA with my SAML21 family.

aabadie · 2018-04-19T15:03:41Z

Thanks @dylad and @fjmolinas for the information. I'll look at #8403 more closely to see how the low power consumption can be reached with the L0 board I have.

tcschmidt · 2018-06-21T11:58:46Z

@dylad are still changes requested?

dylad · 2018-06-21T12:17:40Z

@tcschmidt I don't think so, the current state looks good to me and it works.
I guess I can ACK :)

tcschmidt · 2018-06-21T12:25:05Z

@dylad great. Then hit merge?

miri64 · 2018-06-21T13:21:02Z

This PR broke murdock ;-) https://ci.riot-os.org/RIOT-OS/RIOT/9390/0c9d7aeedce747885e83de340a177c04ce21e307/output.html#error0

miri64 · 2018-06-21T13:23:01Z

This is why we don't merge with builds that are ages old..

miri64 · 2018-06-21T13:27:49Z

See #9393 for fix. Guess someone owes the community a box of beer ;-)

tcschmidt · 2018-06-21T13:30:05Z

@miri64 you'll get free beer on Saturday!

dylad · 2018-06-21T13:31:48Z

Sorry @miri64, I was not aware we need to re-triggers Murdock for this :(

miri64 · 2018-06-21T13:33:01Z

No problem. It was an easy fix after all ;-)

tcschmidt · 2018-06-21T13:33:57Z

@dylad we all live and learn - you'll get free beer at the RIOT summit.

aabadie added Area: pm Area: (Low) power management Area: LoRa Area: LoRa radio support labels Mar 16, 2018

aabadie force-pushed the pr/examples/lorawan branch from 6d93a79 to 9f95963 Compare March 16, 2018 09:49

aabadie added the CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR label Mar 16, 2018

aabadie force-pushed the pr/examples/lorawan branch 7 times, most recently from 366977d to 8367a4a Compare March 16, 2018 10:44

dylad requested changes Mar 16, 2018

View reviewed changes

aabadie force-pushed the pr/examples/lorawan branch from 8367a4a to dfe5caf Compare March 16, 2018 11:17

aabadie force-pushed the pr/examples/lorawan branch 3 times, most recently from 46eaae8 to 13373c9 Compare March 19, 2018 08:00

aabadie added the State: waiting for other PR State: The PR requires another PR to be merged first label Mar 19, 2018

aabadie force-pushed the pr/examples/lorawan branch 4 times, most recently from 3bba77c to 0038928 Compare March 19, 2018 19:34

aabadie mentioned this pull request Mar 21, 2018

pkg/cayenne-lpp: add support for Cayenne LPP format #8809

Merged

dylad reviewed Mar 24, 2018

View reviewed changes

aabadie force-pushed the pr/examples/lorawan branch from 0038928 to 03d0847 Compare March 24, 2018 21:25

dylad reviewed Mar 24, 2018

View reviewed changes

aabadie force-pushed the pr/examples/lorawan branch 2 times, most recently from aa422c8 to 6a85c3d Compare March 30, 2018 09:27

aabadie force-pushed the pr/examples/lorawan branch from 6a85c3d to c8b702e Compare April 19, 2018 14:14

aabadie removed the State: waiting for other PR State: The PR requires another PR to be merged first label Apr 19, 2018

aabadie force-pushed the pr/examples/lorawan branch from c8b702e to 563518b Compare April 19, 2018 14:15

dylad reviewed Apr 19, 2018

View reviewed changes

examples: add a lorawan OTAA/class A example

c9f6013

aabadie force-pushed the pr/examples/lorawan branch from b933367 to c9f6013 Compare April 19, 2018 19:35

dylad approved these changes Jun 21, 2018

View reviewed changes

dylad merged commit 2ae0e1c into RIOT-OS:master Jun 21, 2018

miri64 mentioned this pull request Jun 21, 2018

examples/lorawan: use new nucleo names for BOARD_INSUFFIENT_MEMORY #9393

Merged

aabadie deleted the pr/examples/lorawan branch June 26, 2018 18:57

cladmi added this to the Release 2018.07 milestone Jul 10, 2018

Conversation

aabadie commented Mar 16, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Contribution description

Issues/PRs references

Uh oh!

aabadie commented Mar 16, 2018

Uh oh!

aabadie commented Mar 16, 2018

Uh oh!

jia200x commented Mar 16, 2018

Uh oh!

dylad left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

aabadie commented Mar 16, 2018

Uh oh!

vincent-d commented Mar 16, 2018

Uh oh!

dylad Mar 24, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

aabadie Mar 24, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dylad commented Apr 19, 2018

Uh oh!

aabadie commented Apr 19, 2018

Uh oh!

dylad commented Apr 19, 2018

Uh oh!

aabadie commented Apr 19, 2018

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

fjmolinas commented Apr 19, 2018

Uh oh!

dylad commented Apr 19, 2018

Uh oh!

aabadie commented Apr 19, 2018

Uh oh!

tcschmidt commented Jun 21, 2018

Uh oh!

dylad commented Jun 21, 2018

Uh oh!

tcschmidt commented Jun 21, 2018

Uh oh!

miri64 commented Jun 21, 2018

Uh oh!

miri64 commented Jun 21, 2018

Uh oh!

miri64 commented Jun 21, 2018

Uh oh!

tcschmidt commented Jun 21, 2018

Uh oh!

dylad commented Jun 21, 2018

Uh oh!

miri64 commented Jun 21, 2018

Uh oh!

tcschmidt commented Jun 21, 2018

Uh oh!

Reviewers

aabadie commented Mar 16, 2018 •

edited

Loading

dylad Mar 24, 2018 •

edited

Loading

aabadie Mar 24, 2018 •

edited

Loading