[McIDAS #SKX-144523]: himawari data tranfers from open archive

Hi Nick,

re: code in kbxwari.dlm

> thanks. i was working on that when you wrote.

Great minds think alike ;-)

re:
> i wrote a simple byte reader, and think i can get the calibration information 
> now.
> it looks, though, like the byte indexing in the area file may be off by 1 for 
> the calibation file …
> it is suppose to start at 768, but looks like it starts at 769.

This is likely to be an interpretation of 1 vs 0 indexing.  The byte offset of
768 assumes that the first byte is byte 0, not byte 1.

> >> read_area_block('D262_B4', 769)

I assume that this is in your Matlab code...

> FILE: D262_B4.AREA
> BIDX: 772      771      770      769
> BIN#: 01010111 01000001 01010010 01001001
> DEC#: 87       65       82       73
> ASCI: W        A        R        I
> INT32: 1463898697

re:
> the documentation also seems to say i am able to use DSSERVE to copy a
> Hamawari Data File directly from the SSEC server to my machine, but … I have
> not figured out how to do that yet, so i will keep working with the area file.

This is not the case.  All ADDE transfers use a synthesized AREA format.  ADDE
does not provide access to the original file.

re:
> the calibration coefficients are multipied by 1,000,000 to convert from 
> int64’s to int32’s.

The calibration coefficients are multiplied by 10**-7, not 10**7.

re:
> the pixel ‘count’ data (data block) does not have any conversions, so i think 
> i just
> need to divide the cal coeffiectns by 1,000,000 then multiply by the data 
> block values.
> do you think that is correct?

The code in kbxwari.dlm multiplies the values store in the calibration block
by 10**-7.

NB: all header values in an AREA file are 4-byte integers

re:
> thanks again for the help. i am pretty close now.

No worries, and I think that you are correct, you are close.

re:
> thanks again, if i am reading our code snipped correctly,
> i guess i do not need to divide by 1,000,000 for the cal coefficients.

See above.

re:
> i am still a little puzzled by the data type. i think each block is 4 bytes.

Correct.

re:
> however, cal_blocks 8-17 seem to indicate they are ‘doubles (DBLE?)’

No, kbxwari.dlm converts them to doubles.

re:
> when i read off these 4 bytes should i try to read them as:
> int 32’s (4 bytes)

Yes.

re:
> singles (floating point 4 bytes)  (double in ‘c’ is 8 bytes?)
> or another data type?

No, all AREA file header words are 4-byte integers.

re:
> thanks

No worries.

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: SKX-144523
Department: Support McIDAS
Priority: Normal
Status: Closed