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.
=============================================================================== Robb Kambic Unidata Program Center Software Engineer III Univ. Corp for Atmospheric Research address@hidden WWW: http://www.unidata.ucar.edu/ =============================================================================== ---------- Forwarded message ---------- Date: Mon, 10 May 1999 14:21:46 -0600 From: Jim Cowie <address@hidden> To: Robb Kambic <address@hidden>, address@hidden Subject: Re: 19990510: problems with NOAAPORT metar data (fwd) Robb Kambic wrote: > > Jim, > > Could you shed some light here? > > Thanks, > Robb... The fact that you (Deb) mention metar and maritime specifically makes me think there is another problem. I know I gave you special versions of these decoders, but I may have given you copies that actually USE the CCB contents. (Normally, all the decoders just ignore the CCB header.) One of the last things I did at COMET was to modify the metar and maritime decoders to use the time string that's in the CCB as a reference time for the observations. Previously, these decoders used the system clock. I made this change to allow the decoding of these data for cases. If I gave you this version of the decoders, then they might be having a problem correlating the time in the CCB with the time in the actual metar report, and might thusly be throwing reports out. The addccb.pl script I gave you makes the message look like a "real" NOAAPORT product. It removes the FOS header (everything up to the start of the WMO ID) and adds a stock (fake) 24 byte CCB header. The fake CCB header I got from some product way back, or maybe I even made it up. At that time, it didn't matter since none of the decoders used it. But maybe now that has changed if you have the new decoders. Take a look at the metar and maritime decoder log files and look for messages about bad report times, etc... If that apperas to be the problem, then you should change the addccb.pl script to write a current time stamp in the CCB, instead of using the stock header with the fake time. Based on my documentation, the time info is written as follows: (indexes starting at 1) byte 15: years since 1900 16: month (1-12) 17: day (1-31) 18: hour (00-23) 19: minute (11-59) You'll have to encode each value into a single byte and write them with the rest of the header contents.I have very limited documentation, I tried to find out more info on this but failed. I will fax it to you if you want it. Hey Robb, this would not have been a problem if the message had been left as a pure NOAAPORT-format message :) -jim > > =============================================================================== > Robb Kambic Unidata Program Center > Software Engineer III Univ. Corp for Atmospheric Research > address@hidden WWW: http://www.unidata.ucar.edu/ > =============================================================================== > > ---------- Forwarded message ---------- > Date: Mon, 10 May 1999 13:00:05 -0600 > From: Unidata Support <address@hidden> > Reply-To: "Molenar, Deb" <address@hidden> > To: address@hidden > Subject: 19990510: problems with NOAAPORT metar data > > ------- Forwarded Message > > >From: "Molenar, Deb" <address@hidden> > >Subject: problems with NOAAPORT metar data > >Organization: CSU/CIRA > >Keywords: 199905101657.KAA05878 LDM NOAAPORT > > I'm trying to ingest the Unidata NOAAPORT metar and maritime feed and run it > through the FSL D2D decoders. The decoders won't work on the Unidata files, > but will work on files I bring over directly from the COMET NOAAPORT ingest. > I'm adding the CCB headers via a program from Jim Cowie. My understanding > is that the program strips off the WMO headers and adds the CCB headers to > the data. I'm guessing that might be where the problem is but since Jim's > gone and I don't have access to the source code, I'm grasping. Do you know > if there's any reformatting done on the data at the Unidata side? > > Here's a sample of the files--I don't know enough about the format to know > what's correct. > > from Unidata after being run through the ADDCCB program: > > @^L^ARUKWBC^Ba^E]^UAKWBCSPCN52 CWAO 101610 > SPECI CZPC 101610Z AUTO 33005KT 9SM OVC010 OVC029 OVC070 M00/M02 A3009= > > from COMET NOAAPORT > > @^L^ARUKWBC^Bc^E > ^O^N^AKDENSPCN43 CWAO 101509 > SPECI CYBR 101509Z 06014KT 6SM -SHRASN BKN015 OVC030 RMK SF6SC2+ > > from Unidata before ADDCCB program: > > ^A > 999 > SPCN31 CWAO 101546 > SPECI CYFB 101546Z 06010KT 8SM OVC015 RMK SC8= > > It looks to me like I need to figure out how to add a line feed after the ^E > on the first line of the Unidata feed with the ccb headers? Any format info > you could provide on what these characters mean would be a big help. > > Thanks. > > ___________________________ > Debra A. Molenar address@hidden > Computer Specialist NOAA/NESDIS/RAMM E-RA2 > phone: 970-491-8447 fax: 970-491-8241 > > ------- End of Forwarded Message -- ----------------------------------------------------------------- Jim Cowie Software Engineer WITI Corporation address@hidden Boulder, CO (303) 497-8584