July 23, 2026  ·  🔭 Astronomy 🖥️ Technology

A Lost Guide Star in PHD2, an AI, and the Truth in Between – How I Debug My Remote Rig with Claude

In the first post about my used telescope in Texas I mentioned in passing that an AI had helped me set up the guiding. That remark drew follow-up questions: How exactly? And because every other blog post these days explains how AI supposedly solves everything, I want to try the opposite here — an honest field report. Including the two times the AI got it wrong.

As a case study, I'll take the evening a guide star went missing on me. Or rather: my mid-morning. In Texas it was the middle of the night. It all started with this one image:

The trigger for the whole investigation: in the guide image the stars suddenly looked blurry, the guide star was lost — and I had no idea why.

I looked at exactly this window and asked myself: what happened here, and why are the stars suddenly out of focus? From that question, the detective work began.

A Red "Star Lost" and a Wall of Numbers

PHD2 is the software that keeps my telescope locked onto a star during the exposure and corrects the mount so everything stays sharp. Instead of a calm curve, that morning it showed a red "Star lost – low SNR" — and an image in which almost nothing was right.

For someone who doesn't know PHD2 inside out, a window like that is a wall of numbers. I knew they were bad. I didn't know why. So I did what I now do with almost every puzzle at the rig: dropped the screenshot into Claude, Anthropic's AI. No explanation, no preprocessing. Just the image, straight from the top.

The first thing that amazed me: the AI read the decisive values out of the screenshot without any trouble and put them in context —

• Status: "Star lost – low SNR"
• only 1 of 12 possible guide stars detected
• peak brightness 22 (of 255) — the guide star was extremely faint
• FWHM 14 pixels — the measured star size was absurdly bloated
• guiding error: RA 6.1″, Dec 3.2″, total nearly 7 arcseconds
• exposure time 3 seconds, maximum correction duration 2500 milliseconds

No typing, no log upload — just the image. That ability alone, to pull the right values out of a densely packed screenshot and make sense of them, took half the work off my hands.

Round One: A Plausible, Wrong Answer

From these values the AI immediately formed a first diagnosis: dew or incoming clouds. The argument was clean — weak signal, hardly any stars left, a guide image that looks soft overall. Exactly the pattern a humid night leaves behind. It even matched a botched night in the old log files — which, however, still came from the previous owner, from whom I had only just taken over the rig.

It just turned out to be wrong.

The Moment I Knew More Than the Machine

Because I had something the AI didn't: a view of the real situation. There was no dew, the guide camera had a clear view, and — this was decisive — the guide star had been stuck right at the bottom edge of the frame from the start. On top of that, I had swung the telescope over to a different target on a whim, and there the guiding ran cleanly right away.

That's exactly what I reported back to the AI. And here began the part that makes up the real value: it didn't defend its hypothesis, it discarded it and thought again. A star at the very edge of the frame, it explained, is captured by PHD2 through only half a measurement window — the software then computes over a truncated area, and all reported values become garbage as a result. The sky wasn't the problem, it was where the star sat.

That made sense. But one question remained, which I put to it next: then why did the whole guide image look blurry?

Round Two: Wrong Again — But Honestly Wrong

The AI calculated for me that with my guide scope, just seven hundredths of a millimeter of focus deviation would be enough to produce exactly this blur. And it pointed to a concrete suspect: shortly before, a technician had been at the rig. Maybe he had knocked the focus while handling it.

A good thought. It was wrong nonetheless — and the remarkable thing was that the AI flagged this itself. It noted that this was a plausible guess, not proof, and gave me a concrete test: at the next target, simply look at the sharpness value. Not "this is how it is", but "this is how you could check it".

This restraint has become more important to me than I first thought. An AI that names its own uncertainty doesn't tempt you into following it blindly.

The Resolution Came from a Second Screenshot

So I sent a screenshot of the new target — same optics, a bright star in the middle of the frame:

The same guide scope, a different target — and suddenly razor-sharp values: peak 229 instead of 22, nine of twelve stars detected, guiding around one arcsecond.

That instantly killed the focus theory. The guide scope was sharp, the technician innocent. The supposed 14 pixels of blur from before had never been real — they were the measurement artifact of the truncated edge star. In passing, the AI already pointed to the next detail: peak 229 of 255 means the star is on the verge of saturation — at three seconds it was almost too bright. That would matter shortly.

And now the whole chain made sense, unrolled backwards: my exposure time was too long, which overexposed the bright stars, so the automatic selection discarded them — and all that remained was a faint star at the edge, whose truncated measurement window falsified every number. A correction value set too aggressively finally turned the noisy signal into an outlier. No weather, no defect, no misadjusted optics. A chain of settings.

The best part: from this the AI gave me not just the solution, but a memorable rule of thumb for the future. A jagged, torn star profile means a truncated edge star. A smooth, broad profile means focus or dew. A narrow, sharp spike means: all good. That's exactly the kind of knowledge you don't want to re-derive at three in the morning — or ten in the morning.

Two Things I Understood About Guiding Along the Way

But the real aha moment only came when we got to the bottom of the error instead of just clearing it away. Two relationships I truly grasped for the first time here.

Why exposure time is so delicate on my mount of all things. Guiding is a loop: expose, measure the error, correct, expose again. You can only correct what you measured between two frames. If the exposure is too long, several fast error movements smear into an average — like a wobbling object at a long shutter speed. My ZWO AM5 is a harmonic-drive mount, and it has a markedly higher-frequency guiding error than a classic worm gear. To see it at all, you have to measure more often, i.e. expose shorter. That's exactly why the originally inherited eight seconds were poison — and even the three seconds from the problem screenshot still too long. Only at 1.5 seconds was it right. (Too short is bad too, by the way: then you're chasing atmospheric shimmer. There's an optimum.)

That a single ratio of numbers reveals the diagnosis. At the long exposures, my error in one axis — right ascension — was almost exactly twice as large as in the other. The AI immediately recognized the fingerprint in this: if one axis consistently runs worse than the other, the correction rate is too slow for the fast error of that particular axis. After the shorter exposure this imbalance shrank noticeably — until in the end both axes pulled equally. Since then, with every guiding problem I look at this ratio first, before I suspect anything else.

Both are things that aren't printed in bold in any manual — and that I probably would never have understood cleanly without the patient probing in dialogue.

From Chaos to 0.61 Arcseconds — Step by Step

From here, the troubleshooting turned into real tuning. The routine was always the same: I changed one setting, took a fresh screenshot, dropped it into Claude, the AI read the new values and proposed the next step. This went on over a whole morning — in Texas, the night.

Halve the exposure — but leave the gain alone.

Because the star was almost saturated at three seconds, my reflex would have been to turn the gain up at a shorter exposure to hold the signal. That's exactly what Claude talked me out of — it would only have worsened the saturation. So just the exposure from 3 to 1.5 seconds, the gain stayed. Result: total error down to 0.78 arcseconds, and the RA/Dec ratio from 1.9 to 1.5. The imbalance began to dissolve — exactly as the physics from before had predicted.

Throw away the ten-month-old calibration.

The inherited calibration was from the previous year and had an orthogonality error of 6.4 degrees — besides, a firmware update of the mount had changed the basis anyway. Using the calibration assistant, I ran a fresh calibration near the celestial equator, where the measurement is most accurate.

New orthogonality error: 0.3 degrees — a twentieth of the old value, twelve clean measurement steps per axis, both axes practically equal in speed. In the diagram you can see it immediately in the two perfectly perpendicular lines.

Go through the settings one by one — with reasons, not on suspicion.

Then we went through the critical parameters — each with a reason. I lowered the maximum correction duration from 2500 to 1000 milliseconds: a pulse that lasts longer than the exposure keeps pushing the mount while the next frame is already running — exactly the mechanism that had turned the noisy edge star into an outlier at the start. I raised the minimum SNR for automatic star selection from 6 to 10, so PHD2 would rather refuse to take a star than pick one that's too faint. And I replaced the previous owner's placeholder profile with a clean, named one.

One last problem — and the most elegant fix.

Despite a strong star and good SNR, the automatic selection again picked it at the very edge — exactly the setup a single dither can turn into a lost star.

So the guide star kept landing at the frame edge. I could have set it in the center by hand every time — instead, Claude proposed a structural fix: in N.I.N.A., shrink the search region for automatic star selection from 100 to 70 percent.

Since then, PHD2 simply cannot pick an edge star anymore. A single move that solves the problem for every future target.

In the end, the total error stood at 0.61 arcseconds, at an RA/Dec ratio of practically one — both axes in lockstep. Compared to the inherited state of around 1.1 arcseconds, that's almost a halving, and the best value this rig has ever shown.

What I Learned About AI as a Tool

If I'm honest, the punchline of this story is not "the AI solved it". The AI was wrong twice. The punchline is how it was wrong and what came of it.

It reads data tirelessly and fast. Log files, screenshots, even a cryptic device list in XML format — it pulls out the relevant values without tiring, without overlooking a single one. That alone saves an enormous amount of dull work.

It explains, rather than just judging. Why exposure time is so critical on a harmonic-drive mount, how the measured centroid of an edge star shifts, what saturation does — in these sessions I understood more about my own equipment than in weeks of reading forums.

But I supply the ground truth. The AI didn't know there was no dew, that the star had been at the edge from the start, that a different target worked. Only when I fed in these facts did it get onto the right track. It's a sparring partner, not an oracle: it proposes, I decide.

The value lies precisely in this loop — hypothesis, correction, revised hypothesis — and it only works if both sides contribute their part. Anyone who treats the AI like a fortune teller and takes its first answer at face value would, in my case, have spent hours looking for dew that was never there.

And in the End

These 0.61 arcseconds didn't come about because an AI worked magic. They came about because I had a patient counterpart that went through every number with me, tested every hypothesis, read every screenshot — and in the end explained to me why it got better.

And that, I think, is the realistic version of all the AI euphoria: no substitute for your own judgment, but a damn good amplifier for it.