Altitude (from GPS) optimizations

[Maksym]

Pressure sensor is not very bad: phone has Internet connection and it's not a problem to calibrate time to time pressure sensor using METAR data of nearest airport. Of course if you are not in the middle of Africa where no airports with METAR data. But you can calibrate sensor when get SRTM and GPS height almost the same.

[Menion]

very nice discussion guys, nice surprise. I'm currently finishing some improvements in main menu, point editing and wms layers, anyway since next week, I'll try to focus on better handling of SRTM data (mainly downloading of HGT) and as a first step, create some automatic using of SRTM altitudes, at least for checking of GPS altitudes. So sorry for letting you wait ... I'll start next week on this

[PeterPablo]

Recently, I was on a skiing trip and recorded the tracks. The "information" tab was useless for most tracks since the recorded altitude had big jumps. You certainly remember the discussion about "maximum possible speed". In one case the altitude jumped from one track point to the next from 2500 m to 25000 m (yes, factor ten!) and back.
In my opinion the post-processing of the raw GPS-data can be improved considerably. Additional sources like pressure / SRTM data can be used to improve the altitude for example under known problematic situations (forest, city), when the GPS signal is bad.
The post-processing should first check for obvious outliers (jump of position/speed/acceleratoin between neighbooring points) and secondly use a (FIR-)filter of higher order (meaning that not only the last two points are considered but rather for example the last eight).

If needed I could provide the track showing the above mentioned misbehaviour. I deleted the messy points from the track, though I should have the recorded NMEA data.

Slightly off-topic: Which "altitude correction"-setting is recommanded? Could the option "Use NMEA data" be the source of problems people are sometimes experiencing?

Peter

[Maksym]

I am using "Use NMEA data" and get actual height (of course with jumps). The source of problem is inaccurate height limited by GPS technology. The solution is to use pressure sensor. All other methods will work more or less in the flat open field but useless in difficult situations, I think.

[Christian]

We should wait for Galileo system  

[tommi]

We should wait for Galileo system  

and by new phones . The big players will be happy

[Menion]

fine, all major problems seems to be solved in latest test version, so I'm almost ready for next release version. Because Peter is planning on today some testing on random users, I have some time that I would like to spend on this topic, so ..

Firstly, I will keep support for Pressure sensor, don't worry. There are no plans to leave it be. Problems on Note2 are really stupid, but as jusc wrote, on SGS3 it works correctly and with any alternative ROM on Note2 it will also works fine I think, so don't worry. Pressure will remain.

Biggest problem for me is usually finding best place for some additional features. In user interface I mean. Currently there are three places that work with altitude

- GPS > Altitude filter
- GPS > Altitude correction
- Sensors > Pressure sensor

All three are quite advanced options that may confuse basic users. Ah this is not important now. What I wanted to say, that these three places are really close one to another. So what I have in mind is separate screen called for example "Altitude manager", where will be three tabs, for every item one tab. Except fact that all will be at one place, I'll be also able to add this "manager" as a button to right panel (so you'll have really fast access to required functions like "calibration"). And it will also allow also unlimited extending, because it will be much easier for me. What you think?

Fine, it was about GUI. About what will Locus do on background. Currently I have in mind, compare GPS altitude and SRTM values (or Pressure sensor) and computing deviations, some moving averages etc. For my own surprise, I'll like to have working GUI and then start work on background. Hmm as I think about it, some csv file (text separated by commas) with raw and computed values should be welcome for some check and control right?

[Menion]

so basic system done. Two days of work to create GUI and system and also quite a lot of testing. It's anyway not yet completely ready for publishing and even public testing, but I'll try during next few days, create some testing version. This is mainly information for you, to let you know that I work on this and that, except fixing bugs, this is main priority

[tommi]

Great news!
I appreciate it.

[Maksym]

Thank you. I'll wait for release.

[Christian]

Great! But don't hurry...

[Menion]

I'm not ... it's already here viewtopic.php?f=25&t=2983#p19941 anyway version contain some issues that tommi and others already reported. I'm working on it but seems, fixed version will be tomorrow. It took longer then I expect to fix it ...

[tommi]

Hi Menion,
additional feedback from today recorded tracks:
The slope curve is much to sensible. There are altitude changes <<1m (recorded with baro, no optimization from elevation data (I think this optimization doesn't make sense with the SGS3's pressure sensor)) which create gradients of e.g. 10%. This maybe is mathematically correct but these altitude changes are in many cases only created by noise in the pressure values.

How is the gradient calculated from altitude?
Currently there is light filter configured for altitude. I can test again with heavy filter. What do you think?

[tommi]

Hi Menion,
new results from today morning:
I recorded a tour with a train today, so we can be sure that the terrain was smooth.
With the heavy altitude filter I got a smoot track with altitude on the y-axis. This wasn't the case for a car tour yesterday with light altitude filter.
-> Heavy altitude filter does the trick regarding smoothness of the altitude curve for the use of pressure sensor on SGS3 (I assume that other properly working pressure sensor phones will give similar results,)

The gradient curve shows only integer % values, it should show the curve at least with a granularity of 0.1%, even a higher resolution would make sense to get a smooth gradient curve.
In my case of the train tour the gradient curve was just a constant line with 0%, though there was a altitude differences of about 70m on 30km.

As an alternative to gradient it should be possible to have a chart for the vertical speed.

A bit off topic: The speed curve is really noisy. Could you add a filter for this one, too? But maybe it is better to filter the recorded distance values which would also result in less noise for the speed curve.

If the reported problems are fixed, I think we have a pretty new feature which is another milestone in the development of Locus tracking!

[tommi]

And one more result, actually related to dashboard but as you're anyway working in this area:
Time variable doesn't count up anymore if GPS was lost e.g. in a tunnel. After the tunnel time counts again normally.