12. August 2026  ·  🔭 Astronomie

Die erste Session mit Astro PM – und die drei Dinge, die dabei schiefgingen

Gestern habe ich aufgeschrieben, wie ich meine N.I.N.A.-Sequenz auf Astro PM umgebaut habe – inklusive der drei befüllten Kästen für das automatische Flat Handling. In der Nacht auf den 12. August ist das Ganze zum ersten Mal ohne mich durchgelaufen.

Am Morgen lag das hier auf der Platte:

Das Log dieser Nacht ist der eigentliche Ertrag. Es hat drei Dinge sichtbar gemacht, die ich vorher entweder falsch angenommen oder gar nicht bedacht hatte.

Zuerst die Planung mit Astro PM

Die Nacht beginnt nicht in Texas, sondern in Astro PM auf dem MacBook. Ein Projekt für M33, Status Active, dazu ein Belichtungsplan je Filter. Mehr braucht es nicht – den Rest macht der Nightly Simulator: Datum wählen, Simulate, und man bekommt die Nacht, bevor sie stattfindet.

Die Zielkarte beantwortet die Fragen, die ich sonst von Hand abschätze:

Darunter die Go/No-Go-Prüfungen. Zeit, Mond und Dunkelheit sind grün, die Höhe steht auf Rot – 29° gegen ein Minimum von 30°. Das ist kein Problem, sondern der Grund für das späte Fenster: M33 war zum Zeitpunkt der Simulation noch zu tief, und Astro PM rechnet aus, ab wann es das nicht mehr ist.

Genau diese 01:05 taucht später im Log des Rigs wieder auf. Der Zeitplan, den das Plugin nachts in Texas baut, ist derselbe, den der Simulator morgens am Schreibtisch gezeigt hat – dieselbe Engine, dieselben Regeln. Ich musste dafür kein einziges Mal N.I.N.A. öffnen.

Der Balken unten im Nachtverlauf zeigt es grafisch: eine schmale Säule bei 01:04, oben eingefärbt nach Filtern – grau, blau, grün, rot. Fünf Belichtungen in einer Nacht mit 7,7 dunklen Stunden. Das ist wenig, und es ist Absicht: Ich wollte einen Testlauf, keine Datenausbeute.

Befund 1: Ein falscher Standardwert – und die Kamera lief mit zwei Gains

Beim Anlegen der Ares-M Pro unter Equipment → Camera hatte ich als Standard Gain 150 bei Offset 50 eingetragen. Mein N.I.N.A.-Profil steht aber seit jeher auf Gain 125 – dem Punkt, an dem bei diesem Sensor die High-Conversion-Gain-Stufe öffnet, und dem Grund, warum ich mich überhaupt für diesen Wert entschieden hatte.

Zwei Zahlen, zwei Programme, eine Kamera. Das Ergebnis dieser Nacht, aus dem Log gezählt:

Die Trennlinie verläuft exakt dort, wo man sie erwarten würde, sobald man sie einmal gesehen hat:

Was Astro PM anstößt, bekommt den Wert aus der Cloud. Was N.I.N.A. für sich selbst belichtet, nimmt den Profilwert.

Innerhalb einer Nacht lief dieselbe Kamera also mit zwei verschiedenen Verstärkungen. Harmlos ist das bei Plate Solving und Autofokus – beide interessiert nur, ob genug Sterne im Bild sind. Bei allem anderen nicht:

Die Klammern sind der Grund, warum trotzdem alles lief: Die Einträge hängen nicht an einem bestimmten Gain, sie werden auch dann gefunden, wenn eine Instruktion 150 verlangt. Das Log beweist es – angewendet wurden exakt die Helligkeiten aus dieser Tabelle: 6 für Luminanz, 16 für Blau, 48 für Rot. Sie passen nur eben nicht mehr zu dem ADU-Ziel, für das sie einmal gefunden wurden.

Nebenbei beantwortet die Tabelle eine Frage, die im Flat-Panel-Artikel noch offen war: ob ein Filter an einem der beiden Anschläge klebt. Nach oben ist reichlich Luft – SII braucht 1024 von 4096, ein Viertel des Bereichs. Nach unten wird es eng: Die Luminanz steht auf 6, und viel weniger geht nicht. Zwischen dem hellsten und dem dunkelsten Filter liegt Faktor 170, und beides passt in dieselben drei Sekunden. Genau dafür braucht man die 12 Bit Helligkeitsauflösung.

Was durchlief

Gestartet um 15:07, dann sechs Stunden warten bis zur nautischen Dämmerung, verbinden, kühlen – und um 21:38 fuhr die Panelklappe auf. Im selben Moment baute Astro PM den Zeitplan:

AstroPM | Fetched 1 targets from cloud
AstroPM | Target: M33 loc=Starfront scope=GT81 Blue panels=1 remaining=5
…
AstroPM | Schedule built: 1 blocks, session 00:55–10:35 UTC

Und dann tat es das, was mich am meisten überzeugt hat: nichts. Der Block war auf 01:05 terminiert – dieselbe Uhrzeit, die der Simulator morgens angezeigt hatte. Bis dahin wartete die Schleife dreieinhalb Stunden, ohne dass ich eine Wartebedingung dafür gebaut hätte.

Um 01:05 schwenkte die Montierung, drei Plate Solves, zentriert – in 45 Sekunden. Bemerkenswert daran ist, dass das über die Offset-Methode lief: Meine AM5 verweigert SyncToCoordinates, N.I.N.A. steht deshalb auf Coordinates sync = OFF und rechnet die Abweichung selbst. Im Log liest sich das so, als wäre es der Normalfall:

Sync disabled - calculating offset instead to compensate.

Guiding rastete nach 22 Sekunden ein, Settle über 6 Frames, kein verworfener. Von 01:05 bis 01:33 lief dann der Block – 28 Minuten, in denen vier Aufnahmen entstanden.

Befund 2: Time-Aware hat den Grün-Kanal weggeworfen

Geplant waren fünf Subs: L, L, B, G, R. Aufgenommen wurden vier.

Der Rückstand wuchs über die Nacht, dreimal steht er im Log:

01:13  Time-sync: skipped 1 entries to stay on schedule (jumped from #1 to #3 — L)
01:18  Time-sync: skipped 1 entries to stay on schedule (jumped from #3 to #5 — B)
01:25  Time-sync: skipped 3 entries to stay on schedule (jumped from #5 to #9 — R)

Die ersten beiden Sprünge übergingen nur Dither-Einträge, danach lief die nächste Aufnahme regulär. Der dritte übersprang drei Einträge auf einmal – und darin steckte der Grün-Sub.

Der Zeitplan hatte einen Fünf-Minuten-Takt angesetzt, also die reine Belichtungszeit. Die Wirklichkeit brauchte mehr: 45 Sekunden Slew, 22 Sekunden Guiding-Start, drei Autofokusläufe zu je rund zwei Minuten, dazu Dither und Speichern. Der Log-Parser rechnet es am Ende selbst vor:

overhead categories: CameraTemp:1(436s), Autofocus:3(365s), Wait:1(330s),
  ImageSave:154(142s), FlatPanel:13(44s), CameraDownload:150(36s),
  MountOps:3(4s), PlateSolve:3(3s), Guiding:2(0s)

Sechs Minuten Autofokus auf 20 Minuten Belichtung. Im Playback-Modus Time-Aware heißt das: Die Sequenz springt zu dem Eintrag, der laut Uhr gerade dran wäre, und was dazwischen liegt, fällt weg. Der Grün-Sub war das Opfer.

Der zweite Hebel ist der Autofokus. Ich habe sowohl nach jedem Filterwechsel als auch bei 2 °C Temperaturänderung getriggert. Alle drei Läufe dieser Nacht kamen vom Filterwechsel-Trigger – bei LRGB mit gepflegten Filter-Offsets ist der verzichtbar, und er hat sechs von 28 Minuten gefressen.

Was dabei funktioniert hat, ist die andere Hälfte der Geschichte. Für jedes erfolgreiche Light schrieb Astro PM eine Zeile:

AstroPM | Flats: recorded combo M33 L G150 O50 1×1 @ PA 0.0° (no rotator)

Drei Kombinationen – L, B, R. Kein Grün. Und am Sessionende wurden genau drei Flat-Sätze aufgenommen. Kein G-Flat für ein G-Light, das es nicht gibt. Genau dafür ist der Mechanismus gebaut, und in einer Nacht, in der der Zeitplan nicht hielt, hat er sich zum ersten Mal bewiesen.

Befund 3: Die Flat-Darks sind komplett ausgefallen

System.NullReferenceException: Object reference not set to an instance of an object.
   at NINA.Sequencer.SequenceItem.FlatDevice.TrainedDarkFlatExposure.Execute(…)
      in /_/NINA.Sequencer/SequenceItem/FlatDevice/TrainedDarkFlatExposure.cs:line 219

Der Vorbehalt aus dem letzten Artikel, wörtlich eingetreten. Ich hatte dort geschrieben, dass Astro PM Filter, Gain, Offset und Binning nur in die Trained Flat Exposure schreibt – und dass die Trained Dark Exposure in After Flats außerhalb dieser Schleife steht. Das Log bestätigt es dreimal, für jeden Filter einmal:

AstroPM | Flats: Trained Flat Exposure set to LUMINOS G150 O50 1×1
AstroPM | Flats: Trained Flat Exposure set to BLUE G150 O50 1×1
AstroPM | Flats: Trained Flat Exposure set to RED G150 O50 1×1

Für die Dark-Instruktion: keine einzige Zeile. Sie steht in After Flats, also außerhalb der Schleife, und bleibt deshalb genau so, wie ich sie eingefügt habe.

Warum sie dann abstürzt, sagt das Log nicht. Der Mechanismus ist aber klar: Beide Trained-Instruktionen schlagen ihre Belichtungszeit in der Tabelle von oben nach, und der Schlüssel dafür ist der Filter. Meine Dark-Instruktion hatte keinen zugewiesen. Ohne Filter kein Eintrag, ohne Eintrag kein Rückgabewert – und daraus wird eine NullReferenceException.

Die Reparatur fällt entsprechend klein aus: In der Trained Dark Exposure einen Filter fest eintragen. Einen, nicht sieben. Ein Flat-Dark entsteht im Dunkeln; welcher Filter dabei im Rad steht, ist physikalisch bedeutungslos. Er dient nur als Schlüssel für die Zeit – und die ist bei mir für alle Filter dieselbe, weil ich mich beim Flat Wizard für Dynamic Brightness entschieden habe. In der Tabelle steht siebenmal 3.00 s, und das Log bestätigt es: Alle 150 Flats liefen mit exakt drei Sekunden, unterschiedlich war nur die Panel-Helligkeit.

Gerettet hat den Rest der Nacht eine Einstellung, über die ich nie nachgedacht hatte: ContinueOnError. Die Instruktion scheiterte, die Sequenz lief weiter – Kamera aufwärmen, Find Home, trennen. Die Klappe war zu diesem Zeitpunkt ohnehin geschlossen, dafür hatte „keep closed“ gesorgt. Ohne ContinueOnError wäre die Kühlung weitergelaufen und die Montierung nicht nach Hause gefahren.

Wie stark die Flats durch den Gain-Fehler danebenliegen, habe ich an einem Einzelbild nachgerechnet – zusammen mit Rauschen, Ausleuchtung, Staub und der Frage nach den PWM-Streifen. Das wird ein eigener Artikel, hier führt es zu weit.

Was ich ändere

Unterm Strich sind es drei sehr verschiedene Dinge: eine falsch eingetippte Zahl, eine dokumentierte Betriebsart, die ich unterschätzt hatte, und ein leeres Dropdown. Kein einziger Hardwarefehler, keine abgebrochene Sequenz.

Die eigentliche Lektion steckt im ersten Befund. Nicht, dass die Automatik versagt hätte – sondern dass sie einen Konfigurationsfehler still und vollkommen konsequent bis in jede einzelne Datei durchgereicht hat. Ein Feld in einer Eingabemaske, und der Gain jeder Aufnahme dieser Nacht ist ein anderer als der, mit dem meine gesamte Dokumentation rechnet.

Die Auswertung des Logs und der Flats habe ich, wie inzwischen üblich, gemeinsam mit Claude AI gemacht.