On 02/25/2007 04:36 PM, Dave Perry wrote: > I want to go back to the beginning of our discussion that led to a new > atmos.cxx and altimeter.cxx. My reason for wanting this code to read > the baro setting from the property tree and return to the tree the baro > offset is to make sure it is clear that these are different than the > altimeter setting and kollsman shift and can/should be different in two > types of pilot error.
Ah, but they are not different in kind. They are merely two separate /instances/ of the same kind. The "baro setting" is a different name for the *same* idea as the "altimeter setting". They play the *same* role, one for the autopilot and one for the analog altimeter. I have tried again and again and again to make the point that it is important to distinguish a) classes, versus b) instances of a class. People keep telling me they understand this conceptual distinction, and then sometimes within a few sentences they trample roughshod over the distinction. > Not being clear in terminology and semantics was > one of your original complaints about the existing code. Agreed. > On Sun, 2007-02-11 at 00:22 -0500, John Denker wrote: > >> While we're in the vicinity: >> >> 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. It is also properly >> called the QNH, although private pilots who fly only in >> the US may be unfamiliar with the QNH terminology. > > You convinced me of this. They are different. >> This property needs to be expunged and replaced with >> something else, something with a correct name and with >> correct semantics. >> > Why does this argument apply to the above 2 of the three variable I > point out as my rational for adding 5 lines of c++ to your > altimeter.cxx, but not to the third. I don't know what that is trying to say. My point remains that sometimes things are different because they are different classes ... and sometimes they are different because they are different instances of the same class. Back on the 20th of February I explained (with examples) how to deal with this situation by instantiating two instances of the altimeter class. I didn't hear back. I assumed my explanation had been received and understood. > The "setting" refers to what is entered in the kollsman window and the > baro setting refers to what is entered in the kap140. Those are two instances of the same class of functionality. They have different names but play closely parallel roles. > Even with a separate instantiation referred to as an encoder, not having > these 5 lines of code forces the user to have save the baro setting > variable to the autopilot baro setting location as well as the encoder > "setting" location. This is exactly the type confusing and incorrect > semantics you set out to eliminate. > > Then you suggest that the autopilot nasal should fetch the indicated > altitude from the encoder and the pressure altitude from the encoder and > subtract to get the baro setting offset. Again adding to the > possibility of future confusion and just plane hard to read code. With > the 5 additional lines, all using non ambiguous names we avoid what you > set out to avoid. > > I had proposed this subtraction method to Roy off list and he did not > want to use a value that was unavailable in real life to the kap140. I agree that having the blind encoder serve as an oracle for computing the Kollsman shift is a bit of trickery. If this trick offends you, the appropriate remedy is to not use the trick! The remedy is *not* to add additional code to implement the trick in a more-confusing more-obscure less-consistent less-true- to-life way. The whole issue would go away if the model KAP would calculate the Kollsman shift internally, just as a real KAP does. The correct algorithm is documented in detail at http://www.av8n.com/physics/altimetry.htm and can be implemented with near-zero programming effort and near-zero CPU load. To summarize: My recommendations: -- The typical aircraft will have an instance of the altimetry class to serve as the backend for the steam-gauge altimeter. This instance will be configured with no quantization, which is the default. The configuration and the interface are verbatim and literatim identical to the previous altimeter configuration and interface. -- Those aircraft that want an encoder should use a different /instance/ of the same altimetry /object/. Quantization is a configuration option. The configuration is not identical to the old <encoder> configuration, but it isn't complicated, tricky, or obscure. An example of the configuration appears in the altimeter.cxx code. The runtime interface for the encoder is the same as for the old encoder. The upgrade can be dropped into generic-instrumentation.xml with no per-aircraft fiddling. -- Autopilots should calculate the Kollsman shift on their own. No code should be added to the altimetry object to support using the encoder as an oracle for computing the Kollsman shift. (If some authors find a way to use "oracle mode" *without* complexifying and obscurifying the altimeter, then that's up to them. I will consider "oracle mode" an undocumented bit of trickery.) -- If/when aircraft designers choose to install backup altimeter displays based on encoder outputs, these displays will exhibit quantization steps, just as in real life. This is not a bug. (Note: AFAIK there are currently no such displays in the FG fleet.) Naturally there will be a separate Kollsman setting for each such instrument. This is 100% naturally implemented by means of one /instance/ of the altimetry class for each altimetric instrument. ------------------------------------------------------------------------- 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 Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
