[IDD #EBR-704030]: Decoding NLDN

Hi Jennifer,

re:
> I was wondering whether you ever had a chance to check your decoder against 
> mine for
> the bad data values I am seeing in the sample NLDN data file I attached to my 
> previous
> email.

No, sorry.  I have to admit that once you got your decoding working, I turned my
attention to fires elsewhere.  My apologies!

er:
> It’s weird because the error is similar each time, affecting three consecutive
> records, but then the errors are spaced randomly in the file.

OK.  What I'll need to do is compare your input data files to ones that
we capture here (we save a few days of "raw" NLDN data) to see if they
are the same, and then run both through my McIDAS decoder to see if it
complains.

re:
> Also, I noted that the records in the files delivered by the LDM are only 
> loosely
> ordered in time. My LDM put data into one file per hour, and in order to get a
> complete set of lightning strikes for a given hour, I must scan through the 
> file
> for the current and the previous hour.  In other words, to get all the 
> records for
> 12z, I have to read the 12z and the 11z data files.

The data order that is sent in the LIGHTNING LDM/IDD feed is the same as
in the data sent from Vaisala to UAlbany.  There is no attempt to create a 
monotonically increasing time sequence of data in the packaging and LDM
queue insertion code (which is a Tcl script) since the objective is to
get the data to the end-user with as few delays as possible.

re:
> I have made some progress on this project, moving forward in spite of the 
> suspicious
> bad data, and I want to share my dazzling animation:
> 
> http://cola.gmu.edu/jma/nldn2.gif

Very nice!

I routinely look at animations of positive and negative NLDN
and/or USPLN data on top of both radar and satellite (GOES-16) imagery,
and I think that they are incredibly interesting.  In case you are
interested, my approach is to plot all flashes in a time interval that
is centered on the time of the thing being overlaid, and the time interval
width is set to be the update frequency of the thing being overlaid.
The resulting animation nicely shows where ground-measured lightning
occurs.

I'll try to get to examining your lightning data soon.

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: EBR-704030
Department: Support IDD
Priority: Normal
Status: Open
===================
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.