[fitsbits] SDFITS Convention Comment: Hardware Keywords

[Tom Kuiper]

William Pence wrote:
> This is to announce the start of the Public Comment Period on the
> SDFITS binary table convention that is used for interchange of single
> disk data in radio astronomy.  This is another in a series of
> conventions that have been submitted to the Registry of FITS
> Conventions, which is maintained by the IAU FITS Working Group.
>   
...
> Comments about this convention may be posted here on the FITSBITS email
> exploder or the mirrored sci.astro.fits newsgroup.
>
> Bill Pence
> (on behalf of the IAU FITS Working Group)
>   
Bill, when does this Public Comment Period end?  I'm now working through 
the process of writing the results of a particular series of 
observations into SDFITS.  It'll be the first step in trying to get all 
the DSN spectroscopic runs to produce compatible SDFITS files.  There 
will be issues along the way.  I expect it'll take a few months.

Group, an issue for me right now is how many keywords are needed to 
describe the observing equipment fully.

I like the TELESCOP keyword because it can be a key to a whole host of 
other information for which there are no keywords, like the diameter or 
collecting area, the variation of gain with frequency and elevation.  
Can we agree on a standard set of values so all can share the same 
look-up table? Failing that, BEAMEFF, APEREFF, ETAL, ETAFSS, ANTGAIN, 
and so on must be included for very signal path which has a sufficiently 
different frequency so that it matters.  What I mean is that DSS-28 can 
simultaneously have both polarizations at, for example, 3, 6, 9 and 12 
GHz.  That's a lot of keywords.  Easier if I just tell you that it's 
DSS-28.   Some of our other antenas can give you LCP and RCP at both 8.4 
and 32 GHz.  Fortunately, they all are quite similar with respect to 
antenna parameters.  So there should be a registry to ensure that each 
antenna has a unique TELESCOP keyword.  From a relational database 
perspective, an entry in the TELSCOP table would have a key to another 
table which has antenna parameters according to antenna type.

Certainly, TELESCOP should be defined narrowly enough so that it doesn't 
include the receiver chain and backend.

I like the FRONTEND keyword to mean what package has been selected by 
whatever mechanism the antenna uses: a rotating sub-reflector like the 
DSN 70-m's, a turret mechanism, a rotating tertiary, whatever.  However, 
that's not the end of the story.
First of all, there may be two, separated by a dichroic, as implied 
above.  I'm leaning towards using two values (in one SDFITS file) for 
the FRONTEND keyword to handle that.  That is, FRONTEND will be a 
column.  In this case, the value of FRONTEND only needs to be unique for 
the telescope.  Two telescopes can certainly have a FRONTEND called "K".

There may be multiple feeds, the FEED keyword handles that well, in 
principle.  However, it's only a number without the FRONTEND keyword to 
say what it means.

Each feed generally puts out two orthogonal polarizations. The POLNO 
keyword used in ASAP seems appropriate, but not STOKES because at that 
point the signal is still a voltage.  STOKES doesn't become a meaningful 
keyword until the signal reaches the end of the chain.  Indeed, it may 
never become a meaningful keyword if the raw voltages are recorded for 
later processing in software.

Behind each OMT output is an LNA.  So you cannot make do with one TRX.  
Likewise, TCAL is probably a column, since the cal signal injected can 
in principle be different for each channel.  However, THOT is probably 
the same for all channels.

Behind each OMT output is a down-converter.  At least in our case, the 
two are not necessarily permanently married.  There is a switch to 
select the down-converter.  I haven't yet found a situation in which it 
matters how the down-conversion is done, as long as the frequency vs 
channel number (CRVAL1, CRPIX1, CDELT1) is correct.  However, we should 
probably allow for such a possibility.  I think that defining RECEIVER 
narrowly to mean the RF -> baseband converter will take care of that.  
Then it can be used as a key to look up such details as whether there is 
one baseband output, or a LSB/USB pair, or an I/Q pair.

I think what I'm getting at here is that pretty much anything related to 
the hardware can be a column.

I think there is no hope of fully describing a back-end with keywords.  
The keyword BACKEND should be strictly defined to be the device in which 
the signal ends up, which could be pretty much anything.  However, it is 
important to know what it is. For example, something that puts out 
channelized data could be an autocorrelator, a hardware FFT, or a PPFB.  
At least in the latter two examples, there isn't a clue about their 
difference in other keywords.

A final comment about raw voltages.  The future is here.  The primary 
data files for the observations I mentioned in the beginning are 
recorded that way.   I haven't yet decided how I will finally process 
them.  I think PSRFITS has an extension called SUBINT.  We should adopt 
it as part of SDFITS.


Best regards

Tom