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.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
