Re: [Flightgear-devel] Zero lag altimeter
From: John Denker [EMAIL PROTECTED] I'm under the impresssion that the property called environment/pressure-inhg[0] has a lag computed into the final value. Is that correct or is that the instantaneous value or pressure level the aircraft is at and what I'm looking for? Close. The trick is that altimeters and suchlike are not (and should not be) connected directly to environment/pressure. They are connected to /systems/static/pressure-inhg ... and *that* has an unrealistically huge lag built into it. I would argue that there should be some lag, just not nearly so much. [...] Decreasing the static-system lag from 1 (the previous compiled-in value) to .1 or even .2 makes things look instantaneous or nearly so. There are three types of altimeter in common use: (1) Air data computers, which go to a lot of trouble to report the instantaneous value. Aircraft with such instruments should use the environment value, (2) Basic barometric altimeters, which should have a long lag (second or so, in my experience). Small aircraft manufactured before the 1970s tend to have these, I believe, and this behavior is modelled by the systems value, (3) Corrected barometric altimeters, which have a relatively short lag that is just about observable by eye (therefore presumably around a tenth of a second) when operated in an IFR-like way. Small aircraft of recent manufacture tend to have these, unless the aircraft is aerobatic. As far as I know, we don't have a model for this in FlightGear. Correcting altimeters contain a small accelerometer that detects the vertical component and, using a small bellows, injects a high pass filtered contribution into the static pressure value. The idea is that an increase in vertical acceleration (i.e. more than gravity) implies the aircraft is going up and so the bellows temporarily sucks some air out of the static pressure and causes the instrument to indicate a climb sooner than it would otherwise. Equivalently for descent. This works great for operations in IFR, so normal category light aircraft with an IFR panel tend to have these installed (unless it is an old aircraft with original equipment). To the pilot in IMC, the improvement is comparable to flying with a gyro compass instead of with a wet compass. Of course, the bellows trick of (3) goes wrong for (a) increased G maneuvering and (b) unusual attitudes: (a) If I make a 60 degree banked turn, so the aircraft pulls 2 gravities, the bellows will (for a second or so) cause the altimeter to indicate a higher value than is actually correct. However, providing I roll smoothly into the turn, so the acceleration force picks up gradually, the altimeter information continues to be useful and is not particularly odd. (b) If I'm upside down, changes in apparent G force should have the reverse effect on the altimeter. Some instruments limit out for zero or negative G, so the correction is disabled in unusual attitudes. I suppose it's feasible that there are some which use the absolute value of the apparent G force so they work relatively well when upside down ... but I haven't come across that. Hope that helps ... - 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] Zero lag altimeter
On 02/25/2007 12:32 PM, Alex Perry wrote: There are three types of altimeter in common use: (1) Air data computers, which go to a lot of trouble to report the instantaneous value. Right. Aircraft with such instruments should use the environment value, Is that a typo? I don't know of any environment variable relevant to altitude other than /environment/pressure-inhg. Using that bypasses the lag associated with the /systems/static/pressure-inhg which seems like a small and unimportant part of the overall air-data task. It also bypasses the /systems/static/serviceable check, which seems like a bad idea. There is no reason to have a long lag in the static system. It's unrealistic, as you can verify by /gently/ blowing a breath of air /towards/ the static port while somebody observed the airspeed indication. The response time is very fast. I did say gently, right? I did say towards the static port, so as not to make a tight seal, so as not to create very much pressure, right? Let's just get rid of the long static-system lag. (2) Basic barometric altimeters, which should have a long lag (second or so, in my experience). Small aircraft manufactured before the 1970s tend to have these, I believe, and this behavior is modelled by the systems value, I'm moderately happy to say I've never seen an altimeter with such a long lag. (3) Corrected barometric altimeters, which have a relatively short lag that is just about observable by eye (therefore presumably around a tenth of a second) when operated in an IFR-like way. Small aircraft of recent manufacture tend to have these, unless the aircraft is aerobatic. As far as I know, we don't have a model for this in FlightGear. Correcting altimeters contain a small accelerometer that detects the vertical component and, using a small bellows, Really? I know that's how an IVSI works, but I've never seen an altimeter that did that, or needed to do that. Do you have a reference that gives information on that? I get 29 hits from http://www.google.com/search?q=correcting-altimeter only one of which seems even tangentially relevant. Does it perhaps go by another name? Googling for instanteous altimeter is not rewarding. Compared to an altimeter, a VSI has a much harder problem. An ordinary VSI (not IVSI) has a verrry annoying time lag, comparable to a student pilot's reaction time, and therefore more-or-less guaranteed to cause confusion and PIO (pilot induced oscillations). - 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] Zero lag altimeter
From: John Denker I don't know of any environment variable relevant to altitude other than /environment/pressure-inhg. Using that bypasses the lag associated with the /systems/static/pressure-inhg which seems like a small and unimportant part of the overall air-data task. It also bypasses the /systems/static/serviceable check, which seems like a bad idea. True. But the servicability of air data goes as the whole system - you'd probably be better having a servicability flag for the whole thing. I don't think you can have just the altimeter portion of an air data installation fail, unless you're asserting that the display piece broke. There is no reason to have a long lag in the static system. Interesting point, yes, you're right. On the modern instruments, anyway. Maybe the old lag was actually due to manufacturing tolerances and the like. Let's just get rid of the long static-system lag. Maybe the long lag should be a non-default option, used in old aircraft. Really? I know that's how an IVSI works, but I've never seen an altimeter that did that, or needed to do that. Yeah, although I recall the transition to precision altimeters having some funny gizmo to get rid of the old lags, I don't recall the details ... and am just assuming they used the same technique as a IVSI. Sorry, can't help there. Compared to an altimeter, a VSI has a much harder problem. Yeah. But that VSI lag has a different origin due to the instrument being inherently a single pole high pass filter. --- [This E-mail scanned for viruses by Declude Virus] - 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] Zero lag altimeter
On 02/25/2007 06:36 PM, Alex Perry wrote:
There is no reason to have a long lag in the static system.
Interesting point, yes, you're right. On the modern instruments, anyway.
Maybe the old lag was
actually due to manufacturing tolerances and the like.
There are no relevant tolerances in the /static subsystem/
strictly speaking (as opposed to the altimeter). The static
subsystem is basically just a bunch of tubing. Its lag time
is set by the smallness of the hole(s) in the static port(s),
and by the volume of tubes and instrument cases. This doesn't
amount to much in typical aircraft.
What the pilot perceives as altimeter lag in real aircraft
comes from friction within the altimeter case. The FAA
regulates how much vertical-speed-dependence an airworthy
altimeter can have ... but the limits are higher than you
might have hoped. This could substantially cut into your
margins during a rapid step-down to MDA on a localizer
approach.
Let's just get rid of the long static-system lag.
Maybe the long lag should be a non-default option, used in old aircraft.
Well, I wrote the code to make the static subsystem accept
non-default values. See below, and/or the relevant hunk in
http://www.av8n.com/fly/fgfs/atmo.diff
So the discussion comes down to what the new default should be.
I provisionally left it at 1 for compatibility, but 0.1 would
be more realistic. If we changed it to 0.1 I doubt anybody
would complain.
===
diff --git a/src/Systems/static.cxx b/src/Systems/static.cxx
index b3c916d..3fdbc20 100644
--- a/src/Systems/static.cxx
+++ b/src/Systems/static.cxx
@@ -11,7 +11,10 @@
StaticSystem::StaticSystem ( SGPropertyNode *node )
:
_name(node-getStringValue(name, static)),
-_num(node-getIntValue(number, 0))
+_num(node-getIntValue(number, 0)),
+// Unrealistic default, but compatible with previous version of this
+// module, which had no tau at all:
+_tau(node-getDoubleValue(tau, 1))
{
}
@@ -45,11 +48,11 @@ void
StaticSystem::update (double dt)
{
if (_serviceable_node-getBoolValue()) {
-
+double trat = _tau ? dt/_tau : 100;
double target = _pressure_in_node-getDoubleValue();
double current = _pressure_out_node-getDoubleValue();
// double delta = target - current;
-_pressure_out_node-setDoubleValue(fgGetLowPass(current, target, dt));
+_pressure_out_node-setDoubleValue(fgGetLowPass(current, target,
trat));
}
}
-
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] Zero lag altimeter
On 02/22/2007 01:27 AM, John wrote: Modern avionics and air data computers provide an instantaneous vertical velocity and altimeter. Yes. Is there a property/variable in flightgear that does not contain the lag present in simple baro systems? Yes. I'm under the impresssion that the property called environment/pressure-inhg[0] has a lag computed into the final value. Is that correct or is that the instantaneous value or pressure level the aircraft is at and what I'm looking for? Close. environment/pressure is (and always has been) the real pressure. It is instantaneous. The trick is that altimeters and suchlike are not (and should not be) connected directly to environment/pressure. They are connected to /systems/static/pressure-inhg ... and *that* has an unrealistically huge lag built into it. I would argue that there should be some lag, just not nearly so much. Solving this problem is easy: 1a) Grab the c++ code for my new altimetry and barometry module: http://www.av8n.com/fly/fgfs/atmo.diff 1b) Apply the patch and recompile. This fixes it so that the static system and alimter(s) have lag times that are are configurable (no longer just compiled in). 2) Edit or patch your .xml files to configure the tau values for your static system *and* your altimeter(s). Apply this patch http://www.av8n.com/fly/fgfs/inst.diff or at least look at it to see how things are done. Decreasing the static-system lag from 1 (the previous compiled-in value) to .1 or even .2 makes things look instantaneous or nearly so. - 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] Zero lag altimeter
On Thursday 22 February 2007 13:28, John Denker wrote: Solving this problem is easy: I'd say so too... for exact values rather which don't rely on modelled instrumentation can't one just use the values provided under /position in the property tree? Cheers, AJ - 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] Zero lag altimeter
On 02/22/2007 08:32 AM, AJ MacLeod wrote: On Thursday 22 February 2007 13:28, John Denker wrote: Solving this problem is easy: I'd say so too... for exact values rather which don't rely on modelled instrumentation can't one just use the values provided under /position in the property tree? It depends on what you're trying to model, and whether you want to have any semblance of realism. -- One can imagine a super-fancy inertial navigation system that could report the /position of the aircraft as suggested above. ++ However, most aircraft do not have such a thing. ++ If you did have such a thing, you would not be allowed to use it as your primary altimeter. There are regulations as to what altitude must be flown, and these regulations are written in terms of barometric altitude. That is not equivalent to true altitude. ++ Some of us (not all, of course) would like to get FG to the point where it would be usable as a procedures trainer. This requires modeling the instruments warts and all. As a start, this includes modeling the nonidealities of the barometric altimeter ... such as H-A-L-T among others. - 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] Zero lag altimeter
On Thursday 22 February 2007 14:02, John Denker wrote: ++ Some of us (not all, of course) would like to get FG to the point where it would be usable as a procedures trainer. This requires modeling the instruments warts and all. As a start, this includes modeling the nonidealities of the barometric altimeter ... such as H-A-L-T among others. Yes, obviously. Frankly I would be astonished if anyone at all didn't want FG's instrumentation to be as realistic and flexibly modelled as possible... I was just pointing out that if one wants instant magical readouts of exact altitude, AFAICS it's already easily available in the property tree. I'll be pleased to see your improved altimeter etc committed when it's ready... I get a constant trickle of bug reports about the Lightning altimeter which stops going up long before the a/c itself does! Cheers, AJ - 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] Zero lag altimeter
AJ MacLeod wrote: On Thursday 22 February 2007 13:28, John Denker wrote: Solving this problem is easy: I'd say so too... for exact values rather which don't rely on modelled instrumentation can't one just use the values provided under /position in the property tree? That would give you position in inertial space, but aircraft have to fly on pressure levels to maintain desired altitudes and/or flight levels. Which also needs to be adjusted with the Kollsman setting for reference to sea level. Even the most advanced avionics/inertial systems still rely on this use of air pressure to define aircraft altitude. Just that air data computers can correct for things like installation errors, lags, and such. Thanks John for your info and help Regards John W. - 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] Zero lag altimeter
Hi, Modern avionics and air data computers provide an instantaneous vertical velocity and altimeter. Is there a property/variable in flightgear that does not contain the lag present in simple baro systems? I'm under the impresssion that the property called environment/pressure-inhg[0] has a lag computed into the final value. Is that correct or is that the instantaneous value or pressure level the aircraft is at and what I'm looking for? Thanks John W - 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
