Bill Pellerin

Houston Astronomical Society

GuideStar Editor

If you get into a discussion about the ‘best’ telescope, prepare for controversy. The right answer, of course, is that there is no one best telescope. There are telescopes that are better for the kind of observing you are doing (deep sky, planetary, double star, etc.), but how about the right telescope for the observing conditions you’re likely to find.

Here’s my story. On October 12, 2012 I was part of a group of amateur astronomer volunteers who did a star party at the Camp for All site near Brenham, TX, about 80 miles northwest of Houston. Camp for All is designed to provide a summer camp experience for children and their families with special needs. For this event we were showing the sky to children who are cancer patients. All public star parties are a great experience, but this one is especially rewarding for the volunteers.

The weather conditions for that day were not the best, but there were some breaks in the clouds and we had hope that the sky would clear in time for observing, which was scheduled between 8:00 p.m. and 9:00 p.m. The sky didn’t cooperate – clouds came and went and while a few stars popped out from behind the clouds from time to time, there was no consistent clear sky for us.

Knowing that these were the conditions we would likely have to work with, what’s the best telescope / mount to bring? Last year, when conditions were excellent I had my computerized alt-az 8” SCT at the site. Turn it on, find two stars to set it up, and it’ll find whatever I want in the sky and track it. I didn’t have to keep nudging the telescope to keep the object in view.

This telescope was a great choice last year, but it was a poor choice for this year. It didn’t work well at all, and it wasn’t because anything malfunctioned, it was because observing conditions were different. We had a 50 to 75 percent cloudy sky at the site, with a few stars shining through (notably Vega). The SCT system requires a two star alignment, and on a clear night it’s easy to accomplish. On a night where clouds are coming and going, alignment is virtually impossible. The ‘scope slewed to the vicinity of Alpheratz, said ‘center Alpheratz’, Alpheratz went behind a cloud, and so on.

I never was able to get the telescope aligned. I was able to manually point the telescope to the double cluster and show this to a few campers, but it wasn’t visible for long. The double cluster went behind a cloud.

What would have been better under these circumstances is an alt-az mounted manually pointed telescope – a Dobsonian or some other manual mount. With that kind of telescope I could have pushed it to, say, Mizar, a nice triple star system. Or to Albireo, a lovely double star in Cygnus. (Ok… I could have manually pointed the SCT as well, but it doesn’t lend itself to manual pointing easily.) I would, of course, have had to nudge the manual telescope from time to time.

So… what are the characteristics of a good telescope for these circumstances? The advantage to a computerized and motorized telescope is that it finds objects for you and it tracks them for you. Less fiddling is required during the observing session. This works if the sky is clear enough for you to get a good alignment. The advantage of a manually pointed telescope is that you can point it anywhere, easily, by hand and no alignment is necessary.

My conclusion: The best public star party telescope, especially if observing conditions are iffy, is one which can be manually pointed if necessary but has some pointing assistance capability if the sky allows you to do an alignment. I have an alt-az telescope mount with encoders and a small (deck of cards sized) push-to computer. If I can do a two star alignment, the push-to computer will tell me which direction and how far I have to push the telescope to get the telescope pointed to an object in its database. If I can’t do a two star alignment I can simply push it to some object I already know. I use a small wide field refractor with a on this mount so that the number of telescope nudges is limited and the distance I have to move the telescope is limited. This setup obliges me to select objects that show well in such an instrument, but there are plenty of those. Look in books and magazines for ‘binocular objects’ – these make great wide-field instrument objects.

I could have showed the kids some bright double stars (where the clouds cooperated), perhaps the Andromeda Galaxy, a bright cluster, or a planet (had there been any in the sky on that night).

The key to public star parties is to show the public some bright objects, have a story to tell about the object (how far, what color, the evolution of the object, etc.), and wait for questions. Be prepared to show where objects are in the sky with your green laser pointer and teach the observers about the object.

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.