@afzal_m Hello there, thank you for your answer, the problem has been solved. It was a funny problem though The multimeter’s scale was arranged for micro amperes so when it was trying to switch to radio module, the current of the module was not enough on the multimeter so it forced a reset by creating an impedance. When I switched the scaling parameter to milli amperes, the problem is fixed. To sum up there was not a problem just a scaling problem of the measurement tool. Thank you again.

Good morning @afzal_m, is it possible this Sim requires 3v? This would explain weird behavior when the module provides only 1.8v

I think that you did everything right. Something has changed at All Things Talk’s end. We received more complaints about integrations with ATT. @Eric-Barten already contacted them, but I will give it another try next week.

@Sergey-Vladimirov thx for your enthusiasm! For now only Quectel and Telit are “nuSIM - ready”. But soon more module vendors will be ready as well. Check out: https://iotcreators.com/en/nusim/ PS. you also sent an e-mail with another question and we’re trying to get back to you but it looks like your inbox is not accepting new messages

Thansk Roalnd. Sorry for the delay… had another project. This works for me as well and now I can continue. regards, Paul

Spain confirmed!

Hi, today we took a nice comort sensor (CO2/Temp/Humidity/BodySense) in Barcelona into operation. We configured 21401 as PLMN ID for Vodafone Spain and used 20 for the frequencyband (800Mhz). cdp.iot.t-mobile.nl as APN for IoT Creators It worked immediately without any problems. Regards, Roland

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

@Wessam Hi, have a look to https://forum.iotcreators.com/topic/626/how-long-does-it-take-that-the-network-detects-a-dead-ip-connection. Maybe it contains some info you are interested in. Regards, Roland

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

https://docs.iotcreators.com/docs/_-setup-sodaq-sara-aff-n211 Can you check of these commands help? Sara N211 = same chip as Quect BC-95

@Malte-Neumann Hi Malte, please send the 10 ICCIDs to support@iotcreators.com . I will check them . Please use as PLMN IDs from page https://docs.iotcreators.com/docs/telekom-iot-networks-in-europe Regards, Roland

@Tuyen-Phan I have mailed support@iotcreators with the imei number.

@Ronan-Lacroix I have a question: The min value for T3412 is only valid for the “extended” version of TAU ? Does the 1 hour apply also to the min. value of standard TAU or is it shorter? Having a min TAU of 1 hour seems to me for many use cases difficult because the devices in those use cases need to wakeup from sleeping much more often (e.g. every 10 minutes). Many many thanks for your support! Regards, Roland I

We will use our devices for various stationary applications. However, in most cases we send the devices to customers who then are responsible for deployment themselves. We expect cases where customers ask us if we know where the devices are located because of shipping mishaps or gaps in deployment documentation. For these cases, a cell tower ID based location would be the least we should be able to tell the customer. Also, a shipping history based on that precision level will be helpful. The built-in sensors will be able to tell us, when a device has been moved or gone through a change in environmental conditions.

@Eben-van-Ellewee @Stefan-de-Lange Many many thanks for this hints! I will take this to our doc and dev team. Regards, Roland

@Marijn many thanks for this . I am highly interested in this. Regards, Roland

For the final reply, the datas that are being sent to beeceptor are forwarded to the HTTP endpoint in Turkey. I entered the url of the server In Turkey to the proxy settings on my beeceptor page. So now the problem is handled. Thank you everyone. Kind regards, Mert

@Holger-Wech you can use LTE-M instead of the 2G/3G fallback that is described in our quick start guide. Please use the APN internet.m2mportal.de for LTE-M.

The CoAP stack of the CoAP server is based on Californium version 1 and uses the implemenation as it has been pushed by OceanConnect from Huawei. Although this implementation is not 100% standard compliant there are ublox n211 and quectel bc95 in the market which support this floavor of CoAP I checked the AT command guide of the SIM7070G. It looks like only the standard CoAP is supported. IoT Creators will provide the standard complient CoAP stack in Q1 2021. Hope this helps. Regards, Roland

@Cees-Meijer I just got an error message that the email couldn’t be delivered to you email address. Could you please send an email to support@iotcreators.com to make sure I am using the right address? Thanks! Cheers.

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

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