History of ASCOM and Alpaca Development

For a detailed technical history of activity, changes, and additions to the ASCOM Platform for Windows since 2018 see the ASCOM GitHub Release Notes or for history going back to 5.0 in 2018 see the Platform Tags Pages (there are two, see "Previous <-> next" at the bottom).

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.

The Camera Interface

Doug Grorege of Diffraction Limited first proposed the Camera inteface (based on his extensive experience with Diffraction's Camera API) in 2005. In the Fall of 2009 the last multi-party negotiation, the universal format for Bayer Matrix representation, was completed at the AIC Conference. The Camera interface spec was adopted shortly thereafter.

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 SourceForge Subversion repository. More recently, in the Spring of 2018, it was decided to move the ASCOM open source repository to GitHub, as this system has become very popular and our Subversion service, SourceForge, began do have stability problems. All previous copyrights on Platform components and sources, as well as original drivers, were vacated many years ago 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 late 2016, 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).

Platform 6.3 (and the developer tools)

In early 2017, lead ASCOM Platform developer Peter Simpson researched and identified the source of the problems with Windows 10. In addition, he addressed several small issues that arose in Platform 6.2. On 27-Jan-2017 Platform 6.3 was released.

Conform - Tool for Interface and Conformance Testing

In order to help driver developers assure that their devices and drivers meet the requirements for interface strructure, members, and behavior, the Conform tool was developed in 2017. When run, the tool exercises a device/driver including all required and optional features, as well as out-of range conditions and error responses. It is updated to include additional tests when an undetected problem appears with a device. This tool's development is ongoing so it is not part of the Platform. For details see the Conform GitHub Releases and Release Notes pages.

Platform 6.4 (and the developer tools)

Lead ASCOM Platform developer Peter Simpson did a major overhaul and upgrade of the installation technology for the Platform, as well as incorporating several problems and suggestions during the previous 18 months. In July 2018 Platform 6.4 was released, with a Service Pack in September 2018.

ASCOM Remote

This tool was originally developed by Peter Simpson in late 2017 to allow distributing ASCOM/COM clients and drivers across multiple computers via a network connection. The communication between computers used a REST-like (HTTP/JSON) protocol. However it turned out to be a happy accident, as his design for that protocol could itself be standardized into a next-generation implementation of the standard ASCOM interfaces. ASCOM Remote was the genesis of the cross-platform Alpaca standards. It was first released in May 2018. A more detailed history of ASCOM Remote maybe seen on the ASCOM Remote GitHub Releases and Release Notes pages (there are several continuation pages going back to May 2018)

Cross-Platform (Alpaca)

This project started in mid 2018 with the development of ASCOM Remote, and has now yielded surprising acceptance in the astronomy software and device community. For more information see the Introduction to Alpaca. This project is ongoing and has become an integral part of the ASCOM Initiative's process and deliverables.

Rotator V3

During 2018, several community and device maker requests made it clear that the Rotator interface needed enhancement to support keeping the offset between the mechanical angle and the sky/equatorial Position Angle within the Rotator, to be shared between multiple client applications. As a result the Rotator interface was enhanced to add these capabilities in a universal/device-independent way. This new version was introduced in Platform 6.5.


During 2018 and 2019, community feedback indicated that the Switch interface is awkward for use with combination cover and flat light-source devices. As a result a new interface, CoverCalibrator, was designed and offered for comment. The resulting new interface was introduced in Platform 6.5.

Camera V3

During 2018 and 2019, it became evident athat the Camera interface needed some additional capability to support the new CMOS sensor technology. After community discussion and negotiation, several new members were added to the Camera interface. One set of properties was added to support control of bias or offset for the CMOS sensor. The other member, SubexposureDuration, is used to allow CMOS cameras to combine optimal short exposures (to realize the CMOS dynamic range) into a single image for transfer to the host computer. In late 2020 Camera V3 was adopted and incorporated into the Platform 6.5 SP1 final, as well as the Alpaca specifications and tools.

Platform 6.5 (Jul, 2020, including Alpaca Support and Developer Tools)

This Platform version is the most ambitious and comprehensive in the history of ASCOM. Two new interfaces were added (including simulators, documentation, etc) and one was updated. Many other smaller changes and improvements were made. Also, Alpaca capabilities were addeed to the Chooser. During 2018 and 2019, work on Platform 6.5 resulted in a number of pre-releases and Release Candidates being made available, with the 6.5 production release made in July 2020. Notable items are

Platform 6.5 SP1 (Dec 2020)

A 6.5 Service Pack 1 release was made in December 2020, mainly to fix a problem in Astrometry.Transform library and to restore earth rotation parameter updates following breaking changes made by NASA to its data access web site.

Platform 6.6 (Jan 2022, including Alpaca Support and Developer Tools)

This Platform consists of some internal improvements to COM and Alpaca support, and solutions to problems that appeared during 2021, following the December 2020 release of 6.5SP1, as well as a number of targeted special builds to handle specific and unusual installer issues. For more details, see the ASCOM Platform 6.6 Release Notes.

Platform 6.6SP1 (Aug 2022)

This Platform addresses multiple edge-case installation issues that appeared after 6.6, improvements to various components, plus improved developer tools and templates. For more details, see the ASCOM Platform 6.6SP1 Release Notes.

Platform 6.6SP2 (Aug 2023)

Enhancements to the installer, camera simulator, telescope timulator, SOFA class, DriverAccess library. Bug fixes to Telescope Simulator, Rotator Simulator, Device Hub. For more details, see the ASCOM Platform 6.6SP2 Release Notes.