ASCOM transport

ASCOM is the Windows-only equipment standard. Drivers are COM objects; you talk to them through a COM Chooser dialog and call methods/properties.

Per-role

ASCOM in Starship is per-role. There's a separate slot for each piece of gear:

• Mount (ASCOM Telescope)
• Camera (imaging camera)
• Guide camera (a second camera for guiding)
• Rotator
• Focuser
• Filter Wheel
• Observatory (dome / roof)
• Power (an ASCOM Switch device — relays and power/voltage/current readouts, e.g. a Pegasus UPB)
• Flat device (a CoverCalibrator — flat panel or flip-flat, with cover and brightness control)

Each role is independent — assign and connect them in any order, and only the ones you actually own.

Setup flow

For each role, in Settings → ASCOM you have these actions:

1. Choose — opens the ASCOM Chooser dialog (the standard ASCOM popup) filtered to the right device type. Pick your driver from the list; the dialog returns a prog_id like ASCOM.QHYCCD.Camera, which is saved to config.
2. Setup — opens the selected driver's own Properties/SetupDialog so you can configure it (COM port, model, etc.). If the device is connected, Starship disconnects it first and reconnects afterwards.
3. Connect — connects the device. Once connected, its properties are read on a poll loop and published on the bus as equipment.device events.
4. Disconnect — disconnects the device but keeps the driver assigned.
5. Clear — forgets the assigned driver for that role (disconnecting first if needed), leaving the slot empty.

Native dialogs appear on the imaging PC

The Chooser and a driver's SetupDialog are native Windows dialogs that open on the imaging PC's desktop — they do not appear in the browser. The web page waits while the dialog is open. If you're working remotely over RDP, the dialog appears in your remote session. Starship tries to raise the dialog to the foreground for you, but if a dialog seems to be "hanging," check the imaging PC's desktop for a window waiting behind the browser.

Auto-connect

Each role has an auto-connect option. When set, Starship connects that device automatically at startup (and Connect All connects every role that has a driver assigned), so an unattended rig comes up ready without anyone clicking Connect.

Polling

Once connected, each device's properties are read on a poll loop (default every 5 seconds) and published so the rest of the app — status tiles, safety, the sequencer — sees live equipment state. If a driver stops flipping Connected to true, or a property read fails, the slot is marked disconnected with an error you can see in Settings.

Wedge protection (fail-closed)

ASCOM property reads are synchronous COM calls that can't be given a timeout, so a hung driver could otherwise freeze the poll loop while stale readings still looked "live." A liveness watchdog watches the worker; if a COM call blocks past its budget (default 20 seconds), the affected device — and any other connected device whose polling has stalled behind it — is demoted to not connected with an explanatory error, so safety logic and the UI never trust frozen data. State recovers automatically on the next successful read. Recovery from a truly hung driver may still need the app restarted.

Why per-role rather than a single ASCOM Hub

A hub adds a layer that can fail. A camera using ASCOM.QHYCCD.Camera directly is simpler than going through ASCOM.DeviceHub.Camera which then talks to ASCOM.QHYCCD.Camera. The hub model is great for telescope clients that want a single point of integration; for an unattended observatory app where reliability matters, direct is better.

Requirements

Windows. ASCOM Platform installed (download from ascom-standards.org). The pywin32 Python package — pip install pywin32 on the imaging PC. Without pywin32 (or on a non-Windows machine) ASCOM is unavailable: the transport is disabled cleanly and Settings shows a clear reason (the Chooser and Connect won't work).

Limitations

ASCOM is single-threaded per object (COM apartment threading). Heavy concurrent property reads can stall a driver, so Starship serialises every COM call for all roles through one worker and keeps the poll loop conservative (a few reads per role, once every few seconds) to avoid overwhelming a driver.

When to prefer Alpaca

For new equipment where the manufacturer offers an Alpaca driver, prefer Alpaca: cross-platform, works without pywin32, easier to debug (it's just HTTP). ASCOM is only essential when the only driver available is COM-based.