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.
Kwan-yin, Since upper air data sets in TTAA, TTBB, etc parts do not contain the latitude/longitude of the station, the dcuair decoder uses $GEMTBL/stns/snstns.tbl (by default) for locating the station locations. If you have older data, where the station locations have moved, you can either: 1) create a new station table, and use the -s "stn_table" parameter with dcuair to use that table instead of the default table. 2) If you have already created the GEMPAK upper air file, you can change the station location information using the SNSTNS program and a table of locations for specific stations that have moved in order to update the data base information for the station in the GEMPAK upper air file. Steve Chiswell >From: "Kwan-yin Kong" <address@hidden> >Organization: UCAR/Unidata >Keywords: 200210250548.g9P5mVq09495 >To Steve / GEMPAK support: > > Thanks for your hints. I didn't realize that the >'ZCZC' and 'NNNN' need to be added for EACH rawinsonde >station. After I added those in, dcuair appeared to be >able to decode most of the stations in the files. > > A question came up to me is: Can GEMPAK decode old >stations that have been superceded? When I try to use >oabsnd to do a barnes analysis, do I need to add those >superceded station locations into a station table? > >Kwan >City College of New York > > >On Tue, 22 Oct 2002 16:55:14 -0600 > Unidata Support <address@hidden> wrote: >>>From: "Kwan-yin Kong" <address@hidden> >>>Organization: UCAR/Unidata >>>Keywords: 200210222222.g9MMMHp21301 >> >>>To Steve / GEMPAK support: >>> >>> Lately, I obtained some rawinsonde data in ASCII >>>format and would like to running the decoder "dcuair" to >>>convert them to gempak files. I ran dcuair as suggested >>>in the GEMPAK manual with the -c option plus the date and >>>outfile < infile. However, the program stopped almost >>>immediately and reported that 'The buffer has overflowed, >>>no end of bulletin'. I still don't understand what this >>>message is about, and would appreciate some help. The >>>following is a print-out of the entire error message. >>> >>>[10919] 021022/1807 [DC 3] Starting up. >>>[10919] 021022/1807 [DC -7] The buffer has overflowed, >>>no >>>end of bulletin. >>>[10919] 021022/1807 [DC 5] Normal termination. >>>[10919] 021022/1807 [DC 2] Number of bulletins read and >>>processed: 5 >>>[10919] 021022/1807 [DC 6] Shutting down. >>> >>>Thanks for any inputs on this issue. >>> >>>Kwan-yin Kong >>>City College of New York >>> >> >> >>Kwan-yin, >> >>It sounds like your data is missing the necessary control >>characters >>used in the normal transmission of the upper air data. >> >>In the real-time data stream you will find sequences >>beginning with >>^A \r \r \n >>and the product ends with >>\r \r \n ^C >> >>or >> >>ZCZC >>and ending with >>NNNN >> >> >>If your archived data has these characaters stripped out, >>then you would have to >>recreate them, such as is described in: >>http://www.unidata.ucar.edu/projects/coohl/mhonarc/MailArchives/gempak/msg035 > 78.html >> >>See if your data looks like that described in the >>archived message above, >>and if so, add the ZCZC and NNNN sequences as described. >> >>Steve Chiswell >>**************************************************************************** >>< >>Unidata User Support >>(303)497-8643 >> P.O. Box >>address@hidden >>---------------------------------------------------------------------------- >>< >>Unidata WWW Service >> http://www.unidata.ucar.edu/ >>**************************************************************************** >>< >