[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[McIDAS #GEJ-957244]: McIDAS GOES-South Problem
- Subject: [McIDAS #GEJ-957244]: McIDAS GOES-South Problem
- Date: Thu, 03 May 2012 15:34:12 -0600
Hi Fred,
re:
> The logic which I use for the transfer of images from the ADDE server to the
> processor
> is to check the date/time of the most recent image on the processor and see
> if the
> server has an image that is more recent. If so, then transfer the image to
> the
> processor. The problem comes when the image at the server has an incorrect
> time in the
> future. The future time data set is transferred, and then there are no more
> transfers
> until that future time is past because the server don't continue to update
> the future
> times. I did not use the processor clock time in the transfer logic since
> the local
> clock frequently drifts and cannot be depended upon.
True, but the nominal time for GOES images does not change more frequently than
every 15 minutes (except for rapid scans, of course). Our experience with
maintaining
the accuracy of the system clock to a fraction of a second (needed for robust
LDM/IDD
distribution of real-time data) is not hard for systems connected to the
Internet --
simply run 'ntp'. I assume that the DTN/Telvent machine is connected to the
Internet since it is accessing GOES-South machines from us.
re:
> In looking at the two Linux
> computers on my desk, they have an hour difference in local clock time.
It seems to me that you or the IT staff at ERAU either start using 'ntp' or
figure
out why the 'ntp' instance that is running is not keeping accurate time.
re:
> If I put local
> time into the transfer logic, then provisions would need to be made to insure
> that the
> local time on the computer is the correct time. I don't know if the
> DTN/Telvent
> computers have accurate time.
Point taken, but I would hope/assume that the DTN/Telvent folks would pay
attention to
the system clock in addition to other factors.
The approach I have taken when making composites from different geostationary
satellites is to choose images whose nominal times are "close" (e.g., 15
minutes)
to each other. I do this by creating lists of the most recent images using
IMGLIST
and then selecting the images that are close in time to the composite being
made.
If an image does not meet the time criteria, it is not used. The logic is not
foolproof, but it avoids the problem faced when an new image has a nominal time
that is in the future. I believe that this is the same kind of logic that the
folks
at SSEC use in the creation of the composite imagery they produce.
NB: I want to make sure you know that my comments were not intended to find
fault with
how your composites were being created... if they came across that way, I
sincerely apologize!
I was simply trying to relay an idea that I developed when confronting the same
sort
of problem that I think is occurring at DTN/Telvent.
re:
> I believe that the future time problem is caused by the antenna losing the
> satellite
> signal, and noise getting into the image processing. Can anything be done to
> improve
> the satellite tracking?
This past weekend we switched GOES-South ingest to a 3.8m, single-axis
steerable solid dish;
the dish previously used was a 3.8m, non-steerable mesh Paraclipse unit. Given
that the orbital
inclination of GOES-South (GOES-12) is now over 2.1 degrees, we could no longer
use the
non-steerable dish for GOES-South; it is now back ingesting data from
GOES-East. The
signal strengths we are now seeing vary between -48.5 and -51.5 dBm. As a
comparison
the signal strengths for our GOES-West ingest have varied between -51.5 and
-55.5 dBm over
the past two months, and its images are mostly clean (the GOES-West mesh
Paraclipse dish likely
needs some position tweaking). The signal strengths now being seen for
GOES-East ingest
are in the neighborhood of -52 dBm, and they seem to be completely noise free.
One problem that we face with GOES-South ingest here in UCAR is the position of
our
steerable dish -- it is located between two buildings and needs to point over
the top of
one to see GOES-South. I believe that this pointing is the likely cause of the
3 dB
difference in high and low signal strengths we are seeing since the weaker
signal is seen
when looking at the southern most extent of the GOES-South figure 8.
Unfortunately,
the location of this dish can not be changed. One of the projects we have on
the "back
burner" is to convert an old, non-steerable USAN dish into a two-axis tracking
system.
Whether or not we can pull this off is a good question, but we are going to try
sometime this summer. If this effort succeeds, we will likely move our
GOES-South
ingest to the new dish as it has a completely unobstructed view of the southern
sky (it is located on the south side of the NCAR Mesa Lab on the edge of the
parking
lot).
Cheers,
Tom
--
****************************************************************************
Unidata User Support UCAR Unidata Program
(303) 497-8642 P.O. Box 3000
address@hidden Boulder, CO 80307
----------------------------------------------------------------------------
Unidata HomePage http://www.unidata.ucar.edu
****************************************************************************
Ticket Details
===================
Ticket ID: GEJ-957244
Department: Support McIDAS
Priority: Normal
Status: Closed