Still not a complete Moon, and I said it was

moon-2026-09-22_moon_full.png, 6979 x 6093, eleven registered panels. No seams, no level steps, no rectangles, the best photometry of any run — and 11.8% of the sunlit disc is missing.

I looked at it and called it a complete Moon. Brendan looked at it and said bits were missing. He was right, and the measurement is not close:

OF THE SUNLIT DISC:   captured 88.2%   MISSING 11.8%  (65 sq arcmin)
  30.5 sq arcmin  bottom
  17.2 sq arcmin  top-right
  17.1 sq arcmin  top-left

Measure it, do not look at it. A 6979 x 6093 image viewed at 14% hides a 17-square-arcminute bite. The check that works: fit the limb, model the terminator from the phase, and ask what fraction of the sunlit disc is actually lit in the canvas. Eyeballing a downscaled render is how this got called complete twice in two nights.

Nothing is recoverable. Every panel on disk outside the 5x3 set is from an older run and reads 0.0% lit at peak 1-2. The surface was never photographed.

	tonight	21 September
gain pairs dropped	0	0
gain range	0.985 - 1.020	0.988 - 1.036
median CP residual	6.6 px (1.46")	2.8 px (0.62")
sunlit disc captured	88.2%	missing the western wedge

The residual is worse and the reason is altitude: this was shot at 73 deg, where a 7-minute run rotates the field by about 2.5 deg, against 58-61 deg last night. Shooting high was a deliberate trade for a clear sky that the forecast said would close by 22:00, and it did.

SCALE was 15% wrong, and had been all along

The measurement that mattered, made in daylight from the 21/09/2026 mosaic. Two independent methods, agreeing to 0.3%:

RANSAC circle fit to the LIMB of v3, 4089 inliers, rms 5.2 px
  radius 3545 px against a true 15.114'          ->  0.2558"/px
Hugin's measured positions vs COMMANDED motion, ALTITUDE axis
  1308.4 px for a commanded 5.594'               ->  0.2566"/px
lunar-mosaic.py said                                 0.2220"/px

The azimuth axis reads 0.2660, about 4% high, because step_az carries a 1/cos(alt) that is recomputed per panel while the altitude changes across a run — so the altitude axis is the one to trust.

The true frame is 13.93' x 9.22', not 12.08' x 7.99'. Two things were built on the bad number. mosaic-hugin's "deviation from commanded" converts degrees to pixels with it, so a 15% error shows up as deviation growing with distance from the grid centre — the 1.97' that was read as mount scatter on two separate nights is mostly this. And find-centre.py takes its half-frame from FRAME_W and FRAME_H, so the expected-span check that is supposed to reject a terminator hit was 1.8' off in azimuth, eating 60% of its own +-3' tolerance.

Three launches

One: a 27-step goto hung the mount. axis2: +0.0047 deg (+27 steps, ramp 2) was accepted, never cleared its running bit, and aborted the run after three panels with "goto did not finish in 30 s". Tiny moves are not an edge case in a mosaic — they appear whenever the per-panel target is close to where tracking has already carried the axis, which at high altitude is most of the altitude steps. synscan-goto.py now refuses anything below MIN_STEPS (50 steps, 31"), and the guard fired four more times in the runs that followed.

Two: a 6x4 grid overshoots a 30.5' Moon at the corrected frame size. Row 0 sits 2.5 steps below centre — 2.5 x 6.45' = 16.1' — against a disc radius of 15.26'. The entire outer row is centred off the disc, and the corners worse. Half the grid photographed nothing, which is exactly the failure the lit-panel gate on its branch exists to prevent.

Three: 5x3 at 30%, which shot cleanly and was still the wrong grid.

        c0    c1    c2
   r4    255   255   255
   r3    255   255   247
   r2    255   255   216
   r1    255   255   196
   r0    255   237     3

Fourteen of fifteen usable. The one dead panel is the r0c2 corner, genuinely off the disc at sqrt(12.9^2 + 9.75^2) = 16.2'. Corners always stick out on a rectangular grid over a circle; that is normal and Hugin drops them.

The grid rule, corrected after seeing what 5x3 actually produced. It covers 33.4' x 35.0' against a 30.5' disc - margins of 1.5' and 2.25', which any centring error beyond a couple of arcminutes overflows. That is what happened:

lit fraction   r0:  19.4%   1.0%   0.0%
               r4:  97.9%  99.9%  40.4%

Symmetric rows would mean a centred grid. These are not remotely symmetric - the disc sits about 8' toward r4, so r0 photographed sky while the Moon spilled past r4. Same root cause as 21 September (5.6' then), and it is THE CENTRING, not the grid size.

So 6x4 was right and I rejected it for the wrong reason. Its margins are 6.4' and 5.5'. The dark outer rows and corners I used to condemn it are exactly what a rectangular grid over a circle must produce, and mosaic-hugin drops them for free. Use 6x4 at 30%, accept that eight or nine panels are dark corners, and let the lit-panel gate make that cheap.

Altitude backlash, about 1.5'

Found by accident while calibrating the new centring tool. Bracketing a test move by returning to the start cancels drift but walks the axis into its own slack: altitude read 2.26' for a commanded 3.0' while azimuth, which carries no weight reversal, read 2.96'. Removing the reversal took altitude to 3.71'.

This affects the mosaic runner too. The serpentine reverses altitude between rows, so every row change eats that slack, and it may be part of the deviation-from-commanded that has been blamed on scale.

The centring tool is not finished

centre-on-limb.py finds the disc centre from one frame by fitting the limb with a known radius, and measures the image-to-mount transform itself rather than assuming it — two 4' test moves, solve the 2x2, cache it. That measurement found the camera sitting at -164.9 deg in the focuser, nowhere near the compositor convention, which is why reasoning about the sign failed twice.

The pieces work: 884 votes, 1582 inliers and a 0.87% validation ring on real sky, and 14 synthetic geometries recovered to 0.3-2.8 px. What does not yet work is the end-to-end accuracy — the calibration's implied scales come out 7% and 23% high, and a 23% error on an 18' correction leaves 4'. Remaining causes: drift during each ~20 s measurement, and backlash on the returns between axes. Next: correct each measurement to a common instant from the ephemeris, and approach every test move from the same direction.

And the trap that cost most of the evening: goto_offset sends :K, which stops tracking, and the new tool never restarted it. So from its first move the Moon drifted at 13"/s through an eight-step walk and several multi-second solves, frames went black at positions that had been lit two minutes earlier, and hours went into chasing pointing errors that were really drift. lunar-mosaic.py documents this trap and restarts tracking before every exposure. The new file simply did not.

Why: the first clear hour of the night went into that, and the sky closed at 22:00. The mosaic that worked was shot at 73 deg under a gap, not in the 45-60 band, and the field rotation shows in the residual. How to apply: measure SCALE again if the optical train changes — one mosaic and a limb fit. Size the grid from the real frame, not the assumed one. And restart tracking after every single move, in anything that moves the mount.