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,
--
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
