Deepsleep and LoRaWAN issue when awakening



  • Hi,
    I have added deepsleep capability to my node firmware and now have a problem with LoRaWAN comms. My environment is LoPy4, LoRaWAN node, class C, OTAA and region AS923.

    My node boots and joins network successfully and sends/receives as expected. After joining I use lora.nvram_save() to save join details etc. I call machine.deepsleep(sleep_period_ms) and node sleeps as expected. After awakening I use lora.nvram_restore() and the node correctly believes it has already joined and transmits a message to the gateway which is correctly received. The problem is that the node no longer receives any downlink messages from the network. It's as if the node hasn't joined or alternatively as if the channel frequencies have been messed up.

    I have run out of ideas to try and solve this problem. The only solution has been to have the node rejoin upon awakening but obviously that shouldn't be necessary and would lead to multiple joins per day.

    Any insights gratefully received!

    Thanks
    Alan



  • @jcaron Thanks for reply.

    I'm using a private network with Chirpstack and Laird gateway. Yes I know not to use Class C when in deepsleep. Our network is not used in winter (vineyard irrigation) and during this down time we want to sleep our nodes to save battery drain as we have low solar radiation in winter also. We are therefore not sending/receiving messages when in deepsleep. We have been successfully running Class C with 60 nodes for over 2 years, our only issue has been battery life which we are now trying to address.

    I will try and capture gateway log and post back here.

    Thanks



  • @berryskies what network (or LNS if it’s your own) and gateway are you using? Do you have logs from the gateway?

    Note that deep sleep and class C are not quite things that go together. Class C is designed for devices which do not have power/battery constraints and can stay on permanently in order to listen permanently and receive a message at any time.

    Power-constrained devices (i.e. running on battery) will nearly always run as class A, so they can have very short awake time between longer deep sleep periods, and are ready to accept downlinks only during the two short receive windows after an uplink.

    So if your issue is that you are not receiving downlinks during deep sleep, this is completely normal. And you won’t receive those when the device wakes up either: in class C, the network will send downlinks right away and forget about them, it will not il any way queue them until the node is ready (that’s the very definition of class A, really).



Pycom on Twitter