Erroneous speed data in track record graph
In the first part of the graph that shows my speed during my walking tour, the graph shows 8 km/h speed, which is excessive, and I know for sure that I didn’t walk so fast.
:-)
After a given point, the graph shows real values for speed.
I’m not sure what the cause of this problem is, but I have a guess.
I’ve selected the command: “Fill elevation”, because I have downloaded all the .HGT elevation data beforehand, maybe 6-8 months ago. (On a side note, this is necessary, because GPS-based calculation of uphill/downhill is largely excessive, so I don’t understand why Locus doesn’t have an option to automatically extract elevation data from .HGT files in case those files are present for the relevant area.)
So my first guess would be that there could be a difference in resolution in the .HGT file between parts of the track. (Anyway, I haven’t had a look at the chart before choosing “Fill elevation” so I can’t confirm that this is the cause of the problem occurring.)
I’ve used the paid Locus vector map about Hungary, it that matters. Could be there differences in resolution in that vector map, i.e. e.g. 1:15.000 resolution in built-in areas of Budapest and e.g. 1:30.000 resolution in rural areas? (I’ve started track recording within Budapest, then have left it during the tour.)
If you want me to upload the track file, please let me know exactly where I can find the file on my Android 4.3 phone.
Thanks.
Do you want me to also send you a screenshot of the graph displaying the false data?
All the best,
Cheers!
The same problem 
Don't worry, I'm sure of my competence, however, I consulted this with my colleague Peter and he says the same. Anyway, does this issue occur frequently? Can you repeat the problem? You say that the speed value was doubled only in part of your track - if there was a calculation malfunction, it would consider whole track wouldn't it? Therefore we're quite sure the mistake was in the data Locus acquires from HW sensors.
Don't worry, I'm sure of my competence, however, I consulted this with my colleague Peter and he says the same. Anyway, does this issue occur frequently? Can you repeat the problem? You say that the speed value was doubled only in part of your track - if there was a calculation malfunction, it would consider whole track wouldn't it? Therefore we're quite sure the mistake was in the data Locus acquires from HW sensors.
Hi,
the problem is most probably caused by the phone GPS and inaccuracy of its speed measurement. That can be caused by many factors - weather, limited view of the sky etc. when GPS tries to fix the position and "jumps" around your real position. These jumps can make several tens of meters in a while and that may increase the speed average in your chart.
Hi,
the problem is most probably caused by the phone GPS and inaccuracy of its speed measurement. That can be caused by many factors - weather, limited view of the sky etc. when GPS tries to fix the position and "jumps" around your real position. These jumps can make several tens of meters in a while and that may increase the speed average in your chart.
Please consider all the other ideas that I’ve represented.
I’m sure about that it is not caused by GPS error.
The erroneous state lasted for maybe 10-20-30 minutes, and for that time period the speed was CONSTANTLY the double of our real speed.
Then all of a sudden, the speed chart shows the real values from then on, until the end of our trip.
On the first part, during the erroneous state, there were no jumping in the speed values, I repeat: constant double values.
Also the track is not plotted on the map as if the GPS position was jumping.
There were no problems with the GPS accuracy – and I have never have with this phone – anyway, it is impossible, because it is A-GPS, and acquires the exact position within 5 seconds all the time. I have never had any problems of the sort you’ve mentioned.
Please consider that this might be caused by differences in resolution in the .HGT files and/or the map file itself.
Read again my previous comment for clues/ideas.
I ask again: would it help you if I would send the track log file? Maybe the .HGT files themselves?
If yes, then please tell me exactly how I can attach it.
Best,
Arpad
Please consider all the other ideas that I’ve represented.
I’m sure about that it is not caused by GPS error.
The erroneous state lasted for maybe 10-20-30 minutes, and for that time period the speed was CONSTANTLY the double of our real speed.
Then all of a sudden, the speed chart shows the real values from then on, until the end of our trip.
On the first part, during the erroneous state, there were no jumping in the speed values, I repeat: constant double values.
Also the track is not plotted on the map as if the GPS position was jumping.
There were no problems with the GPS accuracy – and I have never have with this phone – anyway, it is impossible, because it is A-GPS, and acquires the exact position within 5 seconds all the time. I have never had any problems of the sort you’ve mentioned.
Please consider that this might be caused by differences in resolution in the .HGT files and/or the map file itself.
Read again my previous comment for clues/ideas.
I ask again: would it help you if I would send the track log file? Maybe the .HGT files themselves?
If yes, then please tell me exactly how I can attach it.
Best,
Arpad
Dear Arpad,
of course I read your inquiry very carefully and considered your ideas. Kind of map or downloaded HGT files don't have any influence on the actual speed measurement - that is processed by your phone system and its sensors.
Dear Arpad,
of course I read your inquiry very carefully and considered your ideas. Kind of map or downloaded HGT files don't have any influence on the actual speed measurement - that is processed by your phone system and its sensors.
Well, I can’t really say anything, if you are ABSOLUTELY SURE that this error is outside of Locus.
I’m not an Android expert, so I’m just a layman.
These are solely my thoughts on the matter, so I might be wrong:
I suppose the phone (Android 4.3 Sony Xperia SP) can’t measure speed.
The phone is able to measure only position through the GPS.
I suppose the calculation of the speed is the task of the particular software, be it Google Maps, Sygic or Locus.
How is that possible that the track is without error, so there is no any whipsaw or jumping – it’s as straight as we were going.
v = s/t
Locus knows s, i.e. distance – this can be seen on the track displayed on the map. It is without error.
Locus also knows t, i.e. time – this can be checked on the track statistics.
Based upon what you say, Locus doesn’t use the data it knows for calculation; instead, it gets data from outside, from the hardware.
Even if this is the real case, it’s kind of strange that THERE ARE NO JUMPS IN THE SPEED VALUES, so it’s not like 7 km/h and then 2 km/h and then 6.5, 8, 3, 8.5, 3 etc. No, it’s continuously around 7-8 km/h, so double of our real speed.
I only would be totally OK with your answer if you would double check this whole matter with at least one other competent person.
Thanks in advance.
I attach the gpx track file in a zip.
Very strange this matter is, really.
Well, I can’t really say anything, if you are ABSOLUTELY SURE that this error is outside of Locus.
I’m not an Android expert, so I’m just a layman.
These are solely my thoughts on the matter, so I might be wrong:
I suppose the phone (Android 4.3 Sony Xperia SP) can’t measure speed.
The phone is able to measure only position through the GPS.
I suppose the calculation of the speed is the task of the particular software, be it Google Maps, Sygic or Locus.
How is that possible that the track is without error, so there is no any whipsaw or jumping – it’s as straight as we were going.
v = s/t
Locus knows s, i.e. distance – this can be seen on the track displayed on the map. It is without error.
Locus also knows t, i.e. time – this can be checked on the track statistics.
Based upon what you say, Locus doesn’t use the data it knows for calculation; instead, it gets data from outside, from the hardware.
Even if this is the real case, it’s kind of strange that THERE ARE NO JUMPS IN THE SPEED VALUES, so it’s not like 7 km/h and then 2 km/h and then 6.5, 8, 3, 8.5, 3 etc. No, it’s continuously around 7-8 km/h, so double of our real speed.
I only would be totally OK with your answer if you would double check this whole matter with at least one other competent person.
Thanks in advance.
I attach the gpx track file in a zip.
Very strange this matter is, really.
Well, I can’t really say anything, if you are ABSOLUTELY
SURE that this error is outside of Locus.
I’m not an Android expert, so I’m just a layman.
.
These are solely my thoughts on the matter, so I might be
wrong:
I suppose the phone (Android 4.3 Sony Xperia SP) can’t
measure speed.
The phone is able to measure only position through the
GPS.
I suppose the calculation of the speed is the task of the
particular software, be it Google Maps, Sygic or Locus.
.
How is that possible that the track is without error, so
there is no any whipsaw or jumping – it’s as straight as we were going.
.
.
v = s/t
Locus knows s, i.e. distance – this can be seen on the
track displayed on the map. It is without error.
Locus also knows t, i.e. time – this can be checked on
the track statistics.
.
Based upon what you say, Locus doesn’t use the data it
knows for calculation; instead, it gets data from outside, from the
hardware.
Even if this is the real case, it’s kind of strange that
THERE ARE NO JUMPS IN THE SPEED VALUES, so it’s not like 7 km/h and then 2 km/h
and then 6.5, 8, 3, 8.5, 3 etc. No, it’s continuously around 7-8 km/h, so
double of our real speed.
.
I only would be totally OK with your answer if you would
double check this whole matter with at least one other competent person.
.
.
Thanks in advance.
.
I attach the gpx track file in a zip.
Very strange this matter is, really.
Well, I can’t really say anything, if you are ABSOLUTELY
SURE that this error is outside of Locus.
I’m not an Android expert, so I’m just a layman.
.
These are solely my thoughts on the matter, so I might be
wrong:
I suppose the phone (Android 4.3 Sony Xperia SP) can’t
measure speed.
The phone is able to measure only position through the
GPS.
I suppose the calculation of the speed is the task of the
particular software, be it Google Maps, Sygic or Locus.
.
How is that possible that the track is without error, so
there is no any whipsaw or jumping – it’s as straight as we were going.
.
.
v = s/t
Locus knows s, i.e. distance – this can be seen on the
track displayed on the map. It is without error.
Locus also knows t, i.e. time – this can be checked on
the track statistics.
.
Based upon what you say, Locus doesn’t use the data it
knows for calculation; instead, it gets data from outside, from the
hardware.
Even if this is the real case, it’s kind of strange that
THERE ARE NO JUMPS IN THE SPEED VALUES, so it’s not like 7 km/h and then 2 km/h
and then 6.5, 8, 3, 8.5, 3 etc. No, it’s continuously around 7-8 km/h, so
double of our real speed.
.
I only would be totally OK with your answer if you would
double check this whole matter with at least one other competent person.
.
.
Thanks in advance.
.
I attach the gpx track file in a zip.
Very strange this matter is, really.
Don't worry, I'm sure of my competence, however, I consulted this with my colleague Peter and he says the same. Anyway, does this issue occur frequently? Can you repeat the problem? You say that the speed value was doubled only in part of your track - if there was a calculation malfunction, it would consider whole track wouldn't it? Therefore we're quite sure the mistake was in the data Locus acquires from HW sensors.
Don't worry, I'm sure of my competence, however, I consulted this with my colleague Peter and he says the same. Anyway, does this issue occur frequently? Can you repeat the problem? You say that the speed value was doubled only in part of your track - if there was a calculation malfunction, it would consider whole track wouldn't it? Therefore we're quite sure the mistake was in the data Locus acquires from HW sensors.
OK, thanks.
Now I will ditch this stupid brick into the toilet.
:-)
Anyway, this was the first and only issue of this sort.
Yeah, only the first part of the track.
Mysterious thing.
Thanks for your time.
Best.
OK, thanks.
Now I will ditch this stupid brick into the toilet.
:-)
Anyway, this was the first and only issue of this sort.
Yeah, only the first part of the track.
Mysterious thing.
Thanks for your time.
Best.
Yep, mysterious things sometimes happen in Android devices (and not only them) :). Have a nice day!
Yep, mysterious things sometimes happen in Android devices (and not only them) :). Have a nice day!
I went on a similar route, but this time the problem didn’t occur.
So I’ve tried to reproduce the problem, but I couldn’t. This is good.
Regardless, let me ask:
Wouldn’t it be a better representation of the real speed data if Locus itself would calculate it from distance (track points) and time?
E.g. one can alter the track, one can delete track points, especially if one took a walk or a ride in a narrow gorge between rocks, where the GPS signal is weak and your position jumps all over the place. I assume this could mean a false speed report from the HW.
But if Locus would calculate the speed, then after deleting the false location/track points from the track, Locus could simply calculate the speed from the distance between the track points and the time elapsed between those points.
Would be there any drawbacks of such an internal calculation instead of readily accept whatever data is reported by HW sensors?
I went on a similar route, but this time the problem didn’t occur.
So I’ve tried to reproduce the problem, but I couldn’t. This is good.
Regardless, let me ask:
Wouldn’t it be a better representation of the real speed data if Locus itself would calculate it from distance (track points) and time?
E.g. one can alter the track, one can delete track points, especially if one took a walk or a ride in a narrow gorge between rocks, where the GPS signal is weak and your position jumps all over the place. I assume this could mean a false speed report from the HW.
But if Locus would calculate the speed, then after deleting the false location/track points from the track, Locus could simply calculate the speed from the distance between the track points and the time elapsed between those points.
Would be there any drawbacks of such an internal calculation instead of readily accept whatever data is reported by HW sensors?
Hello Michal,
Maybe you've missed my above post, so I just ping this to get some response.
Thanks.
Hello Michal,
Maybe you've missed my above post, so I just ping this to get some response.
Thanks.
HI Arpad,
you do like chatting don't you? ;) I discussed your problem with Menion and he said Locus interferes with the speed calculation only in extreme situations when the values from the HW sensors are complete nonsense (and obviously it didn't assessed this situation this way). The reason is saving CPU capacity > battery consumption.
HI Arpad,
you do like chatting don't you? ;) I discussed your problem with Menion and he said Locus interferes with the speed calculation only in extreme situations when the values from the HW sensors are complete nonsense (and obviously it didn't assessed this situation this way). The reason is saving CPU capacity > battery consumption.
No, actually I don’t like chatting at all (I prefer email-like conversations), but I got your point.
:-)
Ah, I see – battery consumption is a valid aspect.
Maybe this (speed data would be calculated by Locus itself) could be a setting (option to set by the user)?
Even if not (for now), then please consider this idea for the time when other users might also complain about inaccurate speed data, OK?
No, actually I don’t like chatting at all (I prefer email-like conversations), but I got your point.
:-)
Ah, I see – battery consumption is a valid aspect.
Maybe this (speed data would be calculated by Locus itself) could be a setting (option to set by the user)?
Even if not (for now), then please consider this idea for the time when other users might also complain about inaccurate speed data, OK?
That's exactly what we do since the very beginning of developing Locus - considering our users' ideas. And therefore we have this voting system - a user proposes an improvement - others vote for it. When an idea gets many votes, Menion considers its implementation. When it doesn't, the idea is declined.
That's exactly what we do since the very beginning of developing Locus - considering our users' ideas. And therefore we have this voting system - a user proposes an improvement - others vote for it. When an idea gets many votes, Menion considers its implementation. When it doesn't, the idea is declined.
Replies have been locked on this page!