Hi everyone,
I’m searching for a simple method to persist the message counters and other values from an OTAA join. Does anybody know a good LoraWAN library which persists all required values or how to persist and load the required values from LMiC? My goal is to use OTAA in combination with an ESP32 and deep sleep.
First I thought this is a common question but unfortunately I didn’t find a solution…
Thank you very much 
Nice. You may want to check if you can save the state for confirmed downlinks. And if you do, then you’re doing better than the RN2483.
Load the settings in the Lora Setup
...
LMIC_reset();
if(RTC_LORAWAN_seqnoUp != 0)
{
LoraWANLoadOTTAFromRTC();
}
// Start job
LoraWANDo_send(&sendjob);
and after EV_TXCOMPLETE i send my ESP to deep sleep.
At the moment i have no access to my devices. But in i 4 weeks i think i take a look into this.
Thanks for this post.
About 4 weeks ago I was in the same situation and was asking myself why there is no proper Demo Sketch of video for that.
I was very frustated during my programing to do on every small change a new OTAA Activation.
I read a lot of forum discussions with a lot of tips and tricks and finally I found something useful.
After a lot of searching i found this sketch for the EPS8266: https://github.com/Edzelf/LoRa/tree/master/ESP_lora_tracker
Once inspired I modified this sketch according to my needs to ESP32:
I modified the EEPROM Access and the RTC handling.
You may find my modification here:
I am not an expert programmer and hope this sketch helps you. In my opinion there should be much more of this basic examples documented.
Hopefully somebody make this code more cleaner and add this to MCCI stack examples.
LDL passes devNonce and session state back to the application via a callback. The application can choose to save and/or restore this as needed. There is more information in the porting guide.
Unfortunately there is no LDL wrapper for ESP32 Arduino at this time, so it’s not super convenient to try out. Even if there was a wrapper it probably wouldn’t persist by default since it makes experimenting with LoRaWAN more difficult.
Hi @arjanvanb,
i have checked my code on a short test and the ack for the downlink works fine after deep sleep.
I think the downlink retrys came from a timing problem, because it was the same with or without deepsleep on my ESP32.
Some remarks:
Be aware that ESP32 has no EEPROM and the data will be stored in flash.
Flash has a limited lifetime of around 100k erase/program cycles. It should therefore not be used to store data that is very frequently changing.
The EEPROM library for ESP32 is deprecated.
For new applications on ESP32, use Preferences.
About the preferences library:
Preferences provides persistent (across resets) but mutable storage of various types of variables. It is similar to EEPROM library in Arduino, except that EEPROM provides a single contiguous block of storage which the sketch needs to partition between variables, while Preferences performs the partitioning itself.
(I have not used the preferences library yet.)
EDIT: DO NOT USE THIS CODE. ITS WRONG!
Description in the next post below
Hey together,
sorry for my really late response. I was very busy the last days.
Thank you very much @JackGruber! This helped me a lot!
Everything worked for me except the handling of confirmed downlinks.
I found out that we need to persist the LMIC.dnConf too.
The parameter is declared in the lmic.h file with a comment:
u1_t dnConf; // dn frame confirm pending: LORA::FCT_ACK or 0
When loading the data back from the RTC ists important to set the dnConf attribute after calling the LMIC_set... methods because they override this attribute.
I expanded the code from @JackGruber with three lines.
// EDIT: DO NOT USE THIS CODE. ITS WRONG!
// Description in the next post below
//
RTC_DATA_ATTR u4_t RTC_LORAWAN_netid = 0;
RTC_DATA_ATTR devaddr_t RTC_LORAWAN_devaddr = 0;
RTC_DATA_ATTR u1_t RTC_LORAWAN_nwkKey[16];
RTC_DATA_ATTR u1_t RTC_LORAWAN_artKey[16];
RTC_DATA_ATTR u4_t RTC_LORAWAN_seqnoUp = 0;
RTC_DATA_ATTR u4_t RTC_LORAWAN_seqnoDn;
RTC_DATA_ATTR u1_t RTC_LORAWAN_dn2Dr;
RTC_DATA_ATTR u1_t RTC_LORAWAN_dnConf;
RTC_DATA_ATTR s1_t RTC_LORAWAN_adrTxPow;
RTC_DATA_ATTR s1_t RTC_LORAWAN_datarate;
RTC_DATA_ATTR u4_t RTC_LORAWAN_channelFreq[MAX_CHANNELS];
RTC_DATA_ATTR u2_t RTC_LORAWAN_channelDrMap[MAX_CHANNELS];
RTC_DATA_ATTR u2_t RTC_LORAWAN_channelMap;
RTC_DATA_ATTR s2_t RTC_LORAWAN_adrAckReq;
RTC_DATA_ATTR u1_t RTC_LORAWAN_rx1DrOffset;
RTC_DATA_ATTR u1_t RTC_LORAWAN_rxDelay;
void LoraWANSaveOTTA2RTC()
{
Serial.println(F("Save LMIC to RTC ..."));
RTC_LORAWAN_netid = LMIC.netid;
RTC_LORAWAN_devaddr = LMIC.devaddr;
memcpy(RTC_LORAWAN_nwkKey, LMIC.nwkKey, 16);
memcpy(RTC_LORAWAN_artKey, LMIC.artKey, 16);
RTC_LORAWAN_dn2Dr = LMIC.dn2Dr;
RTC_LORAWAN_dnConf = LMIC.dnConf;
Serial.println(RTC_LORAWAN_dnConf);
RTC_LORAWAN_seqnoDn = LMIC.seqnoDn;
RTC_LORAWAN_seqnoUp = LMIC.seqnoUp;
RTC_LORAWAN_adrTxPow = LMIC.adrTxPow;
RTC_LORAWAN_datarate = LMIC.datarate;
RTC_LORAWAN_adrAckReq = LMIC.adrAckReq;
RTC_LORAWAN_rx1DrOffset = LMIC.rx1DrOffset;
RTC_LORAWAN_rxDelay = LMIC.rxDelay;
memcpy(LMIC.channelFreq, RTC_LORAWAN_channelFreq, MAX_CHANNELS);
memcpy(LMIC.channelDrMap, RTC_LORAWAN_channelDrMap, MAX_CHANNELS);
RTC_LORAWAN_channelMap = LMIC.channelMap;
}
void LoraWANLoadOTTAFromRTC()
{
Serial.println(F("Load LMIC from RTC ..."));
memcpy(RTC_LORAWAN_channelFreq, LMIC.channelFreq, MAX_CHANNELS);
memcpy(RTC_LORAWAN_channelDrMap, LMIC.channelDrMap, MAX_CHANNELS);
LMIC.channelMap = RTC_LORAWAN_channelMap;
LMIC.seqnoDn = RTC_LORAWAN_seqnoDn;
LMIC_setSession(RTC_LORAWAN_netid, RTC_LORAWAN_devaddr, RTC_LORAWAN_nwkKey, RTC_LORAWAN_artKey);
LMIC_setSeqnoUp(RTC_LORAWAN_seqnoUp);
LMIC_setDrTxpow(RTC_LORAWAN_datarate, RTC_LORAWAN_adrTxPow);
LMIC.dnConf = RTC_LORAWAN_dnConf;
LMIC.adrAckReq = RTC_LORAWAN_adrAckReq;
LMIC.dn2Dr = RTC_LORAWAN_dn2Dr;
LMIC.rx1DrOffset = RTC_LORAWAN_rx1DrOffset;
LMIC.rxDelay = RTC_LORAWAN_rxDelay;
}
@arjanvanb Did you mean this with “save the state for confirmed downlinks”?
@JackGruber It seems like that it was only luck that your code did something. I wondered that my node only used one channel (with your code modified in the post above this one ) and started investigating
First of all I noticed that the array with the bands is missing which stores the duty cycles and the usages of the channel etc.
When I was typing the corresponding memcpy command I noticed that you switched the destination and the source parameter in your code . Also MAX_CHANNELS as the size parameter is wrong because the command wants a size in bytes and not the count of array entries. So we need to multiply MAX_CHANNELS with the size of the array entries:
memcpy(RTC_LORAWAN_channelDrMap, LMIC.channelDrMap, MAX_CHANNELS*sizeof(u2_t));
It would be nice if you change this in your code block so that other readers of this thread don’t copy a switched memcpy
Currently this code block is working ( I did something with the duty cycle because after deep sleep the ESP resets the system clock):
RTC_DATA_ATTR u4_t RTC_LORAWAN_netid = 0;
RTC_DATA_ATTR devaddr_t RTC_LORAWAN_devaddr = 0;
RTC_DATA_ATTR u1_t RTC_LORAWAN_nwkKey[16];
RTC_DATA_ATTR u1_t RTC_LORAWAN_artKey[16];
RTC_DATA_ATTR u4_t RTC_LORAWAN_seqnoUp = 0;
RTC_DATA_ATTR u4_t RTC_LORAWAN_seqnoDn;
RTC_DATA_ATTR u1_t RTC_LORAWAN_dn2Dr;
RTC_DATA_ATTR u1_t RTC_LORAWAN_dnConf;
RTC_DATA_ATTR s1_t RTC_LORAWAN_adrTxPow;
RTC_DATA_ATTR u1_t RTC_LORAWAN_txChnl;
RTC_DATA_ATTR s1_t RTC_LORAWAN_datarate;
RTC_DATA_ATTR u4_t RTC_LORAWAN_channelFreq[MAX_CHANNELS];
RTC_DATA_ATTR u2_t RTC_LORAWAN_channelDrMap[MAX_CHANNELS];
RTC_DATA_ATTR u4_t RTC_LORAWAN_channelDlFreq[MAX_CHANNELS];
RTC_DATA_ATTR band_t RTC_LORAWAN_bands[MAX_BANDS];
RTC_DATA_ATTR u2_t RTC_LORAWAN_channelMap;
RTC_DATA_ATTR s2_t RTC_LORAWAN_adrAckReq;
RTC_DATA_ATTR u1_t RTC_LORAWAN_rx1DrOffset;
RTC_DATA_ATTR u1_t RTC_LORAWAN_rxDelay;
void Sleep(int sleepSeconds)
{
Serial.println(F("Save LMIC to RTC ..."));
RTC_LORAWAN_netid = LMIC.netid;
RTC_LORAWAN_devaddr = LMIC.devaddr;
memcpy(RTC_LORAWAN_nwkKey, LMIC.nwkKey, 16);
memcpy(RTC_LORAWAN_artKey, LMIC.artKey, 16);
RTC_LORAWAN_dn2Dr = LMIC.dn2Dr;
RTC_LORAWAN_dnConf = LMIC.dnConf;
RTC_LORAWAN_seqnoDn = LMIC.seqnoDn;
RTC_LORAWAN_seqnoUp = LMIC.seqnoUp;
RTC_LORAWAN_adrTxPow = LMIC.adrTxPow;
RTC_LORAWAN_txChnl = LMIC.txChnl;
RTC_LORAWAN_datarate = LMIC.datarate;
RTC_LORAWAN_adrAckReq = LMIC.adrAckReq;
RTC_LORAWAN_rx1DrOffset = LMIC.rx1DrOffset;
RTC_LORAWAN_rxDelay = LMIC.rxDelay;
memcpy(RTC_LORAWAN_channelFreq, LMIC.channelFreq, MAX_CHANNELS*sizeof(u4_t));
memcpy(RTC_LORAWAN_channelDrMap, LMIC.channelDrMap, MAX_CHANNELS*sizeof(u2_t));
memcpy(RTC_LORAWAN_channelDlFreq, LMIC.channelDlFreq, MAX_CHANNELS*sizeof(u4_t));
memcpy(RTC_LORAWAN_bands, LMIC.bands, MAX_BANDS*sizeof(band_t));
RTC_LORAWAN_channelMap = LMIC.channelMap;
//System time is resetted after sleep. So we need to calculate the dutycycle with a resetted system time
delay(random(1000));
unsigned long now = millis();
Serial.println(now);
for(int i = 0; i < MAX_BANDS; i++) {
ostime_t correctedAvail = RTC_LORAWAN_bands[i].avail - ((now/1000.0 + sleepSeconds ) * OSTICKS_PER_SEC);
if(correctedAvail < 0) {
correctedAvail = 0;
}
RTC_LORAWAN_bands[i].avail = correctedAvail;
}
esp_sleep_enable_timer_wakeup(1000000 * sleepSeconds);
esp_deep_sleep_start();
}
void Wakeup()
{
Serial.println(F("Load LMIC from RTC ..."));
LMIC_setSession(RTC_LORAWAN_netid, RTC_LORAWAN_devaddr, RTC_LORAWAN_nwkKey, RTC_LORAWAN_artKey);
LMIC_setSeqnoUp(RTC_LORAWAN_seqnoUp);
LMIC_setDrTxpow(RTC_LORAWAN_datarate, RTC_LORAWAN_adrTxPow);
memcpy(LMIC.bands, RTC_LORAWAN_bands, MAX_BANDS*sizeof(band_t));
memcpy(LMIC.channelFreq, RTC_LORAWAN_channelFreq, MAX_CHANNELS*sizeof(u4_t));
memcpy(LMIC.channelDlFreq, RTC_LORAWAN_channelDlFreq, MAX_CHANNELS*sizeof(u4_t));
memcpy(LMIC.channelDrMap, RTC_LORAWAN_channelDrMap, MAX_CHANNELS*sizeof(u2_t));
LMIC.seqnoDn = RTC_LORAWAN_seqnoDn;
LMIC.dnConf = RTC_LORAWAN_dnConf;
LMIC.adrAckReq = RTC_LORAWAN_adrAckReq;
LMIC.dn2Dr = RTC_LORAWAN_dn2Dr;
LMIC.rx1DrOffset = RTC_LORAWAN_rx1DrOffset;
LMIC.rxDelay = RTC_LORAWAN_rxDelay;
LMIC.txChnl = RTC_LORAWAN_txChnl;
LMIC.channelMap = RTC_LORAWAN_channelMap;
}
Im sure that there are some attributes missing. I will add them in this post when I know about them
Anyway: Thank you @JackGruber for giving me the right hint to persist the attributes in the RTC This was really helpful!
I think the following handles that?
However,
I wonder why that worked then, without that line of code. (And also: why the erroneous memcpy worked.) Or maybe the settings are simply not lost at all, in the sleep that is used for testing?
Oh my, the memcpy mistake is so embarrassing 
…
yes, I already noticed that with the dutycycle.
In my ATmega projects I adjust the clock after the deepsleep.
// LMIC uses micros() to keep track of the duty cycle, so
// hack timer0_overflow for a rude adjustment:
cli();
timer0_overflow_count+= 8 * 64 * clockCyclesPerMicrosecond();
sei();
I have not yet checked how this works with ESP32 and what variables we need to store.
I have deleted the old post, because editing was not possible.
I’m guessing these are the critical structure members to copy to/from RTC? The idea of copying the entire LMIC struct during deep sleep is proven to not be a good idea?
Context: My Heltec ESP32 LoRa V2 code works fine in ABP and OTAA, but getting out of deep sleep is not working well for me at all. Random payload uplink (very intermittent)
My ESP32 nodes that use DeepSleep and OTAA rarely lose an uplink and I think this is due to the network.
I do not think that I have connection quality issues. I placed the gateway, and it’s 20M from my node. I can connect quite consistently also.
My issue centers around exploring deep sleep on the ESP32. I’ve seen examples where the entire LMIC structure is copied to RTC, but some of this thread is centered around copying specific structure members to RTC only. I’m guessing there is a game I need to play with respect to the LMIC structure and the ESP restarting after deep sleep.
It sums up to me trying to understand the best methodology to use ESP, LoRaWAN, and deep sleep together.
@JackGruber Thanks for the prompt reply! I’m actually using the example in your post (very well written, btw).
I’m in the US. The resetting of the bands structure member does not appear to be an option.
LMIC.bands[bi].avail = 0;
I’ve looked at the LMIC library and the portion of the structure is not compiled in for US915, so I cannot perform that operation. 
not sure if this works for US, because I cannot test it.
for (u1_t i = 0; i<4; i++)
{
LMIC.channelMap[i] = 0xFFFF;
}
LMIC.channelMap[4] = 0x00FF;
LMIC.activeChannels125khz = 64;
LMIC.activeChannels500khz = 8;
or calling LMICbandplan_resetDefaultChannels(0) …
@JackGruber I’ll give it a try At the moment, I’m my own worst enemy and need to clean up my code. I’ll give feedback soon.