Best posts made by Stefan de Lange

@Roman-Dyzhyk

LTE-M is a good decision for multiple reasons:

• It supports HTTP(S) so I can directly reach my cloud endpoint without the need to build new CoAP/UDP proxies.
• Roaming. Virtual MNO’s like ibasis offer great coverage for LTE-M in many countries with a single SIM. This saves a lot of headache for global products. I have yet to see a similar offer for NB-IoT.
• Larger data bundles. Generally LTE-M data is cheaper and can be bought in larger quantities. This means I can ocasionally roll out an update without blowing up my data bundle.
• It supports most low power features (except RAI) and increased coverage benefits.

The biggest advantage I see today for NB-IoT is ability to use release assist (RAI). RAI has proven to be the biggest energy saver for simple TX only sensors and the fact none of the LTE-M networks or modules supports it is a major drawback for LTE-M. I understand this will be adressed in coming 3GPP releases but those are months if not years away. The fact that RAI is available today for NB-IoT means it will always beat LTE-M in energy consumption.

Hoi iedereen,

Ik vroeg mij af of het ook mogelijk is om downlink berichten te sturen naar een groep devices ipv een enkel device. Nu werkt het goed op basis van device ID, met een handjevol devices is dat nog te doen. Het wordt echter al gauw te veel bij meerdere devices. Is dit mogelijk? Zo niet, kan deze feature geïmplementeerd worden?

@Cher Hi, looking at your screenshot, I think there is a bug in the modem firmware. If you look at the logs on the right you can see:

+CPIN: RE DY

This means the sim card is detected and ready. However, one letter is missing. This is supposed to be +CPIN READY. So I think the serial tool is therefore failing to interpet the correct string.

Can you query the CCID/IMSI? If it returns a number then the sim card is for sure working. You can also try updating the firmware

@Roalnd-Baldin Would be interesting to see how it compares to our measurements on modules. I also used this tool from Nordic Semiconductor: https://devzone.nordicsemi.com/nordic/power/w/opp/3/online-power-profiler-for-lte

@felixdonkers Volgens T-Mobile zelf is het guard band operation: https://docs.iot.t-mobile.nl/docs/general-settings

@niels-veul Hoi Niels. Verkeer tussen jouw applicatie en het T-Mobile netwerk is altijd in JSON formaat via HTTP(S). Verkeer tussen jouw modem en het T-Mobile netwerk kan UDP of CoAP zijn. Je zou het dus zo kunnen zien:

Modem <- [UDP] -> T-Mobile CDP <- [HTTP] -> Jouw applicatie

Dit betekent dus dat je nooit ‘direct’ over het open internet met een modem praat, zoals je LTE-M demo. Er zit altijd een proxy tussen, het CDP. Om te praten met het T-Mobile netwerk zul je dus een applicatie moeten opzetten die om kan gaan met HTTP.

@Timo-Siekmann Hi Timo, just to let you know, I have seen latency up to 30 seconds in extremely poor conditions (RSRP < -130 dBm). So what you are seeing is expected at those low RSRP levels. If you were to plot this on a graph you would see a correlation between ping and RSRP (and EC level).

@afzal_m hi Afzal, maybe a good idea to provide commands for different modems? Because commands are always modem specific

@pieterhoenderken Hoi Pieter, als het goed is kun je hiervoor de register application API call gebruiken (in postman). Die stuurt namelijk vanaf het CDP een leeg datapakket naar je north application, voor jou dus node-RED. Als Node-RED correct geconfigureerd is zal deze een 200 (OK) response sturen naar het CDP. Een correcte connectie tussen de north application en het CDP is hiermee bevestigd.

@Timo-Siekmann I suggest you enable debug information on the module. There are several commands like AT+CEREG, AT+CSCON that can help you determine what’s happening at the radio access level (they may be called different on your module). If you have a module that supports L1, L2, L3 logging via a PC tool that will be even more helpful. You may also plot the current to see where the transmit peaks are to determine if the radio’s behavior is correct.

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

@alfons-geurts Mooi dat het werkt.

Ik raad je toch sterk aan om de firmware te upgraden, de firmware versie waar dubbele quotes niet verplicht zijn is behoorlijk verouderd

@Eben-van-Ellewee ps. you can download the user guides by replacing https://forum.iot.t-mobile.nl/ for https://forum.iotcreators.com/ in any of the links

@Timo-Siekmann said in Limited Data Rate after to many messages on aday?:

Quectel BG96

Hi, please try:

AT+QCSCON=1
AT+CEREG=4

I highly suggest to plot the current too.

@pieterhoenderken said in Postman request send uplink:

@stefan-de-lange Hoe zend ik een downlink bericht vanaf Node-Red?

Verbind een ‘inject’ node met een ‘http request’ node en kopiëer de instellingen van de downlink postman API call

@HaraldNaumann Yes, but when we want the exact numbers you tell us to buy your cookbook or attend your webinar. So how can we be educated then?

@Alessandro-Parmigiani Hi Alessandro. I have experimented a lot with this on various networks/modules and in general my experience is that RRC inactivity cannot be controlled by the device. The only succesful way I have found to circumvent the RRC inactivity period is to use Release Assist.

However, release assist has some downsides. I have found that it only works on NB-IoT, I have not found any LTE-M modules/networks that support it. The implementation also highly depends on which module you are using. Release assist does lead to significant power saving, in some specific cases (like uplink only nodes) more than 90% of power can be saved.

In general it is very hard to visualize the RRC timer. The best method I found is to activate the +CSCON URC. This will tell you when the modem has left RRC connected state.

However, I do not know the specifics for the T-Mobile network. I am just a user

@gerrit-seigers Hoi Gerrit, probeer het eens zonder SSL (In postman -> File -> Settings -> SSL certificate verification)

@florian-duecker test123

edit: works

@David-Micallef Yes, you are right, RAI is not supported for LTE-M. Even if you find a module that supports it for LTE-M you will be out of luck because as far as I am aware there are currently no networks that support it either. This leads to some significant powerconsumption in the PSM case for LTE-M. The nRF9160 however, has extremely low idle/active currents. During C-DRX the module may go as low as 70 uA. Thus the effect of the C-DRX phase on energy consumption is limited, compared to some other modules.

Disabling the radio (CFUN…) is also not ideal because the attaching process is still costly from a battery perspective.

Also true. But it is a gray area and depends on several parameters. For example, the nRF9160 can attach/detach very quickly. Thus you may find that if you do uplink once an hour turning off/on the radio can still save you some energy. Operators may not like it if you detach/attach frequently, but that’s the world they have created as it stands today

@supersjimmie Netjes! Eigenlijk zouden we een document moeten hebben om dit soort info voor iedere module op te slaan

@Alessandro-Parmigiani

@Alessandro-Parmigiani said in RRC inactivity timer duration for NB-IoT and LTE-M:

• From your experience, is the RRC inactivation time related to the number of LTE frames, in this case 5 s ~ 5.12 s, therefore 512 frames or can it also be uncorrelated?

I do not know. The module normally does not expose such details. You would need to have a network simulator or a module which supports extensive tracing on L1/L2/L3 (like the Sequans for example).

• Is the RRC inactivation time ending where the spikes on the right begin? Or is the transition to idle mode also included?

I believe the large spikes on the right signal RRC release. The very low power level afterwards suggests PSM mode. Your module also seems to be skipping the C-DRX phase, according to power consumption it is continuously in receive mode… I wonder why that is?

@supersjimmie Hoi Sjimmie, wanneer je een callback URL toevoegd wordt er een leeg HTTP[post] pakket naar jouw callback URL verstuurd. De callback URL (thingsboard dus) moet hierop reageren met een 200 OK bericht.