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

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

@Mert-Karabagli hi, please check the following page for the correct settings https://docs.iotcreators.com/docs/general-settings

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

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

@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

@Eben-van-Ellewee @Roalnd-Baldin I get the same problem. It looks like there are some dead links in the docs, I guess because they are pointing to https://forum.iot.t-mobile.nl/ instead of https://forum.iotcreators.com/

@Mert-Karabagli One alternative to beeceptor is to host your own server, then you have a lot more freedom. For example, I setup a node-red server on a raspberry pi and that works great.

@Roman-Dyzhyk This is okay for UDP, but what about LWM2M?

@JeroenD I don’t think it’s possible to do TCP/IP over NB-IoT and therefore it’s also not possible to do HTTPS. Atleast not on the networks I have used, maybe it’s supported from the standard point of view. The 512 byte limit is not coming from T-Mobile but from the standard. TCP/IP is a very inefficient protocol for IoT in both data and energy consumption so not a good choice for NB-IoT. It will consume a lot of energy because many bytes are transported and the bitrate is very low. That’s why it’s a better fit for LTE-M

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

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

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

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

@afzal_m Proprietary sucks I hope more open protocols are added, UDP is pretty limiting