The open observatory runs on four different clocks

An eight-inch Ritchey–Chrétien imaging rig collecting data on IC 10 at Kickapoo Valley Reserve, Wisconsin, in October 2025. Its control computer used N.I.N.A., GS Server, PHD2, and ASTAP rather than the full stack mapped here; the photograph documents the same physical handoffs among optics, cables, a moving mount, and the night sky. Photograph by Brainandforce, CC BY 4.0.[10]

At 2:13 a.m., an imaging camera may be halfway through a five-minute exposure while the mount approaches the meridian, a second camera measures the drift of a guide star, and a focuser waits for the next temperature-triggered adjustment. Each component is doing sensible work. None possesses the whole truth about the night.

An open observatory coordinates that scene through several projects with deliberately different responsibilities. INDI gives devices a shared language. KStars/Ekos plans and sequences work. Astrometry.net derives pointing from the stars recorded in an image. PHD2 measures short-term tracking error and sends corrections. Treating these projects as interchangeable “telescope control” software obscures the most useful part of the design: they run on four different clocks.

Here, a clock is not merely a refresh rate. It is the cadence at which a layer can establish a new fact. A device property can change in milliseconds; an imaging sequence advances after an exposure; a plate solution arrives after a camera readout and computation; a guiding loop corrects motion every few seconds. Reliable automation depends on explicit handoffs among those clocks, especially when the mount crosses the meridian and the system must recover a common account of where it is.

Image context: the cover records an eight-inch Ritchey–Chrétien imaging rig collecting data at Kickapoo Valley Reserve in 2025. Its documented control stack used N.I.N.A., GS Server, PHD2, and ASTAP rather than INDI/Ekos, but the exposed cables, optics, camera, and moving mount make the shared physical constraints visible.[10]

The four clocks at a glance

Clock	Open-source layer	The fact it owns	Typical handoff
Device state	INDI	“This property was requested, is busy, succeeded, or raised an alert”	Drivers report mount coordinates, exposure state, filter position, temperature, and connection status
Night plan	KStars/Ekos	“This target and operation should happen next”	The scheduler invokes capture, focus, alignment, and guiding modules
Pointing truth	Astrometry.net	“These pixels correspond to this patch, scale, and orientation of sky”	A solved image supplies a world-coordinate system for correction or verification
Tracking correction	PHD2	“The guide stars moved this far since the previous sample”	Calibrated guide pulses nudge the mount while the main camera exposes

The boundaries are practical, not absolute. Ekos can coordinate an internal guider as well as PHD2, and INDI carries information used by every other layer. The map describes ownership of evidence: who can make a claim, what observation supports it, and when another component should trust it.

INDI gives hardware a shared grammar

The Instrument Neutral Distributed Interface protocol is XML-based, stateful, asynchronous, and built around properties rather than a catalogue of device-specific commands. An INDI driver publishes vectors containing text, numbers, switches, indicator lights, or binary objects. Each vector can report one of four states: Idle, OK, Busy, or Alert. Clients discover those properties at runtime instead of assuming that every mount, camera, wheel, dome, or weather station has the same capabilities.[1]

That model produces a useful division of labor. A mount driver can expose CONNECTION and EQUATORIAL_EOD_COORD; a camera can expose CCD_EXPOSURE; a filter wheel can expose FILTER_SLOT. A client changes a desired value, the driver operates the hardware, and the resulting property state reports progress. indiserver routes that traffic between multiple clients and drivers, whether they run on one machine or across a network.[1]

The first clock therefore advances through property transactions. A Busy exposure is not yet an image. An OK coordinate is the mount driver's report, not independent proof that photons from the intended field reached the sensor. An Alert says that a transaction failed, but it cannot necessarily distinguish a cloud from a closed dust cap or a snagged cable. INDI standardizes the conversation without claiming that software state and physical reality are identical.

This is why the protocol is more valuable than a giant universal driver API. New equipment can add properties without requiring every client to be rebuilt around one fixed device schema. The cost is that automation must inspect capabilities and states rather than infer success from elapsed time.

Ekos turns the night into a state machine

KStars supplies the sky model and user-facing observatory environment; Ekos supplies coordinated modules for Mount, Capture, Focus, Guide, Align, and Scheduler. Its manager starts local or remote INDI services, while its capture sequence queues define ordered exposures and its scheduler decides which job is eligible to run.[2]

The second clock advances more slowly than a device property. A scheduler job may wait for darkness or a target altitude. A capture step may wait for the camera temperature, a filter change, a dither, guiding to settle, or autofocus. Ekos exposes those as states because “take 20 images” is not one command. It is a conditional process that repeatedly asks whether the surrounding system is ready.[2]

The meridian flip makes this coordination visible. An equatorial mount tracking across the local meridian may need to move the telescope to the opposite side of its pier to continue safely. Ekos documents a sequence in which it completes the current capture, suspends imaging, commands a slew to the same celestial target so the mount changes pier side, runs alignment, restarts guiding, and resumes capture.[2]

That is a resynchronization event, not merely a 180-degree movement. The mount has a new physical orientation. The imaging camera may now frame the field differently. Guiding calibration may need a side-of-pier adjustment. A cable that was slack can become taut. Ekos owns the order of operations, but it depends on the other clocks to establish that each transition really worked.

Astrometry.net asks the pixels where the telescope is

A mount coordinate begins as an encoder-and-model claim. Plate solving tests that claim against an exposure. Astrometry.net detects geometric patterns among stars, matches them against an index, and returns a world-coordinate system describing the image's celestial position, orientation, and scale. Its central achievement is blind calibration: useful prior pointing or scale estimates can accelerate a solve, but the method was designed to identify arbitrary astronomical images without trustworthy metadata.[3][4]

This gives the ecosystem an independent pointing clock. The main sequence is simple to name and profound in practice: capture, solve, compare, correct. Ekos can take an alignment image, call a local or online Astrometry.net solver, and use the result to sync or slew the mount. The next solution tests the correction.[2][3]

Without this loop, a system can be internally consistent and astronomically wrong. A mount may report the requested coordinates after a poor initial alignment, an incorrect time or location, mechanical flexure, or a disturbed setup. Plate solving does not ask what the mount intended. It asks where the camera's pixels actually landed.

The distinction also improves diagnosis. A failed solve may indicate insufficient stars, the wrong index files, distorted optics, clouds, bad focus, or an implausibly narrow search. A successful solve with a large offset points elsewhere. The image becomes evidence rather than just an output file.

PHD2 lives inside the shortest clock

Deep-sky exposures are long enough to reveal tiny tracking errors. PHD2 watches one or more stars through a guide camera, measures their motion between short exposures, and sends calibrated corrections to the mount. Its guide is explicit about the compromise in sampling: one- to three-second exposures are a common starting range, with two to four seconds often smoothing atmospheric seeing, while some mounts with high-frequency error need roughly half- to one-second samples.[5]

Before those corrections are meaningful, PHD2 calibrates how camera motion maps onto the mount's right-ascension and declination axes and how much movement a guide pulse produces. The guide describes calibration moves that displace a star by about 25 pixels in each direction under normal settings. Once calibrated, multi-star guiding can use secondary stars to refine the measured motion and reduce volatility from any single star.[5]

The connection path affects what survives a larger movement. Through an INDI mount connection, PHD2 can receive pointing and side-of-pier information, allowing it to adjust and reuse calibration after slews or a meridian flip. A direct ST-4 guide-camera cable carries correction pulses but not that contextual mount information unless an auxiliary mount connection supplies it.[5]

This fourth clock must remain separate from the main exposure clock. A guide sample is a measurement of recent drift, not a reason to interrupt every long exposure. Conversely, the completion of one perfect science frame says little about whether the next five minutes will track well. Ekos coordinates dithering and settling between frames; PHD2 owns the fast feedback loop within them.

The seams are the ecosystem

The stack is easiest to understand by following evidence upward and intent downward:

Ekos requests an exposure or motion according to the night plan.
INDI carries the request to a driver and returns property state.
A camera image gives Astrometry.net independent evidence of pointing.
PHD2 converts guide-image drift into short corrective pulses.
Ekos decides whether the combined states justify advancing, retrying, realigning, refocusing, or stopping.

This arrangement permits substitution without pretending that substitution is free. A device driver can change without rewriting the scheduler because INDI is the boundary. A local solver can replace a remote service because the alignment step consumes a solution. PHD2 can remain its own application because a documented connection carries guiding state and commands. Yet versions, configuration, and physical behavior still meet at each seam.

The projects also have independent release trains. As of this article's publication, KDE lists KStars 3.8.3, released on 1 June 2026; INDI published its 2.2.4.2 bug-fix release on 5 August; and PHD2 maintains its own 2.6.14 release line.[7][8][9] Those dates are not a compatibility guarantee. They are evidence that the observatory is assembled from active projects whose changes should be tested as separate layers.

This architecture is not limited to hobby imaging. Researchers have described a fully robotic pipeline built by extending KStars/Ekos to plan, schedule, and execute follow-up observations of near-Earth objects with commercial hardware controlled through INDI.[6] The important lesson is not that the same configuration fits every observatory. It is that open interfaces let a research team add domain-specific planning while retaining existing device and execution layers.

Unattended still has a physical meaning

Simulation can validate property discovery, sequence logic, and many failure paths. It cannot certify the torque margin of a slipping clutch, roof clearance at every pointing, a weather sensor coated in ice, recovery after a power cut, or whether a dangling USB cable will catch during a meridian flip.

An unattended system therefore needs a commissioning ladder, not one triumphant end-to-end test:

Build the exact device profile and exercise its INDI properties with simulators where available.
Connect real devices one at a time; confirm units, limits, state transitions, and safe defaults.
Under the sky, test focus, plate solving, guiding, dithering, and recovery independently.
Dry-run the complete meridian-flip sequence while an operator watches the mount and cables.
Test weather, park, enclosure, power-loss, and emergency-stop behavior as physical interlocks, including failures of the control computer and network.
Upgrade one layer at a time, preserving known-good configuration, logs, and a rollback path.

The decisive safety action should not depend on every clock agreeing. If rain arrives, a fail-safe enclosure or local controller must be able to protect the instrument even when the scheduler is stuck, the network is down, or the guiding process has crashed. Software coordination expands what an observatory can do; tested hardware limits determine what it may do without a person present.

That is the deeper value of this open ecosystem. INDI makes device state inspectable. Ekos makes the night plan explicit. Astrometry.net lets the pixels challenge the mount. PHD2 exposes the correction loop instead of burying it in a black box. The four clocks will never tick together perfectly. A trustworthy observatory is one that knows when they have diverged, has evidence for bringing them back into agreement, and can stop safely when it cannot.

cronfeed.work