Hello Sean --

I would say thanks very much for generating the housekeeping keyword
set, but by definition it's a thankless task.  Most of the notes
below are questions and comments rather than concerns:

* CHOPFREQ: Are there also keywords for chopping secondary throw,
  direction, and coordinate system?

* NODTIME: This is presumably elapsed time, not just on-source time.
  As a separate internal issue we need to define a convention for the
  time that appears in the headers (WASP uses time-on-source that
  takes transition times into account; CSO uses total elapsed time
  alone; KOSMA uses ?).  Since the telescope doesn't know about nods
  as such, isn't this part of an observing parameters list?

* HUMIDITY: Is this really the ground-level humidity, or the humidity
  that goes into the atmospheric model for refraction correction? 

* TAU, TAUIMAGE, TAUZENIT: These are really derived from the receiving
  system, I'd think, and aren't properly part of the observatory
  housekeeping data.  For instance, there's (properly) no information
  on observing frequency in your list, so giving tau alone has little
  meaning.  We'd normally keep this kind of information in an
  observing parameters list elsewhere.

* WINDDIRE, WINDSPEE: I'm not sure what we'd use this for,
  particularly if it's had the aircraft velocity removed.

* OPERATOR: This is customary to carry, but I've never understood why
  since we're always in a situation where running the observation
  requires many people.  We should probably either drop this or expand
  it so we can enter the TA, receiver, and data acq. "operators."

* HEADING: this is useful; we should add aircraft SPEED as well.

* TELRA, TELDEC: can we only point in RA and Dec?  That's not good, if
  so.  Generally, it's interesting to see that we can have reference
  positions in many coordinate systems but here we only seem to get
  center positions in RA/Dec.  That will make beam maps and mapping
  the Galactic center interesting.

* TELFOCUS: can we get this in units of mm or something instead of
  encoder units?  We're usually interested in the position in
  fractions of a wavelength -- either we can do the transformation or
  the SOFIA system can.

* TRACMODE: what is this?

* SCANNING: what does SOFIA mean by the "scanning mode" that we would
  flag?  Is is what we would call on the fly?  It seems odd to specify
  boolean values for three of many possible modes without providing a
  nonboolean string to specify a particular observing mode, but maybe
  these are the only three modes the *telescope* can ever know about.
  If so, perhaps a more descriptive set of keywords would be useful
  instead of specifying a typical use in a common observing mode.

* TRACKING: this presumably is what we'd call "total power" or stare
  mode?  

* SCANDIR: in what coordinate system?  

* radial los velocity: Will SOFIA provide this?  And if so, in what
  coordinate frame?  
 

POTENTIALLY NEW KEYWORDS


* Should we add collimation terms, for instance receiver reference
  position offsets in the telescope coordinate frame that go into the
  pointing terms?  Or is this what AZDELTA and ELDELTA are for?  These
  seem to be corrections of some sort.

* Should we add secondary mirror x and y offset collimation terms (if
  it has them)?

* How can we use the pointing error estimate to generate a simple bad
  scan or suspect scan flag for a given scan?  Is there any way to ask
  the observatory to do this, checking for errors past some bound for
  some time between two requests?

* Same for rms pointing error.  Or rms pointing error averaged over
  the past minute, or something.  

* Will one of TEMPPri? be the cavity temperature for a representative
  number for spillover termination?

* Should we add information about the door positions, or just assume
  that the door control system will keep them well out of the field of
  view?  


Well, despite the task, thanks very much.

Andy