There are two ideas that need to be kept separate. a) The idea of an /class/ aka /object/, versus b) the idea of an /instance/ of such a class.
As applied to altimetry: a) Writing a single altimetry /object/ that can perform either as a digital encoder *or* as an analog "steam gauge" is a good idea. b) Trying to make a single /instance/ perform both functions is a bad idea. In real aircraft, it is common practice to have an analog altimeter in one place, and an encoder in another place. The FG fleet generally does it this way, too: you can see separate instances of altimeter and encoder in generic-instrumentation.xml. As has been pointed out, a pilot is free to put one setting (right or wrong) into the Kollsman window of the main analog altimeter, and another setting (right or wrong) into the baro-setting feature of the autopilot. This is another reason for having two /instances/ of the altimetry object. On 02/25/2007 08:39 AM, Dave Perry wrote: >>> 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. This is not a bug. It was my intent to model an encoder that rounds the pressure altitude, just as it happens in real life. > 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. 1) I did test my code. 2) Yes, the altitude coming off the digital encoder does jump. In real life, one sometimes sees backup altimeters that are based on the output of the encoder. They jump. This is not a bug. It's just how things work. I say again: -- If you want an analog "steam gauge" altimeter, use an /instance/ of the altimetry object configured to do that. -- If you want a digital encoder, use an /instance/ of the altimetry object configured to do that. -- Do not expect a single /instance/ to both jump and not jump. Do not ask a single /instance/ to have two separate Kollsman settings. This would be inelegant, inefficient, and inconsistent with how things have been done heretofore. It was my intent to be consistent with how things are done in real life, which is also consistent with how the FG fleet has been doing things all along. If there is some reason from departing from this consistency, somebody should explain the reason. ========================================== As an almost-separate matter, I have a question for the community: The question is whether the <quantum> configuration option should be removed from the new altimeter object. ++ The argument for keeping it is that real encoders do quantize the pressure altitude. So writing the quantized pressure altitude to the property tree, as my code does, must be considered realistic. -- The argument for removing it is that if users consider realistic behavior to be a bug, there's no point in offering the behavior. -- Also, the c++ implementation isn't necessary, because if the autopilot wants to round the indicated altitude, it can do so. That's at most one line of nasal code. -- Similarly, if the autopilot wants to round the pressure altitude, it can find the Kollsman shift (by subtracting pressure altitude from indicated altitude), round the pressure altitude, and add the Kollsman shift back in. In the worst case that's three lines of nasal code, usually less. Any opinions? Other suggestions? ------------------------------------------------------------------------- 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
