Strategy for LoRaWAN with deepsleep 2

[Eric24]

@papasmurph It seems that the issue is not so much about whether it's possible to re-join, but the additional "on time" and radio power budget required to do so. Ideally, a LoRaWAN device should join very infrequently, sleep most of the time, and minimize its "on time" and radio usage (i.e. no re-joining) as much as possible. And that's not only a battery-life issue, but can also become a duty-cycle or simply system capacity issue at scale.

Ultimately, I think storing the information needed to wake-up and transmit without re-joining is a necessity (especially for battery-powered devices). How that information is stored is another matter (the RTC NVRAM would be ideal, as soon as it's supported). But the question your comment brings up is what to do about the "joined" flag? If it's always necessary to re-join after deep sleep, that would be a significant issue. Has anyone else been able to "force" a joined state after deep sleep?

[papasmurph]

@_peter My experience: I tried testing for whether it had already joined, but that flag doesn't seem to be set until you attempt and succeed to join, indicating it's always "unjoined" (?) after a deep sleep, so it wouldn't have helped to save state. The service I connect to doesn't mind though.

[livius]

@jmarcelino
one fet for control power of SD card start it read value and deinit and "close fet" :) same for write :)
I think the same as you here:

I wouldn't worry too much about flash wear

[jmarcelino]

SD cards tend to consume a godawful amount of power so they're not a good pairing for generally very power efficient LoRa stuff :-)

I wouldn't worry too much about flash wear, by the time you've killed the flash by writing sequence numbers a new Py with proper deepsleep (and more importantly RTC NVRAM preservation) will be out :)

[livius]

@Thosch42 said in Strategy for LoRaWAN with deepsleep 2:

It would be not very clever to stress the internal flash and kill the module slowly.

Yes, as i say before it is not recommended way - but you must test how offten you need to write.
But why not SD card? It is really cheap and small :)

[Thosch42]

@livius Yes, that's right. But it depends a little bit on how often the keys change. I need to reed the datasheets and specs. It would be not very clever to stress the internal flash and kill the module slowly.

Cheers,
Thomas

[livius]

@_peter said in Strategy for LoRaWAN with deepsleep 2:

I do not have an sd card in my project

but you have internal flash where you can write files same as into SD card.

[_peter]

@Thosch42 What you think seems to me very clever. This means, however, that it is not possible to have full functionality with the supplied hardware now. In your opinion, what can be the best compromise at this time?

[Thosch42]

@_peter While I was planning a board with the OEM LoPy, I run into the same problem. Currently I think about a small I2C NVRAM to save DevAddr and keys. I think there's no other way. Possibly something similar could be implemented in a future release of the Expansionboard.

Cheers,
Thomas

[_peter]

@Camot That's exactly what I meant. Normally who uses the lopy in lorawan should use these escamotage? I do not think it's possible to use it in the right way. Or miss me something?

[Camot]

I have asked myself the same quations.

@_peter An easy solution I think would be ABP with disabled frame counter check.

@livius With OTAA everytime a devices comes out of deepsleep,TTN performs a join-procedure with the network, during which a dynamic DevAddr is assigned and security keys are negotiated with the device. I think it is not hard to imagine that a wake up every 5 minutes for example with a new join procedure is not the way the network is designed. If some more devices do that, the gateway would come to the sending limitations.

With ABP, which is not the preferred way, a frame counter check wil be performed. A device just woken up from deepsleep, starts with 0. The network will not accept the connection.

Therefore, the ability to store and reload the DevAddr and keys for OTAA or the frame counter for ABP would be required. A product that requires you to disable security features of the network is not best of the art.

[_peter]

@livius

I do not have an sd card in my project and i need the lopy when it wakes up after the deepsleep send the payload without re-join

[_peter]

This post is deleted!

[livius]

@_peter
what do you mean remember to join?
If you join in main.py it once again is executed and joined.
You can save state to sd card - or not recommended way wrate state to flash.
But you must programm what to remember