Location "stuck" - Traccar server logging old location while Apache logs show latest?
Please provide more info from Traccar logs.
This is journalctl, apache, and traccar log output to console, beginning with the start of the traccar service: https://pastebin.com/GTkyM20z
- Apache is running as proxy so when it receives the entry before Traccar is started it seems to hold onto it for a short period before Traccar is up.
- Have been running this Traccar instance for a few years. The device in question is unique mostly in that it sends very frequent updates.
- I checked the HEX output and it looks right, mirrors the Apache logs.
- The Apache logged coordinate is always changing as expected but the Traccar logged coordinate is always exactly the same.
You redacted the most important information.
You can see that the longitude from the device (Traccar client) through Apache is -78.xx, but the longitude from Traccar log is -77.xx, an old location.
The HEX dumps (redacted) look like:
POST /?id=392645×tamp=1640646239&lat=37.xxxx&lon=-78.xxxx&speed=0.0&bearing=0.0&altitude=72.0&accuracy=0.0&batt=50.0 HTTP/1.1
Host: localhost:5055
Content-Type: application/x-www-form-urlencoded
User-Agent: Dalvik/2.1.0 (Linux; U; Android 9; SM-J260A Build/PPR1.180610.011)
Accept-Encoding: gzip
X-Forwarded-For: [redacted internet IP]
X-Forwarded-Host: [redacted hostname]:5455
X-Forwarded-Server: [redacted hostname]
Content-Length: 0
Connection: Keep-Alivefollowed by:
HTTP/1.1 200 OK
content-length: 0This is the HEX that corresponds to lines 34-37 of the pastebin:
2021-12-27 23:04:06 INFO: [fe6e1d9f: osmand < 0:0:0:0:0:0:0:1] HEX: [redacted]
2021-12-27 23:04:06 INFO: [fe6e1d9f: osmand > 0:0:0:0:0:0:0:1] HEX: [redacted]
107.126.39.33 - - [27/Dec/2021:23:04:06 +0000] "POST /?id=392645×tamp=1640646239&lat=37.xxxx&lon=-78.xxxx&speed=0.0&bearing=0.0&altitude=72.0&accuracy=0.0&batt=50.0 HTTP/1.1" 200 4919 "-" "Dalvik/2.1.0 (Linux; U; Android 9; SM-J260A Build/PPR1.180610.011)"
2021-12-27 23:04:06 INFO: [fe6e1d9f] id: 392645, time: 2021-12-27 23:03:59, lat: 37.xxxx, lon: -77.xxxx, course: 0.0Sorry if there's still some info I'm erasing - I figured that would cover it. Is there something specific you're looking for?
I want to see HEX.
Emailed all of the unredacted output to you just now - But also had the decoded HEX up above.
Are you using standard config? If any changes, please post here.
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE properties SYSTEM 'http://java.sun.com/dtd/properties.dtd'>
<properties>
<entry key='config.default'>./conf/default.xml</entry>
<!--
This is the main configuration file. All your configuration parameters should be placed in this file.
Default configuration parameters are located in the "default.xml" file. You should not modify it to avoid issues
with upgrading to a new version. Parameters in the main config file override values in the default file. Do not
remove "config.default" parameter from this file unless you know what you are doing.
For list of available parameters see following page: https://www.traccar.org/configuration-file/
-->
<entry key='geocoder.enable'>false</entry>
<entry key='database.driver'>org.h2.Driver</entry>
<entry key='database.url'>jdbc:h2:./data/database</entry>
<entry key='database.user'>sa</entry>
<entry key='database.password'></entry>
<entry key='coordinates.maxError'>500</entry>
<entry key='coordinates.filter'>true</entry>
<entry key='database.historyDays'>1</entry>
<entry key='notificator.types'>web,mail,traccar</entry>
<entry key='notificator.traccar.key'>[redacted]</entry>
<entry key='#filter.maxSpeed'>78</entry>
<entry key='status.timeout'>360</entry>
</properties>The #filter.maxSpeed is just my attempt to comment that out - it was part of the troubleshooting.
This is likely the problem:
<entry key='coordinates.maxError'>500</entry>The value is extremely low.
Ah-ha, I didn't realize that filtered locations would still update the timestamp. Seems like a likely path to go down! Thanks!
My intention when I set that a few years ago was to only accept higher accuracy GPS fixes - cell tower based fixes with 1 km uncertainty are useless in my use-case.
SatStat on this device shows 1-4m error. Traccar Client reports accuracy=0.0 in its submissions, but looking at the GPS coordinates it knows exactly where it is. Is accuracy=0.0 high accuracy or low accuracy? If it's high accuracy... Wouldn't 500 (meters per the doc) maxError be fine?
What's the best way to see that filtering is happening?
In any case, disabling maxError appears to have done the trick. And in the Traccar web interface the device shows: "Accuracy: 0.00mi" as expected. But I'm curious why Traccar Client is giving Traccar Server the impression that the error is >500 meters...
When you set coordinates.maxError to 500, it means that if distance from last location to the current one is more than 500 meters, it will reuse coordinates. It is very dangerous configuration and only intended to be used with very high values, mostly to handle obviously wrong coordinates (for example if location suddenly jumps to zero).
Ah-ha. I thought that case was handled by the max speed param. Makes sense. I'll leave these disabled for now and do some searches to see how other people solved the desire to have only accurate datapoints accepted.
Thank you Anton, hope you had a good holiday and a happy New Year!
Apache logs:
But Traccar logs:
I was thinking this was a device issue, as the device had run its battery down at the "old" location a few days ago - but now it's at the "new" location (as shown in Apache logs) but Traccar is still logging these submissions as being at the "old" location.
Things I have tried: