NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
Jason, dcmetr is the metar decoder since GEMPAK 5.6. If you just installed the decoder and are still writing to a file created with dchrly, you probably want to move the old file aside since the packing files used by the different decoders are different. Since the dcmetr action in my example use the -m 72 option for storing the data in 20 minute bins, this will create a different output file than the dchrly decoder as well which used 24 hourly bins for a daily file. You can log the decoder output more verbosely, eg: -v 4 if you want to search the decoder logs for possible problems such as not being able to find the tables being requested. Steve Chiswell Unidata User Support On Wed, 9 May 2001, Jason J. Levit wrote: > > Hi all, > > I just switched over from Gempak 5.4 to the last version (5.6.c1, I > think?), and I'm seeing some weird problems with the new deocders. > "dchrly" became "dcmetr", and I followed the example pqact.conf file on > the Unidata web page to make the necessary changes. Now, when real-time > METAR data comes in, hardly any of it ends up in the GEMPAK file. I > would say only about 5% of the METARs we had before are saved. What's > changed? Does anyone know why I suddenly can't see the entire data > stream? > > Thanks for any info! > > Jason > > -- > ---------------------------------------------------------------------------- > Jason J. Levit, N9MLA Research Scientist, > jlevit@xxxxxx Center for Analysis and Prediction of > Storms > Room 1022 University of Oklahoma > 405/325-3503 http://www.caps.ou.edu/ >
ldm-users
archives: