[McIDAS #YGF-361048]: GOES R calibration

Hi Ioan,

re:
> are you aware by any chance of some documentation on McIDAS AREA
> calibration block for GOES-R

The only "documentation" that I know of is the code in the McIDAS-X
calibration module, kbxabin.dlm and the code that puts together the
calibration array in their GOES-R data servers, abinaget.cp and
abinadir.cp.  Since you previously indicated that you are licensed
for McIDAS-X, you should be able to download the latest McIDAS-X release,
v2017.2, from SSEC.

I assume that the lack of more documentation is a reflection of how
fast the code for GOES-R data serving has been evolving.

re:
> I figured out it consists for 18 elements for a given channel.

Yes, that is what I gleaned from the code.

re:
> For example,
> channel 2 from class contains following information (NetCDF) related to
> calibration
> 
> 'vis064_esun': 1618.35, 'vis064_add_offset': -20.2899,
> 'vis064_scale_factor': 0.158592, 'vis064_earth_sun_distance_anomaly_in_au':
> 0.998059
> 
> 
> the calib block from the same image (lead server) (McIDAS AREA)  looks like
> this
> 
> 
> (2, 6399999, 1585923, -202899112, 0, 0, 0, 0, 0, 0, 0, 18753, 0, -9990000,
> -9990000, -2147483648, -2147483648, 4095)
> 
> 
> I can recognize the channel/band  number (pos 0) vis064_scale_factor*100000
> (pos 2) vis064_add_offset * 1000000 (pos 3) and Nodata values (pos 17)
> o you have any clue what position 1 , 11, 13, 14, could mean

This should be more clear in the code I referred to above.

re:
> I interpreted the bytes as float as well but  could't see anything:))

It is _highly_ doubtful that any value in a McIDAS ADDE transaction would
be in floating point format.

re:
> Another aspect that concerns me a little is the DOC keyword.  As per ADDE
> doc the DOC keyword ifs set to YES, results in the line documentation
> being included in the area file.

Yes.

re:
> I use the line doc for example to compute the scan duration in seconds of
> any given image, (start scan of  last line - scan time of last line)

I asked SSEC specifically about the calculation of the time of each
scan line, and I was told that there has been some internal development
aimed at calculating the time.  I have not, however, received any specifics
about what they have developed, or if it is, in fact, accurate.

re:
> I have the feeling that line doc is not returned form the ADDE even if the
> DOC=YES

I have not investigated the effect of including DOC=YES on IMGCOPYs for GOES-16
images, so I can not comment about doc values being nor not being returned
in an ADDE transaction.  I assume that a careful review of the AGET server
code, abinaget.cp, will reveal what is really going on.  Other than that, I
know of no other documentation.

I'm sorry that I can't be a better source of the intimate details of GOES-R
ADDE transactions.  I have been forced to read poorly documented code to figure
out how to add support for the MCSTRETCH environment concept that was introduced
in SSEC's v2017.2 release... sigh!

Cheers,

Tom
--
****************************************************************************
Unidata User Support                                    UCAR Unidata Program
(303) 497-8642                                                 P.O. Box 3000
address@hidden                                   Boulder, CO 80307
----------------------------------------------------------------------------
Unidata HomePage                       http://www.unidata.ucar.edu
****************************************************************************


Ticket Details
===================
Ticket ID: YGF-361048
Department: Support McIDAS
Priority: Normal
Status: Closed
===================
NOTE: All email exchanges with Unidata User Support are recorded in the Unidata 
inquiry tracking system and then made publicly available through the web.  If 
you do not want to have your interactions made available in this way, you must 
let us know in each email you send to us.