20040223: LDM on weather3.admin.niu.edu

Gilbert,

>Date: Mon, 23 Feb 2004 11:57:04 -0600 (CST)
>From: Gilbert Sebenste <address@hidden>
>Organization: Northern Illinois University
>To: Steve Emmerson <address@hidden>
>Subject: Re: 20040223: LDM on weather3.admin.niu.edu 
>Keywords: 200402212235.i1LMZlrV009065

The above message contained the following:

> What is the MD5 checksum?> The 3 digit unumber atthe top? That is always 
> "000", I *think*. At least it was under GPSSRC.

The signature of a data-product is an array of 16 unsigned bytes.  It is
currently implemented using the MD5 checksum algorithm.  When printed,
it will appear as 32 hexidecimal digits.

> But wait. Now I notice this:
> 
> Feb 23 17:50:30 notifyme[18973]:      141 20040223171154.728 IDS|DDPLUS 
> 1187995  SXXX50 KWAL 231709
> Feb 23 17:50:31 notifyme[18973]:      146 20040223171154.735 IDS|DDPLUS 
> 1187997  SRGA20 KWAL 231709
> Feb 23 17:50:31 notifyme[18973]:      141 20040223171154.736 IDS|DDPLUS 
> 1187998  SXXX50 KWAL 231709
...

The above were printed by the function "s_prod_info" in the file
"protocol/ldmprint.c".  Each entry comprises the following (in order):

    a timestamp
    the name of the program,
    the PID of the process
    the size of the data-product in bytes
    the creation-time of the data-product as YYYYMMDDhhmmss.sss
    the feedtype of the data-product
    the sequence-number of the data-product
    the data-product identifier

More information can be found at

    
http://my.unidata.ucar.edu/content/software/ldm/ldm-6.0.14/basics/data-product.html

In general, data-product signatures are only printed if the
logging-level of the process is "debug".

> The ones with the lower numbers at top (right around 1 million instead of 
> 44 million) I assume is the checksum. And the lower ones, I believe, are 
> from NWWS. He might have switched the feed over to an IDS|DDPLUS thing 
> instead of PPS. I have no idea why it stopped working under GPSSRC
> with the upgrade from LDM 5 to 6.

The GPSSRC bit-mask is 0x800, which is the same bit-mask as AFOS.

The PPS bit-mask is 0x1 and the IDS|DDPLUS bit-mask is 0xB.

> I dunno. It was endless looping here. And, when I changed "PPS" back to 
> GPSSRC in my pqact entries, the looping stopped instantly.

Sounds like a problem with either the decoder script or the pqact(1)
configuration-file.

> > For the reason given above, all textual NOAAPORT data-products will match 
> > the PPS feedtype (as well as any combination of the feedtypes DDS, PPS,
> > and IDS).
> 
> Bingo.

I take it you have a PPS entry in your pqact(1) configuration-file
which is being triggered by every IDS|DDPLUS data-product that arrives
(basically, every data-product on the textual NOAAPORT channel).

This is probably too many products.

> Hmmm. Well, as I said above, it's working OK now, changing all my PPS 
> entries back to GPSSRC.

If David is tagging his data-products as PPS and your pqact(1)
configuration-file is keying on GPSSRC, then that configuration-file
entry will never be triggered by one of David's data-products because
the intersection of PPS (0x1) and GPSSRC (0x800) is the empty set.

> It is still a mystery of life I cannot solve. :-) Question: why is the 
> GPSSRC not working for David as described in his emails? Did something get 
> changed?

I'm afraid I didn't pay sufficiently close attention to David's emails
to answer that question.

> *******************************************************************************
> Gilbert Sebenste                                                     ********
> (My opinions only!)                                                  ******
> Staff Meteorologist, Northern Illinois University                      ****
> E-mail: address@hidden                                               ***
> web: http://weather.admin.niu.edu                                      **
> Work phone: 815-753-5492                                                *
> *******************************************************************************

Regards,
Steve Emmerson
LDM Developer