Re: [Flightgear-devel] incorrect altimetry
From: John Denker [EMAIL PROTECTED] Please do not write to me saying that SLP must equal QNH when you are flying at sea level. That's true in that narrow special case, but not representative of the general case. Supporting John's point: In real world operations, even when flying at sea level, QNH is often not equal to SLP. In areas with a dense array of airports, the QNH values are intentionally correlated to increase vertical separation in the airspace between aircraft that have taken off from different airports. As a result, even an accurately calibrated altimeter may not indicate field elevation when sitting on the runway. More generally: It is always very important to distinguish between the facts that arise from the simulation of the planet (such as SLP and variation), and the facts that arise from simulation of the airspace (such as QNH and VOR alignment). There tends to be fairly good correlation between the two, because that makes engineering sense, but the differences are routinely enough to kill people. --- [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] incorrect altimetry
On 02/15/2007 04:55 PM, Alex Perry wrote: More generally: It is always very important to distinguish between the facts that arise from the simulation of the planet (such as SLP and variation), and the facts that arise from simulation of the airspace (such as QNH and VOR alignment). Yes. There tends to be fairly good correlation between the two, because that makes engineering sense, but the differences are routinely enough to kill people. That's 100% true. One slight suggestion: I have recently started avoiding the term SLP. In most cases it is possible to substitute Psl := Pressure at Sea Level and thereby reduce the potential for confusion. The reason is that in some places (such as the Remarks section of a METAR) it is possible to find the term SLP used as an abbreviation for Reduced Sea Level Pressure. (You might think that would be abbreviated as RSLP, but I guess the R is silent.) In fact the METAR is referring to the field pressure reduced to sea level along the ISA contour. Under ISA standard-day conditions, the METAR SLP is equal to the Psl ... but this is a special case not representative of the general case. For details, see http://www.av8n.com/physics/altimetry.htm#sec-psl-slp = By way of status report, I'm moderately far along in moving the atmosphere-modeling code out of altimeter.cxx and into its own FGatmodel object that can be used by other instruments. I totally agree that we need to maintain the conceptual distinction between modeling the planet and modeling the instrument. However, there is a huge amount of commonality between the two tasks, so it looks like the altimeter class and the atmosphere-model class will be /derived/ from a common ancestor. I'd like to tell you I am XX% of the way along in this task, but the problem is going to be teaching environment.cxx to use a model of the air-column that does not violate Newton's laws. I've got the model, but retrofitting it into the FG structure may not be smooth sailing. The problem is that environment.cxx offers a baroque interface. It even has a function to set an arbitrary pressure at an arbitrary point in the air column. In almost all cases, this would contravene the laws of physics. This /particular/ function is easy to remove, since AFAICT it has never been called ... but if certain of the other interface functions are actually being used, things could get ugly. - 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] incorrect altimetry
Dave Perry wrote: On Mon, 2007-02-12 at 21:18 -0500, John Denker wrote: When will you put this in cvs? Ha, funny joke. If you want to do the one-for-all function, the sooner the better. I hope I did not offend by poking, reading, and questioning. I know I like it when someone reads seriously and carefully what technical papers I have written. Thanks again for the effort. It took a while for your vision to sink in. Regards, Dave I think the point is that John doesn't have CVS write access... :-) Since the experts seem to agree that this is a good patch: Can somebody take care of committing it? If not, I'd do it, but then it wouldn't be until at least mid-april Cheers, Durk - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] incorrect altimetry
On Mon, 2007-02-12 at 01:41 -0500, John Denker wrote: On 02/11/2007 11:29 PM, Dave Perry wrote: By the way, I agree that the current algorithm in altimeter.cxx is wrong. This evening, I had time to look at your posted patch and I think it would give the right hi. It is, for now, restricted to the troposphere (36000 feet and below). Extending it would be straightforward ... but see remarks below. It does require two calls to ln() and exp() (i.e. the pow function). Have you thought of just using the C term in equation (15) and PA = pressure altitude which is already being computed. That would only require one call to pow(). Or since C = ( hi offset from PA) only varies with S, compute a replacement table for delta h in terms of S and interpolate that table. Then current hi = PA + interp(S). I considered that, but: 1) It's only a factor-of-two improvement, If by improvement you mean improvement in computation time, since you would only compute the table once for all when you modify the code, it should be better than a factor of two improvement since the interpolation should be much less time than a call to pow(). and 2) This code ought not exist at all. It's hard for me to get excited about optimizing something that needs to be thrown out and redesigned. It does not make sense for altimeter.cxx to be implementing its own model of the atmosphere; instead it should be making a structured call to some sort of atmosphere model module. This and related issues are discussed at http://www.av8n.com/fly/fgfs/README.altimetry.html That document has more questions than answers; if anybody has answers please let us know. After reading that README, one might go to the two layer approach. But that should not change much from a pilot's point of view since 36000 18000 ft, so anywhere in the world, S should be 29.92. As long as we have one altimeter model, a pilot at FL200 will be at the same level as any other pilot at FL200. Also, with this correction to altimeter.cxx, you should be at the field elevation on the ground if you set the local altimeter setting. So even going to a two level model seems to me to be over kill. No mater how detailed we make such an atmosphere model, it is still very different than the real atmosphere. My PhD thesis developed numerical algorithms to recognize the onset of chaos in n dimensional dynamical systems (as well as other transitions in stability of solutions) as parameters changed in the system. Should we someday have the compute power to model the fluid dynamics with very precise boundary conditions and initial conditions in time, the model would soon radically diverge from the real weather. This is sometimes referred to as the butterfly effect and strong dependence on initial conditions. Even the best models today cannot tell us what the weather will be like in Denver two days from now. The Lorenz equations which motivated the initial investigations of chaos were developed by Lorenz, a numerical meteorologist. So I propose that we implement the interpolation of C(s) proposed in my last note. I am not an experienced C++ programmer, but have much experience doing numerical analysis in C, Pascal, and Fortran. I am sure I can do this and if I have C++ questions, I can get help on the list. What about your disagreement with the statement that S = barometric pressure that would make hi = 0 MSL which is taught in most ground schools and is an easy consequence of equation (13) in you reference? Regards, Dave - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] incorrect altimetry
On Mon, 2007-02-12 at 11:33 -0500, John Denker wrote: Overnight I thought of a non-disgusting way to optimize the code. A new, muuuch better patch is now at: http://www.av8n.com/fly/fgfs/altimeter.diff The new patch gets the right answer without calling any transcendental functions. This looks really slick, taking advantage of the identical form for the pressure altitude term and the C(S) term in equation (15) so you can interpolate both terms with only one table. Slick! Also its range of validity has been extended to 100,000 feet. This confuses me?? The approximation did not change from your last patch, only the fact that you use interpolation to replace the two calls of pow(). Last night you posted a total rejection of this when I suggested using PA which is correctly available from the encoder and an interpolation of C(S). Have you thought of just using the C term in equation (15) and PA = pressure altitude which is already being computed. That would only require one call to pow(). Or since C = ( hi offset from PA) only varies with S, compute a replacement table for delta h in terms of S and interpolate that table. Then current hi = PA + interp(S). I considered that, but: 1) It's only a factor-of-two improvement, and 2) This code ought not exist at all. It's hard for me to get excited about optimizing something that needs to be thrown out and redesigned. It does not make sense for altimeter.cxx to be implementing its own model of the atmosphere; Do you agree that you are still computing current hi = PA - C(S) except that you use interpolation in a very slick way for both terms? Or am I misreading the new patch? If my interpretation is correct, then what changed your mind so this code should exist, etc.? Also, why is this patch good above the troposphere ( 100,000 ft.)? It should give the same answer as the last patch, only much more efficiently. As was pointed out, once you are above the transition zone, S = 29.92 and C(S) = 0. How about an if to avoid the second interpolation in this case? I am glad you changed your mind! When will you put this in cvs? Regards, Dave -- Dave Perry [EMAIL PROTECTED] - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] incorrect altimetry
On Mon, 2007-02-12 at 17:24 -0700, Dave Perry wrote: On Mon, 2007-02-12 at 11:33 -0500, John Denker wrote: Overnight I thought of a non-disgusting way to optimize the code. A new, muuuch better patch is now at: http://www.av8n.com/fly/fgfs/altimeter.diff The new patch gets the right answer without calling any transcendental functions. This looks really slick, taking advantage of the identical form for the pressure altitude term and the C(S) term in equation (15) so you can interpolate both terms with only one table. Slick! It occurred to me that we should use John's interpolation function in several other places: 1. We use a form of this function in kap140.nas without the efficiency of the interpolation. 2. The encoder uses a similar interpolation that a general form of this function could replace. Since the encoder computes pressure altitude, John could replace one interpolation in altimeter.cxx by referencing the encoder PA. What I am proposing is to create a C++ function (say height_ft) that has two arguments, P0 and P1 that does the interpolation in John's new patch using his constants. Then the kap140.nas could use that function, the encoder could use that function to compute PA and the altimeter would only need to compute C(S) with that function because it could lookup PA from the encoder in the properties. This would have the added advantage of standardizing the constants used in all three applications. The kap140 already uses the PA from the encoder and I would replace the partial differential offset with a nasal C(S) in any case to assure the kap140 altAlert is compatible with John's rounded FAA fiat constants. I think this will get rid of the altitude error in the kap140 altitude capture. Roy and John, you both have contributed in these areas. What do you think of this idea? Regards, Dave -- Dave Perry - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] incorrect altimetry
On 02/12/2007 07:24 PM, Dave Perry wrote: This looks really slick, :-) ... why is this patch good above the troposphere ( 100,000 ft.)? It should give the same answer as the last patch, only much more efficiently. The tabulated numbers come from a three-layer model, namely layers 0 through 2 as defined in the table at the front of this reference: http://www.av8n.com/physics/altimetry.htm See also references therein. You can check the foregoing assertion by looking at the table-entries at the critical (layer-boundary) altitudes. Yesterday's effort used only layer zero, which is why it was valid only within the troposphere, 36000 ft MSL and below. [snipped several more questions, all with the same answer] As was pointed out, once you are above the transition zone, S = 29.92 and C(S) = 0. How about an if to avoid the second interpolation in this case? As you also pointed out, why not just cache P(S) and re-use it in the overwhelmingly likely case that S is unchanged since last time? I am glad you changed your mind! It wasn't much of a change. My previous point was that /small/ changes were a waste of time; making yesterday's code 2x faster would have been a total waste. I also haven't changed my mind about the following: What I am proposing is to create a C++ function (say height_ft) that has two arguments, P0 and P1 that does the interpolation in John's new patch using his constants. That is the same spirit as what I was suggesting in the opening paragraphs of: http://www.av8n.com/fly/fgfs/README.altimetry.html When will you put this in cvs? Ha, funny joke. - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] incorrect altimetry
Hi John, Thanks for answering my questions. I did not realize the interpolation table was for the first three layers. On Mon, 2007-02-12 at 21:18 -0500, John Denker wrote: The tabulated numbers come from a three-layer model, namely layers 0 through 2 as defined in the table at the front of this reference: http://www.av8n.com/physics/altimetry.htm See also references therein. I did not realize the interpolation table was for the first three layers. I can see how you generate a table that gives PA and C(s) for layers with nonzero lapse rate. I assume you use equation (8) solved for h to generate the table when lamda = 0. In this case, how do you account for S = 29.92 being different from Pb? It seems to me that Equation (8) will give us neither PA nor the Kollsman correction. Yesterday's effort used only layer zero, which is why it was valid only within the troposphere, 36000 ft MSL and below. [snipped several more questions, all with the same answer] Agreed, thanks again. I also haven't changed my mind about the following: What I am proposing is to create a C++ function (say height_ft) that has two arguments, P0 and P1 that does the interpolation in John's new patch using his constants. That is the same spirit as what I was suggesting in the opening paragraphs of: http://www.av8n.com/fly/fgfs/README.altimetry.html It is even more important that all those approximating PA or C(S) use one function since the constants change at the boundaries between the layers in your function but not in kap140.nas and the encoder model. By the way, I need to rewrite the Kollsman correction used in kap140.nas. While reading in detail your altimetry.hml, I was using a spread sheet to compare your equations and constants with what was done for the altitude capture in kap140.nas. I want to replace the partial differential approximation with at least the version of C(S) from your first patch. But if the plan is to do the one-for-all C++ function, I would really prefer to wait and use that. For that to work well above the Tropopause, Roy will have to use that function in the encoder. When will you put this in cvs? Ha, funny joke. If you want to do the one-for-all function, the sooner the better. I hope I did not offend by poking, reading, and questioning. I know I like it when someone reads seriously and carefully what technical papers I have written. Thanks again for the effort. It took a while for your vision to sink in. Regards, Dave - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] incorrect altimetry
On 02/13/2007 12:11 AM, Dave Perry wrote: I can see how you generate a table that gives PA and C(s) for layers with nonzero lapse rate. I assume you use equation (8) solved for h to generate the table when lamda = 0. Yes, equation 8, but I don't even need to solve for h. That's the funny thing about an interpolation table. To convert P(h) to h(P) all you need to do is transpose the ordinate -- abscissa on each line of the table. In this case, how do you account for S = 29.92 being different from Pb? It seems to me that Equation (8) will give us neither PA nor the Kollsman correction. I hope I never have to answer questions about that case. I assume that QNH values, considered as pressures, all lie at pressure altitudes *well* within the troposphere. So the Kollsman shift term can be computed by reference to layer 0 using equation 6, not 8. (I believe that if this assumption is not valid, a whole lot of things other than altimeters will be broken. :-) - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] incorrect altimetry
On Sun, 2007-02-11 at 00:22 -0500, John Denker wrote: Both the Weather Conditions popup and the atis.cxx code rely on the pressure-sea-level-inhg property and use it in ways that the altimeter setting should be used. This is at least a misnomer, and probably a misconception. The altimeter setting is not the same thing as the sea-level pressure. The altimeter setting is something else; it is properly called the altimeter setting. John, The altimeter setting in the Kollsman window adjusts the displayed altitude that the AC is from that standard pressure level. Quoting from the asa Pilot's Manual #3: If you want to measure the altitude of the airplane above the 30.10 in. Hg pressure level, then you set 30.10 in the pressure window. If 30.10 in. Hg happens to be the current MSL barometric pressure, then the altimeter will indicate the altitude of the airplane above MSL. So the altimeter setting is the same thing as the mean-sea-level barometric pressure. That said, there may still be bugs. I noticed in working through the details of altAlert in kap140.nas that once the altimeter setting deviates far from 29.92 in. Hg that the the target altitude differs from the altimeter display even when the baro setting and the altimeter setting agree. Have you looked for bugs? Regards, Dave -- Dave Perry [EMAIL PROTECTED] - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] incorrect altimetry
On Sun, 2007-02-11 at 08:02 -0700, Dave Perry wrote: Have you looked for bugs? I just looked at altimeter.cxx and altimeter.hxx. The indicated-altitude-ft is the result of a LowPass (taking into account the last altitude) of an iterpolation of a table created from an array in altimeter.cxx. I will compare this array to what I get from the formulas used in kap140.nas. If they differ, we should agree on correcting the table or the formulas in kap140.nas or both. I am celebrating my older son's birthday with he and his wife today, so I may not get this comparison done today. Stay tuned, Dave -- Dave Perry - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] incorrect altimetry
On Sun, 2007-02-11 at 00:22 -0500, John Denker wrote: Both the Weather Conditions popup and the atis.cxx code rely on the pressure-sea-level-inhg property and use it in ways that the altimeter setting should be used. This is at least a misnomer, and probably a misconception. The altimeter setting is not the same thing as the sea-level pressure. The altimeter setting is something else; it is properly called the altimeter setting. On 02/11/2007 10:02 AM, Dave Perry wrote: The altimeter setting in the Kollsman window adjusts the displayed altitude that the AC is from that standard pressure level. I can't parse that. There are numerous things that from could mean in that sentence. Certainly it doesn't mean altitude relative to, which is what it seemed to mean the first time I read it. Successive readings have not Quoting from the asa Pilot's Manual #3: If you want to measure the altitude of the airplane above the 30.10 in. Hg pressure level, then you set 30.10 in the pressure window. If 30.10 in. Hg happens to be the current MSL barometric pressure, then the altimeter will indicate the altitude of the airplane above MSL. OK ... assuming by altitude they mean pressure altitude not true altitude or absolute altitude or ... So the altimeter setting is the same thing as the mean-sea-level barometric pressure. Huh? That does not follow at all. The quoted passage does not say that at all. Do you do all of your flying in an atmosphere with a standard temperature profile? In mountainous country it is extremely common to have stations that differ hardly at all in position to have greatly different altimeter settings, because they differ in altitude, and there is a non-standard dP/dh in the column between them. Maybe your theory says this cannot happen, but the fact is it does happen. This is discussed in detail at http://www.av8n.com/how/htm/atmo.html#sec-h-a-l-t The magnitude of the effect is easily computed using: http://www.av8n.com/how/htm/atmo.html#eq-HALT Ed Williams added this formula to his formulary. That said, there may still be bugs. I noticed in working through the details of altAlert in kap140.nas that once the altimeter setting deviates far from 29.92 in. Hg that the the target altitude differs from the altimeter display even when the baro setting and the altimeter setting agree. Have you looked for bugs? When you get a chance, please read the main part of my previous message, the first part, the part not quoted above. It describes in detail how anyone can demonstrate the bug. It takes only a minute. If you've lost that message, you can get the same information from http://wiki.flightgear.org/flightgear_wiki/index.php?title=Bugs Another minute of analysis shows that the bug resulted from the fact that altimeter.cxx was using an algorithm that bears no discernible relationship to the one the FAA uses for computing QNH values, and which in all probability altimeter manufacturers are required to use, and which is consistent with the ASA passage mentioned above. A patch to make the altimeter conform to FAA standards can be found at http://www.av8n.com/fly/fgfs/altimeter.diff Right now it uses transcendental functions, which may or may not be somewhat inefficient. It would not be hard to build suitable interpolation tables, but that's not my top priority at the moment. There are lots of broken things that take precedence over merely slightly inefficient things. - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] incorrect altimetry
On 02/11/2007 01:42 PM, I wrote: OK ... assuming by altitude they mean pressure altitude not true altitude or absolute altitude or ... Typo: I meant indicated altitude instead of pressure altitude. Pressure altitude is something else yet again. Sorry for any added confusion; this was a big enough mess already. - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] incorrect altimetry
Reference: Altimetry principles. Lurid details including equations and derivations. http://www.av8n.com/physics/altimetry.htm - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] incorrect altimetry
On Sun, 2007-02-11 at 13:42 -0500, John Denker wrote: On 02/11/2007 10:02 AM, Dave Perry wrote: So the altimeter setting is the same thing as the mean-sea-level barometric pressure. Huh? That does not follow at all. The quoted passage does not say that at all. Your own paper implies this statement as follows. Using equation (13) in http://www.av8n.com/physics/altimetry.htm, simplifies to (canceling the Pb^N') hi = (1/K')*[S^N' - P^N'] (13') where K' and N' are the constants in your paper and S = Altimeter Setting and P = static pressure at hi. At what pressure P will hi = 0 MSL? Note that hi = O if and only if P = S. So your own paper implies that S = static pressure at 0 MSL. Why talk down to anyone on the list that corrects you or disagrees with you on a point? We all have been known to have to retract assertions. There are many on this list with advanced technical degrees and several with PhDs. We can read your paper. This comment is not intended to imply that degrees differentiate value of contributions to FlightGear, but is only an appeal for courteous dialog. A patch to make the altimeter conform to FAA standards can be found at http://www.av8n.com/fly/fgfs/altimeter.diff Right now it uses transcendental functions, which may or may not be somewhat inefficient. It would not be hard to build suitable interpolation tables, but that's not my top priority at the moment. There are lots of broken things that take precedence over merely slightly inefficient things. By the way, I agree that the current algorithm in altimeter.cxx is wrong. This evening, I had time to look at your posted patch and I think it would give the right hi. It does require two calls to ln() and exp() (i.e. the pow function). Have you thought of just using the C term in equation (15) and PA = pressure altitude which is already being computed. That would only require one call to pow(). Or since C = ( hi offset from PA) only varies with S, compute a replacement table for delta h in terms of S and interpolate that table. Then current hi = PA + interp(S). Thanks for your enthusiasm and contributions in a short span of time. Regards, Dave -- Dave Perry - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] incorrect altimetry
On 02/11/2007 11:29 PM, Dave Perry wrote: By the way, I agree that the current algorithm in altimeter.cxx is wrong. This evening, I had time to look at your posted patch and I think it would give the right hi. It is, for now, restricted to the troposphere (36000 feet and below). Extending it would be straightforward ... but see remarks below. It does require two calls to ln() and exp() (i.e. the pow function). Have you thought of just using the C term in equation (15) and PA = pressure altitude which is already being computed. That would only require one call to pow(). Or since C = ( hi offset from PA) only varies with S, compute a replacement table for delta h in terms of S and interpolate that table. Then current hi = PA + interp(S). I considered that, but: 1) It's only a factor-of-two improvement, and 2) This code ought not exist at all. It's hard for me to get excited about optimizing something that needs to be thrown out and redesigned. It does not make sense for altimeter.cxx to be implementing its own model of the atmosphere; instead it should be making a structured call to some sort of atmosphere model module. This and related issues are discussed at http://www.av8n.com/fly/fgfs/README.altimetry.html That document has more questions than answers; if anybody has answers please let us know. - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
