On Sunday 25 February 2007 17:49, John Denker wrote: > 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.
I have to agree with Dave on this. The indicated altitude should _not_ be quantized. The indicated altitude "belongs" to the altimeter part of the class, and _not_ to the encoder part. AFAIK an encoder never outputs indicated 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. > > 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. Knowing very little about backup altimeters, I would say that such an altimeter based on the output from the encoder would be a fully electronic device. Consequently it should have its own class, being so fundamentally different from a "normal" altimeter (tied to the static port and all). > > 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. What about an encoding altimeter, shouldn't that be able to have an indicated altitude that is not quantized and pressure altitude that is quantized!? > 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? Keep it! -- Roy Vegard Ovesen ------------------------------------------------------------------------- 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
