Time issue device server on GT02A device/clone

Hi there. First GREAT software! Thank you.

I use the software from version 3.2 and until now no problems. I did use it in the past with TK110 (TK103 protocol on port 5002) device and it did work flawlessly. OS Debian 7 64bit and I did make a clean install for eliminating software glitches.

Now about my problem.
I did buy 50 new devices GT02a by Dytech/DYEGOO.
After testing I found that It uses again TK103 protocol on port 5002 and ID 0+last 11 digits of the IMEI and here started the problems.

First I initialy setup the device via SMS:
factory,666666#
apn,666666,inet-gprs.mtel.bg#
server,666666,0,80.72.66.116,5002,0#
timer,666666,,20#
gmt,666666,E,2#

The device start working and send data to the my server.

So I will try to explain the issue/problem.

When the device is "moving" it reports the correct position and time to the server in the transmitted data. But when the device is not moving, it report the correct position (current position) but not the correct time.
Also there is some other communication between the server and the device, which is not present in the TK110 device:

Examples from log of GT02A device when it is moving:

2016-10-25 10:07:40  INFO: [4AE93E29] id: 027044522696, time: 2016-10-25 10:07:39, lat: 42.68910, lon: 23.24268, speed: 11.6, course: 309.4
2016-10-25 10:07:50 DEBUG: [4AE93E29: 5002 < 149.62.201.206] HEX: 283032373034343532323639364252303031363130323541343234312e333835334e30323331342e35313239453033382e383037303734393332362e323830313030303030314c303030303030303029
2016-10-25 10:07:50  INFO: [4AE93E29] id: 027044522696, time: 2016-10-25 10:07:49, lat: 42.68976, lon: 23.24188, speed: 21.0, course: 326.3
2016-10-25 10:07:57 DEBUG: [4AE93E29: 5002 < 149.62.201.206] HEX: 283032373034343532323639364252303031363130323541343234312e343131324e30323331342e34383834453031372e303037303735363331302e353330313030303030314c303030303030303029
2016-10-25 10:07:57  INFO: [4AE93E29] id: 027044522696, time: 2016-10-25 10:07:56, lat: 42.69019, lon: 23.24147, speed: 9.2, course: 310.5
2016-10-25 10:08:00 DEBUG: [4AE93E29: 5002 < 149.62.201.206] HEX: 283032373034343532323639364252303031363130323541343234312e343131314e30323331342e34383335453030362e313037303735393234302e353930313030303030314c303030303030303029
2016-10-25 10:08:00  INFO: [4AE93E29] id: 027044522696, time: 2016-10-25 10:07:59, lat: 42.69019, lon: 23.24139, speed: 3.3, course: 240.6
2016-10-25 10:08:10 DEBUG: [4AE93E29: 5002 < 149.62.201.206] HEX: 283032373034343532323639364252303031363130323541343234312e343039354e30323331342e34383333453030302e303037303830393234302e353930313030303030314c303030303030303029
2016-10-25 10:08:10  INFO: [4AE93E29] id: 027044522696, time: 2016-10-25 10:08:09, lat: 42.69016, lon: 23.24139, speed: 0.0, course: 240.6
2016-10-25 10:08:17 DEBUG: [4AE93E29: 5002 < 149.62.201.206] HEX: 283032373034343532323639364250303033353532323730343435323236393648534f31613429
2016-10-25 10:08:17 DEBUG: [4AE93E29: 5002 > 149.62.201.206] HEX: 283032373034343532323639364150303131613429
2016-10-25 10:09:03 DEBUG: [4AE93E29: 5002 < 149.62.201.206] HEX: 283032373034343532323639364250303033353532323730343435323236393648534f31613429
2016-10-25 10:09:03 DEBUG: [4AE93E29: 5002 > 149.62.201.206] HEX: 283032373034343532323639364150303131613429

Note the time on server 10:08:10 and device 2016-10-25 10:08:09

Examples from log of GT02A device when it is not moving:

283032373034343532323639364252303031363130323556343234312e343039354e30323331342e34383333453030302e303131313330393234302e353930313030303030304c303030303030303029
2016-10-25 10:13:11  INFO: [4AE93E29] id: 027044522696, time: 2016-10-25 14:13:09, lat: 42.69016, lon: 23.24139, speed: 0.0, course: 240.6
2016-10-25 10:13:38 DEBUG: [4AE93E29: 5002 < 149.62.201.206] HEX: 283032373034343532323639364250303033353532323730343435323236393648534f31613429
2016-10-25 10:13:38 DEBUG: [4AE93E29: 5002 > 149.62.201.206] HEX: 283032373034343532323639364150303131613429
2016-10-25 10:14:24 DEBUG: [4AE93E29: 5002 < 149.62.201.206] HEX: 283032373034343532323639364250303033353532323730343435323236393648534f31613429
2016-10-25 10:14:24 DEBUG: [4AE93E29: 5002 > 149.62.201.206] HEX: 283032373034343532323639364150303131613429
2016-10-25 10:15:10 DEBUG: [4AE93E29: 5002 < 149.62.201.206] HEX: 283032373034343532323639364250303033353532323730343435323236393648534f31613429

Note the time on server 10:13:11 and device 2016-10-25 14:13:09

P.S. what is this communication from server > device, wich is not present on the TK110

2016-10-25 10:14:24 DEBUG: [4AE93E29: 5002 < 149.62.201.206] HEX: 283032373034343532323639364250303033353532323730343435323236393648534f31613429
2016-10-25 10:14:24 DEBUG: [4AE93E29: 5002 > 149.62.201.206] HEX: 283032373034343532323639364150303131613429
2016-10-25 10:15:10 DEBUG: [4AE93E29: 5002 < 149.62.201.206] HEX: 283032373034343532323639364250303033353532323730343435323236393648534f31613429

Example from log of TK110 device-no such problems:

2016-10-24 00:33:45 DEBUG: [2AFA734B: 5002 < 149.62.201.206] HEX: 283038383034353137373232324252303031363130323341343234302e383133314e30323331342e37303938453030302e303231333334323230322e373430303030303030304c303030313645314429
2016-10-24 00:33:45  INFO: [2AFA734B] id: 088045177222, time: 2016-10-24 00:33:42, lat: 42.68022, lon: 23.24516, speed: 0.0, course: 202.7
2016-10-24 00:33:52 DEBUG: [2AFA734B: 5002 < 149.62.201.206] HEX: 0a
2016-10-24 00:34:14 DEBUG: [2AFA734B: 5002 < 149.62.201.206] HEX: 0a
2016-10-24 00:34:37 DEBUG: [2AFA734B: 5002 < 149.62.201.206] HEX: 0a
2016-10-24 00:35:00 DEBUG: [2AFA734B: 5002 < 149.62.201.206] HEX: 0a
2016-10-24 00:35:22 DEBUG: [2AFA734B: 5002 < 149.62.201.206] HEX: 0a
2016-10-24 00:35:45 DEBUG: [2AFA734B: 5002 < 149.62.201.206] HEX: 0a
2016-10-24 00:36:08 DEBUG: [2AFA734B: 5002 < 149.62.201.206] HEX: 0a
2016-10-24 00:36:31 DEBUG: [2AFA734B: 5002 < 149.62.201.206] HEX: 0a
2016-10-24 00:36:54 DEBUG: [2AFA734B: 5002 < 149.62.201.206] HEX: 0a
2016-10-24 00:37:16 DEBUG: [2AFA734B: 5002 < 149.62.201.206] HEX: 0a
2016-10-24 00:37:40 DEBUG: [2AFA734B: 5002 < 149.62.201.206] HEX: 0a
2016-10-24 00:38:03 DEBUG: [2AFA734B: 5002 < 149.62.201.206] HEX: 283038383034353137373232324252303031363130323341343234302e383133314e30323331342e37303938453030302e303231333735373230322e373430303030303030304c303030313645314429
2016-10-24 00:38:03  INFO: [2AFA734B] id: 088045177222, time: 2016-10-24 00:37:57, lat: 42.68022, lon: 23.24516, speed: 0.0, course: 202.7

This is a problem, because for real time 11:00 for example , the device is moving and in place X, but earlier when the device was stopped somewhere else place Y and reported another position for 11:01 (unreal time) the route looks like kid scetch.

IDEAS to solve or work around this issue?

Looks like the problem is on the device side. Here are the decoded messages:

(027044522696BR00161025A4241.4095N02314.4833E000.0[070809]240.5901000001L00000000)
(027044522696BR00161025V4241.4095N02314.4833E000.0[111309]240.5901000000L00000000)

First one is valid with correct time (time highlighted with square brackets). Second one is invalid message with incorrect value.

If you look at the letter in the message closer to the beginning:
A - means Active which indicates that device has a GPS fix
V - means inValid which indicates that device doesn't have a GPS fix

I suspect what happens is when device has a GPS fix, it uses GPS time which is correct. When it doesn't have a GPS fix, it uses internal timer which is incorrect for some reason. That's just my guess, but either way it's a device issue, not server.

Anton, thanks for the quick replay.
I did not say that it is the server's fault.
I also did use the HEX converter to check the data between the server and device to find an solution without writing in the forum.

Any idea how to solve or at least workaround this issue?
I have an Idea to set time of A and V states to the same time zone, but then the time on the server will be an issue or not?

P.S. any idea about the communication from server to device?

2016-10-25 10:14:24 DEBUG: [4AE93E29: 5002 < 149.62.201.206] HEX: 283032373034343532323639364250303033353532323730343435323236393648534f31613429
2016-10-25 10:14:24 DEBUG: [4AE93E29: 5002 > 149.62.201.206] HEX: 283032373034343532323639364150303131613429
2016-10-25 10:15:10 DEBUG: [4AE93E29: 5002 < 149.62.201.206] HEX: 283032373034343532323639364250303033353532323730343435323236393648534f31613429

One option is to filter out invalid locations.

where can I read how to do that?

You can find config parameters here:

https://www.traccar.org/configuration-file/

Also search GitHub and forum for usage examples.

OK, I found it.

<!-- Filtering options - 4pcs added by me -->
<entry key='filter.enable'>true</entry>
<entry key='filter.invalid'>true</entry>
<entry key='filter.zero'>true</entry>
<entry key='filter.duplicate'>true</entry>

Do I need the whole or I just could use only <entry key='filter.invalid'>true</entry>

You just need first two.

YOU ARE THE MAN :-)
Now lets hope it does work :-)
Hаздоровье

Just reporting back, that the solution work.
Thank you again.