Early Years

During 1998, DC-3 Dreams developed its Astronomer's Control Panel (ACP1), a Windows program that gave access to all of the capabilities of the Meade LX200 Classic. During the process, DC-3 Dreams focused on including an open Windows Scripting interface that included a Telescope object. Other programs could use this for a high-level way to control the LX200. As this project evolved, it became clear that ACP1 could be used for observatory automation if it could somehow control the CCD camera. DC-3 Dreams contacted Diffraction Limited and together they conceived of an open Windows Scripting interface to Diffraction's MaxIm DL/CCD program. With this key piece of the puzzle, DC-3 Dreams developed Windows Scripts that controlled both the telescope and CCD camera using ACP and MaxIm. This effort culminated in DC-3 Dreams showing the first off-the-shelf automated observing system at the Riverside Telescope Maker's Conference in the Meade tent on Memorial Day Weekend 1999.

As things progressed during 1999, Diffraction and DC-3 Dreams decided that astronomy software needed a driver/client architecture like the rest of the computing world. At that time, there were only a few astronomy software packages that could control telescopes, cameras, filter wheels, etc. All of them contained their own code for each of the devices they supported. This sort of architecture had long since been abandoned by the computing community in favor of the now-familiar driver-client architecture. Neither DC-3 Dreams nor Diffraction wanted to undertake writing their own built-in control code for the rapidly growing family of astronomy devices out there. Led by Bob Denny of DC-3 Dreams, they undertook to establish the ASCOM Initiative to promote the driver-client architecture in astronomy software.

The Telescope Interface Standard

The next task was to develop the first driver interface standard, and the Telescope interface was chosen since it has the highest leverage. Since this interface had to be usable in a wide variety of applications (apart from ACP1 and MaxIm), the design was carefully refined over the span of a couple of years, with a heavy emphasis on real-world applications. During this period, Sienna Software (now Imaginova) joined the effort and provided a $10,000 grant to develop an initial set of telescope drivers for use with their Starry Night planetarium program. There were no strings attached to the drivers, so they could be used by anyone writing astronomy software that needed to control telescopes.

Also during this period, the ASCOM web site was launched, several other software vendors jumped on the bandwagon, and Sky & Telescope published an article on ASCOM. As experience was gained in practical applications, and the Telescope interface was nearing final form, a Telescope Driver SDK was developed. This was the genesis of the ASCOM Platform.

Initial Releases and Adoption

In mid-2001, the Telescope interface was finalized and adopted by the group. At the same time, the first ASCOM Platform was released. It contained the final version of the Telescope Interface Spec, the Telescope Driver SDK, a Telescope simulator, some driver support components, and the set of standard telescope drivers underwritten by the Sienna Software grant. During the remainder of the year 2001, two more Platform releases were made, each containing more telescope drivers. By now, even research-grade telescopes were included in those which had drivers. In addition, ACP and MaxIm DL/CCD joined Starry Night in using standard telescope drivers.

The Focuser Interface Standard

In late 2000, Doug George of Diffraction Limited proposed a Focuser Standard. Eventually, in early 2002, the ASCOM Standard Focuser interface was finalized. Drivers for various focusers followed.

FocusMax

Also during late 2000, Larry Baker and Steve Brady developed their FocusMax auto-focus software. FocusMax is perhaps the most significant advance in automated observing ever. It provides robust automatic focusing for a virtually infinite number of combinations of telescopes, CCD cameras, and focusers. They both asserted that FocusMax would not have been possible without ASCOM telescope drivers and MaxIm DL's Windows Scripting interface. Weber and Brady participated heavily in the discussions and refining of the Focuser Standard.

ASCOM Platform 2.0

Following on the heels of the Focuser interface standard release, the ASCOM Platform 2.0 was released in September, 2002. This Platform contained the new Focuser standard as well as the first set of focuser drivers, developed by various authors. Per the Initiative goals, these drivers were available for anyone to use. During the latter part of 2002 and much of 2003, additional Platform 2.x releases were made, each with more Focuser and Telescope drivers, as well as a new Focuser simulator that serves as the reference implementation of the standard Focuser interface.

The Dome Interface Standard

Also during 2002 and 2003, discussion began toward a dome control driver interface. Robotic control of telescopes enclosed in a dome clearly needed to be tied to the dome rotation, and control of the dome shutter(s) was clearly needed for weather safety during automated operation. A rather large group of people became involved in discussing the dome interface, and the discussion became contentious at times. The goal of eliminating device-specifics from the interface appeared out of reach given the variety of "shutter" configurations in use. An elegant solution was finally reached by including both azimuth and altitude inputs for shutter positioning, leaving the dome controller to simply "make a hole big enough to see through". The standard was finally adopted in August 2003.

It should be mentioned that John Oliver of the University of Florida contributed a vital piece of the puzzle by implementing Chris Lord's dome pointing equations in Visual Basic 6. Calculating the dome's azimuth and altitude needed for that "hole to the sky" for German equatorial and fork mounts is a difficult task. John's code formed the basis of several programs that use dome drivers, and we all owe him a debt of gratitude.

ASCOM Platform 3.0

In October 2003, the ASCOM Platform 3.0 was released. This Platform contained the new Dome standard, a dome simulator and a generic telescope/dome controller and hub. This latter component allowed any astronomy program that used ASCOM telescope drivers to instantly be able to control the combination of the telescope and dome without any changes to the astronomy program itself. ASCOM was clearly coming of age by this time.

The Telescope V2 Interface

During 2003, it was becoming clear that the Telescope Interface Standard needed to grow. A rather large group of application and driver authors participated in discussing additions to the Telescope interface. Additions included control of guiding rates, a new ability to move about the mount's axis, and better pier-side monitoring and control. The interface was adopted in April, 2004.

ASCOM Platform 4.0

In December 2004, the ASCOM Platform 4.0 was released. This Platform contained the new Telescope V2 interface spec, updates for many drivers, and a few new drivers. An update, Platform 4.1 was released about six months later.

Stability and Maturity

The release of Platform 4 marked the beginning of a long period of stability for ASCOM. The Platform 4.1 remained the standard for several years, though individual drivers were updated during this period. by this time, there were nearly a thousand people on the ASCOM Talk group, and over a dozen people had developed drivers and programs that used them. The big issue was the lack of commitment by device manufacturers to provide drivers and support with their devices.

ASCOM Platform 2008 (5.0)

By mid 2006, it was becoming clear that the ASCOM Initiative needed to address several issues:

These issues led to the following changes for Platform 2008:

At the time of this writing, the ASCOM Platform 2008 is nearing final release. There are over 1,700 members on the ASCOM-Talk list!