This object is in archive! 

Altitude manager srtm parameter

haci shared this problem 2 years ago
Solved

Hello. There is misbehavior in altitude manager settings. I intentionally put wrong hgt file for my area and made some experiments, here is the results:

- when "srtm dat"a is set to "don't use" and "use pressure sensor" is on, the altitude is replaced with srtm value, but it shouldn't.

- when "srtm dat"a is set to "optimize gps values" and "use pressure sensor" is off, it doesn't optimize but show raw gps altitude.

- "srtm dat"a is set to "optimize gps values" and "use pressure sensor" is set to on, it doesn't optimize but show gps altitude filtered with pressure.

So when the pressure sensor is on, srtm behavior is inverted, when set to don't use it uses and when set to optimize it doesn't optimize. I don't know the logic of optimize, but if we think that "don't use" should be "optimize", then it doesn't do anything until you turn on pressure sensor.

Other combinations of altitude manager settings work as intended.

Replies (3)

photo
1

Hello Haci,

thanks for the bug report, but I can't confirm your problem.

My tests

  1. all disabled, so the app displays received data: 320m
  2. enabled "Use pressure sensor" and set "Sea level" value to 900 to see the difference: -768m
  3. "SRTM data" set to "optimize" and pressure disabled: 321m
  4. "SRTM data" set to "optimize" and pressure enabled with "Sea level" value to 900 to see the difference: -768m

Extra info:

Because I was standing still, optimizing thanks to SRTM values has no effect. The app needs some changes, movement, to fill the filter that does the optimization.

So to be true, I do not see a problem here. Suggest checking if the value is correct during some small walk.

Jiří M. aka Menion

photo
1

Thank you for your feedback. Let me give some comments on your test:

1. When all is disabled there is no problem, works as it should.

2. When you set sea level or altitude manually, it overrides all other including gps and srtm, isn't it.

3. In this scenario it doesn't optimize.

4. It is same as 2, overrides all other.


My location attitude is 775m above MSL, srtm show 774. For tests and to see it more clear I put hgt file which show 530m at my location, difference is 245m. Altitude offset on and set to automatic.

1. Srtm set to don't use, pressure sensor on and set to automatic: 530m. It is obvious that it is srtm value, but it's set to don't use.

2. Srtm set to optimize, pressure sensor off: 782m with some fluctuations. I made a 3 minute walk, nothing changed. Difference between srtm and gps is big, so the optimization filter should do some changes. Locus shows exact same altitude as gps status app, it is raw gps attitude.

3. Srtm set to optimize, pressure sensor on and set to automatic: 782m without fluctuations because of pressure sensor is used.


The problem is only with srtm data parameter, "don't use" and "optimize" are vice versa. Plese try with automatic pressure sensor to reproduce the issue.

photo
1

Thanks for the description. I'm double-checking the code and you are correct with your observations. It is how the app currently works.

Explanation: automatic pressure calibration compares altitude measured by GPS and the altitude computed from the measured pressure. In case, SRTM data are not used for optimization or replacement, the app uses them here instead of measured altitude. Why I wrote this five years ago - I'm not sure to be true.

Anyway, you discovered this only because of an invalid SRTM file. With correct data, I'm sure, this mechanism works correctly. What you think?

Menion

photo
1

Thank you for the explanation. I use Locus from 2014 and actually was thinking about some strange behavior a long time ago. The thing that let me think so was that, when ever I open Locus at my home location it always showed exactly 774m and I never switched srtm data to optimize or replace. I thought that gps can't be so accurate to always show exactly one value and a week ago decided to make some tests, and my thoughts were right. I think that it should be fixed, because now it does opposite of the choosen setting. Now as a workaround I put it to optimize for not to optimize))).

photo
1

Your workaround is not correct. The fact that the app use HGT files for pressure sensor calibration do not mean that computed altitude is optimized! This only helps to calibrate the sensor faster. HGT here only defines base elevation value. Because of this, you always had 774m, but all following computed altitude is based on this 774m and current pressure > no optimizations.

Anyway, I'll try to remove this old optimization code to the next app version and we will see, how reliable altitude will be.

photo
1

Yes I know that all this occurs only at first calibration of pressure sensor. All my point is that if there is some setting and it doesn't do what it should or does what it shouldn't, in my opinion it's a bug. Just wanted to report it.

It is great that app has so many configurable options and everyone can choose preferable one.

Thank you.

Replies have been locked on this page!