SESSION 3 · 08/26 · PARTLY WORKED
New swivel, a focus lever, and a darker patch of yard
Three changes at once before tonight: the mount is rebuilt onto a friction-loaded roller-bearing swivel, the focuser has a long lever instead of a knob, and I'm setting up out the back away from the streetlight.
What changed
The mount is on a friction-loaded roller-bearing swivel. Lazy-susan smooth, but loaded so it holds position rather than free-spinning. Pointing is now a light continuous push.
The focuser has a long solid lever. Instead of twisting a knob — which torques the whole tube — focusing is a light touch downward on the lever.
Setting up out the back, away from the streetlight.
What I expect each one to do
Writing this down before the session, so I can't retro-fit the conclusion afterwards.
- Swivel → easier re-acquisition. The working method is to park at the leading edge and let the Moon drift through. The cost of that was always the fight to re-point for the next run. This should make the drift-through method cheap to repeat.
- Swivel → less settle time after pointing, because it no longer needs a shove.
- Swivel → no change to drift. Still undriven, still ~17 px/s. Run length is unchanged. A smoother mount is not a tracking mount.
- Lever → shorter settle after a focus change. This is the one I expect to matter most. On a 76 mm tube this light, the hand on the focuser has been a bigger source of image movement than the mount.
- Streetlight → honestly, not much for the Moon. The Moon is overwhelmingly bright and lunar imaging is not sky-glow limited the way deep sky is. What moving should help is stray light falling directly on the optics and on me — glare across the corrector path, and my own dark adaptation. Worth doing, but if tonight's frames are better, the streetlight is unlikely to be the reason. Recorded here so I don't credit it later.
The thing that hasn't changed
The 2.8 km diffraction ceiling and the 1.8 px per Dawes limit under-sampling. None of tonight's changes touch either. A 2x Barlow is still the highest-value thing I could add. Tonight is about making the rig pleasant and repeatable to use, which is a real prerequisite — but it is not a resolution upgrade, and I should not read one into it.
Results
22 runs, 198 GB, and the Moon didn't rise until 20:10.
What the rebuild actually delivered
- The swivel works. It held the Moon across 30-second runs repeatedly and re-pointing stopped being a fight. Twenty-two runs in ninety minutes would not have happened on the old bracket.
- The 2x Barlow went in for the first time — 700 mm effective, f/9.2, 0.426"/px. Dawes limit now spans 3.6 px instead of 1.8. Properly sampled at last.
- Nothing in the chain broke. Full resolution, 15 fps, no dropped connections, 22 clean captures.
The exposure hunt, in order
I never found the right exposure by reasoning — only by measuring the actual pixel values.
| time | exposure | what happened |
|---|---|---|
| 20:15 | 113 ms | left over from hunting. ~28x overexposed, 3.8 px of drift smear |
| 20:20 | 8 ms | overcorrected — peak only 70/255 |
| 20:24 | 40 ms | close, but I didn't know it yet |
| 20:32 | 3 ms | far too dark |
| 20:41 | 32 ms | peak ~137 |
| 20:49 | 46 ms | settled |
The lesson: the histogram is the instrument, not arithmetic. My first estimate said 4 ms. The real answer was around ten times that, because a Moon 20 minutes above the horizon is dimmed hard by the atmosphere it is shining through.
What the snapshots showed
Three snapshots, and the useful finding was not about exposure at all:
| snapshot | peak | frame lit | terrain | usable detail |
|---|---|---|---|---|
| 20:37 | 50 | 25% | mare | none — flat |
| 20:44 | 73 | 7% | limb | visible relief |
| 20:51 | 137 | 98% | disc interior | none — flat |
The dimmest frame had the most detail, because it was the only one pointed at terrain with shadows. At 94% illumination the interior of the disc is lit almost face-on and there is simply nothing to see there. Brightness is not the variable; shadows are.
Then I stacked one, and everything changed
Run 000090 — 20:48, 409 frames, 40 ms — picked by measuring the middle frame of all 22 runs and taking the one with the highest real contrast, rather than guessing. Stacked with PlanetarySystemStacker, Surface mode, best 30% of frames. 119 seconds of compute.
Craters. Actual round craters with rims, a dark mare, bright ejecta rays streaking away from impact sites. Compare the two images above: identical region, identical stretch, one frame versus 409.
Nothing about the optics or the focus changed between those two pictures. The detail was there in the data the whole time, buried under noise and atmospheric wobble — stacking is what dug it out. Every single frame tonight looked like failure. The stack did not.
And then sharpened it
The raw stack only used ~110 of 255 levels, so it came out flat. Stretching it and running a multi-scale unsharp mask — small radius for crater rims, wider radii for broad relief — lifted measured detail 4.2x.
First attempt made it worse: I finished with a bilateral filter to control noise, which smoothed away exactly the detail the sharpening had just recovered. The metric said 1.6 -> 1. Dropping that step took it to 6.5. Measure each processing stage; do not assume a step helped.
All 22 runs stacked — and 000091 still wins
Stacked every remaining run the next morning: 15 of 20 succeeded, 5 failed frame stabilisation (000085, 000076, 000074, 000077, 000080) where the target drifted out of frame mid-run.
The best image of the night is run 000092, and I had it ranked fourth.
I called 000091 the winner on three "independent" measures. Brendan looked at the actual images and said 000092 — the craters on the left are pretty well defined, the others are blurry. He was right, and comparing only similarly-exposed stacks the numbers now agree: 000092 is 50% sharper on normalised surface detail.
000091 was the brightest frame with the strongest limb edge, and every metric I tried found a different way to reward that instead of sharpness. Written up in [[three-metrics-one-eye]].
Getting there needed two corrections, both recorded in [[sharpness-metrics-reward-noise]]: the first ranking put three empty Venus frames from before moonrise in the top three places, and the replacement metric's noise estimate was silently broken for every row.
Curated down, next morning
Looked through all 17 stacks and kept the SER runs for 000081, 000086, 000087, 000088 and 000092 — 40.8 GB. Deleted the other 17 runs outright, 157 GB, without archiving them. The stacked images survive for every run; what is gone is the ability to ever re-stack those runs with different settings. That is an acceptable trade for 157 GB.
000091 went in the bin — the frame I had called the keeper twice. It is bright with a strong limb edge and genuinely blurry on the surface.
One flaw this exposed: archive-night.sh builds its census from what is on disk at
archive time, so curating before archiving made it report the five survivors as though
they were the whole night — the exact lie the census exists to prevent. Now takes
PRIOR_RUNS/PRIOR_BYTES, and the archive page shows a "curated before archiving"
banner with the real total.
The most useful thing I learned all night
Stacked a second run, 000091 at 20:49, one minute after 000090. Identical settings, identical processing. Then measured both:
| run | time | sharpness |
|---|---|---|
| 000090 | 20:48 | 6.5 |
| 000091 | 20:49 | 15.7 |
2.4x sharper, sixty seconds apart. I did not touch the focuser between them. That difference is entirely the atmosphere — seeing varies minute to minute, and 000091 caught a steady patch of air.
Which reframes the whole night. The images were not soft because focus was bad. Some minutes were simply better than others, and the only way to get a good one is to take many runs and keep the lucky ones. Twenty-two runs was not excessive; it was the method, even though I did not know it at the time.
It also explains why the eyepiece looks better than the camera. The eye and brain latch onto the steady instants in real time and discard the rest. A 40 ms exposure averages the good moments together with the bad ones and blurs them permanently. Stacking — ranking frames and keeping the best 25-30% — is a crude mechanical imitation of what the eye does effortlessly.
A third run confirmed the drift maths the hard way
Tried to stack 000085 and PSS refused: "Frame stabilization failed", then "No valid shift computed at frame 406" even at the maximum stabilisation search width. Frame 406 of 422 is about 29 seconds into a 30-second run — the target ran off the edge of the frame right at the end.
That is exactly what the arithmetic predicted: with the Barlow, drift is 34 px/s, so a 30-second run travels 1020 px. 000085 simply started nearer the edge than 000090 and 000091 did, and ran out of room first.
So 20-25 seconds is the real run length with the Barlow, not 30. Confirmed by something breaking rather than by a calculation, which is the more convincing of the two.
Worth noting: PSS exited 0 after skipping that job entirely. That is the third time tonight a tool reported success while producing nothing — rsync copied zero bytes and exited 0, archive-night.sh shipped nothing and exited 0, and now this. Every one was caught by checking the actual artefact rather than the return code.
That is the lesson of the night: do not judge a session by its live preview.
Still soft — but less than I thought
No hard edges at 1:1 in any single snapshot. Honestly, I cannot separate focus from seeing from terrain contrast with this data — the Moon was low the whole session and low means mush. Some of tonight's softness was never fixable.
The predictions — unanswered
Both of the questions this session was set up to answer are still open, because they needed measuring at the scope and I was busy chasing exposure:
- [ ] Settle time after a focus touch, lever vs knob.
- [ ] Time to re-acquire after a drift-through.
Next time: measure these first, before the target is up, rather than hoping to get to them.
And the thing that actually cost the most
Not focus, not exposure, not the mount. An hour spent debugging a working telescope because the Moon was still below the horizon, and no finder scope to aim with once it did rise. Both logged separately.
