Is there any way for my device to know if a packet it has sent has been received?
-
Often, a packet will be “successfully” sent by my BK7020E, but not received by T-Mobile or my endpoint. In my ESP32, I simply get an OK back from my SIM and nothing shows up in the portal or my server. Is there any way to get a response back to my module so it knows if the packet has arrived? (From T-mobile for example)
This is a problem I’ve been having for a couple of months now. I’m catching errors and other messages from the BK7020 and retrying when necessary, but like I said, there’s still a lot of OK’s that don’t arrive. I simply have no idea if a packet has been successfully sent or not.
With kind regards,
Vincent -
I still haven’t found any solutions, and now have some nice data to visualise the problem:
We send one packet with 2 data points every half hour. As you can see, we often have very big gaps in our data. And no way to distinguish between successful and failed sendings in our device. Logs from the periods where no data is received look completely normal.As our application requires visualizing this data to clients, such a gap is pretty much unacceptable. Any advice on how we can ensure more packets get through? We have recently bought the biggest antenna we could find and will test that soon, but the reception at the location from the graph should be pretty good already, especially as NB-IOT should have very good reception.
@Eric-Barten mind chiming in?
-
@IoT-Arista @Sopwafel Interesting problem. Have you considered using CoAP? It supports confirmable messaging at application level over UDP. It is very similar to HTTP (TCP) but at much less energy. If you then still experience packetloss you either have no connection at all or T-Mobile CDP is losing your packets
In any case the packetloss on UDP should be minimal. Big gaps in your data indicate there is some kind of problem either in the network or with your module/SW. There is virtually no way you will lose several UDP packets in a row without some underlying problem to begin with…
-
@Stefan-de-Lange Thanks for the response! I assume our hardware is indeed at least partially at fault, as the BK7020E’s we are using often exhibits other strange behavior too. With some kind of message acknowledgement we could probably circumvent that. Looking for a different module is on our to-do list, but we have no time for that now.
Do you have any suggestions for tools/brokers/whatever we could use? CoAP or MQTT with QoS 1 seems like it would work, but I don’t see any path to actually using that yet. The “Getting started” section of the documentation is simple enough, but the “Getting Serious” part quickly goes right over my head. In the end, all I’m interested in is that my device gets some confirmation if T-mobile receives a packet, so I can resend or reset if transmissions fail. Right now we just send a packet to the CDP and hope it arrives.
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.
-
@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…
-
The BK7020E does support CoAP, but I’m not getting any response from T-Mobile and the packet isn’t showing up in the portal or my endpoint. Is it possible that the BK7020E doesn’t use the CoAP I need? I’ve read something about needing Neulmessenger (https://github.com/otheruse/NeulMessenger)
This particular SIM/ESP32 combo worked fine with UDP so it’s not faulty hardware. I’m using the commands from https://simcom.ee/documents/SIM7020/SIM7020%20Series_CoAP_Application%20Note_V1.02.pdf. All commands seem to respond the way they should, and confirmed the IP/port are correct elsewhere in the forum. I’ve also registered the device for CoAP, and received messages back on my device using the {{base_url}}/m2m/endpoints/{{DeviceId}}/downlinkMsg/0/data API call before when using UDP. Any insight?
-
@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…
-
@Stefan-de-Lange Allright, but isn’t LWM2M built on top of CoAP, which I can’t get to work in the first place? I also only need message confirmation (and QoS would be nice too) for now. There’s indeed a ton of material to be found on LWM2M (and CoAP), but that’s all high-level stuff that doesn’t seem to (directly) apply to the problem I’m having (my CoAP packets not arriving at T-Mobile or my endpoint).
Do you maybe know when I can expect more detailed documentation/tutorials/examples on how CoAP works with your network?
Also, the sign up form at https://iotcreators.com/en/installfest/ doesn’t seem to be working. I’d like to attend, is it already fully booked or can I still join?
-
@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?
-
Hi,
if you want to have more insides about the UDP messages actually arriving at the edge of IoT Creators UDP server please provide me the IMEI of your device to my email roland.baldin@t-systems.com or through the chat function of the forum. I can extract system log info and provide to you. By this you can see what is catched by our servers an when.
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.Currently we are working on a new version on our IoT broker. We hope we can support in Q1 2021 more new device IoT protocolls such as LWM2M, MQTT, Std. CoAP.
Regards, Roland
-
@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
-
@Stefan-de-Lange Many thanks for the hint. I will do it.
Regards, Roland
-
@Roalnd-Baldin is the BC95 already supported for CoAP? I’m trying to get the BC95 from Quectel working with the new CoAP AT commands but the CDP isn’t responding.
-
No the BC-95 only works with the Huawei version of CoAP (neul messaging).
-
If you want to use the BC-95 you can use the same AT-commands at the U-blox SARA N211 we have it here: https://docs.iotcreators.com/docs/ii-network-attach
But these are the commands for UDP. If you want to use the Neul Messaging protocol the commands are little bit different. It is two years ago that I used neul messaging for the last time. Let me try to find the commands for you
-
Ok, here it is:
If you want to use the Quectel BC-95 or U-blox SARA N211 with Neul Messaging (Huawei propietary CoAP), just use these commands and add this command: AT+NCDP=172.27.131.100
to send your uplink payload use:
AT+NMGS=yourpayload -
Hi Afzal, Thank you! So is looks a lot like UDP only the DGRAM and NSOST are different? Do you have to be registered to Huawei platform to use Neul Messaging? Because we disabled this. Else the module will reconnect every hour if you don’t send in between.
-
Hi Afzal,
I have tried your AT-commands. Unfortunately I keep receiving CME Error 4 (operation not supported). We uploaded the newest firmware on the BC95 this week. Looks like a problem with the module. Is Neul messaging actually working on the T-mobile CDP? Because I read some topics on the forum where people keep receiving error codes. Are there more people using Neul Messaging that you know? Is DTLS supported with Neul Messaging?
-
Tbh, still not sure what this CME ERROR means. I often see it coming back on the forum, I also see that people solve it afterwards. But how, that’s not clear.
I myself got this message when I used commands that the modem didn’t recognize.
However, I am very sure that when I used the Quectel BC-95 two years ago, it really worked with AT+NCDP and AT+NMGS… maybe you should try it with quotation marks
e.g. AT+NCDP=“172.27.131.100”Our Service Capability Server (what you refer to as CDP) does support Neul Messaging. It has an UDP adapter and a Neul Messaging adapter. In our portal and documentation we often (wrongfully) refer to Neul Messaging as CoAP. So that is maybe confusing.
I know of at least 3 customers who are using Neul Messaging on our network. One of them is @magnatron
-
Thanks for your response!
I tried with quotation marks and without but no luck. Do I have to register the device as CoAP for Neul Messaging? Because the device is still registered as UDP.
-
Yes, you have to delete it and add it again as CoAP device
-
Can you provide me the ‘adaptationLayerName’?
“additionalParams”: {
“adaptationLayerName”:“{{adaptationLayerName}}”I tried to register the device as CoAP but got an error:
“msg”: “Incorrect Adaptation layer name for IMEI:deleted by admin device”,
“code”: 6030 -
@afzal_m can you delete my message above? I realised my IMEI number is now public
Thank you.
