@uta I might be biased, but I love it. Thanks a lot - great work 👍

That’s strange and annoying!

To me the order looks like it is completed. What do you see if you go to https://portal.iotcreators.com/portal?

With the simcard you cirrently have you only make a REST query to your host if you use NB-IoT. However, we can send you another simcard which allows you do this with LTE and LTE-M as well.

You can also write me directly: afzal@iotcreators.com

@HNEE Hi Daniel, many thanks. I will check.
I am in the process of acquiring documentation from Quectel distributor but community can provide documents much faster!
Thanks,
Peter

Hi Peter,

I just contacted you via our support channel so I can do some additional tests to your connection.

Can you please send my your IMEIs as a response to the email which you just got.

Many thanks!

Regards, Roland

hey, I have a new device (kind of an IOT device) with eSim, it is supposed to be prepaid and activated, but It is not connecting and I don’t know how to check the details, and whether it has global data plan already.
I don’t have a phone number or anything, can have the imsi number.

the embedded sim is from the family MFF2-QNF8

how can I proceed?

Thanks

The problem is, I bought this from a private person used on ebay. I hope they answer next week on my mail.

Sorry, I missed this post.

Showing the payload in our GUI is not a problem for new devices.

What you need to do is the following:

APN cdp.iot.t-mobile.nl
Send your payload to: 172.27.131.100

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

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

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

Hi Karl,
our network department is investigating this issue. We’ll get back at you asap.

Hi Adam,

the APN is always: cdp.iot.t-mobile.nl - independent of your location.

However, it is important to set the PLMN ID correctly according to your country. For Poland this is: 26002

All configuration details can be found here: https://docs.iotcreators.com/docs/general-settings

I hope that helped! Let us know whether this worked out or not!

Hi Petr,

if I understood you right I see the following challenges:

find a location with NB IoT coverage. attach your device to the NB-IoT network of T-Mobile Czech. send messages via UDP to Cloud of Things decode the payload of your UDP message and integrate it with Cloud of Things

Please let us get directly in contact, that we can speak about it (roland.baldin@t-systems.com).

Regards, Roland

Hi Eben,

Quick feedback: I can use GNSS and TCP at the same time using the SIM7000E using the latest firmware, which I had to update beforehand.

Best Regards,
Daniel

AT+CGMR Revision:1529B03SIM7000E OK AT+CGNSPWR=1 OK AT+CGNSTST=1,1 OK $GNGGA,,,,,,0,,,,,,,,*78 $GNRMC,,V,,,,,,,,,,N*4D $GPGSV,1,1,03,18,,,32,20,,,33,30,,,38*78 $GNVTG,,T,,M,,N,,K,N*32 $GPGSA,A,1,,,,,,,,,,,,,,,,*32 $GLGSA,A,1,,,,,,,,,,,,,,,*02 $GAGSA,A,1,,,,,,,,,,,,,,,,*23 AT+CGNSTST=1,1 OK $GNGGA,,,,,,0,,,,,,,,*78 $GNRMC,,V,,,,,,,,,,N*4D $GLGSV,1,1,04,69,04,320,31,85,11,011,23,,,,26,86,00,056,*5C $GPGSV,2,1,06,07,23,066,34,15,34,293,22,18,12,305,32,20,01,329,35*76 $GPGSV,2,2,06,28,49,135,28,30,54,067,38*7D $GNVTG,,T,,M,,N,,K,N*32 $GPGSA,A,1,,,,,,,,,,,,,,,,*32 $GLGSA,A,1,,,,,,,,,,,,,,,*02 $GAGSA,A,1,,,,,,,,,,,,,,,,*23 AT+CGNSTST=1,1 OK ... got a fix after that! Establish test TCP server (Simple Perl script) AT+CPIN? +CPIN: READY OK AT+CSQ +CSQ: 9,99 OK AT+CGATT? +CGATT: 1 OK AT+CSTT? +CSTT: "CMNET","","" OK AT+CSTT="iot.1nce.net" OK AT+CIICR OK AT+CIFSR 100.84.13.2 AT+CIPSTART="TCP","10.65.61.189","5000" OK CONNECT OK WILMA-SERVER #1 AT+CGNSTST=1,1 OK ... Got GPS FIX AT+CIPSEND > PING SEND OK 100.84.13.2:PONG TCP connection successful.

@Florian-Duecker I am using T-Mobile NB IoT sim card. I already sent you the ID of the sim card so you are suggesting me to order a new sim card from link you sent? I’ll check it.

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

@CFH I think we need to do some troubleshooting on our side. Can you please send us the IMEI numbers via welovemail@iotcreators.com?

Thanks!

@Roalnd-Baldin Cool! Nice to see it works now.

@IoT-Arista Interesting combination. You are right, nRF9160 requires a very different development strategy. It uses Zephyr RTOS and c-api’s to control the cellular modem. In my opinion it is much better to work with than the ancient, slow, outdated AT interface. But if you want to use AT commands on nRF9160 you still can:
https://github.com/nrfconnect/sdk-nrf/tree/master/applications/serial_lte_modem

If you don’t want to redesign you should contact SIMCOM and t-mobile ( @Eric-Barten ) to fix your issue

@Crowdsourcer I don’t know. BQ24195 is pretty solid. Probe it if you need to.

@Noah-Marx said in Max message length:

https://forum.iot.t-mobile.nl/topic/504/maximum-number-of-messages-per-day/6

Thnx Noah, but no. My experience is that messages can not exceed 512 bytes from CDP to device and 1024 bytes from device to CDP. I would like this constrained by relieved, at least to one UDP frame of 1460 bytes, but even larger if possible. In the message you refer to I read that larger messages should be split up, but since with a CDP communication is message based and not frame based, you have to sort and glue those messages to one yourself on both sides. That is a waste since TCP/IP was designed to do this for us! So next best to an ordinary TCP/IP connection directly to the backend server (or any other IP address) would be a larger message IMHO.