Re: SAX LEGSPC FITS keywords

[pence@tetra (William Pence)]

>We are at work to define the structure and keywords for the
>FITS data files for the SAX Low Energy Scintillation Proportional
>Counter (LEGSPC) experiment. I have placed a draft document describing
>the proposed FITS keywords and file structure for the raw data in our
>anonymous ftp machine (astro.estec.esa.nl) in the file
>pub/SAX/leda_0002.ps....
>		Fabio Favata


I've had a quick look at this document and am pleased to see that
SAX is attempting to adopt many of the same conventions previously
used in the ROSAT and ASCA FITS files. This should make it much
easier for multimission analysis software like Xspec to read the
SAX data once it is available.  Here are a few detailed comments.
Some of these comments reflect that fact that the current ROSAT data
format has changed somewhat from the format used as a model here.

Primary Header keywords:
------------------------

The SEQ_PI keyword should more properly be called OBSERVER.  There
is already another OBSERVER keyword that should be changed to something
else.

Can you add a DATAMODE keyword?  Is this what SETUPID is used for?

I think RDF_VERS and RDF_DATE keywords are obsolete and can be deleted.

The PROC_SYS and PROC_VER keywords can perhaps be replaced by the
CREATOR keyword to give the name and version number of the program that
generated the FITS file.

Binary Table header keywords - general comments
----------------------------

In general, it would be good to repeat the important keywords
from the primary array in each extension, such as TELESCOP and INSTRUME.
The philosophy within the OGIP has been to make each extension
relatively independent,  so that software does not have to read
the primary array header to get important pieces of information.

Time related keywords
---------------------

Defining the exact time of events within the data is of course very
important, and several more keywords need to be provided to 
describe what the times in the TIME column really represent.  
It will probably take a couple iterations to get these keywords
all right (or at least the way the OGIP timing experts here would
prefer) but as a start,  the following keywords should probably
be included:

MJDREF  - the zeropoint of the spacecraft clock, in MJD days
TSTART  - the start time of the observation in spacecraft clock seconds
TSTOP   - the stop time of the observation
TELAPSE  - = TSTOP-TSTART
ONTIME   - the actual amount of time observed (e.g. sum of all the good time 
           intervals)
TIMEUNIT - time unit of the TSTART and TSTOP keywords (presumably = 's')
TIMESYS  - time system used  

There are a few other timing related keywords that we would probably like
to see added, but I'll leave that to the timing experts to sort out,
once you know exactly what your time values represent.

Misc comments
-------------

It would save space, and look neater, to delete all the TUNITn = 'None'
keywords.  They don't serve any real purpose.

The standard unit for seconds is 's' not 'seconds'.

It would save space, and clarify the meaning of the column names
to put all the comments about the various detector flags, etc, into the
comment field of the appropriate TTYPEn keyword.

It would be useful for software to provide all the conversion scale
factors as keywords, not just as comments.  One could even give these
as TSCALn keywords so that FITS readers would automatically read the
scaled physical value, and not just the telemetry value, but this
can be confusing if users don't know the data is being scaled by the
FITS reader.

In the raw events table, is there a reason for not defining
all the columns except TIME as 'B' (byte) instead of 'I' (I*2)?
This would cut the size of the table nearly in half.

What do the RAW_X and RAW_Y keywords mean?