Mount

The mount drives target acquisition and tracking. Every telescope has exactly one mount; it's the device the task executors call into through the mount driver interface to slew, track, apply offsets, and play offset patterns for mapping observations.

Config shape

Every mount has an entry under device_configs.device_configs_by_id.<device-uid>:

{
  "device_type": "mount",
  "driver": "ascom" | "gbtwenty" | "simulator",
  "driver_configs": {
    "ascom":     { /* see below */ },
    "gbtwenty":  { /* see below */ },
    "simulator": { /* see below */ }
  }
}

The driver_configs map holds parameters for every driver you might use; the active driver is selected by the top-level driver key. This lets you switch between drivers (e.g., simulator and ASCOM) without losing the unused driver's settings.

Drivers

ascom — production

The standard driver for any ASCOM-conformant mount on Windows.

"ascom": {
  "prog_id": "ASCOM.SoftwareBisque.Telescope"
}

Key	Meaning
prog_id	The ASCOM ProgID of the mount driver to load. Examples: ASCOM.SoftwareBisque.Telescope, ASCOM.SiTechExe.Telescope, ASCOM.Simulator.Telescope

Notes:

• The mount's ASCOM driver must be installed and configured on the SkyNode host before SkyNode tries to load it.
• The ASCOM driver app should already be set up for your hardware (COM port, baud rate, pier flip behavior, slew rates). SkyNode does not manage those settings; it loads the ProgID and talks to whatever the ASCOM driver presents.
• ASCOM is Windows-only — the pythoncom and win32com.client bindings are imported unconditionally in the driver. Running SkyNode on macOS or Linux is fine for simulator and native drivers; for ASCOM you need Windows.

gbtwenty — experimental

The native driver for the UNC GBTwenty radio mount. Streams position-velocity (PD) commands to the Observatory Control Unit (OCU). See Driver interfaces → GBTwenty for the implementation details.

This driver is the only native mount integration today and is considered experimental — the limit-checking and invalid-velocity guards still need work at the driver level. Use it only with the GBTwenty hardware and the OCU configured by the GBTwenty operations team.

simulator — testing only

Drives a paper mount that accepts every command and reports back sensible state. Good for verifying the rest of your install before hooking up real hardware.

"simulator": {}

No parameters required.

Troubleshooting

• "ASCOM driver won't load." Check the ProgID with the ASCOM Diagnostics tool or PowerShell: (New-Object -ComObject ASCOM.Utilities.Profile).RegisteredDeviceTypes. A common cause is a 32-bit driver loaded into a 64-bit Python process (or vice versa) — the SkyNode build should match.
• Mount drops connection after slewing. The ASCOM driver app is crashing or the COM proxy is dying. Usually a driver-app issue, not a SkyNode issue. Restart the driver app first.
• "Tracking is engaged but pointing drifts." Mount calibration (T-Point or equivalent) lives in the ASCOM driver app; SkyNode consumes whatever the driver reports. If pointing isn't right in the driver app it won't be right in SkyNode.
• Mount won't go past a pole or meridian. Mount-side limits enforced by the driver and the mount's control system. SkyNode respects these; the fix is in the mount's configuration.