Here is the nasal code to calculate the Kollsman shift.

# Typical usage:  indicated_altitude = pressure_altitude - 
kollsman(baro_setting)
   k_ft = k_set = nil;
   kollsman = func{
     if (arg[0] == k_set) {return k_ft}
     k_set = arg[0];
     k_ft = 145442.156 * (1 - math.exp(math.ln(k_set/29.921260) * 0.1902632365))
   }



1) This achieves the goal of realism in the sense that it allows
  the autopilot code to calculate the Kollsman shift using only
  information available to a real autopilot.

  I'd be astonished if real-world autopilots used anything much
  different from this.

2) This is computationally efficient in the overwhelmingly-likely
  case that the baro_setting is not being changed very often.

3) If you want to standardize this across the FG fleet, put it in
  some accessible place [perhaps atmo.nas] and let people call it
  from there [as atmo.kollsman(...)] rather than cut-and-pasting
  it in multiple places.

4) If you don't think this is -- for all practical purposes -- the
  right answer, please explain what is the right answer ... and
  explain how a pilot could tell the difference between this and
  the right answer.

5) Since this has some advantages and AFAICT no disadvantages, it
  removes any temptation to use the c++ altimetry object as an oracle
  for computing the Kollsman shift.



===================================

Tangentially related note:  I made one recent change to the package
of diffs:
  http://www.av8n.com/fly/fgfs/atmo.diff

I rigged it up so that encoder.[ch]xx are no longer needed, and are
not even mentioned in the Makefile.am or anywhere else.  When you
configure an <altimeter> you get an instance of the Altimeter class,
and when you configure an <encoder> you get a different instance of
the Altimeter class.  The only difference is that the former has a
default <quantum> of zero, while the latter has a default <quantum>
of ten.

Users should not notice any difference (except that their altimetry
suddenly becomes much more accurate).  The configuration files such
as generic-instrumentation.xml can stay exactly the same, and the
runtime interface (via the property tree) is upward-compatible.

-------------------------------------------------------------------------
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

Reply via email to