[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[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 ;-)

> 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

> 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.

> 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.

> 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

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

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

> 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.

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


> however, cal_blocks 8-17 seem to indicate they are âdoubles (DBLE?)â

No, kbxwari.dlm converts them to doubles.

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


> 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.

> thanks

No worries.


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

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.