July 26, 2026  ·  🔭 Astronomy

The Forgotten Meridian Flip – How a Single Checkbox Cost Me Two Exposures

There are failures that look like a catastrophe and are in truth an unchecked box. This was one of them – and it cost me exactly two exposures in the end, even though the screen looked like total collapse. And because I spent minutes staring at the screen suspecting the wrong thing, I am writing it down – as a warning to my future self and to anyone operating a harmonic-drive mount remotely.

Briefly, the setup: my rig sits at Starfront in Texas and I control it from Germany. The mount is a ZWO AM5, a strain-wave mount without a counterweight. On the night in question the session ran cleanly for a very long time – until PHD2, the guiding software, suddenly went off the rails.

The picture that looked like the end of the world

What I saw was a PHD2 window in full alarm: the tracking error in right ascension was no longer measurable in arcseconds but in hundreds of them. The graph ran off the top of the frame. A yellow warning bar sat across the window:

"Your Max RA Duration setting is preventing PHD from making adequate corrections… try restoring Max RA Duration to its default value."

Translated: your maximum correction duration is too small, restore it to the default and I can push back harder. Shortly afterwards PHD2 lost the guide star altogether – signal-to-noise zero, one red "star lost" after another.

My first, obvious reading: something in the guiding has collapsed. Maybe the guide star has become too faint, maybe I really do need to change the maximum correction duration, as the message suggests. That is exactly the trap – and I nearly walked into it.

What the log said that the screenshot didn't

Instead of changing settings, I had Claude analyse the guide log – line by line, across several thousand entries. And the log tells a completely different story from the panic window.

The error didn't arrive abruptly. It grew steadily: 10 pixels, 19, 28, 38 … over four and a half minutes up to more than 700 pixels – a clean, straight rise of roughly eight arcseconds per second.

And the decisive part: the guide star was bright and locked the entire time. Signal-to-noise around 250, full star mass. Only right at the end, when the error had grown so large that the star was simply pushed out of the field, did the loss occur.

That rules out a faint or lost guide star. A star you can still see clearly and brightly, but which keeps "running away" regardless, means only one thing: the mount is moving and the guiding can't keep up. No software correction in the world catches a drift of eight arcseconds per second. So the yellow warning was well meant and completely useless.

Which left the question: why does a mount that ran perfectly for a very long time suddenly drift away?

The meridian I hadn't thought about

The answer was in the log as well, in the header lines of the two sessions. On the first, failed run the mount was on pier side west. On the restart a few minutes later, on pier side east. In between, the target's hour angle had turned from negative to positive – so the target had crossed the meridian.

And that was when the penny dropped: that night, in the legacy N.I.N.A. sequencer, I had simply forgotten to enable the meridian flip. The box was unchecked. So at the meridian my program did – nothing.

The mount just kept tracking past the meridian, up to the point where it stops of its own accord. From there the stars drifted, PHD2 pinned its corrections to the maximum, eventually lost the star, and the run came to a halt. What it cost me in the end was two five-minute exposures – no more, because it was mid-morning in Germany and I glanced at the screen shortly afterwards. On the second run, with the box checked, the mount flipped cleanly to the east side – and everything ran smoothly again immediately.

It was not a hardware fault, not a guiding problem, not a damp night. It was a checkbox.

What a meridian flip actually is

For anyone in the position I was in before that night – here is the principle, calmly:

An equatorial mount follows the sky by rotating about an axis parallel to the Earth's. An object rises in the east, reaches its highest point at the meridian and sets in the west.

As long as the telescope looks east, it hangs on one side of the mount. If it simply kept tracking westwards past the meridian, the telescope would eventually reach an awkward position – on classical mounts up to a collision between optics and tripod, the dreaded "pier crash". And there is what you can't see from a distance: the cables wind further around the axis with every hour.

The meridian flip is the solution: at the meridian the mount rotates the right-ascension axis by exactly 180° and carries the declination axis over the pole far enough for the telescope to point at the same target again – now from the other side of the pier. Afterwards it points correctly at the same target again, just from the other side – and can carry on tracking westwards without trouble.

One side effect: after the flip the image is upside down (rotated by 180°). That is why the software then plate-solves again, recentres the target precisely and restarts guiding.

"But the AM5 has no counterweight and is balanced centrally – surely it can track past the meridian?" True, up to a point. But this is exactly where my aha moment was: the ZWO driver carries the setting "Stop tracking at 4° after meridian". Four degrees – that is exactly 16 minutes. So the mount deliberately tracks only to 16 minutes past the meridian and then stops tracking.

When I later looked at the log, my drift began precisely at four degrees past the meridian. That limit isn't a fault but a sensible end stop – it prevents the mount from running on indefinitely. But it is no substitute for a flip. Without a flip you run straight into that stop.

What you have to set in N.I.N.A. for it

My control software is N.I.N.A. There are two places – and both have to be right. That was my actual lesson: I had mistaken one for the other.

First, the switch – in the sequencer. This is the checkbox that was missing for me. In the classic (legacy) sequencer the option "Meridian Flip" sits at the top of the sequence header. If it is off, the entire run ignores every flip setting, however good. In the Advanced Sequencer you instead add the "Meridian Flip" trigger to the sequence. Without that switch, nothing at all happens at the meridian.

Second, the timing – under Options → Imaging → Meridian flip settings. This is where you define how the flip happens. The key fields:

• Minutes after meridian – how many minutes past the meridian the flip is triggered. Mine: 2 minutes.
• Max. minutes after meridian – the window within which the flip must have happened at the latest. Mine: 8 minutes. This value is the crucial guard: it must be smaller than the mount's tracking limit. In my case well below the AM5's 16 minutes (4°) – fits, with eight minutes to spare.
• Recenter after flip (on) – plate-solves back onto the target after the flip.
• Autofocus after flip (on) – refocuses after the swing.
• Scope settle time after flip – a short pause to settle before continuing.

The curious part: those timing values had been set correctly the whole time. They just do nothing as long as the switch in the sequencer is off. That is precisely the confusion that cost me time – I thought "meridian flip" was one setting. In reality it is two: the on-switch in the run and the fine tuning in the options menu.

The lesson

Two things I'm taking away. One is banal and easily overlooked all the same: before every session, a glance at whether the meridian flip is enabled in the current run. An object crossing the meridian is the normal case, not a special one.

This time it stayed at two lost exposures, because the Texan night falls into my German morning and I was at the desk. If you don't look, you notice nothing: the mount just sits there doing nothing conspicuous, it simply stops recording anything usable. That is the real price: not the ten minutes it cost, but the hours it could have cost.

The other is more fundamental. The most dramatic symptom – exploding tracking error, yellow warning bar, lost star – had almost nothing to do with the actual cause. Only the sober log, in which the guide star stayed bright throughout, revealed the truth.

The screen panicked; the numbers told what was really going on. With a rig standing 8,500 kilometres away in the Texan night, that is often the only route to the right answer: don't react to the loudest alarm, read what actually happened.