How to adjust or cancel the LMIC libraries duty cycle check?

LoRaTracker · December 16, 2022, 12:28pm

I looked at loramac-node, the code is almost impenetrable, clearly written for experts only.

I found this thread in here;

https://www.thethingsnetwork.org/forum/t/deep-sleep-and-otaa-m328p-lmic/27199/12

But code example does not exist anymore.

The function mentioned in MCCI_LMIC is;

LMIC_getSessionKeys() which is this;

LMIC_getSessionKeys(&netid, &devaddr, nwkKey, artKey);

The LMIC version I have used so far has access to these, printed out at join;

LMIC.netid
LMIC.devaddr
LMIC.artKey
LMIC.nwkKey

Presumably stored in RAM, so you might think its not too difficult to save them to FRAM and read back, I have done a library that read\writes the various variable types and arrays to a FRAM.

However, I suspect that storing the above in FRAM is only a part of the problem, the library may well have status flags and other counters that need to be saved ?

LoRaTracker · December 16, 2022, 1:05pm

This looks intersting;

github.com/cyberman54/ESP32-Paxcounter

Persist LoRaWAN keys after OTAA join

opened 11:25AM - 18 May 18 UTC

closed 08:38PM - 19 Nov 19 UTC

cyberman54

enhancement

[HowTo:](https://www.thethingsnetwork.org/forum/t/big-esp32-sx127x-topic-part-2/…11973/97) > After an OTAA Join has finished, your node has the very same details you’d have for an ABP device. So: store the DevAddr and the secret session keys NwkSKey and AppSKey, and keep track of both frame counters. After deep sleep, configure your node as an ABP node using LMIC_setSession(...), and set the frame counters to their last stored values, using LMIC.seqnoUp = ... and LMIC.seqnoDn = .... > > For LMiC, these session details have different names (which originate from the early days where LoRaWAN was still called LoRaMAC). The documentation shows: > > 2.5.4 void LMIC_setSession (u4_t netid, devaddr_t devaddr, u1_t* nwkKey, u1_t* artKey) > > Set static session parameters. Instead of dynamically establishing a session by joining the network, precomputed session parameters can be provided. To resume a session with precomputed parameters, the frame sequence counters (LMIC.seqnoUp and LMIC.seqnoDn) must be restored to their latest values. > > And so does the code: > > void LMIC_setSession (u4_t netid, devaddr_t devaddr, xref2u1_t nwkKey, xref2u1_t artKey); > Indeed, the global LMIC variable provides access to properties such as LMIC.nwkKey for NwkSKey, LMIC.artKey for AppSkey and LMIC.devaddr for DevAddr, which you should be able to retrieve and persist in case EV_JOINED. > > Beware that you might also need to store and set the frequency and RX2 details that you get in the Join Accept, or after subsequent ADR commands… > > (I have not used this.) > >

"After an OTAA Join has finished, your node has the very same details you’d have for an ABP device. So: store the DevAddr and the secret session keys NwkSKey and AppSKey, and keep track of both frame counters. After deep sleep, configure your node as an ABP node using LMIC_setSession(…), and set the frame counters to their last stored values, using LMIC.seqnoUp = … and LMIC.seqnoDn = …

For LMiC, these session details have different names (which originate from the early days where LoRaWAN was still called LoRaMAC). The documentation shows:

2.5.4 void LMIC_setSession (u4_t netid, devaddr_t devaddr, u1_t nwkKey, u1_t* artKey)*

Set static session parameters. Instead of dynamically establishing a session by joining the network, precomputed session parameters can be provided. To resume a session with precomputed parameters, the frame sequence counters (LMIC.seqnoUp and LMIC.seqnoDn) must be restored to their latest values."

Does that sound feasible ?

Jeff-UK · December 16, 2022, 1:18pm

Cheeky but true….I can craft great solutions and systems/architectures and ideas…… I just leave it to/need people like you to actually code them - my days or writing microcode (yep!), registry settings, assembly language or maybe the odd C, Basic, or Fortran! programme seems along time ago….Ok might still copy/edit/pasta a bit of C, C+ or even Python or play with Arduino stuff…. But hard core softie skills? This dogs too old

descartes · December 16, 2022, 2:40pm

Anyone can write impenetrable code, it takes an expert to write understandable & maintainable code.

By the power of GitHub commits:

github.com

bertrik/LoraWanPmSensor/blob/bebac96a5eea0c29a69b1bee99359605b38ce947/LoraWanPmSensor.ino#L152


      
              break;
          case EV_BEACON_TRACKED:
              Serial.println(F("EV_BEACON_TRACKED"));
              break;
          case EV_JOINING:
              Serial.println(F("EV_JOINING"));
              setLoraStatus("OTAA JOIN...");
              break;
          case EV_JOINED:
              Serial.println(F("EV_JOINED"));
              LMIC_getSessionKeys(&otaa_data.netid, &otaa_data.devaddr, otaa_data.nwkKey,
                                  otaa_data.artKey);
              otaa_data.magic = OTAA_MAGIC;
              EEPROM.put(0, otaa_data);
              EEPROM.commit();
          
              print_keys();
          
              setLoraStatus("JOIN OK!");
              break;
          case EV_JOIN_FAILED:

Looking at the repro history it seems that @bertrik, like me, just went with a new join on restart of device which is why the code appears to have been removed, because it was.

There are some other commits that look quite tasty along the way - like saving the ADR value. May be worth picking through it all: Commits · bertrik/LoraWanPmSensor · GitHub

It does, it certainly resonates with prior discussions.

kersing · December 16, 2022, 3:30pm

Very much so. You need to store the frequencies being used as MAC commands can change them, the transmission power and data rate, the frame counters (up- and downlink) and a whole lot more. Loramac-node has a couple of structures with all the information that requires saving and if I recall correctly that amounts to hundreds of bytes being saved.

If you are using a supported MCU and radio combination the actual code you need to change is relatively small. However even then it takes some time to get you head around it.

LoRaTracker · December 16, 2022, 4:15pm

So does the pseudo ABP approach sound feasible ?

I understand that if the processor does not retain memory during deep sleep, such as with an ESP32, then a lot of stuff needs to be recovered at each wakeup.

But that is not the situation here, a watchdog recovery should not need to be used that often, its a just in case. The intention is not for a watchdog to be used to cover up a problem elsewhere.

I suspect that some OTAA nodes may already be powered on\off perhaps more often than is ideal, and they dont recover keys, does that cause significant issues ?

descartes · December 16, 2022, 4:18pm

You suspect correctly. The main downside to a rebooting node is that the join accept has to be transmitted. So if the watch dog reboots a device once in a blue moon, that’s not a big deal. Bit hard to say where the cut-off point would be for it to become problematic - technically under the FUP that would be 10 times a day …

Jeff-UK · December 16, 2022, 5:05pm

Too often/too many times and you start to run out of Dev Nonce count…. May take time to join depending on spec/mechanism the more they get used, also when Dev Nonce pool exhausted only solution is delete device and re register to start new pool….

LoRaTracker · December 16, 2022, 5:17pm

OK, so if you have FRAM you could store it on first join and then recover it from FRAM on a watchdog reset ?

descartes · December 16, 2022, 9:06pm

Yes, if you have any form of memory backup, you can restore the join accept credentials plus the various counters and carry on from where it was before the crash.

FWIW, the LoRa-E5 module running the LoRaMac-node STM32 Cube WL 1.2 with NVM can be run as AT commands, so it will do it all for you.

LoRaTracker · December 16, 2022, 10:36pm

I have tried a coupleof the E5s, and whilst I dont recall the exact details of how it happened both are bricked and I cannot recover them.

descartes · December 16, 2022, 11:10pm

I can imagine, Rising HF chose not to put the BOOT0 pin on to the outside so we can’t get to the ST boot loader for de-bricking via that route. I’ve got in a pickle a couple of times and had to use many fingers & STM32CubeProgrammer to retrieve a module - but not often enough to end up with notes.

LoRaTracker · December 19, 2022, 7:06pm

The LoRa-E5 does look attractive, from the spec sheets, but the device is not what is seems. Make an error in programming and you might well be stuffed. Perhaps the manufacturer should post warnings about it, as in be careful how you program this device, you might implement a self destruct mechanism.

LoRaTracker · December 19, 2022, 7:13pm

Well, I have managed to save the OTAA session state to FRAM, and a sketch that imposes what is saved in FRAM as a session after reset does appear to work, the credentails are accepted ant the node keeps transmitting payloads.

However, the original sketch starts out at SF12 and the ADP quickly brings that down to SF8, then SF7, in about 3 transmissions. But with the sketch that recovers the session details from FRAM, whilst the re-newed transmissions start at SF12, the node does not appear to accept from the Gateway the downlinks to change down SF as you would expect with ADP.

The node does carry on transmitting at SF12 and the FUP code increases the sleep period appropriatly. I realise I could save the session SF in use and recover it, but why does ADP not appear to be working ?

descartes · December 19, 2022, 7:24pm

I haven’t done this YET - and as I have a few hundred as one of the only realistic items available in the supply chain, I’ll be careful - they are a bugg3r to get off once they are on a board.

And to add to not having Boot0 actually available, although Seeed have labeled an input as Boot0 (it’s for getting in to their updater as it comes from them), there isn’t a switch between LP & HP antenna outputs so it’s always on HP so in the EU we burn about 30-40mA more than we need on a Tx. That’s relatively inconsequential over the lifecycle of the battery - but it probably makes the difference between 3/4 years and 4/5 years.

RAK did the same with their STM32WL module but I’m told they have resolved it for their SIP.

descartes · December 19, 2022, 7:25pm

Saving & restoring the current value should help:

LoRaTracker · December 20, 2022, 11:54am

That change does not appear to work, LMIC.dn2Dr starts anew at 3 = SF9BW125, and just stays there.

The change to save the OTAA session stuff to FRAM works well enough and at least when ‘testing’ you dont have to re-join every time you re-program the node.

On reset and recovery of the OTAA session, the node starts up at SF12 and the Gateway does send downlinks, but either the node is ignoring them or not acting on them.

Easy enough to set the SF to the last used on recovery of the session, but not good that the node appears to be ignoring the downlinks.

kersing · December 20, 2022, 12:24pm

Do you save the downlink counter? If not your node will be ignoring the downlinks.

LoRaTracker · December 20, 2022, 12:39pm

LMIC.seqnoUp and LMIC.seqnoDn are saved and restored.

Forcing the reset node to SF7 does stop the downlinks.

LoRaTracker · December 21, 2022, 9:56am

On a node reset, I can force the data rate to what ADR had set, SF7125, but still the Gateway sends downlinks.

Looking at the node up times, a transmission straight after join has an up time of around 7800mS. After a node reset and session recovery the node up time is around 3500mS.

So is it likley that the downlinks are being ignored because the node is not listening for them ?