Odd behaviour in recording data
Have you checked logs to see what's happening?
I tried to tail it, but to be honest i don't know what im supposed to see in it... it's just a bunch of numbers i can't understand.
Concerning "return home" that is happening on one tracker only, however, i noticed that once in a few positions, the server time and device time get misaligned. The server time is saved as one exact hour before the other times (fix time/device time).
Raspberry clock is ok (date/time is correct with my timezone), and also all other tracker and the second server does not have this behaviour.
Note that second server is using default databse, while the one with issues is running sql, but i don't see how this would matter and impact on one tracker only.
Concerning the tracker that report itslef as somewhere else after a few hours in the garage... that's just a mistery to me but in the end seems to be tracker device related.
As i mentioned before, both traccar installations exhibits the same behaviour, and if i dial its number to get its position it reports itself in the same spot as traccar does.
I also tried to reset it to factory, but it keeps doing the same...
Manufacturer of course does not offer any insight but it seems traccar is not the cause.
the first issue is most annoying, i have no clues.
Sounds like the device is reporting time in the future. There have been multiple threads about GT06 timezone issues. I think this is probably related, but without any specific logs and details, it's impossible to tell anything for sure.
Actually, in the past. some positions are good (correct time), and sometimes it jumps back to -1 hour (and reports "at home position") .
What should i look for, in the log, to provide meaningful information to pinpoint issue? And, if it's device related, why it does not seem to happen if i switch to the ond server? (so i may try to look the same data in its log)
tnx.
Server time is always server time. What you described indicated that one hour ago your device reported future time.
Maybe I could not explain myself well.
Please look this screenshot :
https://www.dropbox.com/scl/fi/mnivaxjhm1okkn0sgitcv/misalign.PNG?rlkey=9kwqe0c2zxfz223nomkjr9v0h&dl=0
Top to bottom: device time, fix time, server time. Device and fix are correct (I was there at that time), server time seems not,being one hour behind.
Anyway, I cleared all logs and I'll try to look into new ones as soon as the tracker is moved again.
Have a good evening and thank you.
Hello, All.
I somehow managed to install the version 6.1 and SQL on a raspberry zero w 2. I've been using version 5.9 on another raspberry and h2 database before.
I'm experiencing an odd behaviour with one device.
This device is the usual chinese tracker, using gt06 port/protocol.
On the old raspberry, i had no issues. the path was recorded correctly and played back correctly as well.
On then new install the recording is plagued by a "return home" behaviour.
Let me explain what I mean... positions are recorded , but after a correct position there is one "wrong" point that is placed at the begin of the path... (a garage where the vehicle spends most of its time).
See the link, for an idea of the final result. Every straigh line goes in the garage.
https://www.dropbox.com/scl/fi/1o72ml0msaowim40cbpfn/Screenshot_2024-05-04-20-45-26-938_com.android.chrome-edit.jpg?rlkey=6yg8uav63jhkoswh1iv4v5rew&dl=0
In addition to this, realtime tracking does not work (position is static even if device is moving and the recording shows some moving as well)
Does anyone have an idea of the reason why this happens? As i mentioned, nothing of the sort happens in the old install (version 5.9 and h2 db)
I have a similar issue (on both installs) with another tracker (H2 port/protocol).
In this case, everything works fine, i can see realtime position and tracking... but when the car is parked in the garage (no valid position) and after a few hours, the reported positions jumps to the place the car spent most of her day. This is less annoying and kida funny , but i would like to know if someone else have this issue...
thank you for your feedback.
E.