Re: [Flightgear-devel] altimeter, encoder, and kap140
On Mon, 2007-02-26 at 11:37 -0500, John Denker wrote:
Hi --
I made an /object/ to calculate the Kollsman shift.
# Calculate Kollsman shift/ft versus setting/inHg
# Computationally efficient if, for any given instance
# of this class, the setting is not being changed often.
# Typical usage:
# kxx = atmo.Kollsman.new();
# kyy = atmo.Kollsman.new();
# print (kxx.shift(29.92)); # calculates
# print (kyy.shift(30.92)); # calculates
# print (kxx.shift(29.92)); # uses cached value
# print (kyy.shift(30.92)); # uses cached value
Kollsman = {
new : func { { parents : [Kollsman] } },
ft : nil,
set : nil,
shift : func(setting) {
if (setting == me.set) {return me.ft ~ xx}
me.set = setting;
me.ft = 145442.156 * (1 - math.exp(math.ln(me.set/29.921260) *
0.1902632365))
}
};
Do you plan on using this in altimeter.cxx?
It is written in c++.
John I am presently running your altimeter/encoder in one copy of fgfs
and a modified version in another copy of fgfs with two changes:
1) Of course the two lines of code that put the kollsman shift to the
property tree, and
2) I modified Altimeter::update (double dt) to properly handle the
truncation of pressure altitude for non zero tau. I saw the problem on
reading your diff.
This certainly is a bug. To see the problem in your version for non
zero _tau, it is enough to set _tau = 1.0 and take off and climb hard in
an AC with good climb rate and then level off. The pressure altitude
lags way behind and once you level off will stay perhaps 200 ft too low.
Same after a steep descent, except the pressure altitude lags high.
This is a BIG issue when using altitude capture in a step-down approach
which is common for mountain approaches.
The problem is the logic behind
press_alt = fgGetLowPass(press_alt, newPA, trat);
when press_alt and newPA are not the same kind of PA. newPA is
computed from
_altimeter.press_alt_ft(pressure) which is not truncated and press_alt
is truncated every iterate. So the weighted average done by
fgGetLowPass is meaningless in that it never converges to the target
even in level flight after a climb. The error is nearly as large as the
lag when you level off.
Here is an obvious fix for this bug in the update code:
void
Altimeter::update (double dt)
{
if (_serviceable_node-getBoolValue()) {
double trat = _tau 0 ? dt/_tau : 100;
double pressure = _pressure_node-getDoubleValue();
double setting = _setting_node-getDoubleValue();
// The mechanism settles slowly toward new pressure altitude:
raw_PA =
fgGetLowPass(raw_PA, _altimeter.press_alt_ft(pressure), trat);
_mode_c_node-setDoubleValue(100 * round(raw_PA/100));
_kollsman = fgGetLowPass(_kollsman,
_altimeter.kollsman_ft(setting), trat);
_kollsman_offset_node-setDoubleValue(_kollsman);
if (_quantum) press_alt = _quantum*round(raw_PA/_quantum);
else press_alt = raw_PA;
_press_alt_node-setDoubleValue(press_alt);
_altitude_node-setDoubleValue(press_alt - _kollsman);
}
}
// end of altimeter.cxx
Of cource you need to declare
private:
double press_alt;
double rawPA;
SGPropertyNode_ptr _kollsman_offset_node;
in the header file.
Can we land this flight by trading this bug fix for leaving the
kollsman_offset_node line in the code?
Please, lets agree and go work on some of the other more pressing
issues!
By the way, no matter what, our interaction has had value.
1) I had never used c++ to any extent (numerical analysts my age use
either fortran or just c). I have learned a lot by working on the
altimeter/encoder instances.
2). I have modified kap140.nas so that the kollsman (baro) shift is
computed or pulled from the property tree only when baro setting
changes. This is much more efficient as you have pointed out.
3) I think I have made some contributions to your efforts in this area
as well.
I for one want to see this much improved altimeter/encoder and
atmosphere model in cvs. I did a pros and cons analysis for the the two
likely resolutions to our disagreement which I will share if you are
really serious about putting this in cvs. The options are of course
with and without the 2 lines of code to save the kollsman shift.
After sharing this analysis with the list, I will go with what the
community sees as the best option.
Comments from others?
Dave P
--
Dave Perry
-
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.phpp=sourceforgeCID=DEVDEV
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
Re: [Flightgear-devel] altimeter, encoder, and kap140
On Tue, 2007-02-27 at 19:07 -0700, Dave Perry wrote:
Sorry,
I copied from the wrong version. I will add the missing line and delete
a declaration:
Here is an obvious fix for this bug in the update code:
void
Altimeter::update (double dt)
{
if (_serviceable_node-getBoolValue()) {
double trat = _tau 0 ? dt/_tau : 100;
double pressure = _pressure_node-getDoubleValue();
double setting = _setting_node-getDoubleValue();
double press_alt = _press_alt_node-getDoubleValue();
// The mechanism settles slowly toward new pressure altitude:
raw_PA =
fgGetLowPass(raw_PA, _altimeter.press_alt_ft(pressure), trat);
_mode_c_node-setDoubleValue(100 * round(raw_PA/100));
_kollsman = fgGetLowPass(_kollsman,
_altimeter.kollsman_ft(setting), trat);
_kollsman_offset_node-setDoubleValue(_kollsman);
if (_quantum) press_alt = _quantum*round(raw_PA/_quantum);
else press_alt = raw_PA;
_press_alt_node-setDoubleValue(press_alt);
_altitude_node-setDoubleValue(press_alt - _kollsman);
}
}
// end of altimeter.cxx
Of cource you need to declare
private:
double rawPA;
SGPropertyNode_ptr _kollsman_offset_node;
in the header file.
Can we land this flight by trading this bug fix for leaving the
kollsman_offset_node line in the code?
Please, lets agree and go work on some of the other more pressing
issues!
By the way, no matter what, our interaction has had value.
1) I had never used c++ to any extent (numerical analysts my age use
either fortran or just c). I have learned a lot by working on the
altimeter/encoder instances.
2). I have modified kap140.nas so that the kollsman (baro) shift is
computed or pulled from the property tree only when baro setting
changes. This is much more efficient as you have pointed out.
3) I think I have made some contributions to your efforts in this area
as well.
I for one want to see this much improved altimeter/encoder and
atmosphere model in cvs. I did a pros and cons analysis for the the two
likely resolutions to our disagreement which I will share if you are
really serious about putting this in cvs. The options are of course
with and without the 2 lines of code to save the kollsman shift.
After sharing this analysis with the list, I will go with what the
community sees as the best option.
Comments from others?
Dave P
--
Dave Perry [EMAIL PROTECTED]
-
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.phpp=sourceforgeCID=DEVDEV
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] altimeter, encoder, and kap140
Here is the nasal code to calculate the Kollsman shift.
# Typical usage: indicated_altitude = pressure_altitude -
kollsman(baro_setting)
k_ft = k_set = nil;
kollsman = func{
if (arg[0] == k_set) {return k_ft}
k_set = arg[0];
k_ft = 145442.156 * (1 - math.exp(math.ln(k_set/29.921260) * 0.1902632365))
}
1) This achieves the goal of realism in the sense that it allows
the autopilot code to calculate the Kollsman shift using only
information available to a real autopilot.
I'd be astonished if real-world autopilots used anything much
different from this.
2) This is computationally efficient in the overwhelmingly-likely
case that the baro_setting is not being changed very often.
3) If you want to standardize this across the FG fleet, put it in
some accessible place [perhaps atmo.nas] and let people call it
from there [as atmo.kollsman(...)] rather than cut-and-pasting
it in multiple places.
4) If you don't think this is -- for all practical purposes -- the
right answer, please explain what is the right answer ... and
explain how a pilot could tell the difference between this and
the right answer.
5) Since this has some advantages and AFAICT no disadvantages, it
removes any temptation to use the c++ altimetry object as an oracle
for computing the Kollsman shift.
===
Tangentially related note: I made one recent change to the package
of diffs:
http://www.av8n.com/fly/fgfs/atmo.diff
I rigged it up so that encoder.[ch]xx are no longer needed, and are
not even mentioned in the Makefile.am or anywhere else. When you
configure an altimeter you get an instance of the Altimeter class,
and when you configure an encoder you get a different instance of
the Altimeter class. The only difference is that the former has a
default quantum of zero, while the latter has a default quantum
of ten.
Users should not notice any difference (except that their altimetry
suddenly becomes much more accurate). The configuration files such
as generic-instrumentation.xml can stay exactly the same, and the
runtime interface (via the property tree) is upward-compatible.
-
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.phpp=sourceforgeCID=DEVDEV
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] altimeter, encoder, and kap140
On Mon, 2007-02-26 at 04:57 -0500, John Denker wrote:
Here is the nasal code to calculate the Kollsman shift.
# Typical usage: indicated_altitude = pressure_altitude -
kollsman(baro_setting)
k_ft = k_set = nil;
kollsman = func{
if (arg[0] == k_set) {return k_ft}
k_set = arg[0];
k_ft = 145442.156 * (1 - math.exp(math.ln(k_set/29.921260) *
0.1902632365))
}
This is virtually no change. Only the constants are different (more
digits).
1) This achieves the goal of realism in the sense that it allows
the autopilot code to calculate the Kollsman shift using only
information available to a real autopilot.
I'd be astonished if real-world autopilots used anything much
different from this.
2) This is computationally efficient in the overwhelmingly-likely
case that the baro_setting is not being changed very often.
3) If you want to standardize this across the FG fleet, put it in
some accessible place [perhaps atmo.nas] and let people call it
from there [as atmo.kollsman(...)] rather than cut-and-pasting
it in multiple places.
4) If you don't think this is -- for all practical purposes -- the
right answer, please explain what is the right answer ... and
explain how a pilot could tell the difference between this and
the right answer.
5) Since this has some advantages and AFAICT no disadvantages, it
removes any temptation to use the c++ altimetry object as an oracle
for computing the Kollsman shift.
So only the altimeter can compute the kollsman shift via your oracle?
===
Tangentially related note: I made one recent change to the package
of diffs:
http://www.av8n.com/fly/fgfs/atmo.diff
I rigged it up so that encoder.[ch]xx are no longer needed, and are
not even mentioned in the Makefile.am or anywhere else. When you
configure an altimeter you get an instance of the Altimeter class,
and when you configure an encoder you get a different instance of
the Altimeter class. The only difference is that the former has a
default quantum of zero, while the latter has a default quantum
of ten.
Users should not notice any difference (except that their altimetry
suddenly becomes much more accurate). The configuration files such
as generic-instrumentation.xml can stay exactly the same, and the
runtime interface (via the property tree) is upward-compatible.
-
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.phpp=sourceforgeCID=DEVDEV
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
--
Dave Perry [EMAIL PROTECTED]
-
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.phpp=sourceforgeCID=DEVDEV
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] altimeter, encoder, and kap140
Hi --
I made an /object/ to calculate the Kollsman shift.
# Calculate Kollsman shift/ft versus setting/inHg
# Computationally efficient if, for any given instance
# of this class, the setting is not being changed often.
# Typical usage:
# kxx = atmo.Kollsman.new();
# kyy = atmo.Kollsman.new();
# print (kxx.shift(29.92));# calculates
# print (kyy.shift(30.92));# calculates
# print (kxx.shift(29.92));# uses cached value
# print (kyy.shift(30.92));# uses cached value
Kollsman = {
new : func { { parents : [Kollsman] } },
ft : nil,
set : nil,
shift : func(setting) {
if (setting == me.set) {return me.ft ~ xx}
me.set = setting;
me.ft = 145442.156 * (1 - math.exp(math.ln(me.set/29.921260) *
0.1902632365))
}
};
On 02/26/2007 08:30 AM, Dave Perry wrote:
So only the altimeter can compute the kollsman shift via your oracle?
I'm pretty sure my altimeter code does not use an oracle. The
C++ code uses C++ code to calculate the Kollsman shift. This
is the conventional and appropriate approach.
In close analogy, I recommend that the autopilot .nas code
should use .nas code to calculate the Kollsman shift. This is
the conventional and appropriate approach.
It is also more realistic (as previously discussed), simpler, and
more self-documenting.
There *do* exist exceptional cases where it is appropriate for
the .nas code to escape to C++ or beyond ... e.g. math.atan2() ...
but I see not the slightest evidence that the Kollsman shift
calculation is in this category.
-
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.phpp=sourceforgeCID=DEVDEV
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] altimeter, encoder, and kap140
On Sun, 2007-02-25 at 01:55 -0500, John Denker wrote: On 02/25/2007 12:30 AM, Dave Perry wrote: I have been communicating off and on with both John Denker and Roy Vegard Ovesen off list concerning this topic. I am running an edit of John's most recent altimetry patch and have modified kap140.nas, altimeter.cxx, and altimeter.hxx so that the altitude capture in the kap140 is using the same atmosphere model as the altimeter. It is also using the altimeter.cxx as the encoder, bypassing encoder.cxx. When near sea level, the cvs encoder.cxx did not report the same pressure altitude as the altimeter with kollsman set to 29.92. By replacing the encoder.cxx with the new altimeter.cxx, this is fixed. Roger. Why does the kap140 need info from the altimeter other than the pressure altitude? The altitude capture in the current cvs kap140.nas used altFt = pressureAltitude + hpartial * (baroSetting - 29.92) and compared this to the target altitude. The problem with this is two fold. The second term is a linear approximation to the h(baroSetting,29.92). But h( , ) was the function before altAlert in kap140.nas. It used two transcendental functions each frame and was not the same function now used by John to model the atmosphere (close in the troposphere, but not the same). By saving the result, you only need to do two transcendental functions every time the pilot changes the baro setting (not two per frame) which seems affordable. The real issue here is that the function used is not the same function that the altimeter is using. By the way ... avoiding transcendental functions is not necessarily necessary nor sufficient for good programming. I've measured a few examples relevant to FG, and found that the transcendental functions are only percentage points slower than the interpolation tables that are being used to speed things up. It seems likely that a table small enough to be fast isn't accurate, and a table big enough to be accurate isn't fast. As the saying goes, premature optimization is the root of all evil. I would like to see some actual factual measurements before making very many decisions about what to optimize and how to optimize it. there are three different numbers that matter. There is the Alt inhg returned by metar. There is the setting the pilot puts in the kollsman window, and there is the baro setting the pilot enters in the KAP140. Yes, that's clear. The KAP140 must use the baro setting and the PA returned by the encoding altimeter to get the term altFt it compares to the target altitude. It has access to the static pressure according to the KAP140 manual, but could use a power function approximation similar to what John's altimeter uses to compute the baro offset w/o knowing the static pressure. I don't see how that could possibly work. Encoded pressure altitude and static pressure are two versions of the same idea. Comparing them cannot give any information about the present value and/or desired value of the baro setting. I am now not using the static pressure. The old linear approximation, hpartial, did use the static pressure. Then altFt = PA - baroOffset. The patch attached models the following pilot errors correctly. What patch? It was remove by Sorceforge, but was attached to the e-mail. Are you getting the e-mails sent to the list? Case 1: Pilot enters the QNH in baro setting on the KAP140 but does not enter QNH correctly in the kollsman window of the altimeter. If he sets the target altitude and arms it, the AC will still capture the right altitude, but the indicated altitude will be wrong. That's clear. Case 2: Pilot enters QNH correctly in the kollsman window on the altimeter, but sets baro setting wrong. Even if he sets the target altitude right and arms it, the AC will capture the wrong altitude. For example, if the baro setting is 29.92, the KAP140 will capture PA which is only correct if QNH = 29.92. But since he got QNH right in the kollsman window, the indicated altitude will be correct, telling him he captured the wrong altitude. That's clear. I modified John's code so the altimeter picks up baro setting from /autopilot/KAP140/settings/baro-setting-inhg and uses this to compute baroOffset using the same interpolation function model, _altimeter.kollsman_ft(baro_setting). No comment until I see the code. I will forward it to you off list. I also rearranged the truncation of pressure altitude in John's code so the indicated altitude is computed before the pressure altitude is rounded and saved. John, you may have already caught and corrected this bug. I quite intentionally rounded the pressure altitude not the indicated altitude. This is a realistic model of the action of a blind encoder, which knows nothing of the baro setting. There are multiple mechanical and
Re: [Flightgear-devel] altimeter, encoder, and kap140
On Sun, 2007-02-25 at 06:39 -0700, Dave Perry wrote: On Sun, 2007-02-25 at 01:55 -0500, John Denker wrote: On 02/25/2007 12:30 AM, Dave Perry wrote: The altitude capture in the current cvs kap140.nas used altFt = pressureAltitude + hpartial * (baroSetting - 29.92) and compared this to the target altitude. The problem with this is two fold. The second term is a linear approximation to the h(baroSetting,29.92). But h( , ) was the function before altAlert in kap140.nas. It used two transcendental functions each frame and was not the same function now used by John to model the atmosphere (close in the troposphere, but not the same). By saving the result, you only need to do two transcendental functions every time the pilot changes the baro setting (not two per frame) which seems affordable. The real issue here is that the function used is not the same function that the altimeter is using. I should have added that I cannot save the baro offset only when the baro setting changes in kap140.nas since the only access to _altimeter.kollsman_ft(baro_setting) is via altimeter.cxx and the property tree. We could check for changes in /autopilot/KAP140/settings/baro-setting-inhg and only change the baro offset node when baro-setting-inhg changes. Regards, -- Dave Perry - 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.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] altimeter, encoder, and kap140
There are two ideas that need to be kept separate. a) The idea of an /class/ aka /object/, versus b) the idea of an /instance/ of such a class. As applied to altimetry: a) Writing a single altimetry /object/ that can perform either as a digital encoder *or* as an analog steam gauge is a good idea. b) Trying to make a single /instance/ perform both functions is a bad idea. In real aircraft, it is common practice to have an analog altimeter in one place, and an encoder in another place. The FG fleet generally does it this way, too: you can see separate instances of altimeter and encoder in generic-instrumentation.xml. As has been pointed out, a pilot is free to put one setting (right or wrong) into the Kollsman window of the main analog altimeter, and another setting (right or wrong) into the baro-setting feature of the autopilot. This is another reason for having two /instances/ of the altimetry object. On 02/25/2007 08:39 AM, Dave Perry wrote: I also rearranged the truncation of pressure altitude in John's code so the indicated altitude is computed before the pressure altitude is rounded and saved. John, you may have already caught and corrected this bug. This is not a bug. It was my intent to model an encoder that rounds the pressure altitude, just as it happens in real life. You must not have realy tried your patch in this area. Your patch used the rounded PA to compute the indicated altitude. That makes the altimeter jump in 10 ft jumps. 1) I did test my code. 2) Yes, the altitude coming off the digital encoder does jump. In real life, one sometimes sees backup altimeters that are based on the output of the encoder. They jump. This is not a bug. It's just how things work. I say again: -- If you want an analog steam gauge altimeter, use an /instance/ of the altimetry object configured to do that. -- If you want a digital encoder, use an /instance/ of the altimetry object configured to do that. -- Do not expect a single /instance/ to both jump and not jump. Do not ask a single /instance/ to have two separate Kollsman settings. This would be inelegant, inefficient, and inconsistent with how things have been done heretofore. It was my intent to be consistent with how things are done in real life, which is also consistent with how the FG fleet has been doing things all along. If there is some reason from departing from this consistency, somebody should explain the reason. == As an almost-separate matter, I have a question for the community: The question is whether the quantum configuration option should be removed from the new altimeter object. ++ The argument for keeping it is that real encoders do quantize the pressure altitude. So writing the quantized pressure altitude to the property tree, as my code does, must be considered realistic. -- The argument for removing it is that if users consider realistic behavior to be a bug, there's no point in offering the behavior. -- Also, the c++ implementation isn't necessary, because if the autopilot wants to round the indicated altitude, it can do so. That's at most one line of nasal code. -- Similarly, if the autopilot wants to round the pressure altitude, it can find the Kollsman shift (by subtracting pressure altitude from indicated altitude), round the pressure altitude, and add the Kollsman shift back in. In the worst case that's three lines of nasal code, usually less. Any opinions? Other suggestions? - 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.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] altimeter, encoder, and kap140
On 02/25/2007 12:49 PM, Roy Vegard Ovesen wrote: I have to agree with Dave on this. The indicated altitude should _not_ be quantized. The indicated altitude belongs to the altimeter part of the class, and _not_ to the encoder part. Parts? I didn't know the class has an altimeter part separate from the encoder part. The class can be /configured/ to be one or the other. It cannot and should not be configured to be both. AFAIK an encoder never outputs indicated altitude. 1) We can agree that /usually/ the encoder does not put out indicated altitude. But there *are* backup altimeters that do display an indicated altitude derived from the encoder (quantization and all). This is not super-important. 2) The main reason for that feature was (a) because it was easy to do, and (b) to make life super-easy when writing autopilot code, so that the Kollsman shift could be calculated in one simple step, by subtraction. If the autopilot authors are not interested in doing that, they are requested to please ignore the indicated altitude output. Please don't complain about bugs in something that is both realistic and harmless. I've heard opinions, but I haven't heard any explanation of why quantizing the pressure altitude is either unrealistic *or* unhelpful. - 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.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] altimeter, encoder, and kap140
On Sunday 25 February 2007 19:44, John Denker wrote: Parts? I didn't know the class has an altimeter part separate from the encoder part. The class can be /configured/ to be one or the other. It cannot and should not be configured to be both. I suggested an encoding altimeter as an instance that has both. Do you think that makes sense? AFAIK an encoder never outputs indicated altitude. 1) We can agree that /usually/ the encoder does not put out indicated altitude. But there *are* backup altimeters that do display an indicated altitude derived from the encoder (quantization and all). This is not super-important. 2) The main reason for that feature was (a) because it was easy to do, and (b) to make life super-easy when writing autopilot code, so that the Kollsman shift could be calculated in one simple step, by subtraction. If the autopilot authors are not interested in doing that, they are requested to please ignore the indicated altitude output. Please don't complain about bugs in something that is both realistic and harmless. I've heard opinions, but I haven't heard any explanation of why quantizing the pressure altitude is either unrealistic *or* unhelpful. I have not, and I don't think Dave Perry has either, expressed optinions to indicate that the pressure altitude should not be quantized. What we have said is that indicated altitude should not be quantized. -- Roy Vegard Ovesen - 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.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] altimeter, encoder, and kap140
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, but introduces highly unrealistic complexity and obscurity, especially if a single instance is required to accept multiple settings as input. I have not, and I don't think Dave Perry has either, expressed optinions to indicate that the pressure altitude should not be quantized. What we have said is that indicated altitude should not be quantized. My version of the altimetry object does not quantize the indicated output except insofar as it is based on the pressure altitude which might be (upon request) quantized. This is entirely realistic and natural behavior for a backup altimeter indication based on encoder output, such as we sometimes have in real life. Again, I have not heard any *rationale* for providing a fully-analog indicated altitude in cases where the underlying pressure altitude is quantized. This seems conspicuously unrealistic. I cannot imagine any real- life instrument that would or could work that way. If I'm wrong about that, the easiest thing to do is explain what instrument you have in mind ... then it will be straightforward to model that instrument. I am not in favor of a model instrument that is conspicuously unlike any real-world instrument. I'm a real-world kind of guy. Offering a quantized pressure altitude is realistic and makes sense. Having the encoder object also serve, optionally, as a backup altimeter (quantization steps and all) is also realistic and makes sense. The fact that this encoder instance (*not* the steam-gauge instance) can also be tricked into serving as an oracle for computing the Kollsman shift (by subtraction) is not entirely realistic, but is a natural by-product of the realistic features, so I'm happy to support this bit of trickery. Unrealistic features that increase the complexity, obscurity, and inefficiency need *some* kind of rationale, and I still haven't heard that. The two-instance solution has been available for many days now, along with instructions on how to use it. Why not just use it? - 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.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] altimeter, encoder, and kap140
John, I want to go back to the beginning of our discussion that led to a new atmos.cxx and altimeter.cxx. My reason for wanting this code to read the baro setting from the property tree and return to the tree the baro offset is to make sure it is clear that these are different than the altimeter setting and kollsman shift and can/should be different in two types of pilot error. Not being clear in terminology and semantics was one of your original complaints about the existing code. On Sun, 2007-02-11 at 00:22 -0500, John Denker wrote: While we're in the vicinity: Both the Weather Conditions popup and the atis.cxx code rely on the pressure-sea-level-inhg property and use it in ways that the altimeter setting should be used. This is at least a misnomer, and probably a misconception. The altimeter setting is not the same thing as the sea-level pressure. The altimeter setting is something else; it is properly called the altimeter setting. It is also properly called the QNH, although private pilots who fly only in the US may be unfamiliar with the QNH terminology. You convinced me of this. They are different. This property needs to be expunged and replaced with something else, something with a correct name and with correct semantics. Why does this argument apply to the above 2 of the three variable I point out as my rational for adding 5 lines of c++ to your altimeter.cxx, but not to the third. The setting refers to what is entered in the kollsman window and the baro setting refers to what is entered in the kap140. Even with a separate instantiation referred to as an encoder, not having these 5 lines of code forces the user to have save the baro setting variable to the autopilot baro setting location as well as the encoder setting location. This is exactly the type confusing and incorrect semantics you set out to eliminate. Then you suggest that the autopilot nasal should fetch the indicated altitude from the encoder and the pressure altitude from the encoder and subtract to get the baro setting offset. Again adding to the possibility of future confusion and just plane hard to read code. With the 5 additional lines, all using non ambiguous names we avoid what you set out to avoid. I had proposed this subtraction method to Roy off list and he did not want to use a value that was unavailable in real life to the kap140. Regards, -- Dave Perry - 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.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] altimeter, encoder, and kap140
May I add just a short reminder to this discussion This does not belong _directly_ to this topic, still I hope it might bring this discussion with its feet back to the ground. John Denker wrote: I'm a real-world kind of guy. [...] Unrealistic features that increase the complexity, obscurity, and inefficiency need *some* kind of rationale, and I still haven't heard that. John, a significant part of introducing yourself to the list - the one our readers will probably remember best - was you strongheaded instisting of how to read VOR radials. The discussion spawned quite some days and almost everybody on this list who's involved with aviation certainly knew you were wrong. Now, after this experience, if you really want to make people believe that your opinion is correct, then you'd probably better take an approach that differs from this I'm a real-world kind of guy-way. People remember this 'game' and chances are low that they're going to believe in it. The readers of this list are more likely to trust you if you try to convince them with reasonable arguments instead of trying to force facts upon them. I'm certainly pro making FlightGear as realistic as possible, still there are different ways to get there. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- - 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.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] altimeter, encoder, and kap140
On 02/25/2007 04:36 PM, Dave Perry wrote: I want to go back to the beginning of our discussion that led to a new atmos.cxx and altimeter.cxx. My reason for wanting this code to read the baro setting from the property tree and return to the tree the baro offset is to make sure it is clear that these are different than the altimeter setting and kollsman shift and can/should be different in two types of pilot error. Ah, but they are not different in kind. They are merely two separate /instances/ of the same kind. The baro setting is a different name for the *same* idea as the altimeter setting. They play the *same* role, one for the autopilot and one for the analog altimeter. I have tried again and again and again to make the point that it is important to distinguish a) classes, versus b) instances of a class. People keep telling me they understand this conceptual distinction, and then sometimes within a few sentences they trample roughshod over the distinction. Not being clear in terminology and semantics was one of your original complaints about the existing code. Agreed. On Sun, 2007-02-11 at 00:22 -0500, John Denker wrote: While we're in the vicinity: Both the Weather Conditions popup and the atis.cxx code rely on the pressure-sea-level-inhg property and use it in ways that the altimeter setting should be used. This is at least a misnomer, and probably a misconception. The altimeter setting is not the same thing as the sea-level pressure. The altimeter setting is something else; it is properly called the altimeter setting. It is also properly called the QNH, although private pilots who fly only in the US may be unfamiliar with the QNH terminology. You convinced me of this. They are different. This property needs to be expunged and replaced with something else, something with a correct name and with correct semantics. Why does this argument apply to the above 2 of the three variable I point out as my rational for adding 5 lines of c++ to your altimeter.cxx, but not to the third. I don't know what that is trying to say. My point remains that sometimes things are different because they are different classes ... and sometimes they are different because they are different instances of the same class. Back on the 20th of February I explained (with examples) how to deal with this situation by instantiating two instances of the altimeter class. I didn't hear back. I assumed my explanation had been received and understood. The setting refers to what is entered in the kollsman window and the baro setting refers to what is entered in the kap140. Those are two instances of the same class of functionality. They have different names but play closely parallel roles. Even with a separate instantiation referred to as an encoder, not having these 5 lines of code forces the user to have save the baro setting variable to the autopilot baro setting location as well as the encoder setting location. This is exactly the type confusing and incorrect semantics you set out to eliminate. Then you suggest that the autopilot nasal should fetch the indicated altitude from the encoder and the pressure altitude from the encoder and subtract to get the baro setting offset. Again adding to the possibility of future confusion and just plane hard to read code. With the 5 additional lines, all using non ambiguous names we avoid what you set out to avoid. I had proposed this subtraction method to Roy off list and he did not want to use a value that was unavailable in real life to the kap140. I agree that having the blind encoder serve as an oracle for computing the Kollsman shift is a bit of trickery. If this trick offends you, the appropriate remedy is to not use the trick! The remedy is *not* to add additional code to implement the trick in a more-confusing more-obscure less-consistent less-true- to-life way. The whole issue would go away if the model KAP would calculate the Kollsman shift internally, just as a real KAP does. The correct algorithm is documented in detail at http://www.av8n.com/physics/altimetry.htm and can be implemented with near-zero programming effort and near-zero CPU load. To summarize: My recommendations: -- The typical aircraft will have an instance of the altimetry class to serve as the backend for the steam-gauge altimeter. This instance will be configured with no quantization, which is the default. The configuration and the interface are verbatim and literatim identical to the previous altimeter configuration and interface. -- Those aircraft that want an encoder should use a different /instance/ of the same altimetry /object/. Quantization is a configuration option. The configuration is not identical to the old encoder configuration, but it isn't complicated, tricky, or obscure. An example of the configuration appears in the altimeter.cxx code. The runtime interface for the encoder is the
Re: [Flightgear-devel] altimeter, encoder, and kap140
On 02/25/2007 04:49 PM, Martin Spott wrote: John, a significant part of introducing yourself to the list - the one our readers will probably remember best - was you strongheaded instisting of how to read VOR radials. Well: 1) As you know, I changed my mind about how to report radials. 2) The case under discussion was an exceptional case; we all agreed on the other 9 out of 10 cases. It was also grossly off-topic. 3) I was telling the truth about how *I* reported radials, based on my training and my experience talking to New York approach ... who are not known for being unskillful nor over-tolerant of unskillful pilots. Maybe I was wrong all along, maybe practices have changed over time, or maybe it was a regional thing. I don't know and don't much care. I am willing to learn and change over time. 4) Please consider the possibility that someone can be wrong without being dishonest, stupid, or evil. I'm pretty sure I'm not the only person who has ever been wrong. - 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.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] altimeter, encoder, and kap140
I came up with an answer to my own challenge: In the real world there are two types of encoding altimeters: I) The so-called blind encoders are basically just encoders. Their *only* output is digital and quantized. These can be made non-blind by wiring them to a display, but the display will necessarily exhibit quantization steps. II) There is a second type of instrument that is primarily a plain old steam-gauge type altimeter, producing a fully analog non-quantized display in the time-honored way ... plus an encoder disk attached to the mechanism. The analog display is unquantized, while the digital output is quantized. Therefore the quantum configuration option in my altimeter.cxx is ambiguous. In case (I) the quantization should affect the indicated output, while in case (II) it shouldn't. 1a) Arguments as to which behavior should be preferred should not be based on what the autopilot needs. The autopilot is already so complicated that adding the one line needed to perform the quantization within the autopilot -- not within the altimeter -- is IMHO clearly the right way to go. Code is incomparably more expressive than xml, and can easily resolve the ambiguity whichever way is desired. 1b) I would also point out that writing a stepless indicated output to the property tree and then writing a stepped pressure output to the property tree makes it impossible to calculate the Kollsman shift by subtraction. So this -- in combination with autopilot code that does not do its own Kollsman calculation -- is a self-inconsistent combination. 2) So the discussion comes down to ultra-simple xml-only instruments. We already have a way of producing a stepless indicated altitude output (i.e. the ordinary altimeter object with no quantization). Therefore if the quantization feature is to have any nontrivial value, it should produce stepwise indicated altitude outputs, such as would be seen in certain backup altimeter displays. This sounds to me like two solid arguments why if the encoder writes an indicated altitude at all, it should be based on the pressure altitude (quantization and all) plus a simple Kollsman shift. That's how I originally coded it. Now I know why I coded it that way :-). - 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.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] altimeter, encoder, and kap140
On Sun, 2007-02-25 at 15:14 -0500, John Denker wrote: On 02/25/2007 02:39 PM, Roy Vegard Ovesen wrote: I have not, and I don't think Dave Perry has either, expressed optinions to indicate that the pressure altitude should not be quantized. What we have said is that indicated altitude should not be quantized. My version of the altimetry object does not quantize the indicated output except insofar as it is based on the pressure altitude which might be (upon request) quantized. This is entirely realistic and natural behavior for a backup altimeter indication based on encoder output, such as we sometimes have in real life. Again, I have not heard any *rationale* for providing a fully-analog indicated altitude in cases where the underlying pressure altitude is quantized. This seems conspicuously unrealistic. I cannot imagine any real- life instrument that would or could work that way. If I'm wrong about that, the easiest thing to do is explain what instrument you have in mind ... then it will be straightforward to model that instrument. I am not in favor of a model instrument that is conspicuously unlike any real-world instrument. I have no problem having the rounding apply to the indicated altitude since we can have a separate encoder instantiation where I can ignore that value. I just misread your intent and rearranged the lines to give the performance I thought you intended, that is digitized PA but analogue indicated altitude. So I agree what I thought was a bug is the feature you intended. Sorry. The fact that this encoder instance (*not* the steam-gauge instance) can also be tricked into serving as an oracle for computing the Kollsman shift (by subtraction) is not entirely realistic, but is a natural by-product of the realistic features, so I'm happy to support this bit of trickery. Here I have two problems. 1) You compute the kollsman shift and the PA, but only report PA. What I added was to report the kollsman shift for the baro setting. The KAP140 should approximate this but the model to do this approximation should only be in one place. So having the encoder compute this and put in in the property tree is a reasonable request. 2) Getting the baro setting to the encoder should be done in an unconfusing way. Here is what avoiding 5 lines of c++ that I think are very clear forces in nasal: encoder=/Instrumentation/altimeter[1]/ ... propEncoder = props.globals.getNode(encoder, 1); ... encoderBaroSettingInhg = propEncoder.getNode(setting-inhg, 1); # An extra initialize in apInit encoderBaroSettingInhg.setDoubleValue(baroSettingInhg); ... # save the updated baro setting to /Instrumentation/altimeter[1]/setting-inhg encoderBaroSettingInhg.setDoubleValue(baroSettingInhg) ... # update altFt in altAlert No matter what, we retrieve a rounded PA from an instantiation of the altimeter. What is contested is how to model the baro shift. What you suggest is retrieve the indicated altitude and then subtract the PA to get the encoder baro shift and then add back in the PA. This means the kap140.nas has to retrieve the value it cannot have in reality (indicated altitude) and wants to approximate from values it does have (PA and baro shift), and then create the value it needs to approximate (baro shift) from values it has by subtracting the PA and then add it back in??? This is very unrealistic! The code to compute and save the baro shift using the atmos model is one line in c++ and uses a function I cannot call from Nasal. (see below). This is 5 new lines of code in kap140.nas before the altFt update. Roy does not want to just use the indicated altitude in the target altitude compare since it is not available to the real KAP140. We are assuming that the real KAP140 uses an approximation to the kollsman shift from the baro setting. The model to do this approximation is a function in your atmos/altimeter code and to use that model in a non confusing way is one of the contested 5 lines as _baro_offset_node-setDoubleValue(_altimeter.kollsman_ft(baro_setting)); Unrealistic features that increase the complexity, obscurity, and inefficiency need *some* kind of rationale, and I still haven't heard that. I claim that it is neither unrealistic nor adding complexity, obscurity, or inefficiency to want to use the interpolation model for the kollsman shift in a clear and direct way to approximate the baro shift. That line is clear. It is also clear that baro_setting came from the KAP140 and not from the altimeter setting in the added 5 lines of code. Removing these 5 new lines of code does not meet you stated original goal. Don't confuse the nomenclature; if something needs to be distinct, keep it distinct in the code. Summary proposed compromise: 1) Use an encoder instantiation (altimeter[1]) with quantum = 10 as well as altimeter[0] with quantum = 0. 2) Leave the 5 new lines to allow unambiguous service to autopilot use of the encoder. Regards, --
Re: [Flightgear-devel] altimeter, encoder, and kap140
On Sun, 2007-02-25 at 16:19 -0700, Dave Perry wrote: What is contested is how to model the baro shift. What you suggest is retrieve the indicated altitude and then subtract the PA to get the encoder baro shift and then add back in the PA. This means the kap140.nas has to retrieve the value it cannot have in reality (indicated altitude) and wants to approximate from values it does have (PA and baro shift), and then create the value it needs to approximate ^^^ Correction: values it does have (PA and baro setting) (baro shift) from values it has by subtracting the PA and then add it back in??? This is very unrealistic! The code to compute and save the baro shift using the atmos model is one line in c++ and uses a function I cannot call from Nasal. (see below). Summary proposed compromise: 1) Use an encoder instantiation (altimeter[1]) with quantum = 10 as well as altimeter[0] with quantum = 0. 2) Leave the 5 new lines to allow unambiguous service to autopilot use of the encoder. John, if you don't like the added 5 lines, why not just put the kollsman shift on the property tree? Then any autopilot can approximate the baro shift by putting the baro setting to /Instrumentation/altimeter[1]/setting-inhg and picking up the kollsman shift for the baro shift. At the start of this discussion, I thought you wanted just one model of the atmosphere. So it is a bad idea to have each autopilot use it's own model. Users are going to want to ignore different returned values for different instantiations for realism reasons. Regards, -- Dave Perry - 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.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] altimeter, encoder, and kap140
On 02/25/2007 07:06 PM, Dave Perry wrote: Summary proposed compromise: 1) Use an encoder instantiation (altimeter[1]) with quantum = 10 as well as altimeter[0] with quantum = 0. Yes, that seems entirely reasonable. 2) Leave the 5 new lines to allow unambiguous service to autopilot use of the encoder. How about 2') Have the autopilot calculate the Kollsman shift on its own. At the start of this discussion, I thought you wanted just one model of the atmosphere. So it is a bad idea to have each autopilot use it's own model. Users are going to want to ignore different returned values for different instantiations for realism reasons. But a real autopilot *does* have its own model ... not a model of the real atmosphere, but an ISA-model atmosphere (or, more precisely, a Kollsman-model atmosphere). Ditto for real altimeters. If you want to start with the canonical Kollsman model and then depart from it as a model of realistic instrumental imperfection, that's entirely reasonable. What was not reasonable was the previous altimeter, that used an algorithm bearing no known resemblance to reality, and was off by hundreds of feet under some perfectly ordinary conditions. means the kap140.nas has to retrieve the value it cannot have in reality (indicated altitude) and wants to approximate from values it does have (PA and baro shift), The real KAP does not have access to an oracle of any kind that will perform the Kollsman calculation for it. Arguing about which type of oracle is more realistic is an argument about members of the null set. Not the sort of discussion we ought to be having. The exact FAA-approved Kollsman calculation is well understood and easily implemented in nasal code. I know I previously pointed out that it was possible to use the altimeter as an oracle ... but that was before I realized how seriously people were worried about values it cannot have in reality. If you care about reality at that level, doing the Kollsman calculation within the autopilot code is the only realistic option. - 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.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] altimeter, encoder, and kap140
On 2/12 Dave Perry wrote: It occurred to me that we should use John's interpolation function in several other places: 1. We use a form of this function in kap140.nas without the efficiency of the interpolation. 2. The encoder uses a similar interpolation that a general form of this function could replace. ... What I am proposing is to create a C++ function (say height_ft) that has two arguments, P0 and P1 that does the interpolation in John's new patch using his constants. To which John responded: That is the same spirit as what I was suggesting in the opening paragraphs of: http://www.av8n.com/fly/fgfs/README.altimetry.html Then the kap140.nas could use that function, the encoder could use that function to compute PA ... This would have the added advantage of standardizing the constants used in all three applications. I thought that would be one of the outcomes of your effort. On Sun, 2007-02-25 at 19:58 -0500, John Denker wrote: How about 2') Have the autopilot calculate the Kollsman shift on its own. That is counter to the same spirit you reference above. That is why I wrote: At the start of this discussion, I thought you wanted just one model of the atmosphere. So it is a bad idea to have each autopilot use it's own model. Users are going to want to ignore different returned values for different instantiations for realism reasons. But a real autopilot *does* have its own model ... not a model of the real atmosphere, but an ISA-model atmosphere (or, more precisely, a Kollsman-model atmosphere). The present cvs kap140 does approximate the baro shift with such a model as you well know. Since you already compute the kollsman shift for the value of setting-inhg, why not save that value to the property tree? That would accomplish giving the kap140, the altimeter, and the encoder access to your improved interpolation model for the two terms in equation (15) in your paper. You compute both PA and the kollsman shift, but only allow others access to PA. That only requires two additional lines of c++ in altimeter.cxx plus a declare in altimeter.hxx. I can integrate a 2nd instantiation into the kap140 including the identified changes to altimeter.cxx and altimeter.hxx. Regards, -- Dave Perry - 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.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] altimeter, encoder, and kap140
Hi All, I have been communicating off and on with both John Denker and Roy Vegard Ovesen off list concerning this topic. I am running an edit of John's most recent altimetry patch and have modified kap140.nas, altimeter.cxx, and altimeter.hxx so that the altitude capture in the kap140 is using the same atmosphere model as the altimeter. It is also using the altimeter.cxx as the encoder, bypassing encoder.cxx. When near sea level, the cvs encoder.cxx did not report the same pressure altitude as the altimeter with kollsman set to 29.92. By replacing the encoder.cxx with the new altimeter.cxx, this is fixed. Why does the kap140 need info from the altimeter other than the pressure altitude? The altitude capture in the current cvs kap140.nas used altFt = pressureAltitude + hpartial * (baroSetting - 29.92) and compared this to the target altitude. The problem with this is two fold. The second term is a linear approximation to the h(baroSetting,29.92). But h( , ) was the function before altAlert in kap140.nas. It used two transcendental functions each frame and was not the same function now used by John to model the atmosphere (close in the troposphere, but not the same). The attached patch uses the PA (rounded to the nearest 10 ft.) from the new altimeter.cxx and a baro-offset = kollsman offset with baro setting replacing the altimeter setting. Why is that necessary? Well, there are three different numbers that matter. There is the Alt inhg returned by metar. There is the setting the pilot puts in the kollsman window, and there is the baro setting the pilot enters in the KAP140. The KAP140 must use the baro setting and the PA returned by the encoding altimeter to get the term altFt it compares to the target altitude. It has access to the static pressure according to the KAP140 manual, but could use a power function approximation similar to what John's altimeter uses to compute the baro offset w/o knowing the static pressure. Then altFt = PA - baroOffset. The patch attached models the following pilot errors correctly. Case 1: Pilot enters the QNH in baro setting on the KAP140 but does not enter QNH correctly in the kollsman window of the altimeter. If he sets the target altitude and arms it, the AC will still capture the right altitude, but the indicated altitude will be wrong. Case 2: Pilot enters QNH correctly in the kollsman window on the altimeter, but sets baro setting wrong. Even if he sets the target altitude right and arms it, the AC will capture the wrong altitude. For example, if the baro setting is 29.92, the KAP140 will capture PA which is only correct if QNH = 29.92. But since he got QNH right in the kollsman window, the indicated altitude will be correct, telling him he captured the wrong altitude. I modified John's code so the altimeter picks up baro setting from /autopilot/KAP140/settings/baro-setting-inhg and uses this to compute baroOffset using the same interpolation function model, _altimeter.kollsman_ft(baro_setting). I also rearranged the truncation of pressure altitude in John's code so the indicated altitude is computed before the pressure altitude is rounded and saved. John, you may have already caught and corrected this bug. I consider this combined patch to be a significant improvement to FlightGear. Where you will notice the improvement the most is 1) Mountain airports with QNH != 29.92, 2) Flying down glide slopes to a mountain airport (indicated DH will be close to accurate, often avoiding a crash situation should you fly the approach with the present cvs.) 3) The captured altitude for the KAP140 will be as accurate as it is with real autopilots. I am sure John can point out other situations the new atmosphere model improves. I want both John and Roy to try this patch before we consider submitting it to cvs. Of course, anyone can try it and comment. Is the encoder used anywhere other than by the KAP140? If so, we should use a separate instantiation as suggested by John. Regards, -- Dave Perry altimetry.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.phpp=sourceforgeCID=DEVDEV___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] altimeter, encoder, and kap140
On 02/25/2007 12:30 AM, Dave Perry wrote: I have been communicating off and on with both John Denker and Roy Vegard Ovesen off list concerning this topic. I am running an edit of John's most recent altimetry patch and have modified kap140.nas, altimeter.cxx, and altimeter.hxx so that the altitude capture in the kap140 is using the same atmosphere model as the altimeter. It is also using the altimeter.cxx as the encoder, bypassing encoder.cxx. When near sea level, the cvs encoder.cxx did not report the same pressure altitude as the altimeter with kollsman set to 29.92. By replacing the encoder.cxx with the new altimeter.cxx, this is fixed. Roger. Why does the kap140 need info from the altimeter other than the pressure altitude? The altitude capture in the current cvs kap140.nas used altFt = pressureAltitude + hpartial * (baroSetting - 29.92) and compared this to the target altitude. The problem with this is two fold. The second term is a linear approximation to the h(baroSetting,29.92). But h( , ) was the function before altAlert in kap140.nas. It used two transcendental functions each frame and was not the same function now used by John to model the atmosphere (close in the troposphere, but not the same). By saving the result, you only need to do two transcendental functions every time the pilot changes the baro setting (not two per frame) which seems affordable. By the way ... avoiding transcendental functions is not necessarily necessary nor sufficient for good programming. I've measured a few examples relevant to FG, and found that the transcendental functions are only percentage points slower than the interpolation tables that are being used to speed things up. It seems likely that a table small enough to be fast isn't accurate, and a table big enough to be accurate isn't fast. As the saying goes, premature optimization is the root of all evil. I would like to see some actual factual measurements before making very many decisions about what to optimize and how to optimize it. there are three different numbers that matter. There is the Alt inhg returned by metar. There is the setting the pilot puts in the kollsman window, and there is the baro setting the pilot enters in the KAP140. Yes, that's clear. The KAP140 must use the baro setting and the PA returned by the encoding altimeter to get the term altFt it compares to the target altitude. It has access to the static pressure according to the KAP140 manual, but could use a power function approximation similar to what John's altimeter uses to compute the baro offset w/o knowing the static pressure. I don't see how that could possibly work. Encoded pressure altitude and static pressure are two versions of the same idea. Comparing them cannot give any information about the present value and/or desired value of the baro setting. Then altFt = PA - baroOffset. The patch attached models the following pilot errors correctly. What patch? Case 1: Pilot enters the QNH in baro setting on the KAP140 but does not enter QNH correctly in the kollsman window of the altimeter. If he sets the target altitude and arms it, the AC will still capture the right altitude, but the indicated altitude will be wrong. That's clear. Case 2: Pilot enters QNH correctly in the kollsman window on the altimeter, but sets baro setting wrong. Even if he sets the target altitude right and arms it, the AC will capture the wrong altitude. For example, if the baro setting is 29.92, the KAP140 will capture PA which is only correct if QNH = 29.92. But since he got QNH right in the kollsman window, the indicated altitude will be correct, telling him he captured the wrong altitude. That's clear. I modified John's code so the altimeter picks up baro setting from /autopilot/KAP140/settings/baro-setting-inhg and uses this to compute baroOffset using the same interpolation function model, _altimeter.kollsman_ft(baro_setting). No comment until I see the code. I also rearranged the truncation of pressure altitude in John's code so the indicated altitude is computed before the pressure altitude is rounded and saved. John, you may have already caught and corrected this bug. I quite intentionally rounded the pressure altitude not the indicated altitude. This is a realistic model of the action of a blind encoder, which knows nothing of the baro setting. There are multiple mechanical and electrical reasons why the blind encoder should round the pressure altitude. I see no corresponding reasons why the autopilot should round the indicated altitude, or expect the encoder to do so. In short, I see no reason to think that it is a bug to apply (when requested!) rounding to the pressure altitude. I consider this combined patch to be a significant improvement to FlightGear. Where you will notice the improvement the most is 1) Mountain airports with QNH != 29.92, 2) Flying down glide slopes to a
