Altitude manager srtm parameter
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.
Hello Haci,
thanks for the bug report, but I can't confirm your problem.
My tests
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
Hello Haci,
thanks for the bug report, but I can't confirm your problem.
My tests
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
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.
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.
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
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
Replies have been locked on this page!