As I understand it from your explanation, achieving the same behavior as the blue dot in Google Maps is theoretically possible, but only under ideal conditions. The blue dot is generated directly by the phone’s GPS and displayed by the system without involving any data transmission over the internet. This allows it to update in near real-time, as there's no delay from encoding or network latency—only direct rendering.
In contrast, Traccar Client retrieves the GPS position and must then encode and transmit it over the internet. Its performance depends on several factors such as network quality, OS-level permissions, transmission intervals, power-saving restrictions, and more. Therefore, even when configured with a 1-second interval, achieving the same responsiveness as the native GPS display is quite challenging.
As you mentioned, the best-case scenario would require excellent signal strength, no system restrictions, and a consistently stable network connection. That’s why I was curious whether JohnDoe managed to achieve this, and if so, what setup he used. Sorry if I’m jumping in — just really interested in learning more. Best regards.
The latency should usually be pretty small. Less than a second if you have a good connection.
Well yes, I tested the device in a densely populated urban area where mobile internet is very good... my server is also in my city on good internet and the difference between the blue dot and the device is almost unnoticeable... the question is what it would look like if I were in a rural area...
Not sure what you're trying to say. If you have a bad connection, obviously there's going to be higher latency. There's nothing anyone can do about it.
Frequency and latency are two very different things.