Strategy for LoRaWAN with deepsleep 2
-
Re: Strategy for LoRaWAN with deepsleep It is important that lopy when it wakes up from deepsleep has the opportunity to "remember" to join. Does anyone have any suggestion?
-
@_peter
what do you mean remember to join?
If you join inmain.pyit 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 -
This post is deleted! -
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
-
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.
-
@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?
-
@_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 -
@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?
-
@_peter said in Strategy for LoRaWAN with deepsleep 2:
I do not have an sd card in my project
but you have
internal flashwhere you can write files same as into SD card. -
@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 -
@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 :) -
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 :)
-
@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
-
@_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.
-
@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?
-
@Eric24
That's not possible yet because you have to tell the LoRa stack: "here reuse these keys I stored somewhere to connect" and that's not possible yet. Of course all the source code is out there so if anyone wants to have a go don't let me stop you. That's a functionality me and I'm sure many others will need for larger deployments so, even if Pycom doesn't get around to doing it, it'll come at some point.The other problem - but that's more an issue with LoRa and similar protocols - is it's not possible to know if the keys generated for an OTAA session are still valid without actually getting a response from the network, something you get for "free" with a fresh join. So always doing a join is safer. It's a balancing act.
-
@jmarcelino Right--ability to set keys will be needed. Regarding not knowing if they keys are valid, just thinking out loud...if you have some knowledge (or control) of the server behavior, you could know how long until the keys expire; let's say they last for 24 hours; given that, maybe the device (using the RTC) transmits without re-join for up to 23 hours (or so) and then re-joins on the next interval. Any flaw in that logic? Of course my objective here is to maximize battery life, and for a device that reports every 5 minutes, all that re-joining will add up.
-
-
@jmarcelino Hmmm. I suppose so, if you have control of the network (although some would argue that this would be less secure). But I was also thinking about public networks where you don't have control, but could have specific knowledge of key lifetimes. Of course there's no technical problem with re-joining on every transmission, but it's definitely not optimal. It makes me wonder if a lot of LoRaWAN implementations are actually doing just that, because it's easier to implement?
-
Anyone knows what approach thingamagogs like this use? I guess ABP and pre-generated random keys, but I didn't find any details: http://ecubelabs.com/integrated-waste-management/ultrasonic-fill-level-sensor/
Hello! It looks like you're interested in this conversation, but you don't have an account yet.
Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.
With your input, this post could be even better 💗
Register Login