Bill Pellerin

Houston Astronomical Society

GuideStar editor

Note: This is a technical article about communication between your observing devices and your computer. The ASCOM Initiative only supports Windows PCs.

How long have you been fiddling around with computers and the devices connected to them (sometimes called peripherals)? If you’ve been doing this for a long time you may remember the old days when, if you bought a new piece of software, you had to be sure that the software would support (work with) your printer. That is, the software had to support or communicate directly to your printer and if it didn’t you were out of luck.

Fast forward to almost the current day. And think about astronomy software, in particular planetarium programs that control your go-to telescope. Until recently, if the software did not support your telescope mount, your imaging camera, your guiding camera, your focuser, or some other part of your setup you had a problem. One solution, a bad one, is to use the software that’s compatible with your device instead of the software you’d prefer to use.

The computer / printer problem got solved by offloading the task of communicating from the software to the printer to the operating system. The o/s communicated with a ‘driver’ (a small piece of software) usually provided by the manufacturer of the printer and the ‘driver’ established the communications with the printer. This arrangement made the development of application software easier because the manufacturer was no longer required to support a large number of printers, and it handed off the task of facilitating the communication between the application software (and o/s) and the printer to the printer manufacturer. The printer manufacturer had a vested interest is assuring that their product would work in that environment; nobody would be interested in purchasing a printer that they couldn’t use.

To some degree, we’re still in the dark ages with telescope systems (mounts, cameras, etc.). The software maker is obliged to make, for example, planetarium software work with a large number of telescope mounts to make it marketable. If your software and your telescope mount can’t talk with each other you’re stuck.

But, like the computer / printer problem was resolved by making the printer maker responsible for the final piece of software to enable communications, we’re now moving to a software model where the mount (for example) manufacturer is responsible for writing the ‘driver’ that allows the planetarium software to communicate with the mount. This frees the writer of the planetarium software to concentrate on the aspects of the software that relate to the functionality of the program.

The solution is called ASCOM (which means Astronomy Common Object Model). The idea is that the software maker creates programs that communicate in the same ASCOM compliant language and the device manufacturer (or an interested third party) creates a driver that interprets the ASCOM commands and converts those to commands that their device understands. Communication from the device to the software reverses the communication path; the ASCOM interpreter translates the communication from the device into language that the software understands.

Not all software and not all devices support this approach to establishing communication between the software and the device, but many do and if you need the capability that’s provided by this approach it can serve you well.

Why would you use ASCOM instead of the direct communication that the software provides? One reason – the software you want to use may not support your device directly, but may support ASCOM devices. In other words, it may be the only way to establish communication between your software and your device.

This is why I’m using ASCOM to enable communication between the camera control software I’m using and my imaging camera. The software I want to use for that purpose doesn’t directly support my camera, so the only way to make the communications work is via the ASCOM interface. The manufacture of the camera has provided an ASCOM ‘driver’ as the final puzzle piece that makes this work.

There’s another reason to use this as well. Telescope mounts have long used serial ports (COM Ports) for communication between the software and the device. (This is a bit of a relic, and many mounts are moving away from using serial ports.) The problem is that serial ports are a ‘captured’ by the software that’s using them. No other software can simultaneously use the serial port to connect to the same device. With ASCOM, the serial port is tied to the ASCOM driver, not the application software. The ASCOM driver can accommodate more than one communication path from software so two or more computer programs can communicate simultaneously to the device through the same ASCOM driver.

Why would you want two different software programs to be able to direct your mount to a particular position in the sky? Perhaps the two programs have non-overlapping capabilities. That is, maybe the first program has a great list of NGC objects and the second has a great list of variable stars. Both can be running simultaneously and can share the communication path to the telescope mount.

Saving the best for last, the ASCOM software is free from www.ascom-standards.org. If all this sounds complicated to set up and make work, all you need to know is whether there is an ASCOM driver for your device (telescope mount, focuser, camera, dome, filter wheel, etc.) and whether the software you want to use supports the ASCOM interface. If the answer to both those questions is ‘yes’, you’re good to go.

Much of the software that implements this capability is created by non-paid amateurs (some of whom are professional software developers) who then give the software away for free. These people have done a great service to the astronomical community. Thanks to them.

A work around: The planetarium software that I use does not support ASCOM. It does, however, support a similar, although proprietary, standard. A volunteer software developer created a piece of software that translates the proprietary communications to ASCOM which enables ASCOM communication to the telescope mount driver. Ok, it’s not as clean as we might like, but it works well.

Communication among astronomical devices is evolving, with some devices allowing Wi-Fi communications or wired network communications. I can see the coming of an OAN (Observatory Area Network) to complement the LAN (Local Area Network) and the WAN (Wide Area Network). With this capability installed the ability to control your telescope and other devices remotely is only a few short steps away. Even if those few steps are only the distance between the observatory and a warm room, this could represent a significant advance in amateur capabilities.