Altitude (from GPS) optimizations

jusc · May 15, 2013, 20:25:00

As far as I can see, other devices have the same problem. In the German Naviboard you can read this :
http://www.naviboard.de/vb/showthread.php?t=51647 about the Garmin 62s. The result: They are not very happy with it in addition of the altitude.

Menion · May 17, 2013, 20:43:32

that's what I think, that there is no general method with specified parameters. But as I wrote ... give me at least five various tracks with some results you want to see and I'll gladly spend time on this and improve Locus to match some middle ...

Christian · May 24, 2013, 22:18:33

Hi guys,
sorry for any delay. I was offline and mountainbiking for 2 weeks :-)

I would like to separate the problem:

1: get correct(ed) elevation data during recording
2: computation of uphill / downhill / flat section of a recorded / downloaded track and got elevation values from STRM files

for 1 i have no idea.
for 2 i think its the best to use a simple methode like this:
ele point A + ele point B - ele point C(if C is smaller than B)

I guess with SRTM files we have all we need....
@menion: is it too simple?

I would like to avoid using philosophy of other devices in Locus.
Christian

Menion · May 25, 2013, 11:28:25

hmm wait,

I thought that step 1. is already done. For this exist Altitude manager where you have various methods how to "improve" measured altitude. If you enable "Optimize GPS altitude" in Altitude manager, then Locus will use SRTM files to correct a little measured altitude. So I think point 1 is done, isn't it?

Point 2 is what I want to discuss now. You wrote "avoid using philosophy of other devices in Locus", but I don't want to use system of any other device. Whole this discussion started by "Hey menion, this recorded track has in locus elevation 900m, but in garmin it has only 600m" right? And what I want, is to have 5 - 10 GPX tracks where for every track I'll have values you would like to see in Locus.

So for example
- these 3 tracks from BaseCamp display these values ....
- these 3 tracks from GPSies display ...
- these 3 tracks ...

so in the end, I should optimize Locus to compute elevation that will fit to these values (values you expect) as much as possible. I should do it by myself, but all my recorded tracks has elevation +- 100, because it's really flat around Prague and also I'm still sitting on but at home

So if you may send me few high-hill tracks also with values you see in your favorite program (except Locus

), I'll gladly do improvements. And if you do it today, I can include this into next, probably tomorrow release (I planned to release it already in Thursday, but rather late without bugs, then ...)

Christian · May 27, 2013, 16:01:01

Ahhh, i'm not in time and not up to date :-(
Sorry for that.
I tried new Altitude Manager only the settings. No recordings has been done so far...

And you are right, i started comparison with Garmin stuff .-)
Its difficult to have different track recordings from one unique route / way. I will try to find some.

Menion · May 28, 2013, 18:37:48

so tracks not needed ... we spend half a day together with Peter on some testing and now seems that results are quite usable ... you'll see in next version. Expect anyway that track statistics are stored in database and need to be refreshed. So all new track will have these improved values. Old tracks need some reason to refresh also in database, like "Fill altitude", update/delete of any point etc ...

so gentlemans ... viewtopic.php?f=25&t=3112&p=20936#p20936

Christian · June 03, 2013, 19:07:40

i'm looking forward to the next version.

Menion · June 05, 2013, 15:33:18

fine, version is out. I just suggest to "fill altitude" for already stored tracks, to refresh statistics values

Christian · June 26, 2013, 16:03:36

Thanx for the new version. I tried this but the distances in flat area are still too less (like before)
:-(
Christian

Menion · June 26, 2013, 19:33:20

Christian we took with Peter four tracks and tested them in five different applications. Values that locus compute are now somewhere in the middle of them. Anyway as I wrote, it's need to refresh tracks to display new values. So for example remove last point or fill altitude of track etc. This will refresh also a store statistics. And if you'll still not be satisfied, I really need one track to test and also values you expect! So I can do some more research ...

tommi · June 26, 2013, 20:49:57

Menion,
in past I used heavy altitude filtering, other settings just interpreted simple noise of pressure sensor as change of altitude.
Which setting do you recommend now after optimization for use with pressure sensor?

Menion · June 27, 2013, 18:34:35

hmm hard to say

it needs some field testing ...

anyway heavy filtering should not be needed too much as before. Suggest to try "Optimize GPS altitude" by hgt files. this should improve altitude noise a lot. Pressure sensor itself should work now much better so it's a question if "Altitude filter" is needed at all

tommi · July 09, 2013, 15:53:18

Quote from: "menion"hmm hard to say it needs some field testing ...

anyway heavy filtering should not be needed too much as before. Suggest to try "Optimize GPS altitude" by hgt files. this should improve altitude noise a lot. Pressure sensor itself should work now much better so it's a question if "Altitude filter" is needed at all

Thanks, I tried without "Optimize GPS altitude" and "Light filter" (I didn't find time to check all settings before starting the track recording). I think in general the generated altitude curve is quite smooth.

But: When GPS is switched on and gets a lock it doesn't use pressure sensor value resp. info from .hgt file from beginning. For several seconds it uses the quite bad value from GPS (in my case (or for everyone?) about 50m too high) and after a while it decides to use the value calculated from pressure sensor/.hgt file.
This creates ugly glitches in the track:
- at the beginning
- when recording was suspended/resumed (by pause button) and GPS was switched off (automatically because no function needed it and screen was off).
See the track witch a glitch at start:
https://www.dropbox.com/sc/ba0gn964psqkhtd/gJ5S3zD3KX
See a video which shows the described behaviour of altitude measurement/calculation in the GPS screen:
https://www.dropbox.com/s/pae5507dkglya ... -19-15.mp4

Some month ago (I think it was in March) this bad behaviour didn't occur, the value from pressure sensor/.hgt was taken immediately.
Please fix.

Menion · July 09, 2013, 16:16:22

ah it's problem that jusc (if I remember correctly) reported few days ago ...

I'm going to fix it ...

EDIT: ah yes here viewtopic.php?f=10&t=3207 ... hmm I was recording tracks twice last week and both looks fine even from start, but point is as you mention. To have enabled track recording even before GPS gets fix, so all points are stored, even a first one

tommi · July 09, 2013, 16:19:17

Quote from: "menion"ah it's problem that jusc (if I remember correctly) reported few days ago ...

I'm going to fix it ...

EDIT: ah yes here viewtopic.php?f=10&t=3207 ... hmm I was recording tracks twice last week and both looks fine even from start, but point is as you mention. To have enabled track recording even before GPS gets fix, so all points are stored, even a first one

Hm, maybe there was already a (partial?) fix in the latest testverson on dropbox but I used Locus Pro.