lorawan-example not working

[kfessel]

LoRaWAN stopped working for my application, to verify my Application isn't wrong i tested the lorawan-example and found it also not working.

Description

lorawan-example does not work any more (branch: master) it stops after trying to send the message.

last working commit:6dfc07b0761abe685b6a935cc0b4a1fc87178394
just before "adapt to v4.4.1"

my REGION is set to EU868.

Steps to reproduce the issue

enable debugging in semtech-loramac.c
build and flash the loramac-example
'''
#make clean flash term

xx:30:07,821 - INFO # [semtech-loramac] MAC timer timeout
xx:30:08,063 - INFO # [semtech-loramac] MAC timer timeout
xx:30:08,156 - INFO # [semtech-loramac] MLME confirm event
xx:30:08,160 - INFO # [semtech-loramac] join succeeded
xx:30:08,164 - INFO # [semtech-loramac] loramac join notification msg
xx:30:08,166 - INFO # Join procedure succeeded
xx:30:08,168 - INFO # Sending: This is RIOT!
xx:30:08,172 - INFO # [semtech-loramac] loramac cmd msg
xx:30:08,177 - INFO # [semtech-loramac] send frame This is RIOT!
xx:30:08,186 - INFO # [semtech-loramac] MCPS request: confirmed TX
xx:30:08,191 - INFO # [semtech-loramac] MCPS request: dutycycle restricted
xx:30:08,201 - INFO # [semtech-loramac] loramac TX status msg
''''

Expected results

working example
'''
xx:45:23,723 - INFO # [semtech-loramac] MAC timer timeout
xx:45:24,612 - INFO # [semtech-loramac] MAC timer timeout
xx:45:25,568 - INFO # [semtech-loramac] MAC timer timeout
xx:45:26,524 - INFO # [semtech-loramac] MAC timer timeout
xx:45:27,480 - INFO # [semtech-loramac] MAC timer timeout
xx:45:27,721 - INFO # [semtech-loramac] MAC timer timeout
xx:45:27,820 - INFO # [semtech-loramac] MLME confirm event
xx:45:27,823 - INFO # [semtech-loramac] join succeeded
xx:45:27,827 - INFO # [semtech-loramac] loramac join notification
xx:45:27,829 - INFO # Join procedure succeeded
xx:45:27,832 - INFO # Sending: This is RIOT!
xx:45:27,834 - INFO # [semtech-loramac] loramac cmd
xx:45:27,838 - INFO # [semtech-loramac] send frame This is RIOT!
xx:45:27,841 - INFO # [semtech-loramac] MCPS_CONFIRMED
xx:45:27,850 - INFO # [semtech-loramac] MCPS request OK
xx:45:28,802 - INFO # [semtech-loramac] MAC timer timeout
xx:45:29,758 - INFO # [semtech-loramac] MAC timer timeout
xx:45:30,713 - INFO # [semtech-loramac] MAC timer timeout
xx:45:30,858 - INFO # [semtech-loramac] TX timer timeout
xx:45:31,670 - INFO # [semtech-loramac] MAC timer timeout
xx:45:31,673 - INFO # [semtech-loramac] MCPS confirm event
xx:45:31,674 - INFO # [semtech-loramac] loramac TX failed
xx:45:31,678 - INFO # [semtech-loramac] MAC reply received: 5
'''

Actual results

see above

Versions

Operating System Environment

   Operating System: "Debian GNU/Linux" 
             Kernel: Linux 4.18.0-2-amd64 x86_64 unknown

Installed compiler toolchains

         native gcc: gcc (Debian 8.2.0-9) 8.2.0
  arm-none-eabi-gcc: arm-none-eabi-gcc (15:7-2018-q2-4) 7.3.1 20180622 (release) [ARM/embedded-7-branch revision 261907]
            avr-gcc: avr-gcc (GCC) 5.4.0
   mips-mti-elf-gcc: missing
         msp430-gcc: missing

riscv-none-embed-gcc: missing
clang: clang version 6.0.1-9.2 (tags/RELEASE_601/final)

Installed compiler libs

arm-none-eabi-newlib: "3.0.0"
mips-mti-elf-newlib: missing
riscv-none-embed-newlib: missing
avr-libc: "2.0.0" ("20150208")

Installed development tools

              cmake: cmake version 3.12.3
           cppcheck: Cppcheck 1.84
            doxygen: 1.8.13
             flake8: missing
                git: git version 2.19.1
            openocd: Open On-Chip Debugger 0.10.0
             python: Python 2.7.15+
            python2: Python 2.7.15+
            python3: Python 3.6.7
         coccinelle: missing

[jia200x]

it works for me:

2018-11-08 18:53:55,802 - INFO # Join procedure succeeded
2018-11-08 18:53:55,804 - INFO # Sending: This is RIOT!
2018-11-08 18:54:25,340 - INFO # Sending: This is RIOT!
2018-11-08 18:54:55,849 - INFO # Sending: This is RIOT!
2018-11-08 18:55:25,387 - INFO # Sending: This is RIOT!
2018-11-08 18:55:53,972 - INFO # Sending: This is RIOT!
2018-11-08 18:56:24,482 - INFO # Sending: This is RIOT!
2018-11-08 18:56:55,014 - INFO # Sending: This is RIOT!
2018-11-08 18:57:24,567 - INFO # Sending: This is RIOT!
2018-11-08 18:57:54,118 - INFO # Sending: This is RIOT!
2018-11-08 18:58:24,642 - INFO # Sending: This is RIOT!

Could you give us more information about the hardware you are using? which board and LoRa module?

[aabadie]

From the log you give, you are falling in the duty cycle restriction after the join procedure (xx:30:08,191 - INFO # [semtech-loramac] MCPS request: dutycycle restricted). What DR are you using ?

[kfessel]

I am using a ST B-L072Z-LRWAN1 and have everything set default but the DEV- and APPEUI/KEY in the Makefile (and the ENABLE_DEBUG in semtech-loramac.c as written before)

the example sets the DR to 5

[kfessel]

jia200x: Do you use a dutycycle restricted RegionXXX.h file?

For testing purposes i just disabled the EU868_DUTY_CYCLE_ENABLED in RegionEU868.h. The lorawan-example is working now.
But i don't think this solves the issue, since the application locked up as the "dutycycle restricted" message surfaced at least no further messages showed up , and think -although i am not sure- EU868 has a long enough dutycycle (3.6seconds every hour) to send 18bytes of join request and 15bytes of message after each other at a rate of about 0.6kbit/s (DR5^=SF7) within one cycle.
Maybe these are two separate issues.

Which component is tracking the dutycyle usage?

[aabadie]

Which component is tracking the dutycyle usage?

This is controlled internally by loramac-node with timers.
And there should be no problem with your hardware as we develop on it (at least me!).

Can you tell us what LoRaWAN provider you are using and with what kind of gateway ?
Maybe adding a delay between the join procedure and the first message sent would fix your issue, e. g.add

xtimer_sleep(5);

here. You may also need to include xtimer.h.

Last question: you say the first send fails, is it also the case for all others after ?

[kfessel]

Can you tell us what LoRaWAN provider you are using and with what kind of gateway ?

It's a Kerlink Wirnet Station (at the moment its within the same room as the node) with a local Loraserver.io LoRaServer.

add an delay '''xtimer_sleep(5);''' and test

after adding the sleep after the "Join procedure succeeded". The application is sending the first message after the join :) , but does not do the next message (at least not after 20 seconds as suggested by the source code)

Last question: you say the first send fails, is it also the case for all others after ?

After the "dutycycle restricted" message the application does no further sends it seems to be locked up (no debug messages from LoRa-MAC)

[aabadie]

@fesselk, we just merged a potential fix for your issue. Can you try again with the latest RIOT master and tell if it works ? Thanks

[kfessel]

Hi i just tried. The example still needs a delay after the join either by adding a

xtimer_sleep(5);

or by just calling

_prepare_next_alarm();

instead of triggering the first message immediately. If i do not change that the message is triggert early, will run into being "dutycycle restricted" and the whole program is stopped.

The join seems to be successful every time now, which seem to half solve Issue #10442.
AFAIK:

• xtimer is still used while not knowing how inaccurate it is (no use of crystal on ST B-L072Z-LRWAN1)
• and it is also used for tracking the dutycyle usage but it will be stoped in many sleep modes of the cpu (using LPTIM/RTT/RTC might help whith this).

[jia200x]

Hi @fesselk

Hi i just tried. The example still needs a delay after the join either by adding a

Why? When the join accept is received LoRaMAC all sesion keys are set, so it shouldn't be necessary to wait in case the join was accepted. Could you describe the issue?

xtimer is still used while not knowing how inaccurate it is (no use of crystal on ST B-L072Z-LRWAN1)

The latest fix is a lower bound of really inaccurate timers, so it should work with most boards. We tested it in 5 boards and works good.

xtimer is still used while not knowing how inaccurate it is (no use of crystal on ST B-L072Z-LRWAN1)

The duty cycle is tracking using the Time On Air reported by the driver, is independent on the clock. So there shoudn't be a problem with that

[jia200x]

These calibration parameters we added with #10868 are runtime configurations but they are set to defaults with LORAMAC_DEFAULT_SYSTEM_MAX_RX_ERROR and LORAMAC_DEFAULT_MIN_RX_SYMBOLS.

It would be possible to adjust this automatically if there's a mechanism for detecting how inaccurate is a clock

[aabadie]

xtimer is still used while not knowing how inaccurate it is (no use of crystal on ST B-L072Z-LRWAN1)

By default this board uses HSI and LSI for RTC. So yes there's 1% error when using these clock sources. It's possible to use LSE to clock the LPTIM1, I did it with good results on RTT. But I'm still facing issues with RTC using LSE (it cannot switch to config mode).

it is also used for tracking the dutycyle usage but it will be stoped in many sleep modes of the cpu (using LPTIM/RTT/RTC might help whith this)

Definitely a problem with low-power, we use xtimer to determine when the dutycycle defay is finished which is itself using internal high speed clock (HSI). This is something on my todo-list: replace the use of xtimer with RTT (LPTIM) and maybe one day by the famous ztimer

[jia200x]

Why? When the join accept is received LoRaMAC all sesion keys are set, so it shouldn't be necessary to wait in case the join was accepted. Could you describe the issue?

Nevermind, I didn't read the duty cycle part ;) You are right.

IMO the proper way to handle this would be to try it again if the send command fails so the program never blocks.
@aabadie @fesselk what do you think?

[aabadie]

I need to try the example again, will do it tomorrow with different parameters.

[aabadie]

the proper way to handle this would be to try it again if the send command fails so the program never blocks.

I just had a look at the example code and I think it makes sense, the return code of the send function is not taken into account. If it fails, the receive function is always called, and internally it will wait for an ipc message that will potentially never arrive.

[aabadie]

@fesselk, I can reproduce a similar issue with the test application. I'm working on a fix and will open a PR soon.

[aabadie]

@fesselk, can you try #10903 and tell us if it improves things for you ? That would help so we can add this potential fix to the release. Thanks!