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

[McIDAS #GEJ-957244]: McIDAS GOES-South Problem



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


NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us.