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

20000503: LDM PIPE Question


James,

the NAWIPS decoders require FOS or AFOS product headers to identify a product.
(this is in the dcgbul code). The NOAAPORT data products don't have these
start and end character sequences - that may be your problem if that is where 
your
data is coming from.

A FOS product should have
SOH \r \r \n
SEQ  \r \r \n
TTAAII CCCC DDHHMM [BBB] etc.....
...
...
\r \r \n ETX

Our ingestors for the NOAAport satellite feed create the FOS wrappers 
before inserting the product into the LDM so that decoders which are looking
for the product delimeters can find it.

Steve Chiswell
Unidata User Support






>From: James Hayes <address@hidden>
>Organization: UCAR/Unidata
>Keywords: 200005040218.e442ImG05566

>
>Hi,
>
>I am using pqinsert on an HP machine, running ldm-5.0.8, to ingest text produc
> ts
>and feed them to a LINUX machine running ldm-5.0.9.  
>
>The transfer of products is achieved by the ALLOW and REQUEST lines in the
>ldmd.conf files on the HP and LINUX boxes, respectively.
>
>The pqact.conf on the LINUX box contains an entry to redirect surface obs to
>dchrly using the PIPE command.  The surface observations that are sent to the
>LINUX box look like this:
>
>SAUS80 KWBC 040100
>METAR KPWM 040051Z 18004KT 10SM CLR 08/03 A3034 RMK AO2 SLP273
>     T00780033                                                       
>
>The pqact.log shows that the surface observation is being acknowledged (since 
> it
>it being FILEd as well), and that the PIPE command is being invoked.   Below i
> s
>the relevant section of the pqact.conf file:
>
>EXP .*(...)(MTR)(...)
>    PIPE    /usr2/nawips/exe/linux/dchrly -v 5 -b 9 -m 24
>            -d /usr1/metdat/gempak/logs/dchrly.log
>            -p /usr2/nawips/gempak/tables/pack/hrly.pack
>            -s /usr2/nawips/gempak/tables/stns/sfstns_old.tbl
>            /usr1/metdat/gempak/surface/YYMMDD_surf.gem                       
>   
>  
>
>This entry worked when AFOS was the feed into the LDM.
>
>However,  the file /usr1/metdat/gempak/surface/YYMMDD_surf.gem is NOT being
>created.  Below is a snippet of the pqact.log that shows the text products bei
> ng
>processed by pqact:
>
>May 04 00:29:37 pqact[18546]:                file: -overwrite  
>/usr1/metdat/text/PWMMTRWVL
>May 04 00:29:37 pqact[18546]:                pipe: /usr2/nawips/exe/linux/dchr
> ly
>-v 5 -b 9 -m 24 -d /usr1/metdat/gempak/logs/dchrly.log  -p
>/usr2/nawips/gempak/tables/pack/hrly.pack -s
>/usr2/nawips/gempak/tables/stns/sfstns_old.tbl      
>/usr1/metdat/gempak/surface/YYMMDD_surf.gem 
>
>Instead of creating a GEMPAK surface observation, I get the following messages
>in the dchrly.log file:
>
>DCHRLY[22119]: 000504/0129: Starting up.
>DCHRLY[22119]: 000504/0129: read 83/16383 bytes strt 0 newstrt 83
>DCHRLY[22119]: 000504/0129: read 83/16300 bytes strt 83 newstrt 166
>DCHRLY[22119]: 000504/0129: read 84/16217 bytes strt 166 newstrt 250
>DCHRLY[22119]: 000504/0129: read 80/16133 bytes strt 250 newstrt 330
>DCHRLY[22119]: 000504/0129: read 88/16053 bytes strt 330 newstrt 418
>DCHRLY[22119]: 000504/0129: read 82/15965 bytes strt 418 newstrt 500
>DCHRLY[22119]: 000504/0130: read 88/15883 bytes strt 500 newstrt 588
>DCHRLY[22119]: 000504/0130: read 88/15795 bytes strt 588 newstrt 676
>DCHRLY[22119]: 000504/0130: read 83/15707 bytes strt 676 newstrt 759
>DCHRLY[22119]: 000504/0130: read 87/15624 bytes strt 759 newstrt 846
>DCHRLY[22119]: 000504/0130: read 87/15537 bytes strt 846 newstrt 933
>DCHRLY[22119]: 000504/0140: [DC -6]
>DCHRLY[22119]: 000504/0140: Normal Termination.
>DCHRLY[22119]: 000504/0140: Number of bulletins read and processed: 0
>DCHRLY[22119]: 000504/0140: Shutting Down.                                  
>
>In addition, I am attempting to decode upper air messages of the same type, wi
> th
>the same result.s
>
>Any idea of what I may be doing wrong?
>
>Thanks,
>
>Jim Hayes
>National Weather Service
>Gray ME
>