FMC920 - Server adds records late
What makes you think it's a server issue?
I don't have the best understanding of how the tracker sends the data to the server, and how the server processes it, but based on the logs the tracker seems to connect to the server, submit the data correctly.
But then I'm not sure what submits these entries:
2026-08-27 23:17:10 INFO: [T47ef503b] id: 862129082966205, time: 2026-08-27 12:11:07, lat: XXXXX, lon: XXXXX, course: 354.0
I assumed that's when the server processes the data? Which made me wonder why is it processing data from 12:11:07 but at 23:17:10.
At the same time the configuration of the FMC920 is quite complex, so I equally think I could have made an error in my configuration in terms of when it submits data.
You should check the raw data from your device to confirm what it's actually sending.
I've confirmed that the data the tracker is sending is correct.
All the server logs in the Codec format are being sent from the tracker, and I can verify that all encoded data is near enough the same time that it sends to the server:
2026-08-27 23:16:50 INFO: [T47ef503b: teltonika < 92.40.188.41] 00000000000000588e01000001a04582fb1800000000000000000a00a001101000000000000c000500ef0000f00000150400c800004501000500b5000a00b60007004230a500430fef00440000000200f100005b7c001000041bc900000000010000164e
The tracker data decodes to the timestamp 23:16:47, and that is received by the server at 23:16:50.
The issue comes from the 2nd entry in the log, which I don't have any knowledge on where this log is sourced from:
2026-08-27 23:17:10 INFO: [T47ef503b] id: 862129082966205, time: 2026-08-27 12:11:07, lat: XXXXX, lon: XXXXX, course: 354.0
I've done some more testing, and I confirmed that the above log entries are not from the tracker. This is most definitely data that is already on the server, but being processed with a massive delay.
I disconnected the tracker by disabling it's internet capability at 17:14:14, this was confirmed in the server log:
2026-08-30 17:14:14 INFO: [T876455f3] disconnected
Yet what follows is these entries in the server log of data still being processed from earlier, meaning the server already had this data but it was yet to process it:
2026-08-30 17:18:10 INFO: [T31575ce9] id: 862129082966205, time: 2026-08-30 15:53:13, lat: XXXX, lon: XXXX, course: 56.0
2026-08-30 17:18:17 INFO: [T31575ce9] id: 862129082966205, time: 2026-08-30 15:53:18, lat: XXXX, lon: XXXX, course: 56.0
2026-08-30 17:18:23 INFO: [T31575ce9] id: 862129082966205, time: 2026-08-30 15:53:23, lat: XXXX, lon: XXXX, course: 56.0
2026-08-30 17:18:35 INFO: [T31575ce9] id: 862129082966205, time: 2026-08-30 15:53:28, lat: XXXX, lon: XXXX, course: 56.0
Please provide proper logs fragment.
I've attached a fresh log above, pretty much restarted the server, whilst formatting the tracker to ensure there's no old data to be sent.
2026-08-31 18:48:13 - The tracker connects and sends it's first data
18:48 - 19:05 ignition is off and send period is set to to every 120 seconds, which the tracker is doing.
From 19:05 onwards, ignition is on and send period is every 5 seconds. The tracker is still sending data at the correct rate.
However instantly there is already a delay with the server processing the data
2026-08-31 19:05:16 INFO: [T4f7dcf57: teltonika < 92.40.189.98] 00000000000000588e01000001a0593625e000000000000000000eb74500c100000e00000000000c000500ef0100f00100150500c800004501000500b5000a00b600070042303d0043102300440000000200f100005b7c00100005d01500000000010000c09e
2026-08-31 19:05:16 INFO: [T4f7dcf57: teltonika > 92.40.189.98] 00000001
2026-08-31 19:05:21 INFO: [T4f7dcf57: teltonika < 92.40.189.98] 00000000000000588e01000001a05936396800000000000000000eb74500c100000e00000000000c000500ef0100f00100150500c800004501000500b5000a00b60007004230400043102300440000000200f100005b7c00100005d015000000000100008b00
2026-08-31 19:05:21 INFO: [T4f7dcf57: teltonika > 92.40.189.98] 00000001
Tracker Sent Data Above ^
2026-08-31 19:05:37 INFO: [T4f7dcf57] id: 862129082966205, time: 2026-08-31 19:05:16, lat: 0.0, lon: 0.0, course: 0.0
2026-08-31 19:05:39 INFO: [T4f7dcf57] id: 862129082966205, time: 2026-08-31 19:05:21, lat: 0.0, lon: 0.0, course: 0.0
^
Server is processing it with quite a delay already
This gets worse the longer it goes.
But you can see at the end, bursts of old data that is being processed which is already a minute delayed.
These errors are almost certainly the root cause:
WARN: Speed limit provider failed - HTTP 504 Gateway Timeout
Perfect, Thanks!
I changed speedLimit.enable to false and I can see the server processes the data as it should!
In that case, I do love the variable speed limit info. I'm gonna do some research on other API's or somehow storing the data to be used locally instead of always using the API.
But otherwise, is there any additional configuration variables to change how long it waits for a response from the API?
Or even better (to have less strain on the API), only grab the current road speed limit after every X seconds, or only after every X records?
Another idea popped into my head, so I assume the server waits for the API to respond before it adds the record to the database. Can the priority to be changed to add the record first, and then later update it. Or add the record, and handle the notification after the API responds. I'm guessing not as I assume traccar was created to perform in a specific way.
Answering my first question regarding changing the timeout whilst waiting for a response:
Yes - client.connectTimeout & client.readTimeout
Note that those parameters are only available in the latest version of Traccar.
Thought I'd share some changes I've made. Since I know the Speed Limit API can be temperamental sometimes, I wanted to think of ideas to use the API as less as I can.
One of those ideas was to have an interval for the API to be used every X records. With the help of ChatGPT, I've created a configuration key
<entry key='speedLimit.interval'>X</entry>
Currently I have it set to 6, meaning it will use the API to find the current speed limit after every 6 records. Once it takes the speed limit, it'll cache it to be used for the remaining records without needing to call the API.
Additionally, when the ignition is off it will use the cached speed limit value and not request any new speed limit until the ignition state is changed. This completely cuts of the API requests when it isn't needed since the car isn't moving, whilst storing the current speed limit anyway.
2026-09-02 16:27:03 INFO: [Tb29b57cf: teltonika < 92.40.188.39] XXXX
2026-09-02 16:27:03 INFO: [Tb29b57cf: teltonika > 92.40.188.39] 00000001
2026-09-02 16:27:06 INFO: Ignition off - using cached speed limit 26.06928 for device 1
2026-09-02 16:27:06 INFO: [Tb29b57cf] id: 862129082966205, time: 2026-09-02 16:27:02, lat: XXX, lon: XXX, course: 190.0
2026-09-02 16:29:03 INFO: [Tb29b57cf: teltonika < 92.40.188.39] XXXX
2026-09-02 16:29:03 INFO: [Tb29b57cf: teltonika > 92.40.188.39] 00000001
2026-09-02 16:29:06 INFO: Ignition off - using cached speed limit 26.06928 for device 1
2026-09-02 16:29:06 INFO: [Tb29b57cf] id: 862129082966205, time: 2026-09-02 16:29:02, lat: XXX, lon: XXX, course: 190.0
The API timeouts do still seem to cause a slight delay, but I'm hoping my usage of a cached speed limit will reduce the need to use it as much
Hello all
I am using the latest version of Traccar on a Oracle Free Tier Ubuntu Server, and I have only 1 GPS tracker.
Previously I had a ST-901 4G, which worked good, but would consistently send records whilst ignoring it's own config. However the server was able to cope with that fine. I removed the tracker for a period of time whilst I intended to replace it
Now I have a FMC920, but I was very overwhelmed by the setup possibilities. I have it currently set to 5 sec record and send records whilst moving, and 2 mins record and send records whilst stopped. It's also set to AKL so every time it sends data, the server responds with the OK.
My issue is that as time goes on in the day, it creates a very bad delay but I'm struggling to understand why.
After a day here's an example of what I have in the logs:
The first line shows that the Tracker is actually sending correct data at the correct time, but shortly after the server logs is adding records from 11 hours ago? Those data entries of 23:17 would have been sent from the tracker to the server at 12:11 etc, but the server doesn't seem to acknowledge them till then.
The result of this is the map showing completely out of date location data, and you often see it moves as it slowly updates those entries. But my confusion is whether those delayed lines are coming from the tracker, or if that's the server adding them to the database after massive delay.
After a server reset it returns to normal, so far I've left the car off for a day (so it sends data every 2 mins) and it seems to be coping well after a day. But it's whilst it's moving that something doesn't seem to be able to cope, and creates a longer and longer delay.