This object is in archive! 
Calculation error? Measurement inaccuracy?
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?
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
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
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.
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.
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....
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....
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
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
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.
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.
Replies have been locked on this page!