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

[Datastream #SKA-849721]: SHIP/BUOY data

Hi Kevin,

re:
> I was trying to track down why there are duplicate instances of
> SHIP/BUOY data coming across the WMO feed.
> I tried this:
> notifyme -vxl- -f WMO -p 'SMVD15 KWBC' -o 10000 -h idd.unidata.ucar.edu
> along with this
> pqcat -f WMO -p 'SMVD15' buoy.bin
> to see if I was imagining something.
> Anyway, as an example for BUOY 44043 in Chesapeake Bay, in buoy.bin we
> have the following messages coming across at 18Z
> 
> 066
> SMVD15 KWBC 091800 RRF
> BBXX
> 44043 09181 99392 70764 46/// /0902 10082 91740 333 91203=      (Reading
> at 1740 Z, #1)
> 
> 407
> SMVD15 KWBC 091800 RRU
> BBXX
> 44043 09181 99392 70764 46/// /0000 10089 91810 333 91201=   (Reading at
> 1810 Z, #1)
> 
> 414
> SMVD15 KWBC 091800 RRT
> BBXX
> 44043 09181 99392 70764 46/// ///// 1//// 91758 22200 1//00 70000=
> (Reading at 1758 Z, #1)
> 44041 09181 99372 70768 46/// /2902 10144 91740 333 91203=
> 44041 09181 99372 70768 46/// ///// 1//// 91758 22200 1//00 70001=
> 
> 443
> SMVD15 KWBC 091800 RRV
> BBXX
> 44041 09181 99372 70768 46/// /3001 10149 91750 333 91202=
> 44043 09181 99392 70764 46/// /1002 10083 91750 333 91202=    (Reading
> at 1750 Z, #1)
> 
> 488
> SMVD15 KWBC 091800 RRW
> BBXX
> 44043 09181 99392 70764 46/// /0902 10082 91740 333 91203=   (Reading at
> 1740 Z, #2 - note the same as above)
> 
> 187
> SMVD15 KWBC 091800 RRX
> BBXX
> 44043 09181 99392 70764 46/// /1001 10085 91800 333 91202=     (Reading
> at 1800 Z, #1)
> 41009 09181 99285 70802 46/// /0406 10239 20176 40196 91820 22200
> 00244 11104 20502 300// 41103 70018 333 91208 555 11066 22069=
> 
> 
> 663
> SMVD15 KWBC 091800 RRX
> BBXX
> 44041 09181 99372 70768 46/// ///// 1//// 91758 22200 1//00 70001=
> 44043 09181 99392 70764 46/// /1002 10083 91750 333 91202=    (Reading
> at 1750 Z, #2 - once again, the same)
> 
> 680
> SMVD15 KWBC 091800 RRX
> BBXX
> 44041 09181 99372 70768 46/// /2902 10151 91810 333 91203=
> 44043 09181 99392 70764 46/// /0000 10096 91830 333 91201=    (Reading
> at 1830 Z, #1)
> 44043 09181 99392 70764 46/// /0000 10089 91810 333 91201=    (Reading
> at 1810 Z, #1)
> 44041 09181 99372 70768 46/// /2802 10152 91820 333 91202=
> 
> 732
> SMVD15 KWBC 091800 RRX
> BBXX
> 44043 09181 99392 70764 46/// /0000 10095 91820 333 91201=   (Reading at
> 1820 Z, #1)
> 
> 791
> SMVD15 KWBC 091800 RRX
> BBXX
> 44043 09181 99392 70764 46/// /1001 10085 91800 333 91202=   (Reading at
> 1800 Z, #2 same as previous)
> 
> 793
> SMVD15 KWBC 091800 RRX
> BBXX
> 44043 09181 99392 70764 46/// ///// 1//// 91758 22200 1//00 70000=
> (Reading at 1758 Z, #2, same as previous)
> 
> 422
> SMVD15 KWBC 091800 RRX
> BBXX
> 44043 09181 99392 70764 46/// /0000 10096 91830 333 91201=  (Reading at
> 1830 Z, #2, same as previous)
> 
> 
> If you use McIDAS and point to stimpy.ssec.wisc.edu for RTPTSRC
> PTLIST RTPTSRC/SHIPBUOY SELECT='TYPE SHIP; IDA 4404; IDB 3; DAY
> 2008100; TIME 18' NUM=ALL
> you will notice that there are multiple readings according to the HMS
> field - and the records that are filed are the same as would be expected
> given what I've shown above.

Actually, your listing above shows small differences from product to product.

> I guess I could put something in the code to check for duplicates, but I
> was hoping that the LDM would handle this problem.
> Any insight?

The LDM does not know what is contained in the products it relays, nor does
it care -- it is content agnostic.  The detection and rejection is done by the
downstream LDM (the LDM receiving data) by comparing the MD5 signature of
a new product with the signatures of products that are still in the queue; if
the signature of the new product matches any of the signatures of products that
are in the queue, the product is rejected, otherwise it is accepted and put
into the queue.

The MD5 signature for a product will be different if _any_ portion of the 
product
is different. The difference could include something as simple and unoticable 
as an
extra space in the text or a different order of the same set of bulletins in 
the product.

> Thanks!

No worries.

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