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

[Staging #YUL-837325]: Fwd: NOAAport vendor

Hi Sue,

re:
> So it appears to me that the 789C sequence erroneously appears in TZL data
> packed for the LDM.

Again, the products relayed by the LDM are _never_ modified by the
LDM in any way.  This means that any problem(s) with any product(s)
will have been caused "upstream" of the LDM (e.g., preparation for
inclusion in the NOAAPort broadcast (by the NWS/Raytheon), in the
NOAAPort broadcast itself, NOAAPort ingest (but our NOAAPort ingesters
do not modify any of the products extracted from the NOAAPort SBN), 

re:
> We receive via LDM

Yes, but any site running an LDM can insert products into LDM datastreams.
What I was trying to determine is where your machine is REQUESTing
its NEXRAD Level III data from.  If it is from a machine that is
participating in the IDD, then the origination of the TZL products
will be from the NOAAPort SBN, and their content will have been set
at the radar itself.  If the data you are getting is being sent by
someone inserting the products into the LDM queue that is upstream
from your LDM, then the cause of any problem(s) might lie in something
they are doing.

re: ucnids

My experience with 'ucnids' is very old ... I believe that it was
created by Dan Vietor many years ago for use in WXP, but my memory
could be faulty in this regard.

My only guess is that 'ucnids' does not conform to current ICD
specifications for TDWR products.  Again, the decoders we provide
for NEXRAD and TDWR Level III products are not experiencing any
problems with the TDWR TZL product.

re:
> /*
> Check for 789C byte sequence denoting zlib compression
> If data are not compressed, pass through raw data
> */
> check = (((inbuf[0] << 8) + inbuf[1]) % 31);

I just reviewed the code I wrote that reads and serves the Level II
products.  The logic in the part of the code that checks for
Zlib-compression of a product is:

    /*
    ** These tests were extracted from the 'inflate.c' routine that is
    ** distributed with the zlib distribution.
    */

    if ( (*buf & 0xf) == Z_DEFLATED ) {
      if ( (*buf >> 4) + 8 <= DEF_WBITS ) {
        if ( !(((*buf << 8) + *(buf+1)) % 31) ) {
          return SUCCESS;
        }
      }
    }

SUCCESS -> indicates that a Zlib-compressed buffer has been found.

Since this checking works to identify when a product is Zlib-compressed,
it would seem that the logic in ucnids.c is not quite complete.

I hope that this helps!

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: YUL-837325
Department: Support Datastream
Priority: Normal
Status: Closed