Implementing low-powered push notifications on nrf9160

[royalbee]

Hello,

We are interested in developing mechanism that will allow the server to send push notifications to our nRF9160 device.
We need to be able to respond to the notification quickly (preferably less than a minute), and obviously we need to save battery power as much as possible on our devices.

Can you suggest your preferred solution for that?

---

And some questions from the research we did so far:


Using eDRX to keep the modem in eDRX power saving mode until a notification arrives, seemed like a good option, but we are not sure about various things:

1. How many operators fully support eDRX and how reliable is it?
2. If one thread is waiting on eDRX and another thread tries to send data to server (on a different TCP socket), can they interrupt each other?
3. Is there a working reference project/sample program that implements communication with eDRX?
4. Will eDRX work with UDP sockets?
5. Will eDRX work AWS IoT library (using MQTT), out of the box?


Is there an option to keep the modem in some power save mode, and wake up on incoming SMS?
Or maybe stay on eDRX power saving, and the incoming SMS will trigger eDRX wakeup?


Can we we PSM power saving and wakeup on incoming notification somwhow?


In any case, any working reference code will be helpful.

Thanks in advance..

[Håkon Alseth]

Hi,

 

Both eDRX and PSM are modes that allows the UE (user equipment, ie. nRF9160 in this case) to sleep for longer periods before having to listen.

 

If your eDRX (or PSM) interval is 60 minutes, and the application does not trigger a send() during this period, you'll have a response time of 60 minutes.

If you need to poll a server connection (or incoming SMS for that matter) more frequently, you should adjust the interval accordingly.

 

If you are a TX driven application, ie. that you send data to a server, you can use PSM with a very high interval.

Each time you trigger a send(), PSM will automatically be re-negotiated afterwards.

royalbee said:

2) You said that we need to do nothing special when PSM is used, just use socket and send and receive data. But you also said that you shut down all resources during sleep mode (UART, I2C, etc), so how is that done? you don't listen to XMODEMSLEEP notifications and do the shutdown?

Disable your peripherals that you use, then place the GPIOs for those in its idle state.

royalbee said:

3) Why roaming is needed for PSM, and what is this "always roam" SIM? and can I use SIM that doesn't always roam with PSM?

Roaming is when you're connected to a network that isn't your original subscribed LTE network.

virtual operators, such as hologram/ibasis and many others, will always be roaming. They're socalled MVNO's:

https://en.wikipedia.org/wiki/Mobile_virtual_network_operator

Roaming agreements must be in order, and in some cases; you can roam but not get eDRX/PSM for instance. This is something you should ask the virtual operator about specifically.

 

Kind regards,

Håkon

[emh203]

1.)     Yes,  when using PSM   the modem only can get incoming packets during the TAU update  or during the active time after a transmit.      

So, as an example,  in my application I send packets every 10minutes.     The Modem stays alive for roughly 8seconds when I transmit.   I have my backend Tx any messages during this period.   It is it knows it can send a message to the device as it just received something.

You server initiated request really has to work within these boundaries.         You could have the modem wake up more quickly, to send a heart beat but your battery life will be severely impacted.

2.)   I decided to skip the zephyr driver API.  It seemed that the power management interface didn't work well.   There were various bits still left enabled.    I ended up just writing my own bare metal drivers for I2C, SPI, GPIO.   I had to implement some interconnect between peripherals (GPIO IRQ, SPI DMA, etc) and the Zephyr driver model wasn't really useful.   The hardware is quite simple on the nRF an I found it was easier to have  fine grained control over everything.

To shut off peripherals I simply looked at the register documentation and found the appropriate bits.    I also created a custom Zephyr board where I left most things disabled in the device tree.

In my case, I am able to get around 4.5uA sleep current using PSM.  This includes the nRF9160,  the quiescent draw of some other parts on my board, leakage, etc.      

I use a few more uA when a thread wakes up to check things, etc.   

Most Zephyr examples use the Shell/UART.    The shell spins up its own thread which uses power.   I ended up using the shell over Segger RTT and wrote some code to turn it off after a few minutes.

It takes some work but you can get current on the application side pretty low.

3.)    I should have been more clear.   If you use a MVNO   (Twilio, Hologram, etc) that works with various carriers,   they will show up on the carrier's network as a roaming device.  In some cases, T-Mobile for example,  will not allow PSM states while roaming.  AT&T however will allow PSM states on a roaming device.

If you uses a carrier sim card  (say directly from T-Mobile, ATT, Verizon, etc),   it will not be roaming on the network.  However, you still need to test that the tower grants you the PSM/eDRX state.

Services like Twilio, etc. are popular as it is easy to prototype.   Some carriers are very difficult to work with until you spend mega-$$$$