iotcreators.com web
    • Login
    • Search
    • forum.iotcreators.com
    • docs.iotcreators.com
    • Tags
    • Popular
    • Recent
    • Register
    1. Home
    2. techniek
    T
    • Profile
    • Following 0
    • Followers 2
    • Topics 3
    • Posts 57
    • Best 8
    • Controversial 0
    • Groups 0

    techniek

    @techniek

    13
    Reputation
    2052
    Profile views
    57
    Posts
    2
    Followers
    0
    Following
    Joined Last Online

    techniek Unfollow Follow

    Best posts made by techniek

    • RE: How much battery lifetime can we expect with a Sara-N200 module on our IoT network?

      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

      posted in Hardware
      T
      techniek
    • RE: AT commands gezocht om SIM7020E te verbinden

      Hi Eve,

      Ik heb het hier nog eens nagespeeld met mjin device:

      modem                   SIM7020E
      modem_version           R1752
      application_version     1752B06SIM7020E
      manufacturer            SIMCOM_Ltd
      

      Initialiseren aaloggen op het netwerk, ik voeg CBAND toe om het zoeken te versnellen. Ik ben benieuwd wat de ervaringen zijn mbt tot de snelheid van het modem bij het aanloggen op het netwerk…

      1540037744.413999 > AT+CTZU=1     # allow for Time update from network
      1540037744.423895 < OK [10 ms]
      1540037744.424127 > AT+CEREG=2  # Allow for registration notifications
      1540037744.432038 < OK [8 ms]
      
      1540037748.440100 > AT+CFUN=0
      1540037749.373692 < +CEREG: 0 +CPIN: NOT READY OK [934 ms]
      1540037749.373866 > AT*MCGDEFCONT="IP","cdp.iot.t-mobile.nl"
      1540037749.391285 < OK [17 ms]
      1540037749.391504 > AT+CFUN=1
      1540037749.762289 < OK [371 ms]
      1540037749.762414 > AT+CBAND=8
      1540037749.786240 < OK [24 ms]
      1540037749.953470 : +CPIN: READY
      1540037749.967231 : +CEREG: 2
      1540037751.551438 : +CEREG: 5,"xxxx","xxxxxxxx",9,"00"
      

      Informatie opvragen:

      1540038292.482340 > AT+CENG?
      1540038292.508500 < +CENG: 3747,3,78,"xxxxxxxx",-79,-5,-75,11,8,"04ED",0, OK [26 ms]
      1540038292.526431 > AT+CGCONTRDP
      1540038292.545609 < +CGCONTRDP: 1,5,"cdp.iot.t-mobile.nl","10.128.1.141.255.255.255.0" OK [19 ms]
      

      IP address geeft aan dat we verbonden zijn…

      …

      posted in iotcreators.com portal & API
      T
      techniek
    • RE: NB-IOT in nomadic mode

      @felixdonkers said in NB-IOT in nomadic mode:

      Will this also work abroad and with other MNO’s (NB-IOT interoperability question) ?

      Definitely 3gpp standard will be inter operable across all operators global…
      The latest non-backwards compatible change happened during rel 13… but this is a rare event… Not all operators have this change implemented but this will be resolved in the next couple of months… And this has only some effects on PSM I believe.

      Today read: "GSMA counts 31 NB-IoT launches to date… " As far as I can see is the NB-Iot rollout pace a lot faster than Cat-M1…

      What if connection is lost after all, e.g. due to a bad signal, how to detect that in a reliable manner? Using parameters CSQ=99 or RSRP=0 does not seem to be reliable. Is there a white paper that describes a solid solution?

      I would assume that connection only gets lost when after device misses its periodic registration requirements…
      AT+CGATT? if returns 1 the device is attached.

      NB-IOT provides various parameters to minimize power consumption; T3314, T3324, etc. I’m wondering how to apply those parameters in the most efficient way. And also what the impact is, e.g. on responsiveness, when changing these parameters. Is there a white paper that demonstrates adequate use of these parameters. And when will they be supported (roadmap question), as experiments have shown that these parameters currently seem to have no noticeable effect.

      AT+CPSMS command influences this.

      White paper covering these topics:
      NB-IoT Deployment Guide to Basic Feature set Requirements.pdf

      regards,

      posted in Archive
      T
      techniek
    • RE: All steps to succesfully send UDP messages

      Hi Andre,

      As promised:

      Send UDP message regular:
      0_1527495092621_nbiot-udp.png

      Send UDP message with early release:
      0_1527495067334_nbiot-udp-earlyrelease.png

      posted in Archive
      T
      techniek
    • 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.

      0_1531815688415_setup-smal.jpg

      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.

      0_1531817858606_msg_udp.png
      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:

      0_1531818009652_msg_udp_er.png
      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.

      0_1531818037760_msg_coap.png
      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.
      0_1531818090630_table.png

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

      0_1531821413357_iot-henk-small.jpg
      Henk Vergonet
      henk.vergonet@t-mobile.nl
      IoT Architect & Engineer
      T-Mobile Netherlands
      https://iot.t-mobile.nl

      posted in Hardware nb-iot ublox battery lifetime
      T
      techniek
    • RE: Kan ik data vanaf een node versturen met "standaard" AT HTTP commando's

      @jeroend said in Kan ik data vanaf een node versturen met "standaard" AT HTTP commando's:

      @techniek Ik ben inmiddels een stukje verder. Ik neem aan dat het CoAp protocol gebruikt wordt over UDP. Ik probeer met AT+CIPSEND een bericht te versturen in plaats van met AT+NMGS maar weet niet wat de server van T-Mobile verwacht. Kunnen jullie me dat vertellen? Ik neem aan een CoAp POST, moeten er opties gezet worden? Zo ja welke? Moet er een token gestuurd worden? Zo ja: hoe bepaal ik het token? Ik heb geprobeerd om hex 50 02 30 FF 41 42 43 44 te sturen (CoAp versie 1, non confirmable, geen token, POST, message id 30 hex, marker FF en payload ABCD) maar dat werkt niet. Kan iemand mij helpen? Alvast dank!

      Klopt OceanConnect praat een Huawei implementatie van CoAp. In de nabije toekomst gaan we ook plain UDP over de module mogelijk maken even geduld… we zitten in de pilot fase en ik voorzie nog een aantal grote aanpassingen…
      Groetjes,

      posted in Archive
      T
      techniek
    • RE: Minimal set of specifications of the NB-IoT network

      Hi Felix, PBM_NL

      Ik heb de “requirements / opmerkingen” geregistreerd in een excel.
      En ik ga hier intern de antwoorden verzamelen.

      posted in Archive
      T
      techniek
    • RE: PSM op de uBlox SARA-N211

      @felixdonkers

      Sorry ik was misschien iets te stellig in min uitspraak…

      Hi Felix, dus jij kunt bevestigen dat de timers op vaste waardes blijven staan?
      Had jou post over het hoofd gezien…

      Toch proberen te testen, belangerijker nog wat hebben we eraan alswe de timers kunnen aanpassen …
      Heb nog geen goed beeld bij de voordelen…

      posted in Archive
      T
      techniek

    Latest posts made by techniek

    • RE: Pincode simkaart starterspakket

      Hoi Stefan,
      Ik kun je je IMSI doorgeven? Dan kunnen we kijken of er iets geks staat in het SIM profiel.
      Grt,
      Henk

      posted in iotcreators.com portal & API
      T
      techniek
    • RE: ThingsBoard via

      @supersjimmie
      De server valideert tijdens de registratie van de callback url of het ‘endpoint’ bestaat met een lage call. Volgens mij is het handig om een http code 200 terug te sturen…

      Overigens wordt je data verpakt in een JSON bericht zoiets als dit:

      {"reports":[{"serialNumber":"IMEI:00000000000000","timestamp":1542371038999,"subscriptionId":"6acb29e3-293c-44ca-85bf-77aded8efde0","resourcePath":"uplinkMsg/0/data","value":"7b226e223a225465616d34222c226970223a2231302e302e312e323534222c2274223a313534323337313033382e39363639372c22736d223a3339352c227576223a3433312c227374223a32342e31382c226d6e223a3536377d"}],"registrations":[],"deregistrations":[],"updates":[],"expirations":[],"responses":[]}
      

      meer dan een uplink bericht kan worden verpakt in de callback:

      {"reports":[{"serialNumber":"IMEI:00000000000000","timestamp":1542799597211,"subscriptionId":"0f238f58-5bc3-4b02-be8f-a1985f84e3a5","resourcePath":"uplinkMsg/0/data","value":"7b226e223a225465616d33222c226970223a2231302e302e312e313633222
      c2274223a313534323739393539372e31353131322c22736d223a3336362c227576223a3434382c227374223a2d3132372e30302c226d6e223a3131387d"},{"serialNumber":"IMEI:000000000000000","timestamp":1542799606147,"subscriptionId":"0f238f58-5bc3-4b02-be8f-a198
      5f84e3a5","resourcePath":"uplinkMsg/0/data","value":"7b226e223a225465616d33222c226970223a2231302e302e312e313633222c2274223a313534323739393630362e31303930392c22736d223a3336372c227576223a3434332c227374223a2d3132372e30302c226d6e223a3131397d
      "},{"serialNumber":"IMEI:00000000000000","timestamp":1542799615678,"subscriptionId":"0f238f58-5bc3-4b02-be8f-a1985f84e3a5","resourcePath":"uplinkMsg/0/data","value":"7b
      226e223a225465616d33222c226970223a2231302e302e312e313633222c2274223a313534323739393631352e36343634322c22736d223a3336362c227576223a3433342c227374223a2d3132372e30302c226d6e223a3132307d"},{"serialNumber":"IMEI:00000000000000","timestamp":1542799624654,"subscriptionId":"0f238f58-5bc3-4b02-be8f-a1985f84e3a5","resourcePath":"uplinkMsg/0/data","value":"7b226e223a225465616d33222c226970223a2231302e302e312e313633222c2274223a313534323739393632342e36303937352c22736d223a3334352c227576223a3434312c227374223a2d3132372e30302c226d6e223a3132317d"},{"serialNumber":"IMEI:00000000000000","timestamp":1542799634106,"subscriptionId":"0f238f58-5bc3-4b02-be8f-a1985f84e3a5","resourcePath":"uplinkMsg/0/data","value":"7b226e223a225465616d33222c226970223a2231302e302e312e313633222c2274223a313534323739393633342e30373131322c22736d223a3336362c227576223a3434362c227374223a2d3132372e30302c226d6e223a3132327d"}],"registrations":[],"deregistrations":[],"updates":[],"expirations":[],"responses":[]}
      

      Ik ken de Thingsboard omgeving niet goed genoeg maar ik vermoed dat je het JSON bericht moet parsen, in de “uplinkMsg/0/data”,“value” staan de berichten in hex gecodeerd.

      posted in iotcreators.com portal & API
      T
      techniek
    • RE: AT commands gezocht om SIM7020E te verbinden

      Hi Eve,

      Ik heb het hier nog eens nagespeeld met mjin device:

      modem                   SIM7020E
      modem_version           R1752
      application_version     1752B06SIM7020E
      manufacturer            SIMCOM_Ltd
      

      Initialiseren aaloggen op het netwerk, ik voeg CBAND toe om het zoeken te versnellen. Ik ben benieuwd wat de ervaringen zijn mbt tot de snelheid van het modem bij het aanloggen op het netwerk…

      1540037744.413999 > AT+CTZU=1     # allow for Time update from network
      1540037744.423895 < OK [10 ms]
      1540037744.424127 > AT+CEREG=2  # Allow for registration notifications
      1540037744.432038 < OK [8 ms]
      
      1540037748.440100 > AT+CFUN=0
      1540037749.373692 < +CEREG: 0 +CPIN: NOT READY OK [934 ms]
      1540037749.373866 > AT*MCGDEFCONT="IP","cdp.iot.t-mobile.nl"
      1540037749.391285 < OK [17 ms]
      1540037749.391504 > AT+CFUN=1
      1540037749.762289 < OK [371 ms]
      1540037749.762414 > AT+CBAND=8
      1540037749.786240 < OK [24 ms]
      1540037749.953470 : +CPIN: READY
      1540037749.967231 : +CEREG: 2
      1540037751.551438 : +CEREG: 5,"xxxx","xxxxxxxx",9,"00"
      

      Informatie opvragen:

      1540038292.482340 > AT+CENG?
      1540038292.508500 < +CENG: 3747,3,78,"xxxxxxxx",-79,-5,-75,11,8,"04ED",0, OK [26 ms]
      1540038292.526431 > AT+CGCONTRDP
      1540038292.545609 < +CGCONTRDP: 1,5,"cdp.iot.t-mobile.nl","10.128.1.141.255.255.255.0" OK [19 ms]
      

      IP address geeft aan dat we verbonden zijn…

      …

      posted in iotcreators.com portal & API
      T
      techniek
    • RE: T-Mobile USA nu ook gelanceerd

      @felixdonkers Ik heb een paar rudimentaire tests gedaan met de R410 en ik heb verbinding kunnen opzetten… Mijn enige observatie is dat device iets langer nodig heeft om op het netwerk aan te loggen… maar dat kan ook liggen aan mijn onervarenheid met het device… …
      Ik verwacht snelle certificering op ons netwerk.

      posted in iotcreators.com portal & API
      T
      techniek
    • RE: T-Mobile USA nu ook gelanceerd

      @felixdonkers said in T-Mobile USA nu ook gelanceerd:

      @techniek Het verschil in LTE banden is bekend en daar kun je op designen. Ik ben inderdaad benieuwd naar die andere regionale verschillen, opdat we er bij by-design rekening mee kunnen houden. Hopelijk zijn die verschillen minimaal en leiden ze niet tot ander functioneel gedrag. Denk aan: wel of geen CDP, instellingen van de timers, andere latencies, etc.

      In dat kader is het interessant om te vermelden dat ik Riot Micro heb gecontacteerd, zij doen al veel tests in de VS, wij gaan direct na de zomervakantie tests doen op ons netwerk met hun devices…
      Verder is interessant om te vermelden dat meeste modules die nu op de markt zijn de radio in software op DSP’s implementeren… Dat is een hele goede benadering als je naar de complexere modulaties zoals bij cat 6 7 8 … toegaat, bovendien geeft dat een enorme flexibiliteit…

      Cat M1 en NB-IoT modulatie is bewust minder complex en daarom loont het zich om processing in analog in gates op de chip te implementeren, met als voordeel goedkopere en zuinigere chips…
      Du ik kijk hier naar uit!
      @felixdonkers dank voor de tip…

      posted in iotcreators.com portal & API
      T
      techniek
    • RE: T-Mobile USA nu ook gelanceerd

      Dat zou in principe zeker kunnen, als zul je wel validatie moeten doen. Omdat er kleine regionale verschillen zouden kunnen zijn… al was het maar dat frequentie band in US een andere is…

      posted in iotcreators.com portal & API
      T
      techniek
    • RE: How much battery lifetime can we expect with a Sara-N200 module on our IoT network?

      @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…

      posted in Hardware
      T
      techniek
    • RE: How much battery lifetime can we expect with a Sara-N200 module on our IoT network?

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

      posted in Hardware
      T
      techniek
    • RE: How much battery lifetime can we expect with a Sara-N200 module on our IoT network?

      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

      posted in Hardware
      T
      techniek
    • 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.

      0_1531815688415_setup-smal.jpg

      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.

      0_1531817858606_msg_udp.png
      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:

      0_1531818009652_msg_udp_er.png
      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.

      0_1531818037760_msg_coap.png
      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.
      0_1531818090630_table.png

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

      0_1531821413357_iot-henk-small.jpg
      Henk Vergonet
      henk.vergonet@t-mobile.nl
      IoT Architect & Engineer
      T-Mobile Netherlands
      https://iot.t-mobile.nl

      posted in Hardware nb-iot ublox battery lifetime
      T
      techniek