Examples of APT software projects for 2003 (a) Gamma ray burst alert software and GUI. When a gamma ray burst (GRB) goes off, the sequence of events is approximately as follows: 1. An earth-orbiting satellite detects the gamma rays, and relays this information to a ground station in the United States. 2. Within seconds to hours, the ground station alerts the GCN system at Goddard Space Flight Center. 3. The GCN send out a packet of information on a TCP/IP socket connection to our computer at Siding Spring. 4. Within six seconds our telescope (ROTSE) has moved to the position of the GRB and is taking its first image. 5. Other telescopes around the world are also taking images, but ROTSE is likely to be the first. 6. The ROTSE data pipeline automatically analyses the images, and identifies stars that aren't in known catalogues, and/or are changing in brightness from one image to the next. 7. A human (one of several people in the ROTSE consortium) needs to review the ROTSE data and issue a GCN e-mail announcing the discovery. This is currently the weakest link in the chain, and we need to get the delay down to less than 30 minutes in order to be the first to make the announcement. The software project involves making it easier for the human collaboration in step 7 to arrive at a rapid result. Possibilities include: - a browser interface where are all relevant information (ROTSE images, light curves of stars and images, images from the Digital Sky Survey, the original GCN alert packet, recent GCN messages, status of the ROTSE telescopes in Australia and Texas, astronomical ephemeris information (e.g., when the object is going to rise/set)) is readily displayed. - chat software to enable collaboration members to communicate. - automated generation of a template GCN message. - ability to generate fake GCN alerts, and to monitor the performance of the team. (b) Simulator, test harness and unit testing The APT software system is quite complicated, but its interface to the hardware is fairly straightforward. Some work has been done on making a simulator and test harness that would allow the software to be run on computers not actually connected to the telescope. It would be very valuable to resurrect this work and integrate it into the new software release system. Unit tests (using either junit or suiterunner) could be incorporated. (c) User/password/encryption The APT currently uses an Openldap database for storing usernames and passwords. Some work was done last year in using the Linux password system instead. It would be useful to examine the pros/cons of these approaches, and look into the whole question of security. (d) Engineering GUI The aim would be to create a GUI that would display the overall status of all the various hardware and software components in the APT system, perhaps using the colour block diagram of the system as a starting point. Working systems could be displayed in green, faulty systems in red and/or flashing, with advice being given to the user on how to correct problems. (e) Interface to commercial software Some good work has already been done on interfacing the telescope control system and CCD camera to commercial packages (TheSky and CCDSoft). This work is still somewhat preliminary, and it would be very valuable to make it more robust so that deployment to a Windows environment would be easier. (f) Kyocera 7135 phone software I am just about to purchase a Kyocera 7135 phone that is based on the Palm Operating System. It is possible to download a software development kit for this phone, and it would be very interesting to explore possibilities such as: - low bandwidth display of the telescope status (ROTSE and APT) - ability to control the telescopes - ability to participate in the GRB alert collaborations (g) Database possibilities Some work has already been done on a database of APT images: software exists to take a directory (or CD) of images and to produce thumbnails and summaries of the essential information by looking at the FITS headers. This work could be extensively improved upon. Databases are also be used for scheduling upcoming observations. There is some existing work on this. (h) Telescope safety issues With remote telescopes it is crucial that all possible errors (loss of mains power, loss of Internet connection, hardware/software faults, and so on) are thought about and planned for. We need a robust system that establishes a human as having prime responsibility for the safety of the telescopes, with the ability to telephone/SMS various people in emergencies. (i) Webcamera software improvements The existing webcamera software could be substantially improved. For example, add the ability to add/delete new webcamera displays, have predefined positions and zoom settings for particular objects, archive images at Siding Spring and construct movies, incorporate the new CONCAM all-sky camera, and image processing to detect clouds. Automated image characterisation could be helpful. (j) Weather information We need a website to display the latest weather information for the observatory. Sources of this information include: NOAA satellites sending images directly to our radio receiver connected to the mistral computer, the 2.3 m weather station, the ROTSE weather station, Coonabarabran airport, various webcameras, sky transparency data obtained from the images taken by the telescopes themselves. We might plan to install additional weather stations with, for example, infrared cloud detectors, to provide more information about the observing conditions.