How to send the nrf9160 to sleep mode and wakup up periodically every 6hour ?

Question

Hi, 
 I am using the nrf91 Thingy board for our pilot project. 
 I am trying to save as much power as possible since we have to depend on a lithium battery for the power. Our idea is for both chips in the nrf91 thingy board to work in combination to solve our specific problem. I am planning to connect to the network every 6 hours, and then exchange data over MQTT between the server and the device. The server will also send the active hours window, so we can schedule the time to wake up. Additionally, I am planning to add a push button to the nrf52840 to wake up the device if there is any need while in sleep mode. 
 Questions: 
 
 I just wanted to know how to schedule an alarm on the nrd91 to wake up after 6hr. 
 Is it possible to keep the UART communication (uart1 between nrf91 and nrf52) open and wake up on an event from nrf52? 
 We are facing some disconnection issues with the. aws_iot lib. It is quite unpredictable, sometimes we are able to get a stable connection for almost 40 hours, but sometimes will get AWS_IOT_EVT_DISCONNECTED after 3-4 hours, Is this an expected behaviour? But for now, we have implemented a heartbeat data exchange between the client and server on every 3 minutes and added a reboot logic on the disconnection. The ping interval is 60Sec. Is there any better workaround? 
 
 Thanks 
 Tom Victor

Charlie · Accepted Answer

Hi Tom, 
 Developing an application for your project is a kind of engineering process that needs time and people with expertise in this domain. 
 We can provide general direction advice and problem-debugging on specific issues, but you have the whole control of your projects, like Achim mentioned, some features are opposite, so some hard decision needs to be made. 
 1) If power consumption is your top concern, then just using UDP for transmission, PSM and RAI features demonstrated by this sample shows how low power you can achieve. 
 2) If you use MQTT/TCP for data transmission, it is not power efficient as explained by Achim, but you can get other benefits like security, maturity and so on, nRF9160: Asset Tracker v2 — nRF Connect SDK 2.2.0 documentation (nordicsemi.com) default nRF Cloud solution is based on MQTT protocol, it is a very good reference for your application. 
 3) 
 I just wanted to know how to schedule an alarm on the nrd91 to wake up after 6hr. 
 You do not need it, when you send a message in PSM mode, nRF9160 will reconnect with the mobile network automatically, so you just need to create a work scheduled every 6h. 
 4) 
 Additionally, I am planning to add a push button to the nrf52840 to wake up the device if there is any need while in sleep mode. 
 It is not hard to implement, you can set sense edge interruption for GPIO like gpio_pin_interrupt_configure_dt(&buttons[I],GPIO_INT_EDGE_TO_ACTIVE); + sense-edge-mask configuration in the overlay. 
 5) 
 Is it possible to keep the UART communication (uart1 between nrf91 and nrf52) open and wake up on an event from nrf52? 
 You may want this feature Low Power UART — nRF Connect SDK 2.2.0 documentation (nordicsemi.com) 
 6) 
 We are facing some disconnection issues with the. aws_iot lib. It is quite unpredictable, sometimes we are able to get a stable connection for almost 40 hours, but sometimes will get AWS_IOT_EVT_DISCONNECTED after 3-4 hours, Is this an expected behaviour? But for now, we have implemented a heartbeat data exchange between the client and server on every 3 minutes and added a reboot logic on the disconnection. The ping interval is 60Sec. Is there any better workaround? 
 I would suggest you create a dedicated case for this described issue. Sharing the modem trace recording and log printouts will be very helpful to understand what is going wrong with the combination. 
 Best regards, 
 Charlie

Achim Kraus · Answer

> but you can get other benefits like security, maturity and so on 
 As someone, who spend a lot of time in making CoAP/DTLS a "working alternative", I would like to amend, that there are quite mature implementations out, even if not all CoAP/DTLS stuff has the same quality. 
 - security: currently the two variants for CoAP/DTLS, which supports ip-address changing. Without ip-address changing you may even use DTLS 1.2 (RFC 6347): 
 DTLS CID (RFC 9146), that the variant is the one I Implemented in Eclipse/Californium (released 2 years ago) and Eclipse/tinydtls (currently feature branch). It's also available in mbedtls (it's merged, but I'm not sure, if it's released). With Californium (cloud server) and tinydtls (device) using CoAP/DTLS CID on a Thingy:91 was running over 100 days, exchanging every hour a message. That required about 35% of the internal battery. 
 OSCORE, (I'm not common to that, so leave it for others) 
 - maturity: I run Californium on a couple of cloud servers now for several years. The main issues reported by others also running Californium (or Leshan) in the cloud in that time was unaware network configuration or components, which "translated" the ip-addresses. Here DTLS CID is in my experience the "game changer". Beside of that network issues, the feedback about Californium is very well. It runs stable for weeks and months and requires restarts mainly on updates. Using the "DTLS graceful restart" then even keeps your DTLS encryption on such server updates (in that last two years I lost only twice the sessions). 
 Sometimes, it feels like not the "maturity" of the implementation is the culprit, it's more the missing expertise of the users.

Achim Kraus · Answer

Just to be clear: 
 The device sleeps in both cases, eDRX and PSM. And the ratio of sleep and active is the base for the savings. For eDRX it sleeps for a couple of seconds or minutes, and in PSM for hours or days. For eDRX the SIM-card may be important, at least my SIM cards are consuming about 20&micro;A additional current in eDRX sleep compared to PSM sleep. 
 If you want to limit the power consumption in eDRX and you use longer intervals, e.g. 655s, then your device does not receive messages for 10 minutes (including the TCP internal/injected IP messages). If your TCP connection is stable with a 10 minutes "quiet phase", is something you need to test. If you use a shorter interval (163s is close to your current 3 minutes), then you need to check your savings.

Achim Kraus · Answer

I guess, the first topic is to clarify the term "sleep" and the statement "save as much power as possible". 
 Let me split the "sleep" in two topics: 
 - modem 
 - application mcu 
 For the modem, you may either use "CFUN=0/1" (switching off/on) or configure PSM, which would be my preference, if your network provider supports it. 
 For that application mcu zephyr does already the most for you. If you use "k_sleep" on the main and no other job is running in some queues, the application mcu is already sleeping. To schedule an alarm, just specify the time in "k_sleep". 
 "save as much power as possible" 
 I guess, the question is more precise "save as much power as possible using mqtt", otherwise the very first thing to use less power is not to use a TCP based protocol. Reading the stuff with ping and heartbeat, I would even guess, that the question is "save as much power as possible but being always connected". The culprit is then very easy to see: power saving is bound to disable the radio, the mcu and power consuming peripherals. But your application seem to require exactly the opposite. Sending an ping every 60s and a heartbeat every 3 minutes consumes the energy. Sleeping for 6h is something else. I guess, if you go towards "6h sleep", you will need to drop the connection and reconnect on every wake up. That doesn't come for free, if you use TLS that requires then handshakes, but I don't see an stable alternative using TCP. Otherwise forget about the "6h sleep" and try to optimize the ping and/or heartbeat interval. Maybe using eDRX helps the to reduce the energy for the radio, if the network provider supports that. But the savings are far away from the savings of an 6h sleep.

How to send the nrf9160 to sleep mode and wakup up periodically every 6hour ?

Top Replies