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

There is some information here: https://forum.iotcreators.com/topic/733/how-long-will-a-downlink-message-stay-in-the-network-queue

@hans-liefting Hi Hans.

Our device registers itself every hour at the network, after which it will send an uplink message.

What protocol are you using? I would definitely not recommend to register every hour. Registering with the network is very costly energy consumption wise since many messages are exchanged. So unless your module has a very poor PSM mode the tradeoff is not worth it. Operators also generally don’t like it since it creates more load on the network.

When the device sends the uplink message, our backend replies with a downlink message that is delayed by a maximum of 3 minutes.

I am not entirely sure but I don’t think this will work since the downlink message has to be queued before you sent the uplink… but t-mobile will know the details on that.

After the uplink message has been successfully sent, the modem waits for 10 seconds for a downlink message. Afterward, it closes the connection and shutdown the modem (we use the Telit modem ME310G1-WW).

My guess is that when the modem deregisters itself from the network, the downlink message queue is cleared. But again t-mobile has to confirm this…

Note that for energy reasons, our device does not go to PSM but actually shuts down.

Can you please try again without shutting down but staying in PSM mode?

@florian-duecker test123 :)

edit: works

@Florian-Duecker said in Edit forum posts, after posting:

Would be happy to get some feedback if this works.

Doesn’t work yet unfortunately.

@Florian-Duecker said in Edit forum posts, after posting:

within the first hour after posting.

Why only within the first hour?

@magnatron It can work ofcourse but in general NB-IoT was not designed to handle so much data

@magnatron Because 75KB is too much for NB-IoT. It’s better suited for LTE-M

@magnatron if you have 75KB to send to a device you should probably switch to LTE-M… :)

Editing never worked, also deleting never worked

@magnatron said in Collegial roaming?:

The signal quality hovers at 99,99 when a modem doesn’t find an MT to connect to. Once it finds an MT and is able to connect the signal quality will indicate RSSI and QUAL.

I understand. But CSQ tells you nothing about the ability to connect, it’s just an indication that there is a signal.

In my experience, on band 8 this is no problem and happens almost instantly. Tested in The Netherlands and in Germany.

I have also not had any problems. Perhaps it is a modem issue? You can try u-blox or nRF91, those are very reliable in my experience.

But on band 20, in NL only available through VL, auto-COPS (AT+COPS=0) doesn’t work. The device will only connect when COPS is specified via AT+COPS=1,2,"20404".

You mean you are trying to roam on band 20 VFNL NB-IoT using a T-Mobile sim?

@magnatron Is this for NB-IoT? As far as I know T-Mobile NB-IoT is not available on band 20 in NL.

@magnatron said in Collegial roaming?:

On band 8 auto-COPS works fine but on band 20 I have to set COPS to 1,2,“20404” before the CSQ goes below 99,99.

I don’t understand this part, the COPS command will force it to vodafone. What do you mean by CSQ goes below 99,99?