Low power mode with AWS MQTT + GPS

callumctaylor

Hi,

We are trying to reduce the nRF91 chip to its lowest possible power consumption (a few µA). I know this involves disabling the serial communication in the config, however, our application requires both GPS and AWS MQTT, which I believe won’t work without CONFIG_SERIAL=y. When we disable serial, the module won’t connect to the MQTT server.

Is there a workaround so that anytime the device is going to enter its sleep stage we can reduce power consumption further. I watched you video on this, but am stuck on how to achieve this when the device wakes up from PSM mode and might receive an AWS MQTT update.

Not sure if this makes sense and happy to clarify or include my current code.

Kind regards,
Callum

AchimKraus

We are trying to reduce the nRF91 chip to its lowest possible power consumption (a few µA).

There are several topics:

a few µA is only the case in sleeping mode. That is usually entered with PSM, or, if available, with eDRX.
using PSM is switching off the SIM, writing data to the SIM (usually limited by around 500 000 writes), using eDRX keeps (a common) SIM in “idle” which adds about 20µA.
using TCP comes with two flavors: one is trying to keep the connection, the other one is closing the connection. With PSM it’s more about to close, with eDRX it is also possible to keep the connection.

You will find some arguments for each, so you need to make your own experience, what’s the best match in your case.

Anyway, overall, you will recognize, that TCP will take more energy than UDP. How much depends a lot on your use-case. About 3 times more is usually not a bad assumption/result.
One, maybe irritating point seems to be, that it’s hard to get some data about what energy consumption is reached in reality with MQTT. Maybe you share your values, when you have them.

For UDP (CoAP/DTLS 1.2 CID) the values are:

98-06:34:10 [d-hh:mm:ss], Thingy:91 v0.8.101+0, 02279, 160, 2132, 32, failures 0
NCS: 2.4.2, HW: B0A, MFW: 1.3.5, IMEI: 352656101079724
!3801 mV 51% (188 days left) battery
!CE: down: 8, up: 2, RSRP: -126 dBm, CINR: 3 dB, SNR: 4 dB
Stat: tx 2131 kB, rx 171 kB, max 893 B, avg 473 B

That’s from a Thingy:91 v1.4.0. I t runs now for 98 day, has about 2460 messages exchanged, some (about 200) required a retransmission or two (usually, that’s less, but this device runs at low radio conditions of about -126dBm). After 100 days, the battery is down to 50%. The forecast reflects the near past, while the 100 days also include two periods, where the device was doing more network search. I guess, it will be only 100 days left. That result in 200 days overall, exchanging an message every hour.)

Just if you’re interested to make also experience with CoAP/DTLS 1.2 CID, I’ve setup and “nRF9160 - CoAP-S3-Proxy” integrated demonstration, see Zephyr - Coaps Demo Client with Eclipse/TinyDtls and Californium (Cf) - Cloud CoAP-S3-Proxy Server.

AchimKraus

I know this involves disabling the serial communication in the config, however, our application requires both GPS and AWS MQTT, which I believe won’t work without CONFIG_SERIAL=y. When we disable serial, the module won’t connect to the MQTT server.

About GPS, that’s not my experience, CONFIG_SERIAL=y is not related to that. Even with CONFIG_SERIAL=y you may use the zephyr “power management” e.g. “int ret = pm_device_action_run(dev, PM_DEVICE_ACTION_SUSPEND);” to suspend the UART and save some energy.

AchimKraus

Just to add.

31-07:03:22 [d-hh:mm:ss], nRF9160 feather/bat. monitor v0.9.101+0, 0848, 10, 20, 30, failures 0
NCS: 2.5.0, HW: B1A, MFW: 1.3.5, IMEI: 351516178706909
!4114 mV 97% (1120 days left)
!CE: down: 8, up: 1, RSRP: -102 dBm, CINR: 12 dB, SNR: 13 dB
Stat: tx 653 kB, rx 151 kB, max 1105 B, avg 483 B

That’s a nRF9160 feather v5, running with a 3000mAh Battery in pretty good radio conditions (-102 dBm).

AchimKraus

(a few µA)

As I wrote, that’s only the case in the quite phase.

Depending on quite a lot of factors, using UDP ends up in about 100mC per message exchange and requires about 3-5s modem active time. Assuming 1 message per hour, the modem will be 3595s in the quite phase. Assuming a battery self discharge of about 10µA and also a quiescent current of about 15µA (+20µA with eDRX for the SIM) ends up in about 90mC for the quite phase. If you send more, you need more energy. Even if you only send a “alive” every 20 minutes, that will already cost you that more energy (3×100mC+90mC => doubled energy).

In your case, with GPS, that also takes about 40mA when active. Assuming you get fast an fix (10s), that’s adds also 400mC. So, if some are saying, that their device runs for longer from battery, that’s more the cases, where 1 message is sent per hour (or less) and no GPS is used. Once you send more or use GPS, the quiescent will get less important.