How to avoid rejoining with OTAA?

1

Hi The-Things-Network Community,

I’m currently working with a low power stm32 MCU and an SX1276 (RFM 95 HOPE) with the Arduino LMIC Libaray changed to the used periphery. I want to use the standby mode, which has very low power, but also resets all contents of the chip. I can retain some memory and plan to do so, to avoid having to do a join request over and over.

Currently I’m saving the LMIC-Struct with its data content, but it does neither rejoin nor send a message at all (beyond the very first join and message). What else do I require to avoid rejoining over and over?

Kind regards

Crackl1ng

1 Like
2

What STM chip are you using? I’ve got STMs down to 3 micro ampere without loosing state using loramac-node.

3

It’s the STM32L4R+. 3 micro amps is great, my personal best is 64µA. I should get even about 1 µA if it works like planned.
How did you do that? Does your MCU reset aswell? I’m currently using

HAL_PWR_EnterSTANDBYMode();

Which resets everything except SRAM2.

4

Please check the loramac-node codebase. I’m using STM32L072. No MCU reset. Timer/UART driven wakeup.

5

This seems to be related to the absolute timing values stored in the LMIC struct. With that the node needs to wait until the clock value reaches those again when the MCU starts from reset. I did some experiments with that and found that before the LMIC struct is archived those fields need to be cleared:

for(int i=0;i<MAX_BANDS;i++)
	LMIC.bands[i].avail = 0;
LMIC.globalDutyAvail = 0;
6

May-be saving the timing and making sure the controller uses increasing time in stead of resetting is a better solution? Save time to nvram and add the increment when waking? By clearing the structure you open the potential to exceed legal airtime.

1 Like
7

I will keep it in mind and try it out. Thank you very much!

8

Usually, I dont use the tx_interval variable to declare when it has to send a lora message and do it somewhat external. I have a timer who stops the program for x minutes (either sleep/stop/standby mode). In stop-mode, all clocks except RTC (whose only task is to give an interrupt when stop mode is finished) are stopped. But in stop-mode, it still works and it still does send a message out to the world, while in standby it does not. In neither modes, the internal clock should provide a tick-interrupt, since every interrupt would wake it up from any sleep-stop-mode (except standby-mode) and has to be disabled.

9

Will keep it in mind, though I don’t want to reconfigure lorawan again from anew. My current lorawan-solution is also pretty suboptimal, since I took the arduino lmic some years ago and reconfigured it for STM32.

10

I strongly suggest you update to a recent version of LMIC or loramac-node as technology has moved on and old LMIC versions are not a great match for the current LoRaWAN networks, including TTN.

11

Thank you,

I will consider that if I get employed to work further on the project. Currently it is just a protoype for my master thesis and wanted to optimize it as good as possible.

Kind regards

12

The MCCI LMIC is LoRaWAN 1.0.3 compliant and (at least through V4.1) is pretty backward compatible. I use it with STM32L0 all the time, so should be OK with L4. There are threads on the github page about saving state (several people are doing this with ESP32). See GitHub - mcci-catena/arduino-lmic: LoraWAN-MAC-in-C library, adapted to run under the Arduino environment

1 Like