13. August 2026 · 🔭 Astronomie
Dreißig von dreißig – die zweite Nacht mit Astro PM
Nach der ersten Session hatte ich eine Liste mit sechs Punkten. Vier davon habe ich abgearbeitet, bevor es in Texas wieder dunkel wurde. Diesmal stand M16, der Adlernebel, auf dem Plan – dreißig Aufnahmen in Schmalband, zehn je Kanal.
Am Morgen lag das hier auf der Platte:
30
Lights von 30 geplanten
15
Flats
15
Flat-Darks
Die drei Befunde, eine Nacht später
Der Gain stimmt. Ich hatte in Astro PM unter Equipment → Camera versehentlich 150 stehen, während mein N.I.N.A.-Profil auf 125 steht. In dieser Nacht taucht die 150 kein einziges Mal mehr auf – Lights, Flats, Flat-Darks, Plate Solving und Autofokus liefen ausnahmslos mit Gain: 125; Offset 50. Ein Feld in einer Eingabemaske, wie vermutet.
Die Flat-Darks sind da – und zwar auf einem Weg, den ich im letzten Artikel noch ausgeschlossen hatte. Ich hatte geschrieben, Astro PM befülle nur die Trained Flat Exposure, und die Dark-Instruktion müsse man deshalb von Hand mit einem Filter versehen. Das Log dieser Nacht sagt etwas anderes:
AstroPM | Flats: Trained Flat Exposure set to HA G125 O50 1×1 AstroPM | Flats: Trained Dark Flat Exposure set to HA G125 O50 1×1
Zwei Zeilen, für jeden Filter. Astro PM schreibt in beide Instruktionen. Damit ist meine Erklärung aus dem letzten Artikel – die Dark-Instruktion brauche zwingend einen von Hand gesetzten Filter – überholt.
Was in der ersten Nacht wirklich schiefging, sagt auch dieses Log nicht; belegt ist nur, dass es diesmal funktioniert. Meine Vermutung ist der Ort: Die Dark-Instruktion lag damals in After Flats, also außerhalb der Schleife, die je Kombination läuft – und was außerhalb steht, bekommt nichts zugewiesen. Jetzt steht sie in der Schleife, und die Zuweisung passiert von selbst.
Ergebnis: 15 Flats und 15 Flat-Darks in zwei Minuten und 55 Sekunden. Die Panel-Helligkeiten waren 768 für Hα, 256 für OIII und 1024 für SII – exakt die Werte aus der trainierten Tabelle, diesmal beim Gain, für den sie gefunden wurden. Die Darks landen in _CALIB\DARK\3.00s_G125\.
Die fünf je Filter sind Absicht: Für einen Testlauf wollte ich sehen, ob der Mechanismus überhaupt greift, und nicht zwanzig Minuten auf Kalibrierframes warten. Für den Normalbetrieb gehe ich wieder hoch – im Flat-Panel-Artikel hatte ich hergeleitet, dass unter zehn bis fünfzehn Aufnahmen die Ausreißerverwerfung beim Stapeln unzuverlässig wird.
Sequential statt Time-Aware. In der ersten Nacht hatte der Time-Aware-Modus den Grün-Sub weggeworfen, um im Zeitplan zu bleiben. Diesmal stand der Playback-Modus auf Sequential – und im ganzen Log steht keine einzige Time-sync-Meldung. Alle dreißig geplanten Belichtungen sind entstanden.
Der erste Meridian-Flip unter Astro PM
M16 kulminiert von Texas aus bei rund 44 Grad und kreuzt mitten in der Session den Meridian. Ein sauberer Flip ist bei mir nichts Neues – im alten Sequenzer lief er nach einer folgenschweren Lektion seit Ende Juli zuverlässig. Neu ist, dass er jetzt innerhalb des Astro-PM-Containers passiert, ausgelöst von einem Trigger, der am „While Safe“-Container hängt. Genau das war die Stelle, an der ich dem Plugin am wenigsten getraut hatte.
Der Trigger feuerte um 22:25:45 mit sechs Sekunden Restzeit bis zum eigenen Limit. Dann: Guiding aus, Tracking aus, zehn Minuten warten, bis das Ziel wirklich über dem Meridian steht, Slew auf die andere Seite der Säule im ersten Versuch, Autofokus, Plate Solving zurück aufs Ziel, neuer Leitstern, Guiding an. Um 22:41:42 stand im Log:
NightSummary: Event logged — MeridianFlip: Meridian flip completed successfully
Zehn der sechzehn Minuten sind reine Wartezeit – das ist keine Trägheit, sondern Absicht: N.I.N.A. lässt das Ziel bewusst über den Meridian laufen, statt am Umschaltpunkt herumzuzappeln.
Die Bilanz der Nacht
Der Block lief von 22:00:00 bis 01:05:43, also 186 Minuten. Davon waren 150 Minuten offener Verschluss – 81 Prozent. Wo der Rest geblieben ist, rechnet der Log-Parser am Ende selbst vor:
overhead categories: MeridianFlip:1(958s), Autofocus:3(821s), CameraTemp:1(538s), ImageSave:60(108s), FlatPanel:23(54s), Wait:1(30s), MountOps:3(26s), CameraDownload:30(9s), PlateSolve:4(3s), Guiding:2(0s)
Zwei Vorbehalte zu dieser Liste. Sie umfasst die ganze Session, nicht nur den Block – die 538 Sekunden CameraTemp sind das Aufwärmen der Kamera nach dem letzten Flat und liegen komplett außerhalb. Und die 821 Sekunden Autofokus zählen nur die drei Läufe nach Filterwechsel; der vierte gehörte zum Flip und steckt in dessen 958 Sekunden. Zusammen kommen alle vier Autofokusläufe auf rund 17,6 Minuten.
Von den 36 Minuten im Block, in denen der Verschluss zu war, gehen damit knapp 30 auf Flip und Autofokus. Der Rest ist Speichern, Dithern und Filterwechsel.
Nebenbei: Der Night-Summary-Bericht selbst rechnet mit einem anderen Fenster und kommt auf coverage=59.2% – dort zählt die Zeit ab 21:37 mit, inklusive der Wartezeit auf M16.
Auch das Kleinzeug stimmt jetzt: Night Summary läuft vor dem Trennen und schreibt die Gerätenamen in den Bericht statt der n/a-Zeilen von letzter Woche. Bis auf Rotator=n/a – den habe ich schlicht nicht.
Zwei neue Sachen
Der Cloud-Token war abgelaufen. Beim Bauen des Zeitplans um 21:37:
AstroPM | Couldn't reach the Astro PM cloud — using this NINA
install's local scheduling settings.
AstroPM | Cloud error: Invalid or expired sync token., falling back to cache
AstroPM | Using cached targets (fetched 6.9 hours ago)
Folgenlos, weil der Cache vom selben Nachmittag stammte. Die Ursache: Ich hatte am Abend zuvor die Volllizenz gekauft, und damit wird der alte Sync-Token ungültig. Nach dem Kauf muss man einen neuen erzeugen und im Plugin eintragen – erledigt, die Verbindung steht wieder. In der Dokumentation steht das nicht; der Token ist dort nur als kontoweiter Schlüssel beschrieben.
Der Autofokus nach Filterwechsel läuft weiter. Der stand auf meiner Liste und ist der Punkt, den ich nicht abgearbeitet habe. Drei der vier Läufe kamen von diesem Trigger, der vierte gehörte zum Flip. Bei 300-Sekunden-Subs fallen die knapp vierzehn Minuten weniger ins Gewicht als bei kurzen Sequenzen – dringend ist es also nicht mehr.
Was bleibt
Nach zwei Nächten sieht die Sache so aus: Die Automatik selbst hat nichts falsch gemacht – in keiner der beiden. Was schiefging, war ein falscher Wert in einer Eingabemaske, eine Instruktion an der falschen Stelle und ein Token, der nach dem Lizenzkauf neu gezogen werden will. Lauter Dinge, die man abarbeiten kann. Das ist eine beruhigende Sorte Fehler.
Die Auswertung des Logs habe ich, wie inzwischen üblich, gemeinsam mit Claude AI gemacht.
Quellen
Astro PM – Playback Modes · Automated Flat Handling
N.I.N.A.-Log der Nacht: 20260812-143006-3.2.0.9001.11680-202608.log
🔭 Die Nacht davor: Die erste Session mit Astro PM → · Wie die Sequenz aufgebaut ist: Mein Einstieg in Astro PM · Das Rig dazu: Mein Rig @ Starfront in Texas