One of the projects I worked on was the development of
ASCOM compatable drivers
for the remote-control of telescope hardware over the Internet.
The ASCOM standard specifies the exact methods and properties a driver should have as well as their behavior.
2. The Problem
One of the challenges of this project was to counter-act the typical latency of the internet.
The ASCOM standard was designed only with direct access to the hardware.
Hence, many client programs poll the properties very frequently.
Furthermore, some of them continuously change by themselves (clocks, position, dome status, etc).
The following devices were considered for control:
- Telescope (movement, tracking of stars)
- Telescope Camera (digital)
- Telescope Focuser (focuses image as well handles color filters )
- Dome (motorized opening/closing)
3. The Solution
The following problems were analysed and solved:
- Allowing multiple clients to communicate through one instance of the driver
(solved by creating an ActiveX-EXE instead of a DLL for the drivers.)
- Update of various ASCOM-specified properties (Azimuth, Elevation, etc) automatically
Solved by having the server continuously send updates to the client (PUSH)
- Keeping the properties in a consistent state.
Solved by the client maintaining a cache of all properties.
The execution of certain methods invalidates those properties.
The client driver blocks if those properties are subsequently read, until updated data is received.
- Propagating physical-driver exceptions to the remote client.
(Some drivers generate VB errors exceptions routinely)
- Methods for authentication, device sharing, privilage handling, etc
One of the advantages of an Ascom-compliant interface is that the server can use any ASCOM-compilant
driver to communicate with the hardware. Thus a wealth of astronomy software can be used remotely to connect to any physical telescope.
The telescope hardware used at the Baton Rouge Observatory is described
on this page: http://www.bro.lsu.edu/telescope