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

[LDM #KWB-817118]: Intepretation of NLDN binary data.

Hi Takeshi,

re:
> Thank you for quick reply.

No worries.

> We are working on sprite research. Sprite occurs above cloud-to-ground
> lightning stroke at height from 40 to 80 km with duration of tens of
> millisecond. We use location and time of NLDN stroke as proxy of those
> of sprite. We would have millisecond resolution data due to transient
> nature of sprite.

I understand.  This sounds very interesting indeed.

> It sounds like that millisecond resolution data is no longer available.

The NLDN data distributed in the IDD from SUNY Albany has always been like
the data you are receiving now.  Since neither McIDAS nor GEMPAK needed time
resolution finer than 1 second, we never worried too much about the 'nsec'
value in the NLDN data records.

> Do you know if we can get millisecond resolution data in any way via LDM?

Before responding to this, please read through the following:

Question:

- what kind of machine are you running your NLDN "decoder" on

The reason I ask is that 4-byte quantities in the NLDN data records are turned 
into
integer values in my ldm-mcidas decoder using:

static int
read_int( file, value )
FILE         *file;
int          *value;
{
    unsigned char x[4];         /* NB: 32-bits assumed! */
    int     retcode;
    int     num = 1;

    if (fread(x, 1, sizeof(x), file) == sizeof(x))
    {
    *value = (x[0] << 24) | (x[1] << 16) | (x[2] << 8) | x[3];
    retcode = 1;
    }
    else
    {
    retcode = 0;
    }

    return retcode;
}

(by the way, the exact same thing is done in the GEMPAK decoder).

The shifting of the values in the 4 bytes read from the NLDN record into
a 4-byte integer word implicitly assumes that the 4 byte values represent
a big endian integer. I say this because the ldm-mcidas NLDN decoder was
originally intended to be run on Sun SPARC machines.

So, if you are decoding the values on a little-endian machine (e.g., PCs running
Linux, FreeBSD; DEC OSF/1 machines, etc.) it might well be that the value needs 
to
be byte flipped to get the correct value of nanoseconds.

It seems to me that the acid test for whether or not the 'nsec' time value needs
to be byte flipped on little endian machines is if the byte-flipped values
show a wide range of values while the unflipped values do not. My reasoning is:

I would not expect that time values of 'nanoseconds from the current second' for
physical processes would be clustered around low (or high) values.  Instead, I 
would
expect a full range of values.  Now, if the values are really representative of
milliseconds, I would expect that, given a large enough sample, they would range
from 0 to 999 milliseconds.

What do you think about the above reasoning?
 
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: KWB-817118
Department: Support ldm-mcidas
Priority: Normal
Status: Closed