19990113: missing data...

Maureen,

I looked at the information Don passed along and noticed that the 
reports from the KBDR site were incorrectly formated, and therefore
causing the decoder to dump those bulletins. The CHINO string in the
KBDR report does not have a $ or group after it as the parsing
routine is expecting.

For a quick fix, you can download the routine:
~gbuddy/nawips5.4/patches/dcdmtrmk.c

and replace the routine on your system in the directory
$GEMPAKHOME/src/bridge/metar

Update your dchrly:

cd $GEMPAKHOME/src/bridge/metar
make clean
make
make clean

cd $GEMPAKHOME/src/programs/dc/dchrly
make clean
make
make install
make clean

I'll have to accumulate apatch in the near future, including
nwx updates for noaaport.

Steve Chiswell
Unidata User Support

On Wed, 13 Jan 1999, Unidata Support wrote:

> >From: Maureen Ballard <address@hidden>
> >Organization: UK Ag Weather Center
> >Keywords: 199901132117.OAA24360 dchrly missing obs
> 
> Maureen-
> 
> >> >Recently we have noticed that we are missing some data. Specifically
> >> >there have been a couple hours when a couple different stations' hourly
> >> >reports are not received here at UK. Most of the times are in the
> >> >morning. If it was always one station, I wouldn't be too concerned
> >> >(there could be equipment problems at that site) but it is happening at
> >> >too many stations to be a coincidence I think.
> >>
> >> Is it always the same stations?  If you can give me some examples,
> >> I can see if we received them.  Does it always seem to happen
> >> (the gap) at the same time each day?
> >
> >Not the exact same stations - today it has been LEX, BWG, EVV (what I 
> >consider
> >  1st
> >order) and they are missing at different periods. When I do an sflist for
> >AREA=@KY, DATTIM=all, I get:
> >
>  .... snip...
> 
> I compared what you have with what we got (for LEX).  You had:
> 
>     LEX    990113/0000     48.00
>     LEX    990113/0100     48.00
>     LEX    990113/0200     48.00
>     LEX    990113/0800     52.00
>     LEX    990113/0900     51.10
>     LEX    990113/1000     50.00
>     LEX    990113/1100     50.00
>     LEX    990113/1200     51.10
>     LEX    990113/1500     50.00
>     LEX    990113/1800     51.10
>     LEX    990113/1900     50.00
>     LEX    990113/2000     51.10
> 
> and we got:
> 
>     LEX    990113/0000     48.00
>     LEX    990113/0100     48.00
>     LEX    990113/0200     48.00
>     LEX    990113/0800     52.00
>     LEX    990113/0900     51.10
>     LEX    990113/1000     50.00
>     LEX    990113/1100     50.00
>     LEX    990113/1200     51.10
>     LEX    990113/1400     51.10
>     LEX    990113/1500     50.00
>     LEX    990113/1800     51.10
>     LEX    990113/1900     50.00
>     LEX    990113/2000     51.10
> 
> So we only got on ob more (14Z) than you using dchrly.
> 
> For raw reports, we got them every hour (except 4Z (0354)).  In McIDAS,
> we decoded every hour except the one we missed (4Z) so I'm assuming
> it is a problem with dchrly.  I don't see anything obvious in the raw
> reports that would cause a problem.  Since Chiz is in Dallas this week, 
> I'll have to wait until he gets back and have him look at it.
> 
> >> >Any thoughts as to why this would occur? It was noticed first on our
> >> >meteograms.
> >>
> >> The only thing I can think of is if there was network congestion that
> >> slowed down your data reception to the point where data was lost.
> >> Are there any messages in your LDM logs about reclasses or broken
> >> connections?
> >
> >The closest thing I can find are a couple broken pipes in the ldmd.log.1 
> >file.
> >Here are a couple excerpts from this file with today's date:
> >
> >Jan 13 00:57:51 kelvin pqexpire[266]: > Recycled  19414.615 kb/hr (  
> >6000.549 
> > pr
> >ods per hour)
> >Jan 13 00:58:51 kelvin pqact[268]: pbuf_flush (6) write: Broken pipe
> >Jan 13 00:58:51 kelvin pqact[268]: pipe_dbufput: 
> >/usr/local/ldm/decoders/dchrl
> > y-
> >v1-b9-m24-d/d2-agwx/ldmdata/gempak/logs/dchrly.log-p/
> >Jan 13 00:58:51 kelvin pqact[268]: pipe_prodput: trying again
> >Jan 13 00:58:51 kelvin pqact[268]: child 26640 terminated by signal 11
> >Jan 13 01:02:52 kelvin pqexpire[266]: > Recycled  19383.048 kb/hr (  
> >5999.657 
> > pr
> >ods per hour)
> >.....
> >Jan 13 07:05:37 kelvin pqexpire[266]: > Recycled  19870.359 kb/hr (  
> >6158.236 
> > pr
> >ods per hour)
> >Jan 13 07:05:58 kelvin pqact[268]: pbuf_flush (6) write: Broken pipe
> >Jan 13 07:05:58 kelvin pqact[268]: pipe_dbufput: 
> >/usr/local/ldm/decoders/dchrl
> > y-
> >v1-b9-m24-d/d2-agwx/ldmdata/gempak/logs/dchrly.log-p/
> >Jan 13 07:05:58 kelvin pqact[268]: pipe_prodput: trying again
> >Jan 13 07:05:58 kelvin pqact[268]: child 11111 terminated by signal 11
> >Jan 13 07:10:39 kelvin pqexpire[266]: > Recycled  19841.870 kb/hr (  
> >6162.672 
> > pr
> >ods per hour)
> >...
> >Jan 13 09:56:31 kelvin pqexpire[266]: > Recycled  19521.375 kb/hr (  
> >6119.533 
> > pr
> >ods per hour)
> >Jan 13 09:58:52 kelvin pqact[268]: pbuf_flush (6) write: Broken pipe
> >Jan 13 09:58:52 kelvin pqact[268]: pipe_dbufput: 
> >/usr/local/ldm/decoders/dchrl
> > y-
> >v1-b9-m24-d/d2-agwx/ldmdata/gempak/logs/dchrly.log-p/
> >Jan 13 09:58:52 kelvin pqact[268]: pipe_prodput: trying again
> >Jan 13 09:58:52 kelvin pqact[268]: child 14934 terminated by signal 11
> >Jan 13 10:01:32 kelvin pqexpire[266]: > Recycled  19490.859 kb/hr (  
> >6114.226 
> > pr
> >ods per hour)
> >
> >Those are the only 3 occurances of "Broken" in the files.
> 
> I would expect to see more of these if it were to account for big
> gap you have between 2 and 8 Z, so I'm not sure why dchrly is not
> decoding/filing these reports. 
> 
> I'll cc Chiz on this so he'll have something to look forward to when
> he returns. ;-)
> 
> Don
>