Re: [Flightgear-devel] b1900d asi suggestion

[Syd&Sandy <syd...@te...>]

On Sat, 16 Feb 2008 10:28:24 +0100
"K. Hoercher" <wb...@gm...> wrote:

> Hi!
> 
> According to 
> http://www.pprune.org/forums/archive/index.php/t-166572.html
> http://www.airweb.faa.gov/Regulatory_and_Guidance_Library/rgMakeModel.nsf/0/4bd70d173cbc5f4586256fb80048f054/$FILE/A24CE.pdf
> and others at google's discretion the b1900d is restricted to a
> Vmo=248KIAS and a Mmo of 0.48 at an, allegedly, pressure altitude of
> 13200ft or above. That restriction is "somehow" displayed by the barber
> pole in the airspeed indicator. Short of knowing (despite some search)
> how the asi works to that effect I suggest something like the patch
> attached.
> 
> The change in the asi300gauge.ac would reset the barber pole to start
> from a position where its lower edge meets the upper one of the airspeed
> needle. That allows for it to be driven through the illinear scaling of 
> the modelled asi mimicking the airspeed needle animation.
> 
> I have cutoff its movement at an arbitrary 178(KIAS), as that would be
> way beyond any specified operating limits.
> 
> The calculation itself is a bit messy. I think the changeover point is
> a made up reference to essentially construe a meaning of
> limit=min(Vmo,Mmo). Apparently the equality would be at that pressure 
> altitude in ISA standard day conditions, but could shift somewhat as the
> speed of sound isn't dependent on the pressure itself alone. I decided
> to stick to that published pressure alt restriction until I know 
> positively otherwise.
> 
> As the indicated-speed-kt property is calculated from the density of
> the air (thus including temperature), side-slip, pressure etc. which I
> think would also define the mach number to compare against, I avoided the
> real calculation steps and just took it as a reference to "somehow"
> arrive at a value for representing the Mach 0.48 in the KIAS scale. Any
> noise at low speeds/altitudes can be written off following the sticking
> to the mentioned changeover criterium. That should also minimize the
> computing effort needed every frame.
> 
> The same is perhaps true for not overwriting the property with the Vmo
> every frame. Yeah I know, don't speculatively optimize without
> profiling. I plead guilty on infringing that one; please change as you
> see fit.
> 
> HTH
> K. Hoercher
> 

I,ve added your improvements , it's now in cvs .Thanks .
Cheers

-- 
Syd&Sandy <syd...@te...>