Another wrong distance calculation with teltonika devices.
Oh, and it doesn't seem to be isolated to trips (api endpoint).
I have a ~171kilometer trip (with spots of no gsm coverage underway) that shows up in trips as ~139052km.
The same ridiculously long distance is show when I ask for a summary for the device within the trip time period.
Some forum post mentioned it might be a difference, but in my case it's not.
Any tips or hints are greatly appreciated.
Additional info: I looked through every entry in tc_positions for this trip, and they are all valid. From what i can tell, not records are sent out of order, but alot are sent in batches.
I found the two entries where the total distance increases by a lot (138881km added on a 177km trip right there). These two records are identical, except from the totalDistance attribute.
Arrived at the server at the same time, and was recorded on the device at the same time. Like a duplicate transmission/retry or something.
But why would the totalDistance increase like that?
MariaDB [traccar]> select * from tc_positions where id=10460903\G
*************************** 1. row ***************************
id: 10460903
protocol: teltonika
deviceid: 326
servertime: 2021-10-11 05:24:53
devicetime: 2021-10-11 05:24:48
fixtime: 2021-10-11 05:24:48
valid:
latitude: 69.9609599
longitude: 23.3707433
altitude: 5
speed: 28.0778
course: 124
address: NULL
attributes: {"priority":0,"sat":14,"event":0,"ignition":true,"motion":true,"rssi":3,"io200":0,"gpsStatus":1,"pdop":0.5,"hdop":0.30000000000000004,"power":14.144,"battery":4.011,"io68":0,"operator":24201,"odometer":54716,"distance":110.99,"totalDistance":2.3993955E7,"hours":3843000}
accuracy: 0
network: null
1 row in set (0.00 sec)
MariaDB [traccar]> select * from tc_positions where id=10460912\G
*************************** 1. row ***************************
id: 10460912
protocol: teltonika
deviceid: 326
servertime: 2021-10-11 05:24:53
devicetime: 2021-10-11 05:24:48
fixtime: 2021-10-11 05:24:48
valid:
latitude: 69.9609599
longitude: 23.3707433
altitude: 5
speed: 28.0778
course: 124
address: NULL
attributes: {"priority":0,"sat":14,"event":0,"ignition":true,"motion":true,"rssi":3,"io200":0,"gpsStatus":1,"pdop":0.5,"hdop":0.30000000000000004,"power":14.144,"battery":4.011,"io68":0,"operator":24201,"odometer":54716,"distance":110.99,"totalDistance":1.62875E8,"hours":3843000}
accuracy: 0
network: null
1 row in set (0.00 sec)
Have you configured Teltonika to report data in the chronological order?
"Namely the "Sort order" in the devices themselves. Oldest first or newest first? Currently we have oldest first, which sounds more sane to me."
This part? Yes. If there's another setting like this in the device, I haven't found it.
This is under GPRS settings:
Help me in a direction; Is the totalDistance attribute computed on the server, or is this number from the teltonica record/packet?
If the first, maybe a filter.duplicate is in order? If the second, I'll investigate with teltonika.
Yo tuve la misma situación con los equipos FMU130, FM36M1, FM3612
Comparto la siguiente posible solocion:
En la configuración coloque el reporte más nuevo,” de momento no recuerdo el nombre de las casillas siguientes “ pero se colocan los parámetros más altos posibles y en Ping timeout se coloca 5min
Aparte de eso en el archivo appmin 4.14 lo compare el archivo con el appmin 4.12, si viene muy diferente, del 4.12 copie “server time”, y lo remplace en 4.14 devicetime, funcionó todo, lo reiteró posible solución, ya que uso SQLSERVER y nada más actualizó la parte del servidor
The totalDistance is calculated on the server.
Anton; Thank you. Any idea of filter that could prevent this from happening? filter.duplicate ?
Also, is sending the newest records first a bad idea?
I currently only use these:
<entry key='filter.enable'>true</entry>
<entry key='filter.invalid'>true</entry>
<entry key='filter.zero'>true</entry>I applied these filters after these trips, but since no positions in this trip was at 0,0 OR invalid, I figure it doesn't matter for the ongoing investigation.
AvlMexico: Thank you. I don't speak spanish well enough, and google translate's version was a bit hard to follow, but I gather you recommend setting newest records first sent in teltonika config sort order?
Also, increase Open Link timeout, Response timeout and network ping timeout in the same category as the "Sort by" settings are? My settings are the default 300, 30 and 0 respectively.
Last, version 4.14 and it's change to use devicetime in events actually has something to do with this?
I noticed most of the records i this trips (especially around the area where the huge distance increase happened), devicetime is 2-5 seconds before servertime. Later, max 60 seconds, and many more records pr. packet. (bulk).
You need to figure out why it's happening first. For example, you mentioned that all coordinates are valid. Then those filters obviously won't help.
And by the way, filters are applied at the time of receiving data. So, setting filters later won't affect existing data.
Hi.
I appreciate you taking the time to consider this.
And of course, figuring out why this is happening is what I'm trying to do. But I don't know the deep internals of traccar, so if this happens when calculating the totalDistance attribute, there's not much I can do, except try to avoid it.
So any hint, tips or insight that can help me figure out more is all I'm hoping for.
For example: Could this possibly be a bug in distance calulcation that happens in some weird universe where two identical packets arrive at the same time? Would then filter.duplicate have avoided it?
Yes, I realize the filters won't have an effect on already stored data. :)
Again, I appreciate your time. I know we're using this software for free.
At the same time, once we have concluded this to be a reliable backend for our service, we're moving this to the cloud.
Ps; We had a good number of cases where trackers reported 0,0 coordinates and invalid positions and also messed up total distance. But that was a different situation. I'll expect that to be fixed from the point in time I added those three lines.
The calculation logic is dead simple. As Traccar receives data from the device, it first calculates distance, which is distance between last known location (latest by time) and currently processing location. Then it adds that to totalDistance from the last known location to get new value.
Allright, then I really don't understand why this is happening.
Please take a look at the database entries as they arrived for this vehicle on this trip.
Entry 10460903 and 10460912 (line 12 and 13) are completely identical, even the distance attribute. But a massive increase in totalDistance.
I've included a few entries above and below in case I've missed something that could be related.
MariaDB [traccar]> select id, servertime, devicetime, valid, latitude, longitude, attributes from tc_positions where deviceid=326 and devicetime > "2021-10-11 05:21:00" and devicetime < "2021-10-11 07:50:00";
| 10460819 | 2021-10-11 05:24:27 | 2021-10-11 05:24:22 | | 69.9629099 | 23.3647383 | {"priority":0,"sat":14,"event":0,"ignition":true,"motion":true,"rssi":3,"io200":0,"gpsStatus":1,"pdop":0.5,"hdop":0.30000000000000004,"power":13.734,"battery":4.003,"io68":0,"operator":24201,"odometer":54347,"distance":114.48,"totalDistance":2.399358576E7,"hours":3825000} |
| 10460822 | 2021-10-11 05:24:28 | 2021-10-11 05:24:25 | | 69.9625966 | 23.3642833 | {"priority":0,"sat":14,"event":0,"ignition":true,"motion":true,"rssi":3,"io200":0,"gpsStatus":1,"pdop":0.7000000000000001,"hdop":0.4,"power":14.012,"battery":4.009,"io68":0,"operator":24201,"odometer":54386,"distance":38.96,"totalDistance":2.399362472E7,"hours":3828000} |
| 10460834 | 2021-10-11 05:24:28 | 2021-10-11 05:24:26 | | 69.9624833 | 23.3642233 | {"priority":0,"sat":14,"event":0,"ignition":true,"motion":true,"rssi":3,"io200":0,"gpsStatus":1,"pdop":0.5,"hdop":0.30000000000000004,"power":14.144,"battery":4.007,"io68":0,"operator":24201,"odometer":54398,"distance":12.82,"totalDistance":2.399363754E7,"hours":3829000} |
| 10460846 | 2021-10-11 05:24:34 | 2021-10-11 05:24:27 | | 69.962375 | 23.3642066 | {"priority":0,"sat":14,"event":0,"ignition":true,"motion":true,"rssi":3,"io200":0,"gpsStatus":1,"pdop":0.5,"hdop":0.30000000000000004,"power":14.146,"battery":4.005,"io68":0,"operator":24201,"odometer":54398,"distance":12.07,"totalDistance":2.399364961E7,"hours":3830000} |
| 10460849 | 2021-10-11 05:24:34 | 2021-10-11 05:24:28 | | 69.962275 | 23.3642083 | {"priority":0,"sat":14,"event":0,"ignition":true,"motion":true,"rssi":3,"io200":0,"gpsStatus":1,"pdop":0.5,"hdop":0.30000000000000004,"power":14.147,"battery":4.006,"io68":0,"operator":24201,"odometer":54422,"distance":11.13,"totalDistance":2.399366074E7,"hours":3831000} |
| 10460852 | 2021-10-11 05:24:34 | 2021-10-11 05:24:29 | | 69.9621599 | 23.364325 | {"priority":0,"sat":14,"event":0,"ignition":true,"motion":true,"rssi":3,"io200":0,"gpsStatus":1,"pdop":0.5,"hdop":0.30000000000000004,"power":14.149000000000001,"battery":4.007,"io68":0,"operator":24201,"odometer":54435,"distance":13.56,"totalDistance":2.39936743E7,"hours":3832000} |
| 10460855 | 2021-10-11 05:24:34 | 2021-10-11 05:24:30 | | 69.9620766 | 23.36455 | {"priority":0,"sat":14,"event":0,"ignition":true,"motion":true,"rssi":3,"io200":0,"gpsStatus":1,"pdop":0.6000000000000001,"hdop":0.30000000000000004,"power":14.156,"battery":4.01,"io68":0,"operator":24201,"odometer":54448,"distance":12.63,"totalDistance":2.399368693E7,"hours":3833000} |
| 10460864 | 2021-10-11 05:24:36 | 2021-10-11 05:24:32 | | 69.9619516 | 23.3651766 | {"priority":0,"sat":14,"event":0,"ignition":true,"motion":true,"rssi":3,"io200":0,"gpsStatus":1,"pdop":0.5,"hdop":0.30000000000000004,"power":14.162,"battery":4.006,"io68":0,"operator":24201,"odometer":54461,"distance":27.66,"totalDistance":2.399371459E7,"hours":3835000} |
| 10460888 | 2021-10-11 05:24:46 | 2021-10-11 05:24:40 | | 69.9615083 | 23.3683133 | {"priority":0,"sat":13,"event":0,"ignition":true,"motion":true,"rssi":3,"io200":0,"gpsStatus":1,"pdop":0.5,"hdop":0.30000000000000004,"power":14.162,"battery":4.01,"io68":0,"operator":24201,"odometer":54605,"distance":129.42,"totalDistance":2.399384401E7,"hours":3843000} |
| 10460891 | 2021-10-11 05:24:46 | 2021-10-11 05:24:40 | | 69.9615083 | 23.3683133 | {"priority":0,"sat":13,"event":385,"distance":0.0,"totalDistance":2.399384401E7,"motion":true,"hours":3843000} |
| 10460903 | 2021-10-11 05:24:53 | 2021-10-11 05:24:48 | | 69.9609599 | 23.3707433 | {"priority":0,"sat":14,"event":0,"ignition":true,"motion":true,"rssi":3,"io200":0,"gpsStatus":1,"pdop":0.5,"hdop":0.30000000000000004,"power":14.144,"battery":4.011,"io68":0,"operator":24201,"odometer":54716,"distance":110.99,"totalDistance":2.3993955E7,"hours":3843000} |
| 10460912 | 2021-10-11 05:24:53 | 2021-10-11 05:24:48 | | 69.9609599 | 23.3707433 | {"priority":0,"sat":14,"event":0,"ignition":true,"motion":true,"rssi":3,"io200":0,"gpsStatus":1,"pdop":0.5,"hdop":0.30000000000000004,"power":14.144,"battery":4.011,"io68":0,"operator":24201,"odometer":54716,"distance":110.99,"totalDistance":1.62875E8,"hours":3843000} |
| 10460933 | 2021-10-11 05:25:09 | 2021-10-11 05:24:51 | | 69.9607983 | 23.3716716 | {"priority":0,"sat":14,"event":0,"ignition":true,"motion":true,"rssi":3,"io200":0,"gpsStatus":1,"pdop":0.5,"hdop":0.30000000000000004,"power":14.041,"battery":4.006,"io68":0,"operator":24201,"odometer":54756,"distance":39.72,"totalDistance":1.6287503972E8,"hours":3846000} |
| 10460936 | 2021-10-11 05:25:09 | 2021-10-11 05:24:53 | | 69.9606633 | 23.3719816 | {"priority":0,"sat":14,"event":0,"ignition":true,"motion":true,"rssi":3,"io200":0,"gpsStatus":1,"pdop":0.5,"hdop":0.30000000000000004,"power":13.875,"battery":4.007,"io68":0,"operator":24201,"odometer":54775,"distance":19.12,"totalDistance":1.6287505884E8,"hours":3848000} You have to extract data by servertime because your results might be missing something.
This is awkward.
I broadened my search to the traccar server logs and noticed this little line:
2021-10-11 07:24:55 INFO: user: 20, action: resetDeviceAccumulators, deviceId: 326
(note time difference because GMT+2)Fantastic.
Someone manually updated the total distance accumulator while the car was moving. (old car, newly added into system = huge error in accumulator.) This difference was added to the trip, it seems.
I'm sorry for wasting your time.
...But on the bright side, we didn't find any actual bugs! :)
Hi.
I've searched around and seems we're affected by the fact that teltonika devices may send records out of order or in batches.
But couldn't reach a conclusion from the forum posts on which settings was best to use. Namely the "Sort order" in the devices themselves. Oldest first or newest first? Currently we have oldest first, which sounds more sane to me.
Also from the changelog: (4.13) "Events are now using GPS time when possible instead of relying on server time" Is this something that could help the situation? We're still on 4.12 on the server in question.
Our situation seems to be happening mostly (possibly only) when the device drives out of gsm coverage for a while and starts pumping backlogs when it's back online.
Does anyone have Teltonika (FMBxxxx) devices running with traccar and have accurate distance calculations and could share their configuration settings? Be it server or device parameters.