Location "stuck" - Traccar server logging old location while Apache logs show latest?

OverkillTASF3 years ago

Apache logs:

107.126.39.1 - - [27/Dec/2021:21:33:22 +0000] "POST /?id=392645×tamp=1640640802&lat=37.xxxxxxx&lon=-78.xxxxxxx&speed=0.0&bearing=0.0&altitude=65.0&accuracy=0.0&batt=53.0 HTTP/1.1" 200 4919 "-" "Dalvik/2.1.0 (Linux; U; Android 9; SM-J260A Build/PPR1.180610.011)"

But Traccar logs:

2021-12-27 21:33:22  INFO: [87670afa] id: 392645, time: 2021-12-27 21:33:22, lat: 37.xxxxx, lon: -77.xxxxx, course: 0.0

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:

  • Reinstalling on the device
  • Changing Traccar ID on the device and on the traccar interface
  • Disabling maxspeed filtering.
  • Setting max history to 1 day (it has been more than 24 hours since the device was last at the "old" location)
Anton Tananaev3 years ago

Please provide more info from Traccar logs.

OverkillTASF3 years ago

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.
Anton Tananaev3 years ago

You redacted the most important information.

OverkillTASF3 years ago

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-Alive

followed by:

HTTP/1.1 200 OK
content-length: 0

This 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.0

Sorry if there's still some info I'm erasing - I figured that would cover it. Is there something specific you're looking for?

Anton Tananaev3 years ago

I want to see HEX.

OverkillTASF3 years ago

Emailed all of the unredacted output to you just now - But also had the decoded HEX up above.

Anton Tananaev3 years ago

Are you using standard config? If any changes, please post here.

OverkillTASF3 years ago
<?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.

Anton Tananaev3 years ago

This is likely the problem:

<entry key='coordinates.maxError'>500</entry>

The value is extremely low.

OverkillTASF3 years ago

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...

Anton Tananaev3 years ago

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).

OverkillTASF3 years ago

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!