This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.
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