Skip to content

ASCOM

The Control Standards: ASCOM and INDI

You do not write code for a "Sky-Watcher EQ6" and then a "Celestron CGX." You write code for the standard interface (the API).
Standard Core Technology Key Feature Control Flow
ASCOM Alpaca RESTful (JSON over HTTP) Cross-Platform: The modern, recommended standard. It allows your central scheduler (written in Python/Go) to send simple JSON commands to the telescope's local computer. Central Scheduler $\rightarrow$ Alpaca JSON $\rightarrow$ Local ASCOM Driver $\rightarrow$ Telescope Mount
INDI Client/Server Network Protocol Network Transparency: Designed from the start for remote access. Excellent for Linux-based control nodes (like a Raspberry Pi). Central Scheduler $\leftrightarrow$ INDI Server $\leftrightarrow$ Telescope Mount

The Core Pointing Command

To point any telescope at a given place, your central scheduler only issues a command using the Universal Coordinate System (RA/Dec):

  1. Scheduler: Sends command: SlewToCoordinates(RA, Dec).

  2. Local Driver (e.g., Alpaca): Receives the universal RA/Dec.

  3. Local Driver: Automatically performs the complex geometric and atmospheric math to convert RA/Dec into the telescope's current motor commands (Alt-Az, Equatorial, etc.)

I. 📡 Control and Hardware Adaptations (The Node)

The amateur nature dictates a reliance on flexible, low-cost computing at the local node.

A. Dominance of INDI and Alpaca

While professional arrays often rely on vendor-specific drivers, your network must leverage the open standards:

  • INDI (Instrument Neutral Distributed Interface): This becomes the dominant standard, especially for Linux-based control (e.g., Raspberry Pi or Intel NUC). It's robust, supports nearly all amateur hardware, and is entirely open-source.

  • ASCOM Alpaca: Essential for sites running Windows. The scheduler must be able to issue commands to either an INDI server or an Alpaca server using the same universal RA/Dec command structure.

B. Hardware Synchronization (Reliable Timing)

You cannot require every amateur to install expensive PTP gear.

  • Standard: Rely on high-quality NTP (Network Time Protocol) running on the local control computer.

  • Best Practice (Optional): Encourage or provide a simple, low-cost GPS-Disciplined Oscillator (GPSDO) card for the local node computer. This drastically improves the local clock's stability, pushing synchronization accuracy into the sub-millisecond range—sufficient for most SSA and asteroid parallax.

  • Verification: Require every image to have a Time Stamp in the FITS Header recorded by the local computer immediately upon camera readout. Your processing pipeline must check the difference between the local time and a central NTP server's time and flag any image taken by an unsynchronized telescope.

Local Coordinate Transformations (from Telescope pointing.md)

The central scheduler always issues pointing commands in J2000 RA/Dec — a single universal coordinate language. The local agent (ASCOM Alpaca driver or INDI) then performs three transformations before sending motor commands:

The Three Local Transformations

  1. Time and Location Correction: Converts celestial coordinates (RA/Dec) into coordinates relative to the telescope's physical position (Hour Angle / Declination), using the telescope's GPS location and the Local Sidereal Time at the moment of observation.

  2. Atmospheric Refraction Correction: Calculates and corrects for the bending of light as it passes through the atmosphere. This correction is unique to the telescope's altitude above sea level and the target's current elevation — a target near the horizon is displaced much more than a target overhead.

  3. Mount Conversion: Converts the corrected coordinates into the instrumental coordinates specific to the mount type:

Mount Type Conversion
Equatorial Rotate RA axis to calculated Hour Angle; set Dec axis
Alt-Azimuth Calculate exact Azimuth (horizontal angle) and Altitude (vertical angle) at that precise second

The Closed-Loop Plate-Solve Fail-Safe

Even the best pointing model has errors (alignment drift, mechanical flexure, polar alignment inaccuracy). For reliable synchronisation across heterogeneous mounts:

  1. After slewing, the agent captures a short exposure
  2. The image is plate-solved (ASTAP or Astrometry.net) to determine the exact WCS of the image centre
  3. If the centre deviates from the commanded RA/Dec, the software calculates the angular offset and sends a final correction to the mount motors
  4. A second short exposure confirms alignment before science imaging begins

This loop ensures that regardless of mount type or mechanical quality, the final image is centred on the exact intended astronomical coordinates.