AUSSIESCIENCE CLIPS. Subscribe on YouTube

SESSION 7 · 09/26 · WORKED

Five metres of cable, an altitude limit, and an eyepiece where the camera should have been

Four and a half hours between first question and first frame, almost none of it spent on the sky. A new five-metre USB cable that would not enumerate, an altitude limit I had set and forgotten, a star alignment attempted before any stars were out, and ninety seconds of black frames that turned out to be an eyepiece sitting where the camera should have been. Then thirty-one minutes, eleven runs, 5,500 frames, and the best Moon I have. Went back out at nine, got fifteen more runs, and then spent an hour trying to hand the mount over to the laptop. Got it talking, got it connected, got it to move — and then a coordinate bug slewed it two degrees off the Moon and I could not find it again.

Brendan, Goolwa SA · 09/26

Targets
Moon
Gear
SVBONY SV205, 102 mm f/12.7 Maksutov, AZ-GTe goto mount, SVBONY SV165
Outcome
Worked
Chapter
First Moon
Twenty-six stacked moon images in a six-wide grid, labelled by run number and time, most showing the moon filling the frame, two of them almost black
All twenty-six runs, best 125 of 500 frames stacked, in time order. 000334 at 21:18 is the sharpest of the night, 000329 at 19:11 a close second. The two black ones at 19:26 and 19:29 are runs I kept recording onto an empty frame.

It was over my head the whole time

Asked at 17:14 what time the Moon would rise. It had risen at 09:17, and was at that moment 79 degrees up — eleven degrees off the zenith, in broad daylight, a 36 per cent waxing crescent in a bright blue sky.

I had been scanning the horizon. That is the reflex and it is wrong about half the time. Anything past about seventy degrees is outside the cone people actually look at, which is the same blind spot as [[moon-is-an-hour-later-every-night]] but in altitude rather than time: I know where it should be, I just do not point my head there.

Conditions were the best of any session so far. Clear Outside gave 0 to 4 per cent cloud every hour from 18:00 to 01:00, good seeing and transparency throughout. Sunset 18:07, astronomical dark 19:32, moonset 00:23. Wind 12 to 14 mph until midnight dropping to almost nothing by 01:00 — which, at 1300 mm, was the only thing in the forecast working against me.

The cable

New five-metre USB cable. The camera did not appear at all — nothing in lsusb, no device, no error on screen.

The kernel had plenty to say:

usb 2-3: new SuperSpeed USB device number 44 using xhci_hcd
usb 2-3: device descriptor read/8, error -71
usb 2-3: unable to enumerate USB device
usb usb2-port3: attempt power cycle

It went through fifty-three device numbers doing this. The port sees a device, powers it, fails to read its descriptors, power-cycles, retries, forever.

-71 is a protocol error — corrupted data on the wire, not a power problem. The port was delivering, the camera kept re-presenting itself, and every descriptor read came back mangled. The give-away is the first line: SuperSpeed. Passive USB 3 cabling is good for about three metres and realistically two. At five metres the high-speed pairs simply do not carry a clean enough signal, so the link negotiates a mode it cannot then sustain.

Changed the arrangement and it came up clean as 0bda:5880 on /dev/video4, uvcvideo bound, and ran eleven capture runs without a visible dropout.

The logs say "Connection Monitor resets: 0 events" and that proves nothing. The Camera Connection Monitor checkbox in the connect dialog was unticked, so the monitor was never running — the line is printed either way. I read it as evidence the link was solid. It is evidence of nothing at all. Tick the box and the number means something.

The part I did not measure, and should have. [[usb3-or-no-max-resolution]] says that on a 2.0 link the SV205 omits its full-resolution YUYV mode from the descriptor entirely. Tonight, after the fix, v4l2-ctl --list-formats-ext did list YUYV at 3264x2160 at 15 fps. So either the link came up at 5000 after all, or that August finding needs revising. One command settles it and I did not run it while the camera was plugged in:

cat /sys/bus/usb/devices/*/speed   # 5000 = USB 3.0, 480 = USB 2.0

Straight onto the list. This is [[measure-dont-derive]] again and I walked past it.

Also worth writing down so it stops looking like a fault: this camera logs a wall of invalid maxpacket 64512, setting to 1024 and Isoc endpoint with wBytesPerInterval of 32769 on every single connection. The SV205's descriptors are out of spec, the kernel clamps them, and it works. Normal.

The altitude limit

Goto Moon, and the app greyed out both buttons with "Altitude outside of limits".

I assumed a bad home position — tube not level at switch-on, everything offset upward. It was not that, and the screenshot proved it. The app's own numbers for the Moon read azimuth 300°39'44", altitude +74°34'51" at 17:49, against a computed 300.95 and 74.47. 0.11 degrees apart. Site, date, time and timezone were all correct, and the mount was not confused about anything.

Both buttons were greyed before any movement. That is a pre-flight check against a configured limit, not a pointing failure — the mount was refusing the target on paper. And because it refused 74.58 degrees, the ceiling was set below that.

I had set that limit myself and forgotten. There is a real reason for it: a 102 Mak with a diagonal and an eyepiece will foul the mount arm at steep angles, and tonight there was a camera and five metres of cable hanging off the back as well. Raised it after checking the clearance by hand.

The lesson is not "turn off the limits". It is that a mount refusing a target on paper and a mount pointing in the wrong place produce completely different symptoms, and I spent twenty minutes treating one as the other. See [[declination-sets-the-ceiling]] for the other half of this — that one is about what the sky will not give you, this one is about what the mount will not.

Aligning before there were stars

Then I could not complete a star alignment, which I put down to the mount.

The sun was 2.6 degrees below the horizon. Civil twilight had not ended. There was not a single star visible to the naked eye and would not be for another half hour — mag 1 targets need the sun down around eight degrees. Antares, which I wanted, was also sitting at 71.5 degrees, above the altitude ceiling that had just refused the Moon, so it would have been rejected anyway had I been able to see it.

Nothing was broken. I was thirty minutes early and looking at the wrong star.

Aligned the SV165 on Venus visually instead, which worked. Venus was at 34 degrees and the Moon at 67, a 33-degree swing, but the guidescope's field is 2.18 degrees so flexure over that distance is a small fraction of the field. It held.

Ninety seconds of black

Camera in, exposure ladder from 1 ms to a full second, and every frame came back with a maximum pixel value of 1 out of 255.

That is not "the Moon is just off the edge of the frame" — a Moon anywhere nearby floods the sensor with scattered light. At half a second even blank sky registers something. I handed exposure back to the camera on aperture priority; it ran to its maximum of one second and returned zero pixels above 20 out of 921,600.

So: no light reaching the sensor. I went through the caps, the diagonal, whether the camera was seated, whether the SV165 was capped.

The eyepiece was still in the focuser. The camera was not in the light path at all.

In fairness to the diagnosis, every measurement was correct and pointed exactly where it should have — a sensor in the dark reads as a sensor in the dark. It just never occurred to me to check the simplest possible physical fact before checking the complicated ones.

What the controls were actually doing

Two things fought me here and both are worth recording.

An exposure sweep left the camera at one second. A diagnostic ladder ran to its last value, 10000 units, and stopped there. On a sunlit Moon at f/12.7 that is a blank white frame, which looks exactly like a fault. Any script that sweeps a control needs to put it back.

AstroDMx resets controls when it opens the device. Set gamma to 100, sharpness to 0 and white balance off via v4l2-ctl; AstroDMx reopened and they were back to 300, 50 and auto. Manual exposure mode survived, the rest did not. So v4l2-ctl is fine for probing a free device and useless for configuring one AstroDMx is about to take over — those have to be set in its own UI. This is the flip side of [[inactive-uvc-controls-discard-writes]]: there the write is discarded because the control is inactive, here it is discarded because another process owns the device and re-asserts its own defaults on open.

The runs

Eleven runs between 18:58:10 and 19:29:38. Thirty-one minutes. 500 frames each, 5,500 frames, 109 GB.

Full sensor 3264x2160, RGB 8-bit, 21.15 MB per frame. AstroDMx settled on 11 ms exposure, gain 1.35, 15.13 fps, 33 seconds per run. Moon 36.4 per cent lit, waxing, around 55 degrees altitude and falling.

Stacked best 125 of 500 per run, aligned sub-pixel on a central crop and averaged.

run time frames stack detail note
000323 18:58 500 3.01
000324 19:00 500 4.46
000325 19:02 500 3.02 worst raw frames of the night
000326 19:04 500 3.54
000327 19:07 500 2.87
000328 19:09 500 4.07
000329 19:11 500 6.38 keeper
000330 19:17 500 1.99
000331 19:22 500 2.14
000332 19:26 500 0.24 empty
000333 19:29 500 0.28 empty

The seeing moved enormously inside half an hour. Per-frame sharpness within each run, same metric:

run time best frame median worst
000325 19:02 37.2 4.7 0.0
000328 19:09 128.1 62.1 28.4
000329 19:11 145.7 80.8 28.9
000331 19:22 62.0 37.5 25.4

Nine minutes separates a run whose median frame scores 4.7 from one whose median is 80.8. That is the entire argument for lucky imaging in one table, and it is the first time I have measured it rather than read about it. On 000325 the best-25-per-cent cut is throwing away frames that are genuinely worthless; on 000329 it is choosing between frames that are all usable.

Runs 000332 and 000333 are empty — mean level 1.3 of 255. Something came off target at about 19:26 and I carried on recording for two more runs, seven minutes and 21 GB, without looking at the screen.

Back out at nine

Reconnected and shot again from 21:18. Fifteen runs in nineteen minutes, 500 frames each, 158.6 GB. Exposure 19 ms this time, gain unchanged, 15.13 fps, Moon 37.3 per cent lit and down around 28 degrees.

The view was the best of the night — a large flooded crater sitting near the limb with a chain of worn craters running away from it, the whole field crisp. At 6.4 days old the likely candidates are Vendelinus with Langrenus and Petavius nearby, but I never nailed down the identification because a diagonal on an alt-az mount rotates the field by an arbitrary angle and from here everything is inverted relative to the atlas anyway. Wanting a wider frame to orient from is the real argument for the mosaic.

Stacked the same way, best 125 of 500:

run time stack detail note
000334 21:18 7.18 sharpest of the night
000335 21:19 2.93
000336 21:20 2.79
000337 21:21 2.25
000338 21:23 2.64
000339 21:24 2.91
000340 21:26 3.61
000341 21:28 3.98
000342 21:29 5.71
000343 21:30 3.67
000344 21:31 2.68
000345 21:33 4.86
000346 21:34 3.92
000347 21:35 2.57
000348 21:37 2.98

The first run of the block was the best one, and the three sharpest of the whole night — 000334, 000342 and 000329 — are spread across two hours with soft runs on either side of each. Nineteen minutes of continuous shooting produced one excellent run and fourteen ordinary ones. That is seeing, not technique, and the only defence is to keep shooting.

Handing the mount to the laptop

Everything needed was already installed — indi_skywatcherAltAzMount, indi_v4l2_ccd, indiserver, indi_getprop/indi_setprop. What followed was four discoveries, three good and one expensive.

Raw SynScan UDP commands need a trailing carriage return. :e1 gets nothing. :e1\r returns =030FA5. Every probe I have sent without it — including the ones on 10 September I read as "the module is busy, the phone must still be connected" — was simply malformed. The failure mode is indistinguishable from a contended connection, which is what makes it so misleading.

The module is not single-client. Raw reads kept answering the whole time the INDI driver was connected. That matters enormously: :K1\r / :K2\r is a stop channel independent of INDI, and tonight it proved itself — both axes halted instantly and stayed frozen through twelve seconds of checking. The thing that made 10 September frightening was not knowing this.

Connecting the driver did not slew. With the axis counts watched at 1 Hz through the connect, motion was 0.025 degrees in azimuth and 0.042 in altitude over ten seconds — the Moon's own rate, nothing more. Connection settings were already correct in the driver (TCP mode, UDP type). The driver exposes EQUATORIAL_EOD_COORD only, no HORIZONTAL_COORD, so alt/az targets have to be converted.

Do not use the GPS simulator to feed the site by snooping. Its GEOGRAPHIC_COORD is read-only and hardcoded to latitude 51 North. A mount snooping that has a site 86 degrees of latitude wrong, which is far more dangerous than no site at all.

Two degrees the wrong way

Then I synced INDI to the Moon, turned tracking on, and the mount started walking away — altitude error growing past a degree, azimuth drifting at about a degree a minute.

The cause was one line. get_body("moon", t, SITE) returns a position with distance attached. Calling .transform_to("icrs") on it re-origins from the geocentre to the solar system barycentre, and for something as close as the Moon that swings the direction by tens of degrees. It came back as RA 23.62h, Dec −2.46 instead of 16.4h, −26.8. I handed the mount that as "here is where you are pointing" and told it to track.

Stopped it with the raw channel. Total excursion about two degrees, against seventy-five on 10 September, and the difference is entirely that the stop had been tested beforehand rather than improvised during.

The safeguard I had written was in the wrong place. The script limits how far each commanded move may be. But a poisoned coordinate model turns a small command into a large motion, so the limit never fires. What it needed — and now has — is a check that converts INDI's reported position back to alt/az and compares it against the mount's own raw axis counts, refusing to enable tracking if they disagree by more than 0.3 degrees. That would have caught this before a single motor turned.

The correct conversion is via alt/az, which is a pure direction with no distance and so cannot be re-origined. Written into the script with the reason beside it.

By the time the mount was parked and safe it was 1.6 degrees off in altitude and the Moon was at 25 degrees and falling. I could not re-acquire it and called the night there.

What I got wrong

Results

Success, on fifty minutes of a seven-hour night. Twenty-six runs, 13,000 frames, 268 GB, and 000329 at 19:11 is the best lunar image I have — three times the detail of the softest run of the same night, on the same target, nine minutes apart.

Exposure was well judged. 85 per cent of the frame lit, 0.10 per cent clipped. With [[no-gain-control]] the exposure is the only lever and 11 ms at f/12.7 put the bright limb just where it needed to be.

The USB link showed no visible dropouts across all eleven runs, after an hour of the same cable refusing to enumerate at all. Not the same as "held perfectly" — the connection monitor was switched off, so nothing was actually watching.

The full disc does not fit. 12.1 by 8.0 arcminutes of field against 31 arcminutes of Moon — I see about a third of it. A full-disc mosaic needs 24 panels at 25 per cent overlap and about 50 GB at 100 frames a panel. Decided against it tonight, correctly, given the wind.

Best conditions of any session so far, and I used seven per cent of them. The forecast was cloudless from 18:00 to 01:00 with the wind dropping to nothing after midnight. The temptation is to call the calm hour before moonset the best one — but the Moon is at 9 degrees at 23:30 and 4 at midnight, and [[altitude-beats-everything]] outranks a drop in wind every time. The usable window was the early evening I spent debugging.

The stop channel is proven, and that is the most valuable thing tonight produced. Raw UDP answers while INDI holds the link, and :K1\r/:K2\r halts both axes instantly. The mount-automation idea is no longer gated on nerve; it is gated on getting the coordinate maths right in daylight.

Stacks are in ~/stacked/ — an 8-bit PNG per run plus a float32 .npy of each holding full precision before the display stretch. Stacker is ~/stack-ser.py, 73 seconds per 500-frame run. Mosaic runner is ~/lunar-mosaic.py — dry-run by default, refuses to move without --go, with sun avoidance, an altitude envelope, a step limit, model validation against raw axis counts, and the raw-UDP stop wired to every exception. Twenty-six SERs on the laptop, 268 GB of them, 103 GB free — the disk is the binding constraint now, not the sky.

To fix

Everything still outstanding from 12 September, plus:

What's next

Stacked lunar surface filling the frame, a large flooded crater left of centre, bright limb curving along the top right with black sky beyond
Run 000334, 21:18:50 — the sharpest of the night. Best 125 of 500 frames, aligned sub-pixel and averaged. 37.3 per cent lit. The whole disc does not fit: the field is 12.1 by 8.0 arcminutes and the Moon is 31 across.