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

[LDM #BVM-113085]: Question about NEXRAD Level II data

This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.

  • Subject: [LDM #BVM-113085]: Question about NEXRAD Level II data
  • Date: Wed, 12 Jul 2006 17:05:48 -0600
Hi Niles,

re:
> Thanks for the quick reply.

No worries.

> I'm attaching a tar archive of about 20 files
> that we've recieved today that had this problem.
> The most recent is abut 15 minutes old.

Very good.  I used the most recent product in your
tar file and compared it to what we received and
FILEd (this was not as easy as it sounds since we write
all of the pieces into a single output file).  I
verified that what you received and what we received were
identical.  Given this, I will assert that there was no
munging of the product by the LDM.

Furthermore, I ran the GEMPAK uncompression routine, dcnexr2, on our file
and saw that it runs into an error and then exits:

/local/ldm% less logs/dcnexr2.log [585] 060712/1653[DC 3]  Starting up. Version 
5.9.3
[585] 060712/1653[DCNEXR2 -5] decompress error - -4
[585] 060712/1653[DC 5]  Normal termination.
[585] 060712/1653[DC 2]  Number of bulletins read and processed: 17
[585] 060712/1653[DC 6]  Shutting down.

I believe that this matches your observation since the name of your
file contains the segment number of the piece in question:

202945_18.BZIP2          <- the 18th piece of the full volume scan

The question is if the product was damaged at the source (i.e., radar)
before it was inserted into the initial LDM queue for transmission.
I would conjecture that it was.

> These are for the Denver nexrad, KTFG.

Yup.

> I'm also attaching a copy of the C++ code that
> I'm using to decompress the data - some of it
> uses our libraries, but I'm sure you can follow the gist
> of what it does if you read C/C++

Since I verified a problem with one of the products you sent, I did not
feel the need to look at your code.


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: BVM-113085
Department: Support LDM
Priority: Normal
Status: Closed