How much battery lifetime can we expect with a Sara-N200 module on our IoT network?
-
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 -
@techniek Mooi experiment Henk.
Ik heb nog een aantal opmerkingen / vragen:
- Heb je bij iedere meting via het +NUESTATS commandado gekeken welk ECL niveau gebruikt werd? In mijn metingen zie ik soms ECL niveau 1 ondanks goede signaalcondities. Figuur 1 lijkt een ander ECL niveau te gebruiken, ik zie daar meerdere pieken welke ik op andere metingen niet zie.
- Klopt het dat een device dat UDP gebruikt langer blijft luisteren dan een device dat CoAP gebruikt? Het verbaast mij dat ik tussen +CSCON: 1 en CSCON: 0 een verschillend stroomfiguur zie voor beide metingen.
In je tekst schrijf je dit:
With the early release enabled the radio module will be forced to go into sleep (PSM) mode and not stay several seconds first in idle mode (where it listens for downlink messages).
-
Volgens mij bedoel je hier connected mode. De interval tussen +CSCON: 1 en +CSCON: 0 wordt verkleint met het gebruik van assisted release, zie figuur 2. De idle mode is de interval tussen CSCON:0 en NPSMR: 1 en wordt dus bepaald door de T3324 idle timer, zie ik ook deze foto van rohde en schwarz:
-
Aanpassen CPSMS parameters. Is het al mogelijk om de PSM timers aan te passen op het device? T3324 (idle) en T3412 (TAU) zijn configureerbaar via AT+CPSMS maar het netwerk lijkt dit nog niet te ondersteunen.
-
Het gebruik van de connected mode lijkt een wel/niet verhaal. Óf mijn device blijft 20 seconden luisteren naar downlink berichten, of hij doet dit niet. Kan ik deze tijd niet variabel maken? Een device hoeft in heel veel gevallen niet zo lang te luisteren, enkele seconden volstaat.
-
Heb je ook gekeken wat er gebeurt als we PSM niet activeren? Het device blijft dan periodiek pagen. De interval van de pages (ongeveer 10 seconden) heb ik tot nu toe nog niet kunnen verklaren, ik denk dat het iets te maken heeft met eDRX aangezien het device dan in idle modus blijft.
-
Wat is precies het nut van de pages? Kunnen we op deze momenten downlink berichten ontvangen, zo ja, lukt dit dan zowel met UDP als met CoAP?
-
CoAP lijkt meer energie te verbruiken dan UDP. Waarom zouden we dan alsnog CoAP gebruiken? Wat krijgen we terug voor dit (bijna dubbele!) stroomverbruik?
-
Hogere ECL en een hoger zendvermogen is niet meegenomen in de metingen. Het is daarom niet met zekerheid te zeggen dat de data in iedere situatie geldig is. Zeker in situaties met slechtere signaal condities waar ECL: 2 optreedt zal de batterij minder lang meegaan dan in de tabel staat.
-
Ook een grotere pakketgrootte heeft invloed op het stroomverbruik. Er kunnen namelijk 512 bytes verstuurd worden in een enkel uplink bericht. Misschien interessant om hier ook nog naar te kijken.
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…
- Het proces van het uitrollen van features verward mij nog een beetje. Als ik naar de roadmap kijk dan zie ik geen van de features die je nu noemt. Wanneer is het T-Mobile NB-IoT netwerk release 14 ‘ready’? 3GPP release 14 is namelijk al frozen in juni 2017: http://www.3gpp.org/release-14
Al met al is het stroomverbruik nog steeds een ingewikkeld verhaal met veel factoren die meespelen.
-
Hi Stefan,
Dank je voor je opmerkingen…
Iets over stroomverbruik roepen is idd. lastige materie, alles hangt af van de context en de context kan op oneindig veel manieren varieren…
Gellukig maar want dat maakt het een leuk vak!Op je vragen:
- Idd de term idle is niet correct moet zijn connected mode, ik heb het aangepast tnx!
- De 20 seconden luistertijd is een soort default setting die we op cell nivo kunnen configureren… Volgens mij komt deze mee als parameter in het radio beacon, de module gebruikt de door het netwerk gesuggereerde default, of kan kiezen voor een early release…
Ik weet niet wat de voors en tegens zijn als we deze tijd gaan aanpassen… als er een duidelijk betoog is waarom we voor x seconden kiezen dan kunnen we dat aanpassen. - Correctie… UDP gebruikt meer energie dan COAP omdat in het COAP protocol de early release features zijn ingebouwd. (Tenzij je zelf early release features gebruikt natuurlijk… )
- De metingen omtrend stroomverbruik zijn alleen relevant voor de setting van het experiment… Desalnietemin geven ze je een soort benchmark voor wat je minimaal realistich kunt halen, (in een soortgelijke context natuurlijk :)…
- Als rel 14 wordt uitgerold zullen we het zeker laten weten… Ik kan nu nog geen datum roepen helaas…
Zoals gezegd zal ik in volgende post iets roepen over eDRX en paging…
In de tussentijd hoop ik dat jullie mijn resultaten ten aanzien van stroomverbruik weten te verslaan!
Henk
-
Proficiat met deze resultaten. Ik ben benieuwd onder welke RF condities deze metingen gedaan zijn, rssi waarde, TX power waarde, etc.
Heb je deze metingen ook al gedaan onder corner case situaties, dwz onder ECL1 en 2 mode condities?
Verder wordt in het volgende artikel gesproken over nog veel energie zuinigere technologie. Hebben jullie daar al concrete ervaring mee? https://www.eetimes.com/document.asp?doc_id=1332677
-
@techniek Nog een vraagje: je geeft aan dat COAP impliciet al gebruik maakt van early release. Betekent dit dat er met COAP geen downlink berichten mogelijk zijn (net zoals bij UDP met early release) ?
-
@felixdonkers said in How much battery lifetime can we expect with a Sara-N200 module on our IoT network?:
@techniek Nog een vraagje: je geeft aan dat COAP impliciet al gebruik maakt van early release. Betekent dit dat er met COAP geen downlink berichten mogelijk zijn (net zoals bij UDP met early release) ?
Hi Felix,
Zoals Stefan al terecht opmerkte verkort de early realease assist de connected mode… Je ziet in figuur 2 nog steeds de stroompiekjes tegen komen van de paging… Dus device is nog steeds beschikbaar voor downlink berichten gedurende die periode. -
@felixdonkers wow dat EEtimes artikel is super interessant!
Dat gaat gewoon gebeuren de hardware gaat natuurlijk ook nog een evolutie maken… Ik probeer via linked in in contact te komen… Ik ben benieuwd hoe ver ze zijn… -
How will LPWA as in low power IoT solutions change this?
-
This post is deleted! -
This post is deleted!
