Thanks

@HaraldNaumann maybe you’ve got some advice?

I see successful connections in our backend and will send you details by email.

Before activating radio module Set APN with AT+QCGDEFCONT rather than **AT+CGDCONT Set frequency band explicity with AT+QBAND Configure first APN, fequency band and mobile operator ID before switching on automatic attachment

Hi Frank, WUS and other 3GPP Release 15 features aren’t yet supported in the DT networks and to our knoweldge in most other Operator networks. Our focus is right now on completing the roll-out of key features like eDRX, while in parallel planning the introduction of new Rel. 14 features like New Category NB2. WUS and other important Rel. 15 features are of course already on our Roadmap, unfortunately we cannot give you a concrete date when those will be deployed in the our networks yet. Can’t eDRX to a certain extent address your power saving requirements for the time being? Best regards, Ronan

@Roalnd-Baldin The 2 hours is probably related to the 3GPP TAU timer, if it expires the device is implicitly released from the network I believe. Which is bad if you have a device that wants to sleep for more than 2 hours. So usually you set this value to whatever is the greatest the network accepts. You can run AT+CEREG=5, AT+CEREG? and check the returned values. It will tell you the timers that are used.

@Sven-Brandau said in Network time: Hello, is the feature ‘network time’ (3GPP 27.007 Ch. 8.15) for NB-IOT/Cat-M1 supported in the Deutsche Telekom mobile network? The NRF9160 SIP returns an error, while requesting the time. Also after a long time of being connected. Hi Sven, sorry that it took us so long. But now we have a clear statement from our experts that the network time feature is NOT supported in our network in Germany.

Hi, I did “normal” TCP/IP MQTT on top of NB-IoT connection with the Quectel BC66. So TCP/IP is possible. But I didn’t try to post a normal HTTP request. LWM2M is implemented on top of CoAP and UDP. By this it works perfectly on NB-IoT. It is also supported by Quectel BC66. We tested it successfully with Eclipse Leshan server and the Nokia Impact LWM2M server. Regards, Roland

Hi Thomas, Yes, SMS is supported over our LTE-M network. We will soon provide an detailed overview of the supported features and capabilities, please stay tuned! Best, Ronan

Hello @Ahmed-Elhaddad, We do these tests in parallel to normal network maintenance and improvement measures and we can share some preliminary results in CE-0 conditions from measurements in our Labs. • Up to 200 devices can attach successfully simultaneously within 10 minutes under the condition that they do not immediately send data after a successful attach. • Average round trip time (RTT) increases with increasing number of parallel transmitting devices. A randomization of transmission attempts leads to reduction of RTT and potentially improvement of battery lifetime • With regards to the initial attach, only a small number of devices should be activated simultaneously (max. 60 devices) • With regards to the regular data transmission with good signal level the following was observed: • Failure rates increase with more than 160 devices trying to send 100 byte of data within one second • Introducing a randomization timer of at least 40 seconds solves this limitation • Avoiding synchronized data transmission results in better share of coverage levels across all devices • Implication - Customers should avoid synchronized attaches and data-transmission of their devices Best, Dominik

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

Unfortunately it didn’t work out, what we tried yesterday. Please follow this topic for new updates.

@trick2011 I use the following sequence: AT+UDCONF=1,0 AT+USOCR=17,7000 <rx socket number> AT+USOCO=<socket>,“172.127.131.100”,<udp port> AT+USOWR=<socket>,<data length> <wait for @> <send user data> AT+USORF=<socket>,127 #127 is max rx length, depends on yr buffers +USORF: <socket>,“172.27.131.100”,15683,17,“downstream data” AT+USOCL=<socket> # close socket

Okay, my problem is fixed. I flashed the sequans modem again and I tested my code again. But it was still not working. I wiggled the cable of the antenna a bit and it connected to the network! I think the antenna of my gpy wasn’t connected properly or the antenna cable is broken or something.

Currently, data packet buffering works only in combination with PSM, in the nearest future it should also work with eDRX. So once you activated this feature on your module, packets will be buffered automatically.

@Dylan-Frings said in Connection to Azure IoT Hub: Hi, I’m trying to connect an Arduino MKRNB1500 to MS Azure IoT Hub but I constantly get the error -2 (Connection refused) on both port 443 and 8883. If I try to run the exact same script with a different SIM and carrier everything works perfectly. My company uses T-Mobile SIMs and with those SIMs I can’t establish a connection to the IoT Hub. Is T-Mobile blocking any ports on the mobile network in the NL or is there another fix for this problem? Thanks a lot! You can’t access any server on the internet directly, this is why it’s not working. The CDP is always in between and acts as a proxy. You can register a URL as an endpoint and the CDP will forward any trafic it receives from your device to your registered endpoint

Unfortunately there is no interactive map for the coverage of NB-IoT in Poland. However, T-Mobile Poland has published a press release in which they announced the nationwide coverage (coverage of 94%). They also published a map where you can get an overview of the coverage in different regions:

Problem solved. It denpends on the sim card

May I suggest you also take a look at our central FAQ page for NB-IoT Roaming?

Hi Thomas, sorry for late response. Please check our latest version of the Solution Guidelines, we have extended it with the information you inquired about. BR, Aleksandra

Hi Aleksandra, thanks for your offer. But I think at the moment it is not necessary to conduct tests in your lab in Bonn. We have the oppotunity to do some tests with a network simulator in an other Honeywell department (in India). If I will have the need for testing in Bonn before June, I would gladly come back to your offer. Best regards, Thomas

Hi Thomas, every module supplier implement their own Maximal Transfer Unit (MTU). They can reach up to 1.358 Bytes. If the message is larger than the MTU, the message should be divided into smaller messages. We only limit the amount of data per month and the number of daily messages per device. Best regards Noah