Weather monitor - query nearby telescopes (ANU 2.3m and the AAT). There is a "cron" job running on the APT PC that uses "ftp" to retrieve weather data from these two telescopes every ten minutes. - satellite maps; there are various sources of these available; - meterological data and weather forecasts from the met bureau - all-sky webcamera; we could have a daytime version for seeing clouds in the afternoon, and a nighttime version for clouds during observing. We could generate a short movie showing, e.g., the last hour of cloud movements. Diagnostic module - somewhat like "Norton Utilities", i.e., a program that monitors the health of the computer and lets you know when things are wrong, and offers to implement solutions to fix things - things to monitor include: - disk space filling up - CPU load - network connectivity - network errors - kernel messages (e.g, scan the output of "dmesg", and look for suspicious things) - whether the CCD, PMAC and CAN device drivers are loaded - whether the CCD, PMAC and CAN appear to be working - whether all other telescope hardware is working - is the weather information flowing in? - security issues (e.g., report the results of "tripwire", failed login attempts) - should have a GUI interface to assist the novice user, but should also have a command-line interface (e.g., you could run a program from a script, and its return value could indicate whether a particular error has occurred). Interface to commercial software - e.g., The Sky (from Software Bisque), Xephem (free from Elwood Dowdney of the Clear Sky Institute), Comsoft's software, Cicada (from Mt Stromlo & Siding Spring Observatories), Meade LX200 command set. - need to obtain the various pieces of commercial software and attempt to find the software/hardware interface specifications, and then design an interface to the APT. - this will need to be carefully interfaced with the scheduling/control software Gamma-ray alert software - it is particularly important that we are ready to go when the HETE-II satellite launches in May. - the current system uses a C program that acts as a network server. A machine at Goddard Space Flight Center connects to the server using TCP/IP sockets, for as long as the server is running. A "keep-alive" packet is sent once a minute to monitor the connection, and to measure the network delay. If a gamma-ray burst (GRB) is detected by an earth-orbitting satellite, an "alert" packet is sent to the APT. We have to decode the packet and act appropiately. - search for "GCN" on the web, and have a look at the on-line documents by Scott Barthelmy of NASA. - there are lots of different alert types, e.g., - from different satellites - from different analyses of data from the same satellite (i.e., you get an initial alert within a few seconds that has a crude position of the GRB; you then get more accurate positions as more data is analysed) - alerts need to be able to interrupt the telescope's operation, but care needs to be taken that multiple later alerts do not cause problems (e.g., if we are in the middle of a 60 second exposure caused by a previous alert, we do not want to abort the exposure if an updated position comes in) - an observer needs to be notified of recent alerts that might have occurred just before the telescope was turned on (so the alert software has to be able to query the Internet to find out about alerts that may have occurred when the server software was not on). Scheduling/security - there are many possible "entities" that would like to control the telescope: - a variety of people on the Internet (professional astronomers, undergraduates, high-school students) - a "superuser" who has override capability - the gamma-ray alert software - possibly a "batch" queue of observations - scripted observations running from IRAF (an astronomical image analysis package) - people communicating via commericial interface software (e.g., The Sky) - an emergency override, e.g., if it starts to rain - access to the telescope has to be controlled in some nice fashion - security has to be carefully considered, so that malicious people can't interrupt observations or damage the telescope. - a possible way of handling the multiple-user aspect of scheduling would be to treat the telescope as a "device". We could even write a device driver for it, and provide nodes on the filesystem to control it, e.g., /dev/apt (open this file to gain control of the telescope, write ASCII commands to it run the telescope, close the file to relinquish control) /proc/apt (the file, when read, returns the current status of the APT (e.g., RA, Dec, who is controlling it)) we may also need an "ioctl" interface to implement special commands that don't naturally fit with the idea of treating the APT like a file (e.g., forcing the currently user to yield to a higher priority user). A GUI interface for running the telescope - including a graphical representation of the state of the telescope/hardware/software - providing an integrated "help" system that is easy to use - easy to use for novice users; including advanced functionality for the seasoned professional - have a look at commercial software to get ideas, but try to think laterally and come up with some unique ideas of our own - should include interfaces to the other modules, e.g., - weather information - webcams - video-conferences, microphones - diagnostics - image display (quick look, and full-resolution) - databases CAN interface - begin by carefully reviewing the CAN development kit that we have - software interface (JNI - Java Native Interface) to the CAN device driver Image compression, quick-look software - the idea is to give users rapid feedback on the last image, by providing a greatly compressed (say 40:1) version that can be rapidly transmitted off the mountain - explore various image compression techniques, e.g., gzip, jpeg, hcompress Database software - store information on the images that have been taken: - image filename - size of image - date/time - object name - filter - exposure time - telescope position - user comments - perhaps even a thumbnail-sketch of the image itself? - etc - store weather data, so that historical trends can be analysed - store telescope usage statistics (i.e., opening/closing times, user names, etc) - store gamma-ray burst alerts - it would be very nice to have an automatically generated web page summary of the recent statistics Pager interface - provide a UNIX command interface to a pager, so that important events (such as a gamma-ray alert) can be sent. watchdog board for the PC, to power-cycle it if the software stops