4. ASCOM Basics

Let's get specific and see how these principles apply to ASCOM (Alpaca and COM as well). In the diagram below we see a simplified Telescope interface which has the bare minimum functionality exposed. In the pattern areas (interfaces) the upper box contains variables ("properties") which can be read and written. The bottom box shows functions ("methods") which can be called to do things. This telescope can be commanded to slew to a place in the sky and track the earth's rotation sidereally. The client can see where it is currently pointing and see if it's in the process of slewing or not. The client can also turn sidereal tracking on and off, and it can see if tracking is on or off. Take a moment to study this until you can see what the interface supports. See the important points below!

There are some important points here:

• The client makes the same calls (methods) and reads from or writes to the same variables (properties) regardless of which make/model of mount it's using.
• The set of methods and properties (functions and variables) exposed in the interfaces of the mounts is identical. It is a universal standard interface.
• ASCOM COM and ASCOM Alpaca provide exactly the same function: Communication between the app and the device's universal interface.
• The behavior of the mounts, when used via this interface, is identical to a point. Telling it to slew causes it to start a slew, reading its current location works while it is slewing, and the Slewing property will be true while it is slewing. On the other hand, a given mount may be slower or faster when moving from one location to the next, and it may be more or less accurate in its pointing and tracking. The closer it is to ideal (perfect pointing and tracking) the better, but the client app must assume only that it is "doing its best".
• This interface supports only routine operations, "the things we do every night". No adjustments, installation settings, alignment aids, periodic error tables, pointing models, servo currents, encoder tick counts, home sensor position settings, etc. are included. This is by design.
• Mounts differ greatly in the many ways they support their pointing and tracking accuracy and repeatability. A "prime directive" for ASCOM is to exclude device-dependent features from the standard interfaces (*), The ASCOM ecosystem leaves management of these internal mount design features to the mounts themselves. The client apps are left to use the mount for astronomy, and the closer it is to ideal the better. The client apps know nothing about how the mount accomplishes its tasks of pointing and tracking.

We're now at the conceptual heart of ASCOM. Hopefully you now understand the ASCOM interface concept and the important consequences of this design pattern. Now it's time to look at just a few key underlying characteristics in 5. Key Characteristics.

(*) This is a white lie. The ASCOM interfaces for all devices include a free-form Action() method and a property SupportedActions that provides the list of supported actions (if any) for that device only. None of this is covered by standards. Use of this feature is rare for reasons that, by now, should be obvious to you.