TK1000 (h02 protocol) tracker not updating map position in real-time

mmcnamee7 years ago

Hi all,

I've purchased a couple of Trackers from Amazon (https://www.amazon.co.uk/Tracker-Waterproof-Tracking-Children-Bicycles/dp/B06WGR5QM3/) listed as TKStar TK-1000 model.

It appears to use the h02 protocol via GPRS, and was relatively easy to configure with a command:

adminipXXXXXX IP.ADD.RE.SS PORT

If I enable grps, and then issue a "run,SS" command where run is the number of seconds between updates, it posts nicely into Traccar running on a raspberry pi, with the relevant ports mapped through the firewall.

All works nicely, but the position of the device does not update in real-time. However, if I view the route of the tracker using the Report option, I can see the full track of where it has been, so the data is coming into the server ok, confirmed also by watching the logs.

Any thoughts, anyone seen something similar? I have double-checked the ID parameters etc, and also tried deleting and re-adding the Device entry, in case something got corrupted in the DB. Other devices (Android and iOS clients) seem to update in realtime.

Any help greatly appreciated, all other functionality works fine with this device, and it seems pretty solid so far.

Thanks in advance!

Anton Tananaev7 years ago

I would recommend to check time in the "state" panel. Is it in the future? If yes, that's your problem. It has been discussed many time before, so you can search for more details.

mmcnamee7 years ago

That's probably the fastest and most useful response I've ever had from any forum, thanks Anton!

I will surely check the time, I did set the tracker to GMT+1, to offset for summer time, so perhaps changing it back to GMT/UTC might help that out.

Will do some testing and see if I can get it resolved!

Cheers

mmcnamee7 years ago

So, it looks like the tracker is sending two updates, one with nearest base station location, and the second with a GPS fix. The time on the GPS fix is right, the time on the other update is wrong!

I've taken the liberty of decoding the hex in the log debug output, and stripped the post-decimal point coordinates from the GPS locations, removed IDs and phone numbers etc from the log.

Happy to send the full log over via a more secure method if that will help with debugging.

2017-08-07 23:25:00  INFO: [572B30BA] connected
2017-08-07 23:25:00 DEBUG: [572B30BA: 5013 < 82.132.238.116] HEX: [DECODE: *HQ,*****ID*****,NBR,222733,234,10,0,1,21420,24410,31,070817,FFFFFBFF,4#]
2017-08-07 23:25:00  INFO: [572B30BA] id: *****ID*****, time: 2017-08-08 13:05:57, lat: 53.00000, lon: -3.00000, speed: 0.0, course: 0.0
2017-08-07 23:25:00 DEBUG: [572B30BA: 5013 < 82.132.238.116] HEX: [DECODE: *HQ,*****ID*****,V19,222401,V,5300.0000,N,00300.0000,W,000.00,076,070817,,PHONE_NUMBER,IMEI_NUMBER?,FFFFFBFF#]
2017-08-07 23:25:00  INFO: [572B30BA] id: *****ID*****, time: 2017-08-07 23:24:01, lat: 53.00000, lon: -3.00000, speed: 0.0, course: 76.0
2017-08-07 23:25:48  INFO: [572B30BA] disconnected
Anton Tananaev7 years ago

Fix time comes from the last known location, which means that it was wrong somewhere earlier than your log sample.