GPS altitude filtering/smoothing (feature)

[luszczyszenko]

I know that mobile phone's GPS has limited accuracy. And if I put the phone in the pocket there's only worse. But... Is there a possibility to "smooth" logged GPS altitude data? Maybe moving average of a few last samples? Some kind of low pass filter?

Current situation is that "climb/descend" parameter counts every single meter up/down but these are not real values.

[bailuk]

Current situation is that "climb/descend" parameter counts every single meter up/down but these are not real values.

This is not the case: AAT uses AverageAltitude.java to average altitude before calculating deltas. Its my impression that total descend and ascend give quite realistic values. But personally I'm not interested in super precise values.

These are the limits used to average GPS samples:

private static final int MIN_SAMPLES = 5;
private static final int MAX_SAMPLES = 50;
private static final float MIN_DISTANCE = 50f;

To get more precise altitude you can adjust GPS value (in preferences) with a fixed correction value or enable the phones barometer sensor and then manually set altitude whenever you come to post sign.

BTW if you have Adjust altitude or barometer sensor enabled you can just tab altitude in the cockpit view to adjust altitude.

[luszczyszenko]

Yes, in the fact, you got me. I did not checked if any averaging of altitude is done.

AAT uses AverageAltitude.java to average altitude before calculating deltas.

But why it gives so poor result? Is my GPS so inaccurate?

To get more precise altitude you can adjust GPS value (in preferences) with a fixed correction value or enable the phones barometer sensor and then manually set altitude whenever you come to post sign.

That's not solution. It makes only an offset. I made a test loop:

AAT shows ~60m of climb / downhill. It's not real values. It should be about 20m. So I made similar loop track with brouter.de to show you the real values (or close to real) of altitude changes.

Because start point is the end point there should be identical values of climb and downhill. But they're different. Why? There is no influence of GPS accuracy.

[bailuk]

The BRouter variant is much smaller. It has only 87 samples while your track has 246. As one can see on the graph BRouter leaves away many smaller climbs. To me 60 m look realistic, if you add the smaller climbs.

Because start point is the end point there should be identical values of climb and downhill. But they're different. Why? There is no influence of GPS accuracy.

You're right, climb and downhill should be the same. The difference comes probably from the low resolution of the route in combination with averaging.

Some notes to clarify:

• The altitude AAT records and saves to the GPX track are identical with altitude received from GPS.
• So what you see on the graph is identical with what was received from GPS.
• Only climb and downhill are averaged and the averaging is done when loading a GPX track.

[luszczyszenko]

To me 60 m look realistic, if you add the smaller climbs.

I cannot agree. These are plain streets, not off-road. There are a lot less smaller climbs (and downhills) than GPS claims. Next example. It is downhill street, so there is no climb.

The main problem is in GPS accuracy, so it seems to me that nothing can be done with it. Ergo: climb and descend are unusable.