Hi,
My question is related to a strange behavior in recorded track for elevation values (set in Point to point mode).
It seems a growing "offset" is added through the recording time and it reset after pause recording.
It results a highest altitude after few hours of recording (about +10m every hour, seen on every tracks for july and august hikes)
In my example, I've been recording for five hours to a submit at 3630m
Is that a bug related to Altitude calculation algorithm?
OruxMaps v10.1.9GP on Xiaomi Mi 8 (dual-frequency GPS GALILEO GNSS - "Force full GNSS measurements" activated in Developer options
Many Thx for your feedbacks!
My question is related to a strange behavior in recorded track for elevation values (set in Point to point mode).
It seems a growing "offset" is added through the recording time and it reset after pause recording.
It results a highest altitude after few hours of recording (about +10m every hour, seen on every tracks for july and august hikes)
In my example, I've been recording for five hours to a submit at 3630m
- 3618m Sonny's LiDAR DTM 1"
- 3628m my Garmin watch (dual-frequency GPS GALILEO GNSS)
- 3683m before stopping recording
- 3627m after restarting recording (10 minutes after, same position for sure
)
Is that a bug related to Altitude calculation algorithm?
QuoteSince 8.2, we have two different algorithms to calculate altitude differences. It can be selected in global configuration - Tracks -> Altitude calculation algorithm:Can you give us some more detail about algorithm method / computation done for the two algorithms?
a) Point to point. It is the preferable in general. It should work better with very bad GPS calculating altitudes, or on flat terrain.
b) Threshold difference. Perhaps it works best in mountainous terrain, and with GPS that measure the most accurate altitude.
OruxMaps v10.1.9GP on Xiaomi Mi 8 (dual-frequency GPS GALILEO GNSS - "Force full GNSS measurements" activated in Developer options
Many Thx for your feedbacks!
