LEARNED IT · 09/26
A sync fixes the mount's model, not the mount's encoders
Syncing on the Moon in the SynScan app corrects the firmware's pointing model, which is what GOTOs use. A script that reads raw axis counts never consults that model, so the sync is invisible to it. My azimuth error sat at about 8 degrees through three syncs and two re-centrings and did not move, because nothing I did in the app could have moved it.
There are two different coordinate frames inside this mount and I had been treating them as one.
The first is the firmware's pointing model: its idea of where the sky is, built from the home position and whatever alignment or sync you have given it. GOTOs use this. Sync on a known object and the model is corrected, and every subsequent GOTO inherits the fix. That is the whole message of [[compass-north-is-not-true-north]], and it is true.
The second is the raw encoder frame: two step counters, reading out as degrees from
wherever the tube physically was at switch-on. lunar-mosaic.py reads this and nothing else:
:j1 / :j2 -> (counts - 0x800000) / 2073600 * 360
The docstring on that function says "Independent of INDI", and I wrote it, and I still spent three hours on 19 September trying to fix the encoder frame from inside the app.
What it looked like
The mosaic script refused to run, complaining that the centring residual was too large. I re-centred. I re-centred again. I synced on the Moon. The azimuth error across the night:
| time | azimuth offset |
|---|---|
| 19:16 | −9.62° |
| 19:18 | −9.61° |
| 19:24 | −9.89° |
| 20:01 | −8.59° |
| 20:42 | −8.03° |
A genuine centring error would have moved when I re-centred. This did not, because it was never centring. It was Goolwa's ~8 degrees of magnetic declination, baked into the encoder frame by homing on magnetic north, and a sync cannot reach it. The app rewrites the model. The encoders keep counting from where the tube started.
The tell
The two frames disagree in a way you can see if you look. Take two encoder reads a couple of minutes apart while the mount tracks:
19:16 axes alt +78.634 az −63.337 moon alt +77.688 az −53.713
19:18 axes alt +78.397 az −64.306 moon alt +77.449 az −54.698
Δaxes −0.237 / −0.969 Δmoon −0.239 / −0.985
The axes moved by exactly what the Moon moved, to within 0.02 degrees. Tracking is working perfectly. The offset is constant. A constant offset that survives re-centring is a frame error, not a pointing error, and no amount of work at the eyepiece will touch it.
Why the gate got angrier as the night went on
The residual is checked on sky, as hypot(res_alt, res_az × cos(alt)). A constant error
in the encoder frame therefore projects larger and larger as the target descends:
| Moon altitude | cos(alt) | on-sky residual |
|---|---|---|
| 77° | 0.21 | 2.26° |
| 61° | 0.48 | 3.84° |
| 46° | 0.69 | ~6° (extrapolated) |
The cap was set at 2.5 degrees. So the gate was not catching bad centring — it was catching the Moon going down, and it would have refused every run for the rest of the night while the conditions actually improved. With the frame offset declared, the true centring residual was 0.035 degrees. Two arcminutes. My centring had been fine all along.
What to do
The real fix is to re-home on true north — compass 352 at Goolwa, not 0 — so the encoder frame and the sky agree from the start. That is the same instruction as [[compass-north-is-not-true-north]], arriving from the other direction.
The workaround is to declare it. --az-frame-offset -8.0, subtracted for the cap test
only. The targeting maths already absorbs a constant offset — that is exactly what the
anchor is for, and it is why 96 gotos landed within 6 arcseconds on 18 September carrying
this same error. Only the safety check needed telling.
The general shape of it
A sync corrects the frame your mount reasons in. It does nothing for the frame your script reasons in, if your script deliberately bypasses the mount's model — and mine does, on purpose, because that independence is what makes the raw motion path trustworthy.
You cannot have it both ways. Bypassing the model means owning the calibration yourself.
Related: [[compass-north-is-not-true-north]] is the same 8 degrees seen through the mount's own GOTOs, where a sync does fix it. [[measure-dont-derive]] — I derived "the sync worked" from "I performed a sync", three times, instead of reading the number back.