GPS data incorrect
Attached is the GPX file and screenshots of the problem described.
When stationary, the elevation is 210.3 meters. After a few meters of riding on a completely flat stretch, the elevation is 209.8 meters... It's okay that there might be a difference of a few centimeters, but certainly not 50 centimeters after less than 5 meters of riding! And the gradient indication from 0% to -880.3% is completely insane!
How does this happen? My phone is mounted horizontally on the handlebars.
It may be that when I get on/off and tilt the bike, the elevation and gradient data get mixed up, but even during normal riding, acceleration/braking and every bump are apparently recorded in the elevation and gradient data. This shouldn't be allowed. Such brief changes must be filtered out, especially when the elevation data barely changes.
Can I do something about this – in the settings, or is this an algorithm issue that you need to correct?
Greater accuracy for a small price.
The cost of a GNSS (Global Navigation Satellite System) surveyor, or the equipment used, can vary significantly depending on the features, accuracy, and brand. Generally, prices range from a few thousand dollars for basic units to tens of thousands for more advanced systems. For example, a basic GNSS receiver can cost around $2,000, while a high-precision RTK (Real-Time Kinematic) system can cost upwards of $10,000.
Greater accuracy for a small price.
The cost of a GNSS (Global Navigation Satellite System) surveyor, or the equipment used, can vary significantly depending on the features, accuracy, and brand. Generally, prices range from a few thousand dollars for basic units to tens of thousands for more advanced systems. For example, a basic GNSS receiver can cost around $2,000, while a high-precision RTK (Real-Time Kinematic) system can cost upwards of $10,000.
Das mag sein, allerdings liegt das beschriebene Problem nicht an der Anlage oder am Preis, sondern schlicht an der Rechengenauigkeit!
Wenn ich stillstehe – was selbst ein billiges GPS-Telefon erkennt – kann es keinen Höhenunterschied geben! Dann habe ich das Telefon wahrscheinlich einfach an eine andere Stelle gebracht …
Ebenso kann eine Steigung von über 100% NIEMALS korrekt sein! Ebenso kann es, wenn ich mich bewege und die Höhendaten konstant bleiben, nicht sein, dass eine Steigung „erkannt“ wird, nur weil ich über Unebenheiten fahre…
Mit anderen Worten, hier muss der Algorithmus einfach korrigiert werden …
Testweise habe ich nun zusätzlich zur Korrektur auch die Routendaten und barometrischen Daten der GPS-Sensoren verwendet und den Filter auf „hoch“ eingestellt. Vielleicht löst das das Problem – zumindest was die Höhendaten betrifft. Die Steigungsdaten werden offenbar von den Beschleunigungs- und Neigungssensoren des Telefons ausgelesen – womit ich wieder beim Algorithmus wäre … Just reading and displaying 1:1 is not enough.
Das mag sein, allerdings liegt das beschriebene Problem nicht an der Anlage oder am Preis, sondern schlicht an der Rechengenauigkeit!
Wenn ich stillstehe – was selbst ein billiges GPS-Telefon erkennt – kann es keinen Höhenunterschied geben! Dann habe ich das Telefon wahrscheinlich einfach an eine andere Stelle gebracht …
Ebenso kann eine Steigung von über 100% NIEMALS korrekt sein! Ebenso kann es, wenn ich mich bewege und die Höhendaten konstant bleiben, nicht sein, dass eine Steigung „erkannt“ wird, nur weil ich über Unebenheiten fahre…
Mit anderen Worten, hier muss der Algorithmus einfach korrigiert werden …
Testweise habe ich nun zusätzlich zur Korrektur auch die Routendaten und barometrischen Daten der GPS-Sensoren verwendet und den Filter auf „hoch“ eingestellt. Vielleicht löst das das Problem – zumindest was die Höhendaten betrifft. Die Steigungsdaten werden offenbar von den Beschleunigungs- und Neigungssensoren des Telefons ausgelesen – womit ich wieder beim Algorithmus wäre … Just reading and displaying 1:1 is not enough.
Ordinary phone GPS horizontal accuracy is around+/-2m. Vertical accuracy is far worse. Similar for noise/ jitter.
Ordinary phone GPS horizontal accuracy is around+/-2m. Vertical accuracy is far worse. Similar for noise/ jitter.
Thanks for the info. But if that's known, you can take it into account in the calculation.?
Thanks for the info. But if that's known, you can take it into account in the calculation.?
Hi,
The positioning accuracy of standard smartphones is typically around 1 to 2 metres and the height accuracy is between 2 and 5 metres. In urban environments, reflections from buildings can further affect these measurements. The Locus app updates your location every second, but because satellites are constantly moving and atmospheric conditions are constantly changing, your position and altitude can fluctuate even when you're standing still.
I took a look at the gradient issue, but the GPX file you provided is 27 km long, which makes it difficult to locate the specific point showing an 880% gradient. Additionally, I'm unfamiliar with the software shown in your screenshot, so I'm not sure how it calculates the gradient. It's possible that the location remain almost the same while there's a significant change in elevation over a short distance, which could result in such an extreme gradient value. Understanding how the software derives its measurements would help clarify this further.
Regards
Petr
Hi,
The positioning accuracy of standard smartphones is typically around 1 to 2 metres and the height accuracy is between 2 and 5 metres. In urban environments, reflections from buildings can further affect these measurements. The Locus app updates your location every second, but because satellites are constantly moving and atmospheric conditions are constantly changing, your position and altitude can fluctuate even when you're standing still.
I took a look at the gradient issue, but the GPX file you provided is 27 km long, which makes it difficult to locate the specific point showing an 880% gradient. Additionally, I'm unfamiliar with the software shown in your screenshot, so I'm not sure how it calculates the gradient. It's possible that the location remain almost the same while there's a significant change in elevation over a short distance, which could result in such an extreme gradient value. Understanding how the software derives its measurements would help clarify this further.
Regards
Petr
Thanks for the answer.
The gradient value of 880% is at 2 minutes 49 seconds according to the timestamp in the GPS file. However, since I was still stationary, this could only have happened when I got on the bike (because I was leaning towards it). #The software I can use to display this is called Racerender. It doesn't calculate anything – it only displays the values from the GPX file. But THAT'S the fundamental problem. Other software or apps also rely on these values... they would have to be calculated/filtered accordingly when writing.
If you look at the GPX file, you'll see several points where the gradient values go crazy – whenever there are strong vibrations – even though the elevation values are fairly constant.
Basically, all of this has to be taken into account when writing.
If there is no change in location or speed, there can be no difference in elevation or gradient (elevators and cable cars would have a constantly changing elevation over a certain period of time).
If there are strong vibrations during a change in speed that are interpreted as an incline, but the elevation values remain constant and match the route's elevation profile, there can be no change in the incline.
In principle, a gradient of more than 100% is rather questionable.
Thanks for the answer.
The gradient value of 880% is at 2 minutes 49 seconds according to the timestamp in the GPS file. However, since I was still stationary, this could only have happened when I got on the bike (because I was leaning towards it). #The software I can use to display this is called Racerender. It doesn't calculate anything – it only displays the values from the GPX file. But THAT'S the fundamental problem. Other software or apps also rely on these values... they would have to be calculated/filtered accordingly when writing.
If you look at the GPX file, you'll see several points where the gradient values go crazy – whenever there are strong vibrations – even though the elevation values are fairly constant.
Basically, all of this has to be taken into account when writing.
If there is no change in location or speed, there can be no difference in elevation or gradient (elevators and cable cars would have a constantly changing elevation over a certain period of time).
If there are strong vibrations during a change in speed that are interpreted as an incline, but the elevation values remain constant and match the route's elevation profile, there can be no change in the incline.
In principle, a gradient of more than 100% is rather questionable.
The GPX file does not directly include gradient data—it contains only location coordinates (latitude and longitude) and elevation values. As I expected earlier, there’s no movement around the timestamp 2:49, although the elevation changes slightly by approximately 10 centimeters. Racerender must calculate gradient based on these values. Therefore, the question is whether Racerender should implement logic to account for situations where movement is absent but elevation varies.
>If there is no change in location or speed, there can be no difference in elevation or gradient
There are various use cases, and some users specifically require precise raw values in the GPX file. For this reason, we’re unable to implement your suggestion, as it would complicate the experience for other Locus users.
Thanks for understanding
Regards
Petr
The GPX file does not directly include gradient data—it contains only location coordinates (latitude and longitude) and elevation values. As I expected earlier, there’s no movement around the timestamp 2:49, although the elevation changes slightly by approximately 10 centimeters. Racerender must calculate gradient based on these values. Therefore, the question is whether Racerender should implement logic to account for situations where movement is absent but elevation varies.
>If there is no change in location or speed, there can be no difference in elevation or gradient
There are various use cases, and some users specifically require precise raw values in the GPX file. For this reason, we’re unable to implement your suggestion, as it would complicate the experience for other Locus users.
Thanks for understanding
Regards
Petr
Okay, I understand. This is a big problem, because even Kinomap can't synchronize correct elevation and gradient data with the video to the GPX data.
Unfortunately the GPS data captured by the camera and incorporated into the video is also incorrect. I had hoped it would be better via LM.
I just find it strange that different devices have the same problem...
Okay, I understand. This is a big problem, because even Kinomap can't synchronize correct elevation and gradient data with the video to the GPX data.
Unfortunately the GPS data captured by the camera and incorporated into the video is also incorrect. I had hoped it would be better via LM.
I just find it strange that different devices have the same problem...
In addition to the correction, I also used the route data and barometric data from the GPS sensors and set the filter to "high." This at least eliminated the occasional sudden elevation changes. The elevation profile now corresponds to reality. A partial success ;)
In addition to the correction, I also used the route data and barometric data from the GPS sensors and set the filter to "high." This at least eliminated the occasional sudden elevation changes. The elevation profile now corresponds to reality. A partial success ;)
Replies have been locked on this page!