persist the JOIN credentials, join once

[omnipresense]

Hi everyone, especially including Wolfgang!

We're using the dragino rpi lora hat to connect to a Senet-customized Multitech gateway and Senet cloud.
We've been having substantial difficulties. Some things we've worked around include

• the Multitech uses only channels 0-7 and we changed the LMIC software to use only those
• there are some conditions in the initialization code that appear to have been improved for EU code but not US code (and I've copied them over into the US section.) (want a pull request?)
• to my surprise, I had to make sure we send packets slower than one per two seconds (I don't yet have the Engine fully characterized--perhaps this is ordinary) (Basicly, I took "periodic" and have it read a list of payloads off of argv, with a delay between transmissions)

All that having been said, the people from Senet are adamant that doing a JOIN every time I connect and send messages is something that they strongly recommend against.
Is there any code that shows the credentials returned upon join being saved for later reuse? How about code that reuses what was saved?

There's sort of something like that in the modem example, but that requires hw.h and hw.c for the BCM chip and only STM seems available.

Also, I do observe in Senet's logs that there are multiple JOIN requests and accepts per invocation. I don't know why this is, but it appears to eventually proceed and start sending. I'll look into that later.

My principal request is code showing what to persist (and maybe how) and how to use those saved values. Any advice on other issues is welcome and I would create other issue tickets if preferred.

[omnipresense]

(As I think about it, my request is more "LMIC" oriented and not specific to the dragino raspi hat. I'd still welcome any thoughts you have. I also do truly appreciate that this project exists and all the documentation that is part of it.)

[wklenk]

Hi,

some comments from my side:

to my surprise, I had to make sure we send packets slower than one per two seconds

You should know that public LoRa networks are not suited for high traffic. Sending a message every few seconds is way too much. If your situation allows to should think over if you can send less messages. I think the code in the LMIC stack takes care that duty cycle regulations are not violated. So in case of doubt, the LMIC stack will just queue the message internally, but wouldn't send it to air. Of course, the capability to queue messages is limited and sooner or later the LMIC stack will perhaps will explode if you put too much messages in that cannot be sent. This is a good and understandable paper about duty cycle: https://www.thethingsnetwork.org/docs/lorawan/duty-cycle.html There are also airtime calculators. If you have requirements to send MORE messages than allowed by duty cycle regulations, maybe LoRaWAN is not the right choice for you.

Also, I do observe in Senet's logs that there are multiple JOIN requests and accepts per invocation.

Ideally, the software should do as little join requests as possible. Definitely, there should NOT be one join request per message to be sent. So try to keep the LMIC stack running. And yes, there should be some mechanism that stores the network session key and application session keys received during the OTAA join mechanism and uses it after later starts of the LMIC stack.