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

20000918: dcprof

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: 20000918: dcprof
  • Date: Tue, 19 Sep 2000 12:26:35 -0600

On Tue, 19 Sep 2000, Bob Rozumalski wrote:

> 
> 
> Hey Steve,
> 
> 2 questions:
> 
> 1)  Is there any difference between the text messages coming from the LDM 
>     data stream and another source the would cause problems with processing 
>     by the DC decoders?  I seem to remember a problem with control characters.

Bob,
The GEMPAK decoders expect either FOS or AFOS headers with control characters.
A bulletin with a FOS type header looks like:
^A \r \r \n
### \r \r \r
TTAAII CCCC DDHHMM etc.
<stuff>
\r \r \n ^C

NOAAPORT bulletins don't have the FOS wrappers, ^A \r \r \n, ### \r \r \r
and \r \r \n ^C. Our IDD data stream adds those wrappers to NOAAPORT
products so they are compatible with FOS decoders. If someone either has
a product without the FOS/AFOS wrapper, or without any control characets, then
then the bridge routine bridge/dc/dcgbul.c will not be able to find a "product".

The wrappers are used to denote a product comming in on a PIPE or stream where
you don't have anything else to tell when a product has started or stopped.



>     
> 2)  I have attached a BUFR file that is supposed to contain profiler data;
>     however, the file has eluded my attempts to decode its contents with 
>     dcprof.  My last attempt was:
>     
>     % cat  sn.0284  | dcprof -p $GEMTBL/pack/profiler.pack -s           
>     $GEMTBL/stns/profiler.stn $GEMTBL/grid/tableb $GEMTBL/grid/tableb
>      
>     A check of your support archives seems to suggest that the format
>     of the current BUFR files may no longer be compatible with dcprof.
>     
>      Thanks
>      
>      Bob
>      
>      

I looked at your file. It is not one of FSL's profiler data files that
dcprof was designed to decode. The FSL hourly summary profiler data
have headers like IUPT0[1-4] KBOU.

The headers in your file are:
IUCS10 EUMS 182230
IUCS11 EUMS 182230
IUCN10 EUMS 182230
IUCN11 EUMS 182230
IUAX02 KARP 182305


The dcprof decoder decoded FSL's profiler data...but since the BUFR profiler
files are only hourly summaries, and the FSL NetCDF files have both hourly and 6
minute data, I no longer use dcprof (and haven't maintained it). I doubt it
would work on anything but FSL's BUFR profiler data.

Steve