Overnight I thought of a non-disgusting way to optimize
the code. A new, muuuch better patch is now at:
http://www.av8n.com/fly/fgfs/altimeter.diff
The new patch gets the right answer without calling any
transcendental functions.
Also its range of validity has been extended to >100,000 feet.
I have tested that this behaves properly. The unpatched
code does not handle Kollsman settings properly, not even
close, except near sea level.
Please do not write to me saying you have tested the
unpatched code and found that it works OK at sea level,
or in standard-day conditions. That's true under those
narrow special conditions, but not representative of
the general case. As previously discussed in detail,
try it at Aspen under conditions where the QNH is not
29.92.
===========================
Someone asked me off list:
> A side quick remark : I don't understand, why the altimeter should be
> dependent of the "weather
> condition" dialog.
It's not dependent, except indirectly. The point is that we
are dealing with a /pressure/ altimeter, and that atmospheric
pressure is one of the "conditions" controllable from the
"weather conditions" popup.
The illogic of the weather condition dialog popup is at most
tangentially relevant to the incorrect altimetry. I mentioned it
only as an /example/ of code that incorrectly equated sea-level
pressure to QNH.
Please do not write to me saying that SLP must equal QNH
when you are flying at sea level. That's true in that
narrow special case, but not representative of the
general case.
The unpatched altimeter is broken, quite independently of
how the prevailing atmospheric pressure profile is controlled.
If you don't want to fool with the "weather conditions" popup,
you can equally-easily adjust the pressure profile using the
properties browser. To test things, you *do* have to adjust it
somehow, because the only case where the unpatched altimeter is
OK is the case of absolutely standard-day conditions, which are
the default conditions.
> From my point of view, the altimeter is a model of the real instrument : that
> is pilot oriented, not controversial (= easy to convince mailing list).
Of course.
> If not possible, as close
> as possible of the real instrument, using the standard atmosphere (for
> example = present code).
In real flying, standard-day conditions are the exception, not the
rule. A QNH of exactly 29.92 is the exception, not the rule.
> Even with an approximate model, the altimeter should work whatever the
> atmosphere model with a
> good approximation, in particular whatever the inputs at the "weather
> condition" dialog. If not,
> the problem is inside the altimeter code, not a dialog box.
There is (was) a problem with the altimeter, inside the altimeter.cxx code.
The patch fixes this problem.
FWIW there are *also* deep conceptual problems with the "weather conditions"
dialog, but that is a subject for a different thread.
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier.
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
