I’m writing this post almost two months late. I’d been working on this topic at the turn of the year for at least 2 weeks, and it was actually so frustrating that I’ve only now felt able to write about it, having had some time to cool down …

In automated (remotely operated) observatories, dome slaving refers to the continuous synchronization between the telescope’s pointing direction and the rotational position of the dome. The objective is to ensure that the telescope’s optical axis remains unobstructed and always aligned with the dome slit (shutter opening).

Mathematically, dome slaving is a coordinate transformation problem. The telescope operates in the equatorial coordinate system defined by Right Ascension (RA) and Declination (Dec), which are fixed on the celestial sphere. In contrast, the dome is controlled in local horizontal coordinates, namely Azimuth (Az) and Altitude (Alt).

The transformation chain can be summarized as follows:

• RA/Dec → Hour Angle (via Local Sidereal Time)
• Hour Angle + observer latitude → Alt/Az
• Alt/Az + observatory geometry → required dome azimuth

The final step is critical: the dome must not simply follow the telescope’s azimuth, but rather the intersection of the telescope’s optical axis with the dome surface. This requires a geometric model that includes parameters such as dome radius, slit width, and—most importantly—the spatial offset between telescope and dome center.

Countless test runs and always a different deviation …

If there was ever a time when I thought all that effort had been in vain, it was definitely during these tests… no matter what parameters I set in NINA, the optical axis was almost always off-centre. And by ‘off-centre’ I don’t mean just a few centimetres – in some cases it was over 70 cm off the axis, meaning the telescope wasn’t pointing through the shutter aperture at all.

In order to be able to measure the deviation I installed a „laser levelling device“ in front of the scope

To make matters worse, the error wasn’t even consistent. The test directions were 90, 180, 270 and 360 degrees – i.e. east, south, west and north respectively… the deviations were completely random. It was precisely at this point that another problem arose: when you’re completely stuck, you ask the AI, and as we all know, it always has an answer…

So I had been entering various combinations of parameters into the controlling software N.I.N.A. for days and never(!) managed to achieve even remotely a consistent alignment…

Completely desperate, I was in fact on the verge of giving up when a seemingly simple question from an astronomy colleague actually put me on the right track. The question was: are you sure that the dome rotation drive always moves exactly where you want the dome to go?

After answering the question with “yes, I think so”, I actually thought about it again and then it dawned on me: the dome rotation is measured by a rotation sensor – nothing more than a small measuring wheel that presses against the lower edge of the dome…

At least, that’s how it was supposed to work: it turned out that this wheel had sometimes lost contact with the dome wall… which also explained why the errors were never the same and seemed completely erratic – depending on when the wheel made contact again and took a reading…

Resolution and Implications

The issue was resolved by ensuring continuous and stable contact between the sensor roller and the dome ring. Once reliable contact was restored, dome positioning became consistent and reproducible, confirming the correctness of the underlying geometric model.