On Sun, 2007-02-25 at 01:55 -0500, John Denker wrote: > On 02/25/2007 12:30 AM, Dave Perry wrote: > > > I have been communicating off and on with both John Denker and Roy > > Vegard Ovesen off list concerning this topic. I am running an edit of > > John's most recent altimetry patch and have modified kap140.nas, > > altimeter.cxx, and altimeter.hxx so that the altitude capture in the > > kap140 is using the same atmosphere model as the altimeter. It is also > > using the altimeter.cxx as the encoder, bypassing encoder.cxx. When > > near sea level, the cvs encoder.cxx did not report the same pressure > > altitude as the altimeter with kollsman set to 29.92. By replacing the > > encoder.cxx with the new altimeter.cxx, this is fixed. > > Roger. > > > Why does the kap140 need info from the altimeter other than the pressure > > altitude? The altitude capture in the current cvs kap140.nas used > > > > altFt = pressureAltitude + hpartial * (baroSetting - 29.92) > > > > and compared this to the target altitude. The problem with this is two > > fold. The second term is a linear approximation to the > > h(baroSetting,29.92). But h( , ) was the function before altAlert in > > kap140.nas. It used two transcendental functions each frame and was not > > the same function now used by John to model the atmosphere (close in the > > troposphere, but not the same). > > By saving the result, you only need to do two transcendental > functions every time the pilot changes the baro setting (not > two per frame) which seems affordable. > The real issue here is that the function used is not the same function that the altimeter is using.
> By the way ... avoiding transcendental functions is not necessarily > necessary nor sufficient for good programming. I've measured a few > examples relevant to FG, and found that the transcendental functions > are only percentage points slower than the interpolation tables that > are being used "to speed things up". It seems likely that a table > small enough to be fast isn't accurate, and a table big enough to be > accurate isn't fast. > > As the saying goes, premature optimization is the root of all evil. > I would like to see some actual factual measurements before making > very many decisions about what to optimize and how to optimize it. > > > there > > are three different numbers that matter. There is the "Alt inhg" > > returned by metar. > There is the "setting" the pilot puts in the > > kollsman window, and there is the baro setting the pilot enters in the > > KAP140. > > Yes, that's clear. > > > The KAP140 must use the baro setting and the PA returned by the > > encoding altimeter to get the term altFt it compares to the target > > altitude. It has access to the static pressure according to the KAP140 > > manual, but could use a power function approximation similar to what > > John's altimeter uses to compute the baro offset w/o knowing the static > > pressure. > > I don't see how that could possibly work. Encoded pressure altitude > and static pressure are two versions of the same idea. Comparing > them cannot give any information about the present value and/or > desired value of the baro setting. > I am now not using the static pressure. The old linear approximation, hpartial, did use the static pressure. > > > Then > > > > altFt = PA - baroOffset. > > > > The patch attached models the following pilot errors "correctly". > > What patch? > It was remove by Sorceforge, but was attached to the e-mail. Are you getting the e-mails sent to the list? > > Case 1: Pilot enters the QNH in baro setting on the KAP140 but does not > > enter QNH correctly in the kollsman window of the altimeter. If he sets > > the target altitude and arms it, the AC will still capture the right > > altitude, but the indicated altitude will be wrong. > > That's clear. > > > Case 2: Pilot enters QNH correctly in the kollsman window on the > > altimeter, but sets baro setting wrong. Even if he sets the target > > altitude right and arms it, the AC will capture the wrong altitude. For > > example, if the baro setting is 29.92, the KAP140 will capture PA which > > is only correct if QNH = 29.92. But since he got QNH right in the > > kollsman window, the indicated altitude will be correct, telling him he > > captured the wrong altitude. > > That's clear. > > > I modified John's code so the altimeter picks up baro setting from > > /autopilot/KAP140/settings/baro-setting-inhg > > and uses this to compute baroOffset using the same interpolation > > function model, _altimeter.kollsman_ft(baro_setting). > > No comment until I see the code. I will forward it to you off list. > > > I also rearranged the truncation of pressure altitude in John's code so > > the indicated altitude is computed before the pressure altitude is > > rounded and saved. John, you may have already caught and corrected this > > bug. > > I quite intentionally rounded the pressure altitude not the > indicated altitude. This is a realistic model of the action > of a blind encoder, which knows nothing of the baro setting. > There are multiple mechanical and electrical reasons why the > blind encoder should round the pressure altitude. I see no > corresponding reasons why the autopilot should round the > indicated altitude, or expect the encoder to do so. > > In short, I see no reason to think that it is a bug to apply > (when requested!) rounding to the pressure altitude. You must not have realy tried your patch in this area. Your patch used the rounded PA to compute the indicated altitude. That makes the altimeter jump in 10 ft jumps. I just changed the order of the lines of code to compute the indicated altitude with the un-rounded PA and save the indicated altitude to the property node before rounding the PA. > > > I consider this combined patch to be a significant improvement to > > FlightGear. Where you will notice the improvement the most is > > 1) Mountain airports with QNH != 29.92, > > 2) Flying down glide slopes to a mountain airport (indicated DH will be > > close to accurate, often avoiding a crash situation should you fly the > > approach with the present cvs.) > > 3) The captured altitude for the KAP140 will be as accurate as it is > > with real autopilots. > > > > I am sure John can point out other situations the new atmosphere model > > improves. > > In particular, non-standard temperature situations, which are > quite wrongly handled by the existing atmosphere model. > > Let's keep straight two ideas: > 1) Improving the barometry and altimetry, and > 2) Improving the model of the atmosphere. > > Item (2) is incomparably more complicated than item (1). > > I think we have figured out item (1) backwards and forwards. Much > improvement has been made, and there is little room for further > improvement in the fundamentals. From here on it is mostly a > mopping-up operation, as clients (altimeters, autopilots, AWOS > transmitters etc.) make use of the new capabilities. > > As for item (2), FG still has an atmosphere that violates the laws > of physics ... and a user interface that assumes it can violate the > laws of physics at will. Fixing this will be laborious. I've > laid some of the groundwork. Probably the solution will come out > in phases, starting with a two-parameter model (sea-level pressure > and sea-level temperature) followed by more sophisticated multi-layer > models. > > > Is the encoder > > used anywhere other than by the KAP140? > > I've never seen any sign of that. > > OTOH we want the encoder to be a model of a real, standardized, > TSO encoder ... not something unduly entangled with the details of > the KAP140. > > > If so, we should use a separate > > instantiation as suggested by John. > > That is, two instantiations of *one* object. Combining the functionality > of the encoder and altimeter backends into a single module seems like a > win/win decision. Simpler and better. Agreed. > 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 [email protected] https://lists.sourceforge.net/lists/listinfo/flightgear-devel
