Calculation error? Measurement inaccuracy?

Arpad Orfi shared this problem 2 years ago
Solved

How comes that the average speed during track recording is 6.5 km/h despite both current and maximum speed is below that?

Are some of these values coming directly from the sensors, while other values are calculated by Locus?


If later I apply “fill altitude” at track editing, are these anomalies corrected for this track or not?

Comments (9)

photo
1

Good day Arpad,


this is really interesting. Is it possible for your to export and share your recorded track? I will hope that reimported track on my own device wiill have same problem, so I'll be able to simulate it and fix it. Thank you

photo
1

Hi Menion,


I’ve deleted that track because it was only an experiment for me; I just wanted to try out some features of Locus.

The track was very short, approx. 50 meters long. The problem occurred in the first 10-30 seconds of recording.


Could the reason be that at starting recording a track the initial accuracy of GPS data is lower, hence there could be some track point jumps at the beginning?


Until I can record another erroneous track (no guarantee for this) you could think about if some of these values are coming directly from the sensors, while other values are calculated by Locus?


You could also try to start recording a track and keep the recording panel displayed and constantly watching the various speed values.

If you would encounter similar problem, then you also could later apply “fill altitude” at track editing to check whether the false numbers corrected for the track or not.


If you are unable to reproduce this problem at first, you could try to delete A-GPS data and turn off data access (and change location) to force the GPS unit to rely only on satellites – this way maybe it would be easier to verify if the cause of the problem is not accurate GPS data, i.e. jumping track points…


Or maybe try to record a track at a place where GPS signal is not so strong, e.g. in a gorge or under some concrete ceiling…


But anyway, if I can reproduce this, I will send you the erroneous track record.


Thanks.

photo
2

First, one has to realize the processing noisy data provides noisy output. Different ways of processing provides different noisy output. Correctness or errorneousness of calculation is not directly related to if these 2 outputs fits each other or not. In some scenarios more similar values mean bigger error, as if processed differently, they should not be the same.

Fill altitude can fix GPS altitude noise by SRTM altitude replacement. But it cannot fix GPX position noise.

Also, immediate speed ( either by GPS subsystem either by Locus ) probably uses much stronger position noise fiiltering ( giving lower speed ) than processing of recorded track, from which the avg speed is probably calculated.

50 meters long and first 30 seconds looks like slow motion where position noise is much stronger then signal of the trend. One should not expect number would match nicely....

photo
1

Hello Libor.

Wow. Such a sound and rational comment again, just as this one, thanks again for it: http://help.locusmap.eu/topic/plan-route-and-navigate-on-hiking-trails


Back to the topic of measurement and calculation of various values.

Main question could be that whether there are steps that Menion should consider to take in order to let Locus (measurement/calculation accuracy) be more reliable and precise, in general.


If changing the main manners of how Locus calculates the various numbers is not to be considered by Menion, then maybe allowing the user to choose from Settings how should Locus calculate those numbers would be desirable…

I’m not sure if this make sense… but I even don’t know how Locus calculates these numbers, and to what extent one would face measurement or calculation errors via the “GPS subsystem” or via Locus’ own calculations…


The main goal should be to eliminate these errors as much as possible.

photo
2

The main goal is balancing of wiping of noise and creation of artefacts.


E.g. The raw recorded track has longer passed distance and bigger elevation ascend than real ones, due GPS noise. But any attempt to eliminate all this noise would be a big mistake,

as it would cause severe damage to data. The track and elevation profile would get oversmoothed, distance would be smaller than real one and filtered elevation ascend smaller than real one. The proper filtering level is the level, wher increasing filter strength starts to provide less smoothing gain. As noise is almost fitered out, while track features become being smoothed.


The avg speed can be easily higher than max speed, if they are evaluated over different distance, as consequence of different filtering of the same raw data.


The current speed HAS to use STRONG filtering of position serie, shortening the effective distance, otherwise it would be jumpy and useless. For walking speeds it may have to use even destroying level of filtering to get anything usable.


To get avg speed consistent with max speed, they have to use similar filtering level, what may not be desirable.


The serving of max and immediate/max speed to their purposes is IMHO more important then if they consistently fit each other. If they are to fit each other, then either track may be oversmoothed for avg speed, either immediate speed is undersmoothed for realtime monitoring.


Additionally, if current speed is provided by GPS, Locus does not know its filtering algorithm. As inevitable consequence, the track distance calculated by Locus will differ from distance based on current speed integration. The result will be that avg speed MAY exceed max speed, as each of them would belong to different distances.

photo
1

Thanks for your additional comment.

I start to understand where these inconsistencies might come from.

The one thing that still puzzles me is who calculates these 3 values:

  • Current speed
  • Maximum speed
  • Average speed


Do you have a guess for all three?

Based upon what you write, I got it that the current speed is reported by the “GPS subsystem”. But I would assume that both maximum and average speed are calculated by Locus. Both of them. So how come that avg. speed may exceed max. speed?

I just can’t understand this.

photo
2

IMHO, max speed is max of set of current speeds. While current speed I suppose is a result of Kalman filtering of Gps, or strong filtering by Locus, but speed is result by medium filtering of the recorded track by Locus.

As consequence, there are 2 different distances, so max speed of one can be smaller than avg speed of the other.


Priority for current ( and max as derived) speed is smoothness,

While for avg speed is no oversmoothing.

photo
photo
1

Menion,


You have asked for it, so here it is.

An example showing that average speed might exceed maximum speed, which is perplexing.

I’ve attached the track file in .zip and 2 screenshots. The first screenshot is before, the second is after “Fill elevation”.


The reason for this phenomenon is clear, based upon what Libor have written above; Locus calculates the average speed based upon track length and time. It’s good that Locus itself calculates the average speed.


However, Locus does not calculate the maximum speed – Locus instead readily accepts the maximum speed value reported by the GPS device, or the “GPS subsystem” as Libor refers to it.

This behavior is not so good.

I think it would be more prudent if Locus itself would calculate the maximum speed, too.

That would be a more correct representation of the reality, regardless of the general reliability of the GPS.

I suppose if a measured (by the GPS device) maximum speed is not maintained through at least two adjacent track points, then it must be an outlier that is a result of a measurement error.


So Locus could and should calculate the maximum speed for the whole track examining all adjacent track points throughout the whole track. Probably in real time, but at least when saving the track.


I have to add that there might be cases when the GPS device reports false, erroneous values about speed and hence about maximum speed.

This is not the fault of Locus, but it would be a mistake of Locus not to correct an error that could be corrected by it.


Related remarks:

The other day when I tried to reproduce this error I closely watched the speed values of my phone, and it astounded me that my device reported 7.4 km/h as my speed while I was standing still. When I started to walk, the reported speed went up to approx. 9-10 km/h, since I was moving. Then I stopped, and the speed went back to 7.4 km/h.

Then I restarted the phone, afterwards the reported speed value was OK, i.e. 0 km/h when standing.

Anyway, I don’t know whether this has to do anything with GPS Status & Toolbox, which I have installed on my phone, but this is not the point.


The point is, Locus is capable of correcting the average speed value even if the values reported by the GPS are erroneous – and in fact it corrects it.

Just like correcting this, Locus should correct the maximum speed value by calculating it itself. By default. Or at least make this a user setting – although I can’t imagine anyone who would be better off with inaccurate GPS data…


Additional question that I’d like to get an answer to,

to Libor or anyone competent about First fix, A-GPS data, enabled network location, "Use Wi-Fi Networks / Cell towers", "High accuracy" and GPS Status & Toolbox:

http://help.locusmap.eu/topic/first-fix-a-gps-data-enabled-network-location-use-wi-fi-networks-cell-towers-high-accuracy


Many thanks,

Arpad

photo
2

Hello guys,


quite nice and long discussion. It looks I'll have to really soon hire Libor to optimize huge number of my own filters and algorithms I made in Locus over years ( I never studied any filtering methods, so most of them are just my own creations ... and well, they +- work :) ).


Funny thing: just during Thursday/Friday, I've implemented new system that compute burned calories and I needed a speed. Because of this I already changed compute of max speed to be based just on dist/time, directly in Locus. So consider this issue as fixed. Distance is computed from measured locations and these are not currently filtered. Anyway average and max speeds should match each other now.


Current speed is just an average speed over last 60 seconds with small filtering.


Thanks for nice discussion.