setting DevEUI

[geppoleppo]

Hi,
I ask you if it is possible to set the security keys for the ABP or OTAA connection and the devaddr and devui values ​​interactively without having to write them directly in the firmware source code.
In this way you could compile a single firmware that could be loaded on multiple devices which will be configured subsequently in an interactive way.
Thanks

[terrillmoore]

Hi,

This is done by providing your own functions. The names are pre-LoRaWAN spec, so need translation. For OTAA, you provide functions:

• os_getArtEui(), which returns the app eui,
• os_getDevEui(), which returns the device EUI, and
• os_getDevKey(), which returns the app key.

For ABP, you instead must call the function LMIC_setSession(), and provide the network ID, device address, network session key and app session key. You also must provide a suitable uplink and downlink count values but those have to be set by manipulating the LMIC.seqnoDn and LMIC.seqnoUp variables directly; and you have to adjust any other network parameters. Because of this, ABP is quite tricky to use, and I strongly recommend OTAA.

The library catena-arduino-platform uses Serial and a simple commmand-line interpretrer to do all the provisioning.

[terrillmoore]

May we close this?

[geppoleppo]

I haven't tested your solution yet, but the answer is very clear.
Thanks again.
If I still have problems, I will reopen the issue.

[Beliwars]

Hello @terrillmoore just jumping in here to ask regarding what network parameters are needed when coming back from a deep sleep after a successful OTAA join; I'm using esp32 and at this moment the device is joining every time is waking up (30 minutes sleep).

I got what you commented on issue #380 about the LMIC being idle before sleeping and also the timing handling; but I have doubts on what to store before deepsleep and how to use it after.

thanks in advance and best regards

[Beliwars]

Just to continue on this matter, I've decided to keep these variables:
RTC_DATA_ATTR u4_t rtc_netid = 0;
RTC_DATA_ATTR devaddr_t rtc_devaddr = 0;
RTC_DATA_ATTR u1_t rtc_nwkKey[16];
RTC_DATA_ATTR u1_t rtc_artKey[16];
RTC_DATA_ATTR u4_t rtc_seqnoDn;
RTC_DATA_ATTR u4_t rtc_seqnoUp;
RTC_DATA_ATTR u1_t rtc_dn2Dr;

Which I fill before deepsleep and recover after the reboot, I check what's the wakeup_reason.

So far it's working, OTAA join once and then I use all those variables to set LMIC's session.

Now about the timing issue; microseconds counter on esp32 resets after each deepsleep cycle that's a fact; so far I haven't coded anything to handle this, but I'm getting my package each 30 minutes as intended; so far I don't see any random wait time before tx, time diff between consecutive packets is steady at 29:59

So do I really need to handle that? modifying osticks to get an offset of 1800 seconds when coming back from sleep?

[terrillmoore]

@Beliwars we do all these things in https://github.com/mcci-catena/arduino-lorawan and https://github.com/mcci-catena/Catena-Arduino-Platform.

Short answers:

1. On SAMD and STM32, MCCI found that we needed to resynchronize millis() and micros() so that they indicate that the proper amount of time has passed while sleeping. Otherwise weird things can happen. That was 3 years ago, so all the changes made to the LMIC probably have improved things.

2. MCCI saves a large number of network parameters in FRAM after each uplink, so that the device only joins once, and never repeats FCntUp or gets confused by FCntDn. Somewhere in an issue I identified all the things that ought to be saved; our code is still somewhat defective because I did that before I completely understood the problem.

Hope this helps,
--Terry

[Beliwars]

Thanks for you answer Terry, I commented on #380 (comment)

I can just confirm that after 71 boots (35 hours and a half) I haven't yet seen anything weird; my code is really simple as I send only one buffer at each time.

[JackGruber]

Hi @Beliwars

Could you share your code for the startup where you reload the settings from RTC to lmic?

Regards
Alex

[terrillmoore]

@geppoleppo -- this ticket drifted away from your original question. Is it resolved? May I close this?

[geppoleppo]

yes, thanks