That is very high consumption, Abdullah. I have customers using TCP and TLS who drive regularly and their consumption is about 10MB per month.
I do have some variants, but 20MB being the one which I know the device is functioning, and the range is acceptable.
Devices with the range of 20MB are cutting weekly about 950 KM.
Faulty device's are putting me in a stress of 40MB / month . which I'm not sure if they are faulty or it's a network issue.
But out of a 100 device I'm getting 6 with irregular data sessions.
That's 2 more reasons why I need to test the OP setup with UDP
The difference between TCP and UDP isn't enough to cause that kind of issue. Assuming a 140 byte record sent from a tracker, and a 44 byte response from Traccar, the total byte count including headers is:
If you collect more records before sending them to Traccar, the additional TCP overheard percentage becomes even less:
Assuming 10 AVL records sent in a single connection:
FWIW my data usage is around 5mb per month driving 1000mi/1600km. My device only wakes/sends every 30 mins when the car is off.
Sounds about right Daniel, I concur with your figures.
I have not test connecting my instance to there OpenVPN network, but will surely do now.
I'm using TCP, my device is configured to deep sleep and wake up every 1 hour so I know it's there, unless there is some movement it would just wake up and stay up, in this setup I'm consuming ~ 20MB / month.
I have both FMC920 and FMC003, I will prepare a lab and connect a new traccar instance to 1NCE OpenVPN network, will do both TCP and UDP.
I'm actually free to test with 2 international sim providers and 1 local provider.
Also breaking the TLS at the load balancer level seems interesting, I have not test it yet but I had a use case were I needed to duplicate the connection to two tracking server's ( instead of configuring the duplication at the tracker level).