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

Re: 19990909: Matching PIL id's in pqact

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: Re: 19990909: Matching PIL id's in pqact
  • Date: Thu, 9 Sep 1999 16:25:19 -0600 (MDT)
On Thu, 9 Sep 1999, Unidata Support wrote:

> >To: Unidata Support <address@hidden>
> >From: Gregory Grosshans <address@hidden>
> >Subject: Re: 19990622: Matching PIL id's in pqact
> >Organization: .
> >Keywords: 199909091943.NAA08363
> 
> This is a multi-part message in MIME format.
> --------------3C199EC3E1022E795287F957
> Content-Type: text/plain; charset=us-ascii
> Content-Transfer-Encoding: 7bit
> 
> 
> I'm in the final process of getting the NOAAPORT feed (from a NWS NOAAPORT 
> Receive
> 
> System) injected into LDM properly.  The software I'm using is from FSL and
> obtains the
> NOAAPORT data via client-server and stores the data into a structure 'prod'
> defined by
> 'product' in ldm.h.  The FSL software with some minor modifications works 
> great
> except
> decoders fail to start because the ^A and ^C (SOH, ETX) are missing from each
> product.
> 
> Does SOH and ETX have to be wrapped around the structure 'prod' or just the 
> "data"
> portion
> of the structure?  When one PIPES FOS data to a file the product has a SOH ...
> seqno ... data ... ETX.
> This leads me to believe the SOH and ETX must be around the entire product
> inserted into
> the queue via pq_insert.

Gregg,

The LDM doesn't modify any part of the product data, it creates a
prod_info structure to help it pass through the LDM processes.  If the SOH
and the ETX are missing, then they where missing before entering the LDM.
Look at the raw input file. If need be, you might have to add the SOH and
ETX chars.  Yes, all the decoders are looking for the SOH and ETX chars to
key apon.  You might want to pose this question to the FSL folks.  Let me
know what you find out.

Thanks,
Robb...



> 
> Thanks,
> Gregg Grosshans
> SPC
> 
> 
> 
> --------------3C199EC3E1022E795287F957
> Content-Type: text/x-vcard; charset=us-ascii;
>  name="grosshans.vcf"
> Content-Transfer-Encoding: 7bit
> Content-Description: Card for Gregory Grosshans
> Content-Disposition: attachment;
>  filename="grosshans.vcf"
> 
> begin:vcard 
> n:Grosshans;Gregory
> tel;fax:405-579-0700
> tel;work:405-579-0720
> x-mozilla-html:TRUE
> url:www.spc.noaa.gov
> org:DOC/NOAA/NWS/NCEP/Storm Prediction Center
> adr:;;1313 Halley Circle                              ;Norman;OK;73069;
> version:2.1
> email;internet:address@hidden
> x-mozilla-cpt:;0
> fn:Gregory Grosshans
> end:vcard
> 
> --------------3C199EC3E1022E795287F957--
> 

===============================================================================
Robb Kambic                                Unidata Program Center
Software Engineer III                      Univ. Corp for Atmospheric Research
address@hidden             WWW: http://www.unidata.ucar.edu/
===============================================================================