I know there’s a risk that I get answers about UDP not being guaranteed or having any control, but I will just try…
When I send data to the api, all works fine but sending a small amount of data costs a lot of overhead.
I have read that some people use UDP to send the data to their own UDP receiver and parse it there.
But when I send UDP to a straight-forward UDP listener, only about 1 out of 10 are deliverered.
(yes I know the internet cannot be trusted etcetera… but only about 1 out of 10…)
Most interesting is that my sim7000 is controlled with AT commands that do say that they all work fine, but in the Hologram dashboard I see “0 bytes” for all those failing attempts. Only the attempts that work do have some data.
So does that mean that there is no data received because there is not even data sent (as the dashboard says)? Or does the bytes-counter in the dashboard “know” that my UDP packets are lost? (how then…)
I’m just confused, I would expect to lose UDP data only once in a while, not mostly.
And also confused that it looks like the hologram dashboard seems to “know” it was lost.
To reply to my own message:
I changed from network from the Dutch T-Mobile to the Dutch KPN, and things are working better now!
But still lost 3 out of 11 attempts according to the hologram dashboard.
I heavily use UDP but with the U-blox SARA-R4. I see about 0.4% loss (measured across ~30,000 messages total) in the US and Australia (about 12 units in each) so I dont think its the inherent risk of loss from UDP. My guess is it the modem is failing to actually send the data to the tower. Double check the AT command manual and see if the AT command confirmation actually means “data sent” or means “data received into modem buffer successfully”. If you have an oscilliscope or high speed A2D converter you can also try monitoring the current draw of the modem to see when it actually sends the data (you will see increased current / more frequent current spikes when it sends. On the U-blox I have noticed the actual data send my not occur until ~1 second after its sent over the serial interface.
I guess the first part of my issue is clear.
Here in The Netherlands, the carriers are KPN, Vodafone and T-Mobile.
With KPN, 93 out of 100 succeeded.
With Vodafone 91 out of 100 succeeded.
With T-Mobile only about 2 out of 25 attempts succeeded.
This was done with only 1 attempt per session and no feedback from the UDP listener (no “OK” signal back, so it failed at first attempt).
I recommend NOT implementing any feedack from the listener, if you do its best to go with TCP instead, otherwise you are basically just re-implementing a less efficient, less native TCP
UDP and TCP are just as likely to lose data, the difference is taht TCP will auto re-transmit / detect loss of data. So if you are only getting 2 of 25 UDP packets through on T-Mobile, TCP would have to re-transmit each packet 10x in order to transmit a message. It is likely that TCP would not work on this network anyway as its too unreliable.
How big are your messages? I think UDP packets will be broken up into ~1.4kB so if you are sending like 100kB at a time, it will be broken into ~70 chunks where any 1 of 70 drops may drop the whole message.
Note, I kept my messages < 1.4k (target <1k) in order to make sure the full message fit in one datagram
My messages are currently very small, only about 20b data.
I was thinking of just sending a “1” back over UDP when something is received, just to know if I should retry once.
My data is exactly 24 bytes, the data-usage went from 52 bytes to 81 bytes by adding the UDP reply.
(at least when it works, otherwise the extra TX-bytes for a second attempt)
I guess 81 bytes is still much better than the overhead with TCP (over 400 bytes).
