@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

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

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

@David-Netten I don’t think CoAP is supported. Here it says not before february: https://forum.iotcreators.com/topic/633/when-are-we-getting-non-neulmessenger-coap

On N211 I believe you can use the neul messenger version of CoAP, which does support acknowledgements. Look for the command AT+NMGS. General tip, try not to build your own acknowledge system.

@lorenz I checked the PSM timers and everything looks good to me. You request a TAU timer of 10 hours and it is also assigned as per the correct response of +CEREG. So I cannot explain why it doesn’t follow the set timers, it is very strange.

@lorenz Hi Lorenz, can you show the output of AT+CPSMS?

@jonasled I got mine through a supplier. So try asking the company you bought the devkit from. I do not like how quectel handles this, it is very inconvenient and old fashioned…

@jonasled “EMM_CAUSE_UNKNOWN” is hard to diagnose. Any time I have seen this error it could either be some operator issue, a SIM issue or a modem FW related issue. So I would suggest to update the FW first and then try again

@jonasled You can enable more verbose error reporting with AT+CMEE=2. That will tell you what kind of error you have.

Quectel usually has their own version for every command so SARA N211 commands will not work.

What I can think of:

• Make sure you have the latest firmware
• Make sure the SIM works (try with a different module?)
• Make sure the antenna is properly connected
• Make sure you are in range of a network (scan with AT+COPS=?)
• Make sure you have a proper powersupply/cable (especially some USB supplies can be bad)
• Make sure you have the correct LTE bands enabled
• It should autoconnect to an available network but if it doesn’t you can force it with AT+COPS

@jonasled Can you check if you have a working SIM card? Try AT+CPIN?

It should return OK

@Artur-S As far as I am aware all NB-IoT connections are limited to the internal network only. The only reachable endpoint is the CDP so reaching your API endpoint directly is not possible. Maybe that LTE-M does offer this option. Someone from T-Mobile can comment on this

@Artur-S I don’t think so. And since your device can’t access open internet anyway it doesn’t make much sense to do it. Interested to hear why you need DNS

@Sopwafel I agree, regular CoAP is awesome. The Neul Messenger protocol is only usable with a very limited number of modems