@apuhl , with a classic M2M GSIM (IMSI starting with 90140), you may use the standard APN āinternet.m2mportal.deā, with a Consumer SIM card (starting with 26201), it should be āinternet.telekom.deā.
@Thomas-R Hi,
This feature is currently not supported from the vendor and hence wonāt be available this year. Unfortunately I have no exact date for now when itāll be available.
Iām keen to know more about customer prespective on Rel. 14. Could you please let me know more about your interest in this feature? is it relevant to a use case you are developing?
@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
Tuino 096 is an Arduino Zero (M0) compatible board. Grove Base Shield V2.0 doesnāt support this explicitity.
I recommand to try"ARDUINO MKR CONNECTOR CARRIER (GROVE COMPATIBLE)" instead. With this shield you can bridge from Zero/M0 to sensors with Grove connectors.
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:
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.
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
Deutsche Telekom has certified the LTE-M GM01Q platform from Sequans, and there are no plans currently to certify the NB01Q (NB-IoT variant of the same platform). This affects all modules based off of that platform, including the pycom G01, gpy and fipy modules.
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.
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.
We do not have a message broker @Robin-Puthli. But we do use a SCS. The SCS is an essential component for NB-IoT (as also described by 3GPP). Without the SCS you will get in trouble with your battery.
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.