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

20030203: NIMAGE IDD datastream



>From: "Paul L. Sirvatka" <address@hidden>
>Organization: College of DuPage
>Keywords: 200302040006.h14063603767 IDD NIMAGE

Paul,

>OK...I have things figured out (again). Few questions remain.
>
>We are getting data from papagayu who was having some problems over the
>weekend, finally getting fixed today. Is there a way to find out what
>problems are occuring easily?

We were diving into the problems that papagayo was having ourselves.
What we found was only solved by actually logging onto the machine
and taking a hard look at its setup.  (The problem was that papagayo
was receiving all of the CONDUIT datasetream, and its queue was too
small for the job.  Once we turned off CONDUIT, the rest of the
feeds went back to normal).

>Also, is there a bakcup site that feeds NIMAGE data?

Not yet, no.  NIMAGE is not generally available on the IDD since the
sizes of the products are so big, the overall volume quite large (not
as big/large as CONDUIT, but substantial nonetheless).

>Also..I noticed that profiler data (6-min data) has a lot of gaps in it. I
>adde'd to ucar and found even more. Is this normal or should we expect
>data to be in moreconsistently?

We have noticed that the 6-minute profiler data has a lot of gaps in
it lately.  I have been assuming that this is being caused by the QC
routines keeping a lot of the data from being sent.  The hourly summary
profiler data has, however, seemed pretty complete.

>I suppose this is the same questions for
>satellite feeds. I have heard that there are known problems with Goes West
>pertaining to gateway problems.

If there is, this is totally out of our control.  The IDD datastream
that is in our/SSEC's control is MCIDAS/UNIWISC, and it has been
reliable.

>Thanks for getting us going again. I have learned a lot and feel more
>comfortable finding fixes to things.

Sounds good.

Tom