We're writing radio data in binary tables, and fitsverify hates them:

133) fitsverify /share/pdata1/pdev/x108.20080826.b0s1g0.
00800.fits

fitsverify 4.13 (CFITSIO V3.090)
--------------------------------


File: /share/pdata1/pdev/x108.20080826.b0s1g0.00800.fits

2 Header-Data Units in this file.

=================== HDU 1: Primary Array ===================

16 header keywords

Null data array; NAXIS = 0

=================== HDU 2: BINARY Table ====================

*** Error: Keyword #29, CTYPE1 is not allowed in the Bin/ASCII table.
*** Error: Keyword #31, CTYPE2 is not allowed in the Bin/ASCII table.
*** Error: Keyword #44, CTYPE2G is not allowed in the Bin/ASCII table.
.... many more similar errors

Some of the WCS parameters are table columns:
COMMENT axis 1 is the frequency axis
TTYPE6 = 'CRVAL1 ' / Center frequency
TFORM6 = '1D ' /
TUNIT6 = 'Hz ' /
TDISP6 = 'D13.5 ' /
TTYPE7 = 'CDELT1 ' / Frequency interval
TFORM7 = '1D ' /
TUNIT7 = 'Hz ' /
TDISP7 = 'D13.5 ' /
TTYPE8 = 'CRPIX1 ' / Pixel of center frequency
TFORM8 = '1D ' /
TUNIT8 = ' ' /
TDISP8 = 'D13.5 ' /

but others are constant, so we're putting them in the table header
per the "Green Bank Convention".
CTYPE1 = 'FREQ ' / Type of coordinate
CUNIT1 = 'Hz ' / Unit of center frequency

These files are massive and written at 80 MB/s, so we really don't want to make them any bigger than they have to be.

Does that really make us bad people? Or have I missed something?

Thanks,

-Mike


--
Mike Nolan +1 787 878 2612x334 Fax: +1 787 878 1861
Arecibo Observatory, HC 3 Box 53995, Arecibo, Puerto Rico 00612 USA