@Eben-van-Ellewee ps. you can download the user guides by replacing https://forum.iot.t-mobile.nl/ for https://forum.iotcreators.com/ in any of the links
Posts made by Stefan de Lange
-
RE: Documentation download issues
-
RE: Documentation download issues
@Eben-van-Ellewee @Roalnd-Baldin I get the same problem. It looks like there are some dead links in the docs, I guess because they are pointing to https://forum.iot.t-mobile.nl/ instead of https://forum.iotcreators.com/
-
RE: Sending data with NB IoT from Netherlands to Turkey
@Mert-Karabagli One alternative to beeceptor is to host your own server, then you have a lot more freedom. For example, I setup a node-red server on a raspberry pi and that works great.
-
RE: LTE-M or NB-IoT, that is the question…
@Roman-Dyzhyk This is okay for UDP, but what about LWM2M?
-
RE: LTE-M or NB-IoT, that is the question…
@JeroenD I don’t think it’s possible to do TCP/IP over NB-IoT and therefore it’s also not possible to do HTTPS. Atleast not on the networks I have used, maybe it’s supported from the standard point of view. The 512 byte limit is not coming from T-Mobile but from the standard. TCP/IP is a very inefficient protocol for IoT in both data and energy consumption so not a good choice for NB-IoT. It will consume a lot of energy because many bytes are transported and the bitrate is very low. That’s why it’s a better fit for LTE-M
-
RE: Limited Data Rate after to many messages on aday?
@Timo-Siekmann said in Limited Data Rate after to many messages on aday?:
Quectel BG96
Hi, please try:
AT+QCSCON=1
AT+CEREG=4I highly suggest to plot the current too.
-
RE: Limited Data Rate after to many messages on aday?
@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.
-
RE: Limited Data Rate after to many messages on aday?
@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).
-
RE: LTE-M or NB-IoT, that is the question…
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.
-
RE: Is there any way for my device to know if a packet it has sent has been received?
@afzal_m Proprietary sucks I hope more open protocols are added, UDP is pretty limiting
-
RE: eDRX in Germany for NB-IoT
@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
-
RE: Data packet size
@Roalnd-Baldin Did you ever test TCP or CoAP block transfer on NB-IoT?
-
RE: eDRX in Germany for NB-IoT
@Roalnd-Baldin I’m not sure if I agree with that statement. It depends a lot on how you configure the I-eDRX parameters. I have seen modems that can do a few uA’s in between eDRX cycles. So if you can keep both the paging time window and the time between eDRX cycles low enough you can achieve very low average currents. Ofcourse this depends on what latency is acceptable for your usecase.
-
RE: Is there any way for my device to know if a packet it has sent has been received?
@Roalnd-Baldin
Regarding CoAP:
Out of history teasons IoT creators supports only a special flavior of CoAP. This flavior is also supported by ThingsBoard. It is not 100% standard, but it is supported by some devices such as Quectel BC68 out-of-box.Maybe you can change the page https://docs.iotcreators.com/docs/general-settings to reflect this? Because it says there is a CoAP device connector
-
RE: eDRX in Germany for NB-IoT
@Roalnd-Baldin
Reason why I am interested in this is because I think, there are not so much IoT use-cases in which it can be used as a game changer. Many developers want to use it to implement a very low battery consuming „realtime“ push of the decive as we know it from our mobile. But this not possibe
Interesting. Why is not possible? I thought that was the intended use for eDRX.
-
RE: Data packet size
@Roalnd-Baldin said in Data packet size:
some month ago we made some tests with the IoT Creators platform. We send many uplink and downlink messages with very different size.
Which protocol did you use? On LTE-M I was able to upload several MB’s using HTTPS
-
RE: Is there any way for my device to know if a packet it has sent has been received?
@Stefan-de-Lange Allright, but isn’t LWM2M built on top of CoAP, which I can’t get to work in the first place?
Yes, but they are not directly compatible and use different software stacks. So the fact that CoAP doesn’t work is unrelated to LWM2M.
Do you maybe know when I can expect more detailed documentation/tutorials/examples on how CoAP works with your network?
I don’t know since I’m not from t-mobile. Maybe @afzal_m knows?
-
RE: Is there any way for my device to know if a packet it has sent has been received?
@IoT-Arista Neul messaging was used in the past because it was required by OceanConnect from huawei. I believe since then t-mobile moved from OC to Nokia impact so Neul messaging is no longer needed and plain CoAP should just work. Is that correct @afzal_m @Eric-Barten ?
However I think the documentation is missing information on how CoAP can be used. So probably the next best thing is LWM2M, which is based on CoAP but has many more features and is very well documented. I think CDP support for LWM2M is still in beta…
-
RE: IP for CoAP
@IoT-Arista The documentation says CoAP is available at ip address: 172.27.131.100, port: 5683
-
RE: How can I validate my IoT use case using a virtual twin simulation?
@Uta Nice! Looks well designed. But it’s a little slow, took almost 15 seconds to load a page. Is that expected?
-
RE: Attaching Network-BC 95
@Mert-Karabagli hi, please check the following page for the correct settings https://docs.iotcreators.com/docs/general-settings
-
RE: Is there any way for my device to know if a packet it has sent has been received?
@IoT-Arista The T-Mobile CDP has it’s own CoAP ‘endpoint’. There is no usage difference from UDP, it’s just a different port I believe and you must register your IMEI as a CoAP device instead of a UDP device
The best thing I can come up with is using the {{base_url}}/m2m/endpoints/{{DeviceId}}/downlinkMsgBase64/0/data API call to send acknowledgements with message IDs back to our device so it can resend if it doesn’t receive an ACK. Which seems rather suboptimal as there are protocols like CoAP and MQTT that should handle these things, and the acknowledgements would only get sent to the device the next time it sends a message.
Indeed CoAP will handle acknowledgments for you. The only thing I am not sure about is if 7020E supports it…
-
RE: Arduino MKR NB1500: lukt niet om te verbinden.
@Crowdsourcer If you see 15 mA it means there is a problem. I measured an average of 6.7 uA in PSM