Posts made by techniek

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

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

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…

…

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

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

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…

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

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

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

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

@andre-rodenburg said in Minimaliseren stroomverbruik met UDP, release assist en PSM op een SARA-N211:

Nog iets wat ik niet kan verklaren is de grote piek tussen 400 en 500 samples, die zie ik de laatste paar dagen in al mijn metingen terug komen. Hiervoor heb ik deze nooit gezien…

Super Andre… dank je voor deze bijdrage!
Dat noopt me om de test nog een keer te herhalen… en kijken of de ECL nog invloed heeft.

Hi Andre,

As promised:

Send UDP message regular:

Send UDP message with early release:

Hi allen,

Imei zonder spaties registreren zoals dit: IMEI:<digits>

Let ook bij het registreren op de volgorde:

1. Eerst registratie via de north bound interface… API
2. Pas daarna het device op het netwerk aanmelden…

Kun je API registratie nog is proberen?

Hi Paul,

Can you give us some more details?
What API call are you trying todo?

Also what IMEI are u using?

Ik vermoed dat de 3 piekjes momenten zijn waarop het device nog luistert naar een paging request.

Nog even nagevraagd:

Ergens voor de zomer verwachten wij deze te kunnen leveren.
Na bestelling zullen ze met 1 of 2 werkdagen binnen zijn.

Jazeker SIM-Chips zullen beschikbaar zijn in 2 varianten. regular en industrial… Heeft te maken met temperatuur bereik van de chips vermoed ik…

@andre-rodenburg said in PSM Duurtest:

Ik heb wel een paar vraagjes.

De schaal in je tweede foto is in [A] neem ik aan?

1. Ik zie dat je in NCONFIG “AUTOCONNECT” op true hebt staan, is hier een reden voor?
2. Wat is NAS_SIM_POWER_SAVING_ENABLE?
3. Waarom staat bij +CGDCONT <cid> op 0 en niet op 1?
4. Als de <TAU> aan de netwerk kant op 310 uur stond betekent dit dat AT+CEREG=5 een waarde van “010 11111” terug gaf? Volgens GPRS Timer 3 welke gespecificeerd wordt door 3GPP is dit namelijk 310 uur.
   Ik zie dat het AT+CPSMS commando voor <TAU> een waarde van “010 000111” terug geeft. Volgens dezelfde GPRS Timer 3 timer is dit 70 uur, maar toch slaapt je device voor 310 uur… hoe kan dit?

Hi Andre,

1. “AUTOCONNECT”: control if the platform will automatically attempt to connect to the network
   after power-on or reboot. When enabled, will set +CFUN=1 and read the PLMN from the SIM.
   It will use the APN provided by the network

werkt voor mij… en leek me wel een handige feature…;)

2. Nieuwe setting, in fw versie A07.03 (ublox), stond default aan… ik vermoed dat dan de voeding voor de SIM on demand wordt aan gezet… Voor extra laag verbruik in PSM mode…

3. Heeft te maken denk ik dat APN uit nvram werd gebruikt…

4. Interessante observatie… Ik moet toegeven dat ik nog niet de bitmasks heb gedecodeerd… Dat zou staven dat nw nu op een vaste waarde staat…

Voor de liefhebbers, en omdat ik het leuk vind om het te laten zien

Duurtest bordje met stm32

@felixdonkers said in PSM op de uBlox SARA-N211:

P.s. wij meten de stroom door VCC naar het modem te onderbreken, daar een 1 ohm weerstand te plaatsen en daar het stroomprofiel over te meten. Daarmee meet je het stroomverbruik van het modem en de SIM kaart. In indel stand is dat ca 10 uA.

Dank je ik heb iets soortgelijks gedaan zie duurtest ben benieuwd wat je ervan vind… en of je er wat aan hebt.

De vraag was simpel:
Als we de module langer dat <TAU> time in PSM mode zetten wat gebeurt er dan?
Wordt ie weer wakker…?

Setup
De TAU timer staat op ons netwerk op ongeveer 310 uur :face_with_open_mouth_cold_sweat: dus dat is ongeveer twee weken duur testen…

Dus device in test modus gezet… en we meten het stroomverbruik met 1000 samples per seconde…
Om nu de data hoeveelheid klein beetje binnen de perken te houden worden alleen samples bewaard die 2.5 ma verschillen… Dat is een redelijk primitief mechanisme maar aangezien verbruik van de module erg dynamisch is, lijken we ermee weg te komen…

Resultaten

1. Het device blijft keurig gedurende de hele periode status “aangelogd”, status (+CGATT: 1)
2. Na 309.983 uur wordt het device uit zichzelf weer wakker en doet een location area update, hierbij wordt ook data naar het netwerk verzonden, tijdens de stroommeting kun je ook zien dat er daadwerkelijk data wordt verstuurd aan de kortstondige piek van 250 mA, zie onder.

Command log:
Hieronder zie je wat er op de seriële lijn is gebeurd gedurende de test.

legenda:
> AT… commando van PC naar modem.
< +… response van modem.
: +… notificatie van modem.

Stroom meting

Hieronder zie je het moment waarop het device weer is wakker geworden, na ongeveer 310 uur in slaap modus te zijn geweest.
De tx piekjes zijn te zien (op 2.5 S). En vermoedelijk staat device daarna 4 keer te luisteren naar evt. binnenkomende traffic…

Note:
Voor het meten van de stroom gebruik ik een stm32, samen met een (MAX4172EUA) High-Side
Current-Sense Amplifier, meet weerstand 0.25 Ohm…

@andre-rodenburg said in PSM op de uBlox SARA-N211:

@techniek Als bij het netwerk bekend is wanneer het modem slaapt / actief is kunnen we binnen dat tijdframe afspreken dat er data heen en weer gezonden kan worden. De ontvanger zal dus alleen aan staan als er een inkomend bericht verwacht wordt. Dat levert dus een behoorlijk voordeel op qua stroomverbruik.

Top: ben aan het lezen,

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