• State Verified Answer
  • Replies 7 replies
  • Subscribers 75 subscribers
  • Views 2950 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 303151
Options

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

Tom Victor

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

Parents
  • +1

    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

Reply
  • +1

    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

Children
  • +1 in reply to Charlie

    > 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.

  • 0 in reply to Achim Kraus

         Thanks for the detailed answers. I understood that there is no silver bullet to my specific application needs. Basically, I have a working version of the application firmware now with all the bits and pieces together, I will experiment with the PSM and use of a power profiler to measure the current consumption and draw a line between power consumption and stable connectivity. Also, do my research on the CoAP. Additionally, I will create a separate case for the MQTT disconnection after some reviews if needed. 

    Just one more question in the context of PSM and eDRX, Is it possible to receive data over MQTT while the PSM is enabled or is it best suited for data transmission-only applications?

    Thanks

  • 0 in reply to Tom Victor

    Hi Tom,

    Tom Victor said:
    Just one more question in the context of PSM and eDRX, Is it possible to receive data over MQTT while the PSM is enabled or is it best suited for data transmission-only applications?

    It is not possible to receive data when the device enters power saving mode, eDRX can help to extend the LTE connection active time. 

    PSM is suited for telemetry data transmission applications, so the device can sleep most of the time(not reachable by the server) and wake up periodically to send data to the server.

     Best regards,

    Charlie

  • +1 in reply to Charlie

    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µ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.

Related
Terms of service