search

ArmDeveloperEcosystem / lorawan-library-for-pico

Enable LoRaWAN communications on your Raspberry Pi Pico or any RP2040 based board. 📡
BSD 3-Clause "New" or "Revised" License
125 stars 47 forks source link

Raspberry Pi Pico with SX1276 does not join The Things Network - "Duty Cycle restricted" #14

Closed ThomasLeister closed 2 years ago

ThomasLeister commented 2 years ago

Setup / Environment

Goal

Using the SX1276 with the lorawan-library-for-pico on a Raspberry Pi Pico. I'd like to use the library's "hello_otaa" example. The device is expected to use the OTAA mechanism and the send the "hello world!" message.

I would expect to see the device register at the gateway (gateway logs available in TTN Gateway Dashboard). After that, I should see a new upstream message in the Gateway log (and in the device's TTN log).

Issue

After setting the correct values in config.h, enabling LoRa debugging and uploading the example to the Raspberry Pi Pico target, the following log is displayed on the serial console:

Pico LoRaWAN - Hello OTAA

Initilizating LoRaWAN ... 
###### =========== CTXS RESTORED =========== ######
Size        : 2208

DevEui      : E6-60-D4-A0-XX-XX-XX-XX
JoinEui     : 00-00-00-00-00-00-00-00
Pin         : 00-00-00-00

success!
Joining LoRaWAN network ... 
###### =========== MLME-Request ============ ######
######               MLME_JOIN               ######
###### ===================================== ######
STATUS      : Duty-cycle restricted
Next Tx in  : 3599891 [ms]

(XX-XX-XX-XX was redacted ;-) )

"Duty-cycle restricted" appears and I cannot observe any new LoRa payload messages or "join" messages on the gateway. The device log in TTN Dashboard stays empty. No sign of communication. TTN Dashboard says "never connected" about the Raspberry Pi Pico.

Even after wainting for an hour (=3599891 ms) nothing happens. I would have expected the LoRaWAN stack to re-try the join process, but no more log output appears. Also no updates on the TTN dashboard.

What I've tried

I'm pretty clueless why I can't get my setup working. Maybe I forgot something important, maybe there were some undocumented changes or I can into a rare bug ;-) How could I try to debug the issue / what could possible cause the trouble?

I'm aware that this is not a support forum, but there should be plenty of LoRa experts here, so that's why I think this might be the most appropriate place to ask for some help.

References

Attachments

config.h:

/*
 * Copyright (c) 2021 Arm Limited and Contributors. All rights reserved.
 *
 * SPDX-License-Identifier: BSD-3-Clause
 * 
 */

// LoRaWAN region to use, full list of regions can be found at: 
//   http://stackforce.github.io/LoRaMac-doc/LoRaMac-doc-v4.5.1/group___l_o_r_a_m_a_c.html#ga3b9d54f0355b51e85df8b33fd1757eec
#define LORAWAN_REGION          LORAMAC_REGION_EU868

// LoRaWAN Device EUI (64-bit), NULL value will use Default Dev EUI
#define LORAWAN_DEVICE_EUI      "E660D4A0XXXXXXXX"

// LoRaWAN Application / Join EUI (64-bit)
#define LORAWAN_APP_EUI         "0000000000000000"

// LoRaWAN Application Key (128-bit)
#define LORAWAN_APP_KEY         "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"

// LoRaWAN Channel Mask, NULL value will use the default channel mask 
// for the region
#define LORAWAN_CHANNEL_MASK    NULL
gniezen commented 2 years ago

I have a very similar setup and I'm experiencing the same issue. I'm using Elementary OS 6.1, so Ubuntu 20.04.

ThomasLeister commented 2 years ago

Update: I've started using a different LoRaWAN module from Waveshare (SX1262). I'm still in the process of updating / rebasing their custom version of this library, but I stumbled across the "duty cycle restricted" issue once again.

After reverting Commit e31d3c133f0effca9d3660e35b383506018eca39 and thus removing all new EMMc functions, the library seems to work fine for SX1262.

Maybe Commit e31d3c133f0effca9d3660e35b383506018eca39 is also causing the issue here. ... :thinking: Need to check that out.

ep1cman commented 2 years ago

I was unable to replicate this issue with the following setup:

ThomasLeister commented 2 years ago

Thanks for trying! Strange. Maybe that issue is related to my particular module type. I guess I'll continue debugging this issue after my WaveShare module has been brought into service :)

But any further feedback / experiences are appreciated! Maybe it helps to hunt down the issue.

ep1cman commented 2 years ago

Its a long shot but I noticed you used GCC 9 and I used GCC 10. I doubt thats the issue but its worth checking

Mrkvak commented 2 years ago

I've ran into the same issue today, on a brand new board. After I called NvmDataMgmtFactoryReset the problem disappeared. More precisely, I've flashed firmware that called the NvmDataMgmtFactoryReset() before lorawan_init_otaa(). It immediately started to work. Then I flashed the previous version (without the NvmDataMgmtFactoryReset call) and it again joined the network successfully.

It looks like something in LoRaMac-node breaks when the NvmDataMgmtRestore fails? In any case, I'm too tired (and probably too unfamiliar with the code) to try to narrow it down today.

ThomasLeister commented 2 years ago

@Mrkvak this sounds familiar to me. I've run into a very similar issue with my WaveShare SX1262 module. It wouldn't join the network via OTAA and said "Duty-cycle restricted" after a while. I could resolve the issue by running NvmDataMgmtFactoryReset() and then EepromMcuFlush() to write the changes to flash.

To me it seems that there's are bug related to context restoring. Maybe the machanism breaks with invalid data in flash? Not sure what is going on, either, but as soon as I'm back to using my SX1276 module, I'll try and investigate further.

gniezen commented 2 years ago

I can confirm that doing a NvmDataMgmtFactoryReset() fixes the "Duty-cycle restricted" issue.

ep1cman commented 2 years ago

Do you have to do the reset each time, or after doing it once, does it work from that point forward?

Mrkvak commented 2 years ago

Like I've said, after performing the NvmDataMgmtFactoryReset once, everything works. Even after subsequent flashes, reboots, etc..

ThomasLeister commented 2 years ago

Finally had some time to check om this issue. Using NvmDataMgmtFactoryReset and EepromMcuFlush for a single time resolved the issue for me, too! (on my SX1276 setup as well as on my SX1262 setup)

I consider this thread solved, then. Still, it might be advisable to mention this pitfall somewhere in the README, because esp. newbies like me might not be aware that their settings are written to flash and persist on the device, even if the DEV_EUI and other "defines" have changed in the meantime.

sandeepmistry commented 2 years ago

@Mrkvak, @gniezen, @ThomasLeister thank you for the feedback!

I've created pull request https://github.com/ArmDeveloperEcosystem/lorawan-library-for-pico/pull/18 with a new example that can be used to erase the NVM.