From: Syd&Sandy <syd...@te...> - 2008-02-16 20:29:25
|
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...> |