Sudden jumps in position due to GPS device error, its effect to Traccar Server
A followup... I believe, and I'll have to look at the raw GPS data to confirm, that the anomalous report 'jump' data contains the 'GPS position Valid' flag set.
I would recommend to create a feature request on GitHub.
If validity flag is set to "true", then it's not possible to use existing filtering.
I don't have a GitHub account. Could you cut and paste my OP into a feature request there?
Created GitHub thread:
Hi Marc, I've had similar situations like that, but i solved it on devices with a command with a drift suppression command [suppress12345], which in turn disables drift on the tracking device.
Hi Peter. I think what you're referring to is different problem to the situation I've described.
Correct me wrong you're describing random errors in location accuracy, goes unnoticed while the unit is moving, but especially noticeable when the GPS unit remains stationary. It shows up as a random scribble around a central point appearing as vectors of random angles and distances from a central focal point. As you say this can be easily dealt with by issuing the GPS103 device the suppress123456 command via SMS. What suppress123456 does is command the unit to repeatedly send a duplicate of a fixed position report each time, until the unit has traveled beyond a preset distance from that point and then uses that instead. If you look closely at your track you'll see in practice the unit appears to 'freeze' in a nearby location on route to where it actually stopped, along with the speed had been doing on the last report which is continually repeated. The suppress123456 command is similar function to the server's own filter.distance function.
The main identifiers of each these two anomalies is:
looks like a scribble random angles and distances around a central focal point (GPS accuracy error), fixed by suppress
a random occurring horizontal OR vertical jump, typically lasting one report (caused by a numerical error or corruption or something)
I'm not sure how the suppress123456 command could solve the number 2. anomaly, though I would expect the presence of both anomalies working in combination with eachother would indirectly fix the undesired side effect of the suppress123456 command ('freezing' on route to stop point), by forcing the device to use an updated location nearer to its actual stop point.
EDIT: This theory above paragraph could be tested by hooking up a terminal program (such as Windows Hyperterm) to spoof the tracker signal and manually sending to the Traccar server a one-off specially crafted position report of a few 1000 miles offset location. You'd expect to see the offset error eliminated and the falsely reported speed return to zero.
http://i678.photobucket.com/albums/vv144/markrbarker/jump.gif
Here's the raw data of one of these anomalies, from tracker_server.log file I've converted the hex to ascii
Nominal condition:
2017-04-20 09:27:08 DEBUG: [B69DD2B2: 11675 < 82.132.242.152] HEX:
imei:359710040103591,tracker,1704200926,,F,082652.000,A,5152.9067,N,00025.4502,W,20.58,297.15;
2017-04-20 09:27:08 INFO: [B69DD2B2] id: 359710040103591, time: 2017-04-20 09:26:52, lat: 51.88178, lon: -0.42417, speed: 20.6, course: 297.2Anomaly condition: (sudden jump several 1000s miles)
2017-04-20 09:27:37 DEBUG: [B69DD2B2: 11675 < 82.132.242.152] HEX:
imei:359710040103591,tracker,1704200927,,F,082721.000,A,153.0064,N,00025.5761,W,16.29,326.78;
2017-04-20 09:27:38 INFO: [B69DD2B2] id: 359710040103591, time: 2017-04-20 09:27:21, lat: <strong>1.88344</strong>, lon: -0.42627, speed: 16.3, course: 326.8Putting the two above reports raw hex together, you can see exactly what's gone wrong, on the anomalous report there's a byte missing.
696d65693a3335393731303034303130333539312c747261636b65722c313730343230303932362c2c462c3038323635322e3030302c412c353135322e393036372c4e2c30303032352e343530322c572c32302e35382c3239372e31353b
696d65693a3335393731303034303130333539312c747261636b65722c313730343230303932372c2c462c3038323732312e3030302c412c3<em>135332e303036342c4e2c30303032352e353736312c572c31362e32392c3332362e37383b</em>It's likely the device had sent valid data, the valid flag was set, it looks very much like a byte was dropped.
If the server could filter out this anomalous report, using a filter.distance.max function of some sort, that would be good.
I have already implemented a filtering that should solve the problem. Basically you will be able to set max speed value (calculated from distance and time).
Filter messages >speed is a much neater solution than would be my suggestion filter messages >distance. I set speed threshold to double the unit's maximum possible speed. Then I'm sure that would solve the issue.
Is this documented yet in https://www.traccar.org/configuration-file/?
At the time of writing this the nearest I can find is the key speedLimit to me this looks related to event.overspeedHandler , not related to a filter.
The functionality will be available with next release. There will be a new config parameter "filter.maxSpeed".
Marc,
Have you been successful at using “filter.maxSpeed”? It does not seem to filter out any data for me. Even setting filter.maxSpeed to 0 does not work. In theory I should not be seeing any data from moving objects on the map with this value set to 0.
Are you using version 3.13? Have you enabled filtering?
Hi Anton,
I see this in my log when I start the server. I'm assuming Version: 3.12-SNAPSHOT is actually 3.13?
And my traccar.xml has this filtering below. I'm only using "0" value just to test if it'll work at all but I don't see any effect.
<entry key='filter.enable'>true</entry>
<entry key='filter.maxSpeed'>0</entry>
2017-07-11 13:20:12 INFO: Operating system name: Linux version: 2.6.32-042stab120.16 architecture: amd64 2017-07-11 13:20:12 INFO: Java runtime name: OpenJDK 64-Bit Server VM vendor: Oracle Corporation version: 25.131-b11 2017-07-11 13:20:12 INFO: Memory limit heap: 1365mb non-heap: 0mb 2017-07-11 13:20:12 INFO: Character encoding: UTF-8 charset: UTF-8 2017-07-11 13:20:12 INFO: Version: 3.12-SNAPSHOT 2017-07-11 13:20:16 INFO: Starting server...
Zero value means disabled. Don't use it. Use some positive number.
A GPS device such as GPS-103 can and occasionally does report bad coordinates. Some IMEI number range devices do it more than others. It's usually seen as a sudden horizontal or vertical straight line 'jump' across the map, and then returning again to normal on the next report. Either the latitude or the longitude affected by a numerical error.
The negative implications are total distance counters become inaccurate and will also trigger the server to issue premature 'maintenance alerts', because of a sudden jump of a few thousand miles. During the anomaly the unit may appear to have exceeded the speed of light, or at the least appeared to have traveled many times faster than the speed the vehicle could possibly ever attain.
Nothing much can be done with the GPS device to eliminate these random events, so dealing with them at the server would be the way. Fortunately the random anomaly only appears on a single isolated position report, and very seldom ever appears more than two consecutive reports.
There is already a filter.distance function available on the Traccar server but this operates in reverse to would be desired.
What is needed perhaps is a filter.distance.max function which works the opposite way and tells the server to ignore any reports which has a distance greater than the last report by the value in meters.
Care would be needed using this because undesired filtering would occur when the unit exceeds a certain speed and a report rate places the vehicle further than the distance filter threshold. However, a typical anomaly places the unit a very large distance away, further than it could had reached before the next report.