How much battery lifetime can we expect with a Sara-N200 module?
If you want to deploy power sensitive IoT solutions, for example when you would like to power your solution with batteries, it is always a good idea to have some general idea how on how much power is consumed. For the next example I have done some measurements on the power consumption for sending a "hello world" message using different modes of transport on a u-blox Sara-N200 module.
Goal:
In this example below we measure the amount of power consumed when using the different modes of message transport. We send a “hello world” message using: UDP, UDP with early release enabled and CoAP. With the early release enabled the radio module will shorten the “connected” mode. This will help to further reduce the power consumption. We measure the amount of power used by the device and show how to make some general calculations on battery lifetime based on these measurements.
Setup:
The experiment was conducted on the real life network of T-Mobile under good coverage conditions. The device was located in the T-Mobile office and connected to the cell-tower on top of the "Consumentenbond" building, approx. 100 meters apart. In technical terms this means that the device was always in coverage level 0 during the test.
I use off the shelf hardware: a regular u-blox Sara N200 module, with an ultra-cheap stm32 microcontroller to interface the module to the laptop, see photo below. Of course if you would like to deploy your own NB-IoT connected dog collar for example, you would need to handpick the components in order to get even better power performance and stay within a reasonable form factor.
In this example the Sara-N200 module is on the left, powered with 3.3V with the GPS and sensors on board turned off. On the right there's a STM32 microcontroller with a "high-side DC" current sensor. Using the ADC of the STM32 we are able to sample the current consumption every millisecond. This allows us to see in what state the module is, peaks of 250 ma will indicate transmissions, then at 80 mA the device is listening and below 2 mA the device is in idle/sleep mode.
The results:
I have plotted the current consumption in the plots below. To determine what energy is consumed we have to integrate the area below the current consumption curve. In the plot's below the red-line is the integrated current consumption, and a measure of the amount of power consumed. The amount of energy consumed in sleep mode is according to the u-blox datasheet 3 µA, which is difficult to measure in this setup. For the calculations I used 10 µA which would be more realistic for this setup.
Figure 1, send "hello world" using regular UDP message, AT+NSOST=0,"<ip>",<port>,11,"68656C6C6F20776F726C64".
In the case above from the AT command to initiate the transmission till the time the modem goes back in to PSM mode, 925 mA.s of power is consumed in 66 seconds. So if we want to send a message every 10 minutes the average supply current consumed is:
Icc.avg = (925 + (600 – 66)*0.01) / 600 = 1.551 [mA].
Let’s now further assume we have two AA batteries capable of delivering 2500 mAh at 1.5 volts each. Disregarding any power conversion losses we get effectively 1.5x2x2500/3.3 = 2273 mAh at 3.3Volts… With 2273 mAh of battery capacity at 1.551 mA discharge rate we would have 1465 hours of operation, sending out an UDP message once every 10 minutes.
We can do similar calculations for UDP with early release, and for the CoAP protocol:
Figure 2, send "hello world" using UDP with early release enabled, AT+NSOSTF=0,"<ip>",<port>,0x200,11,"68656C6C6F20776F726C64".
With early release flag enabled the module lets the network know that this is the last packet and that the module will not wait for further downlink messages, otherwise the module would wait for incoming messages right after the transmission… As you can see the amount of time listening is drastically reduced compared to the regular UDP case.
The graph below also shows the power consumption for sending 2 CoAP uplink messages.
Figure 3, two times send "hello world" message using CoAP protocol, AT+NMGS=11,"68656C6C6F20776F726C64".
Conclusion:
In the table below the results are ordered for each transmission mode for sending a message once every 10 minutes and once per hour.
Table 1, estimated power consumption and expected lifetimes.
Interestingly and for me unexpected, using UDP "out-of-the-box" is 3 times less efficient than using the CoAP protocol that is built into the modules. So if power is an issue you should either handcraft your protocol applying for example the early release AT command after sending the uplink message if no downlink is expected or rely on the CoAP stack that is present in this u-blox module.
From this experiment we can conclude that it is indeed possible with careful design to operate a NB-IoT device for a few years on 2 AA batteries. This baseline will already serve many use cases for which low power consumption for battery usage is a must. Improvements like for example the extended timer, with which the device can sleep for 413 days, will help to reduce the power consumption even further.
This is by no means final, I see vendors rushing out to get new dedicated NB-IoT chipsets on the market every month now. So I would expect to see even better power consumption figures as the chipsets evolve. Also on the network side we will see improvements with 3GPP release 14, which include:
- a new NB2 modem category with double data rates,
- a new power class of 14 dBm to support coin-cell battery operation e.g. for wearables,
- extentions on the early release, with AS release assistance indication,
- And general capacity increases on the number of devices supported on the network…
So I will have to revisit this experiment soon… I would be happy to hear your thoughts and comments and hear about your experiments…
Goto https://iot.t-mobile.nl/aan-de-slag/ if you want to test it yourself…
In the next article I will explore eDRX and the modes for downlink messages….
Henk Vergonet
henk.vergonet@t-mobile.nl
IoT Architect & Engineer
T-Mobile Netherlands
https://iot.t-mobile.nl
