Issue of reporting, recording, and displaying GPS data.
Have you looked at the fix time?
I checked the fixtime, servertime, and devicetimecolumns in the tc_positionstable in MySQL. The result shows that devicetimeequals fixtime, but servertimeappears to be later than devicetime, looking like the timestamp when the data was written to MySQL.
So sounds like your device reported incorrect data?
From my understanding, devicetime represents the time recorded by the GPS device itself, while servertime should be the time marked by the Traccar server. I’m still not entirely clear on what fixtime specifically means in this context—though based on the database records, it currently matches devicetime exactly.
Also, when I look at each record in order of devicetime, the timestamps align perfectly with the actual physical movement/position sequence of the GPS track.
What I can’t figure out is: when the web interface queries and displays the vehicle track, what determines the order in which individual GPS points are connected? Because right now, it clearly isn’t following the devicetime/fixtime sequence.
My GPS unit is a commercial mass-market that reports via the JT808 protocol. As defined by the JT808 spec, each data packet includes its own checksum/integrity check to ensure the payload arrives intact.
With my limited understanding, since the JT808 protocol ensures data integrity via checksums, I would greatly appreciate your insights into why the device might be incorrect ?
Web app uses fix time for reports.
Apologies for the confusion. After retesting, I realized my previous issue was observed in the Traccar 6.6-based version from https://hub.docker.com/r/bg6rsh/traccar-amap. The official Traccar version 6.11.1 indeed does not rely on the database storage order for vehicle track; it looks correctly uses fixtime instead.
Looking forward to the latest official Traccar release. Also eagerly anticipating the formal Docker release of a GCJ-02-compatible Traccar version for Chinease maps.
My device sends JT808 data to the Traccar server. However, I sometimes notice that when displaying the trajectory, the track points are not connected in the actual driving order.
For example, given several coordinates in the correct chronological order:
gps_data_t0==> gps_data_t1==> gps_data_t2==> gps_data_t3==> gps_data_t4==> gps_data_t5,
the actual display shows the trajectory as:
gps_data_t0==> gps_data_t4==> gps_data_t5==> gps_data_t1==> gps_data_t2==> gps_data_t3.
Upon checking my MySQL database, I found that the records in the database are indeed stored in the order:
gps_data_t0==> gps_data_t4==> gps_data_t5==> gps_data_t1==> gps_data_t2==> gps_data_t3.
I suspect that the trajectory display follows the record order in the database.
The original JT808 data includes a devicetimefield which is correctly sequential according to the trajectory and time. It is estimated that poor communication signals may cause the device to report to the Traccar server out of the real trajectory or devicetimeorder. Alternatively, upon arrival at the Traccar server, factors like server load or other reasons might cause the data to be written to the database out of sequence.
Could you consider modifying this or adding a configuration option so that saving to the database and trajectory display are based on devicetimeinstead?