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.


Also during late 2000, Larry Weber 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 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 5.0 in 2008:

ASCOM Platform 5.0 was released in February, 2008. There are over 1,700 members on the ASCOM-Talk list!

ASCOM Platform 5.5 Update

With the release of Windows Vista came new security features called User Account Control (UAC). Uptake on Vista was slow, but by mid 2008 it became significant. As Vista spread, problems with UAC became an issue for ASCOM drivers and applications. Most people resorted to simply turning UAC off on their systems, as it was a problem for many programs, not just ASCOM drivers. Then WIndosws 7 was released in the Summer of 2009. It had a "smoothed out" UAC and other improvements which resulted in a much faster uptake then Vista. By late 2009 the UAC issue was being aggressively addressed by most software vendors.

Another issue that arose following the release of Platform 5 was the disappearance of "real" serial ports, and the use of USB to Serial converters. The serial support library that was included in Platform 5 and before was not well suited to these devices. It was not understood why the Microsoft-supplied library combined with some USB-Serial devices resulted in unstable combination. It became clear that some sort of rewrite/update of the serial support fopr ASCOM drivers was necessary.

Meanwhile, several more developers joined the core ASCOM Platform team. One developer in particular, Peter Simpson, produced a driver conformance checker called Conform, which revolutionized driver quality control. Peter also saw the problems with UAC, USB-Serial devices, and other issues that had arisen after Platform 5 release. Peter then undertook development of an update to the Platform, which ultimately became the Platform 5.5 update. It included several new tools including the Profile Explorer, a tool for managing ASCOM driver registrations for the Chooser and driver data storage editing.

The Platform 5.5 Update was released late in 2009. There are over 2,000 members on the ASCOM Talk list.

Open Source and Creative Commons

With the expansion of the core ASCOM development team, and some objections having been raised over the old SPACE.com copyrights on many of the components, it was decided to move the entire platform to Open Source, change licensing to Creative Commons, and put the sources online in a Subversion repository. This effort was led by Tim Long, who supplied the servers, secured necessary software, and put it all online. The initial repository was populated in late 2009, and has since served the development team well. All previous copyrights on Platform components and sources, as well as original drivers, were vacated and everything was placed under the Creative Commons Attribution-No Derivative Works 3.0 License. See Who Owns ASCOM?

ASCOM Platform 6

By mid 2010 several issues made it clear that a major revision of the Platform would be a good idea:

These issues led to a 10 month development effort by the now-expanded development team, and using the recently added development and tracking services. The result is the ASCOM Platform 6, which was released in late June 2011. For details on the changes and features in ASCOM Platform 6, see the detailed description of ASCOM Platform 6.

Platforms 6.1 and 6.2 (and the developer tools)

These are maintenance releases of Platform 6, and contain many small additions and corrections as they are reported. Platform 6.2 was released 01-Dec-2015. It contains the new SafetyMonitor and ObservingConditions interfaces. There have been a couple of minor releases since. We owe the ASCOM Developer Team our thanks for keeping this current and maintained. Bravo!

Windows 10 Issues

During 2016, as people started using WIndows 10, some issues with installation and ASCOM driver stability arose. It took a fair bit of time for the underlying issues to surface. As of early 2017, a project is underway to positively identify the problem(s) and to mitigate them as best we can (considering they appear to be bugs in WIndows 10 itself).