Hi all, As stated in prior posts, I want to see the new atmos/altimeter/encoder in cvs. I also want to get an update to kap140.nas that only computes or fetches baroShift = kollsman shift for setting-inhg = baroSettingInhg when the baro setting on the kap140 is changed.
This note is intended to move toward the above goals.
Below I summarize what I understand are the rationals for John, Roy, and
myself VS the three open options. In this note, I want to emphasize
what we all agree on; and that is quite a lot.
Both John Denker and myself are running versions of his atmos.cxx,
altimeter.cxx that have the encoder as a separate instance of the
altimeter with values rounded using a quantum parameter and the having a
tau parameter that should low pass the pressure altitude and kollsman
shift. I have not seen any response from John concerning the bug fix on
how the pressure altitude is rounded in his altimeter.cxx. Since this
is an obvious fix, I assume we agree on the bug fix.
As I see it, and I believe this takes into account John Denker's posts
also, there are only 3 options still being put forward; all having to
do with how the kap140 gets the baro shift. These are:
1) computes it in kap140.nas using the pressureToHeight()
function already there but not presently used (need to check the
constants for consistency with John's model),
2) gets the kollsman shift value already computed by John's
altimeter.cxx (but not presently saved to the property tree by
John's altimeter.cxx) , or
3) gets it by fetching from the encoder propeties the indicated
altitude and the pressure altitude, and then subtracting.
John and I agree on the following:
a) since the baro shift need only be computed when the baro
setting changes (very infrequent event), there is no measurable
efficiency difference between the 3 options.
b) since John's interpolation for the kollsman is always done
using the part of the table generated by for the bottom layer
with positive lapse rate, by assuring that the kap140 function
uses the same constants as John's function, all three options
should produce the same kollsman shift.
What differences remain?
1) and 3) satisfy John's desire to keep the altimeter object
"un- entangled" with the autopilot.
2) and 3) satisfy my goal to keep the various versions of
kollsman shift from varying because of constant differences over
time or even formula errors/differences for various autopilot
implementations.
1) and 2) satisfy Roy's desire to not fetch the indicated
altitude, but use the encoder supplied pressure altitude and a
kollsman shift approximation.
Frankly, the new atmos/altimeter/encoder is a very needed improvement!
Living near Denver, I am very tired of finishing fgfs IFR cross
countries in the Rockies only to be way off in both the captured
altitude from the kap140 as well as at an indicated altitude that is way
off because the QNH != 29.92. Then DH was also way off. All this is
fixed by all three options!!! As John has pointed out several times,
the atmos model is derived so the indicated altitude and field elevation
should agree with a good QNH value in the kollsman window.
John, do you agree with this analysis?
Do you still agree with this quote?
On 02/25/2007 John Denker wrote:
> On 02/25/2007 02:39 PM, Roy Vegard Ovesen wrote:
>
> > I suggested an encoding altimeter as an instance that has both. Do
> you think
> > that makes sense?
>
> Yes, that has been suggested. But what's the rationale?
> It's not the craziest idea in the world... but I still
> haven't heard an argument for it that comes close to
> outweighing the arguments against it, to wit:
> -- Having a separate "steam gauge" instance and a
> separate "encoder" instance is more consistent with
> real life and more consistent with the existing FG
> fleet
> -- Having the altimetry object serve as an oracle for
> computing the Kollsman shift is entirely natural if
> there are separate instances
>
I summarized our present state.
We both have two instances - meets the first --
We both have separate instances, so by the 2nd -- in this quote, "having
the altimetry object serve as an oracle for computing the kollsman shift
is entirely natural."
Like I said, we all agree on a lot, including option 2).
Can we proceed?
1. Please add the bug fix to the pressure altitude low pass.
2. Please add the three lines of c++ to save to the property
tree the kollsman shift you already compute.
3. I have the edits to kap140.nas ready.
We should both prepare patches against cvs and let others test them
before submitting both to cvs. I am attaching a tar.gz patch against cvs
for what I am presently running so others can try it. It includes the
bug fix.
Regards,
--
Dave Perry
alt-encode-kap140.tar.gz
Description: application/compressed-tar
------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
