11. August 2026  ·  🔭 Astronomie

Fünf Minuten bis zur Antwort, eine Nacht bis zum Feature – mein Einstieg in Astro PM

Seit kurzem arbeite ich mich in den Advanced Sequencer von N.I.N.A. ein. Der kann sehr viel, und genau das ist das Problem: Man baut sich Container für Container eine Nacht zusammen, und beim nächsten Zielwechsel baut man sie wieder um. Für ein Rig, das 8.500 Kilometer entfernt steht, ist jede Änderung eine Remote-Desktop-Sitzung.

Beim Lesen darüber bin ich über Astro PM gestolpert. Das Konzept hat mich sofort interessiert – aus einem Grund, der mit Astronomie erst mal nichts zu tun hat.

Was das eigentlich ist

Die Anwendung selbst nimmt kein Bild auf. Sie ist ein Planungsarbeitsplatz für den Schreibtisch – und deckt dabei ziemlich viel ab, was man sonst über Kalkulationstabellen, Planetariumssoftware und drei weitere Werkzeuge verteilt:

Die vollständige Liste steht auf astro-pm.com. Was mich daran gereizt hat, steckt aber nicht in den Modulen, sondern in der Kette dahinter.

Die aktiven Projekte werden per Knopfdruck in eine Cloud geschoben. Auf dem Rechner am Teleskop sitzt ein Plugin für N.I.N.A. 3.x, das sich diese Ziele von dort holt, daraus den Zeitplan für die Nacht rechnet – nach Höhe, Mond und verbleibenden Belichtungen – und ihn abarbeitet. Slew, Zentrieren, Filterwechsel, Dithern, Zielwechsel.

Der Punkt, an dem es für mich klick gemacht hat:

Die Sequenzdatei enthält danach keine Ziele mehr.

Sie wird zu einem Gerüst, das man einmal baut und dann in Ruhe lässt – bei mir: Ausrüstung verbinden, Kamera kühlen, Klappe des Flat-Panels auf am Anfang; Find Home, aufwärmen, Klappe zu, Verbindungen trennen am Ende. Dazwischen ein Container, der sagt: führ aus, was heute Nacht ansteht. Wenn ich morgen ein anderes Ziel will, ändere ich das am Schreibtisch, nicht am Rig.

Für jemanden, der jede Sequenzänderung über eine Fernwartung machen muss, ist das ein anderer Umgang mit der Anlage.

Eine Windows-Anwendung, und ich habe nur einen Mac

Und da kam die Ernüchterung. Astro PM ist eine reine Windows-Anwendung – Windows 10 oder 11, 64 Bit. Ich arbeite seit einiger Zeit ausschließlich auf einem MacBook Air M4. Der Windows-Rechner, den ich habe, steht in Texas.

Das hätte es für mich fast erledigt. Hat es aber nicht, und zwar aus zwei Gründen, die gut zusammenpassen:

Dass Astro PM in zwei nativen Bauformen ausgeliefert wird, x64 und ARM64, ist dabei Komfort, nicht Bedingung: Windows on ARM bringt selbst eine x64-Emulation mit, der gewöhnliche Windows-Build liefe also auch. Nötig ist das nur nicht.

Das Ergebnis ist eine Windows-Anwendung, die auf einem Mac läuft, als wäre nichts. Ich hatte mit spürbaren Kompromissen gerechnet; im Alltag merke ich bisher keinen.

Fünf Minuten bis zur Antwort

Dann kam der Punkt, an dem ich eigentlich mit Ärger gerechnet hatte.

Ich habe N.I.N.A. so eingestellt, dass es FITS mit CFITSIO-RICE-Kompression schreibt – Dateiendung .fits.fz. Das ist verlustfrei und packt ganzzahlige Bilddaten rund 30 Prozent besser als GZIP, beim Komprimieren zwei- bis dreimal so schnell; beim Entpacken nehmen sich beide nichts. Wie viel es am Ende bringt, hängt vom Rauschen im Bild ab – verlustfreie Kompression kann nur das komprimieren, was kein Rauschen ist. Bei den Datenmengen, die über eine Nacht anfallen und die ich anschließend aus Texas herunterlade, ist das trotzdem kein Detail.

Viel Auswahl habe ich dabei nicht. ASTAP liest kein GZIP-komprimiertes FITS – und RICE-.fz überhaupt erst seit Version 2026.07.16. Bleiben unkomprimiert oder RICE, und unkomprimiert heißt die doppelte Datenmenge über eine Fernleitung. RICE ist bei mir also weniger Vorliebe als Ergebnis eines Ausschlussverfahrens.

Beim ersten Herumspielen stellte sich heraus: Astro PM konnte diese Dateien nicht lesen. Also habe ich die Frage in den Discord-Server von Astro PM geschrieben.

Nach fünf Minuten kam die Antwort: kein Problem, das einzubauen – ob ich Beispieldateien hätte. Hatte ich. Am nächsten Morgen war das Update da, mitsamt der Funktion.

So macht das Spaß. Ich bin an große Hersteller gewöhnt, bei denen aus so einer Frage ein Ticket wird, eine Fallnummer und im besten Fall ein Eintrag auf einer Roadmap. Hier saß jemand im eigenen Discord und hat es einfach gebaut.

Erwähnt sei dazu: Ich bin noch im Testmodus. Die Lizenz kostet 49 US-Dollar im Jahr, alle Module inklusive, jederzeit kündbar – sie läuft dann bis zum Ende der bezahlten Periode weiter.

Die Sequenz umbauen

Auf der Astro-PM-Website liegen fertige Sequenzvorlagen zum Herunterladen, die man in N.I.N.A. über Import einliest. Ich bin von „Single Night — with Safety“ ausgegangen und habe daraus meine eigene Fassung gemacht.

Der Startblock beginnt mit der einzigen Astro-PM-Instruktion außerhalb des Nachtteils: Refresh Cloud Targets. Sie zieht den aktuellen Stand meiner aktiven Projekte aus der Cloud auf den Rechner in Texas – was ich tagsüber am Schreibtisch geändert habe, ist damit die Grundlage für die kommende Nacht. Ohne diesen Schritt liefe die Sequenz mit dem Stand von gestern.

Der Rest ist zweistufig: warten bis zur nautischen Dämmerung, dann Ausrüstung verbinden, Kamera über fünf Minuten auf −10 °C herunterkühlen, Heizung am Kamerachip an – die Taukappen laufen unabhängig davon über Auto-Dew in der Pocket Powerbox. Danach ein zweites Warten bis fünfzehn Minuten vor der astronomischen Dunkelheit – erst dann fährt die Klappe des Flat-Panels auf.

Was hier auffällt, wenn man es sucht: Es gibt keine Anweisung, die das Dach öffnet. Das Open Flat Panel Cover im Startblock ist die Klappe des Flat-Panels, nicht das Gebäude.

Das Dach gehört nicht mir

Mein Rig steht in Gebäude 8 unter einem gemeinsamen Rolldach für alle Plätze darin. Bedient wird es vom Gelände aus – nach Wetter, nach Zeit, nach Betriebsentscheidung. Ich habe darauf keinen Zugriff und will ihn auch nicht.

Was ich habe, ist eine Auskunft: den Safety Monitor, bei mir der ASCOM-Treiber Generic File. Er liest eine Statusdatei auf dem Rig-Rechner und macht daraus ein schlichtes sicher oder unsicher. Damit dreht sich die Logik um: Die Sequenz steuert das Dach nicht, sie reagiert darauf. Deshalb hat der Nachtteil zwei Zweige, und der Safety Monitor entscheidet bei jedem Durchlauf, welcher läuft:

Das beantwortet die Frage, die ich mir vorher gestellt hatte: Was passiert, wenn das Dach gar nicht erst aufgeht? Dann dreht die Nacht im Unsafe-Zweig ihre Runden, das Rig steht sicher, und Astro PM behält seinen Zeitplan. Klart es um drei Uhr auf, springt die Schleife zurück und belichtet dort weiter, wo sie aufgehört hat.

Die Trigger hängen am „While Safe“-Container, nicht an der Astro-PM-Instruktion. Bei mir sind das Meridian-Flip, Autofokus nach Filterwechsel, Autofokus bei 2 °C Temperaturänderung, ein Discord-Alarm bei Fehlern und der After-Target-Trigger von Astro PM. Das war die Stelle, an der ich am meisten Skepsis hatte: Ein Plugin, das die ganze Nacht übernimmt, könnte leicht die Mechanismen aushebeln, auf die ich mich verlasse – allen voran den Meridian-Flip, der mich schon einmal zwei Aufnahmen gekostet hat. Tut es nicht: Astro PM wertet die Trigger zwischen seinen eigenen Belichtungen aus, wie N.I.N.A. es täte.

Der Endblock ist wieder gewöhnliches N.I.N.A.: Stop Guiding, Find Home, Chipheizung aus, Kamera aufwärmen, Close Flat Panel Cover. Die Montierung geht bewusst zuerst nach Hause – das Aufwärmen dauert fünf Minuten, so lange soll das Rohr nicht offen stehen. Dass der Flat-Durchlauf die ersten beiden Schritte schon erledigt hat, stört nicht: Der Endblock läuft auch dann, wenn die Flats gar nicht liefen, und ist damit die letzte Instanz, nicht der Normalweg. Vor allem die Klappe muss zu sein, bevor irgendwann der Strom weggeht – sonst verliert der Servo sein Haltemoment.

Dann Disconnect All Equipment, und danach hält kein Treiber mehr einen COM-Port oder ein USB-Handle offen. Genau darauf kommt es an: Wenn ich morgens die Kasa-Steckdose ziehe, reiße ich keine offene Verbindung ab. Zum Schluss zwei Dinge, die nicht in der Vorlage standen – die Nachtzusammenfassung des Night-Summary-Plugins und ein externes Skript, rcopy.bat, das die Bilder der Nacht wegkopiert.

Und über die ganze Sequenz verteilt hängen Discord-Nachrichten: Start, Dämmerung, Ausrüstung verbunden, Dach offen, Dach zu, fertig, Kopierlauf begonnen und beendet. Dazu in drei Containern ein Fehleralarm. Aus 8.500 Kilometern ist das mein Fenster in die Nacht – und eine Meldung, die nicht kommt, sagt genauso viel wie eine, die kommt.

Eine Einstellung ist dabei wichtiger, als sie aussieht: der Playback-Modus. Time-Aware – die Voreinstellung – heißt, dass die Sequenz nach einer Verzögerung dorthin springt, wo sie laut Uhr gerade sein sollte. Eine vierzigminütige Sicherheitsabschaltung kostet also diese Belichtungen, aber der Rest der Nacht bleibt im Plan und die Filter passen weiter zu den geplanten Mondfenstern. Sequential arbeitet die Liste strikt der Reihe nach ab und läuft dann hinterher; die Blockgrenze ist allerdings in beiden Modi hart, es wird also auch hier abgeschnitten statt ins nächste Zielfenster hineinzulaufen. Für ein Remote-Rig, bei dem Wolken und Dachschließungen dazugehören, bleibe ich bei Time-Aware.

Und wie kommen jetzt die Flats zustande?

Beim Umbauen kam ich an die Stelle, an der ich mir den Flat-Block gedacht hatte. Ich hatte ihn im Endblock geplant, direkt hinter dem Aufwärmen der Kamera – aus dem Flat-Panel-Artikel heraus die naheliegende Stelle. Sogar der Kommentar in der Vorlage schlägt genau das vor.

Falsch gedacht. Astro PM bringt dafür etwas Eigenes mit, und die Logik dahinter ist besser als meine.

Es plant die Flats nicht, es merkt sie sich. Jedes erfolgreich belichtete Light trägt seine Kombination aus Ziel, Filter, Rotationswinkel, Gain, Offset und Binning in eine Liste ein. Die wird entdoppelt und weggeschrieben, sie übersteht sogar einen N.I.N.A.-Neustart mitten in der Nacht. Am Sessionende wird genau diese Liste abgearbeitet – nicht die geplante, sondern die gelaufene. Was wegen Wolken ausgefallen ist, bekommt auch kein Flat.

Notiert wird dabei der mechanische Rotationswinkel, nicht der am Himmel – sobald das Teleskop geparkt ist, sagt letzterer nichts mehr. Beim Abarbeiten gruppiert Astro PM nach Rotation und fährt den Rotator einmal je Gruppe auf genau diesen Wert zurück. An meinem Rig läuft das ins Leere, ich habe keinen Rotator; wer einen hat, bekommt damit aber die Staubschatten wieder an dieselbe Stelle.

Dafür gibt es unten im Astro-PM-Container den Abschnitt Flat Handling mit drei Kästen:

Der mittlere Kasten ist der Kern. Astro PM schreibt Filter, Gain, Offset und Binning der jeweiligen Kombination direkt in die Instruktion, bevor es sie ausführt. Der Griff in die Trained-Flat-Tabelle trifft damit zwangsläufig die Werte, mit denen in derselben Nacht belichtet wurde – ohne dass ich pro Filter irgendetwas einstelle. Den Filterwechsel und das Anfahren des Rotationswinkels erledigt Astro PM ebenfalls selbst, außerhalb der Kästen.

Was gehört in die Kästen – und was passiert, wenn sie leer bleiben?

An dieser Stelle bin ich hängengeblieben, weil die Dokumentation die Kästen zwar beschreibt, aber nicht sagt, wie viel man selbst hineinschreiben muss. Die Antwort, nachdem ich beide Seiten nachgelesen habe:

Die Kästen sind Ablageflächen für eigene N.I.N.A.-Instruktionen. Bleibt einer leer, passiert dort nichts. Astro PM parkt also nicht von sich aus, schließt keine Klappe und schaltet keine LED. Es führt aus, was drinsteht, und sonst nichts. Vorbefüllt ist nur der mittlere Kasten, mit einer Trained Flat Exposure auf zwanzig Aufnahmen; die Fehlersuche-Seite von Astro PM fragt bei „Flats Did Not Run“ auch nur nach genau diesem einen Kasten.

Und dann kommt die Wendung, die mir die Arbeit abgenommen hat. Die Astro-PM-Doku schlägt für Before Flats „Montierung parken, Klappe schließen, LED an“ vor und für After Flats „LED aus, Klappe auf“. Das ist die Reihenfolge, die man braucht, wenn man mit gewöhnlichen Belichtungsinstruktionen arbeitet. Mit Trained Flats braucht man sie nicht. Die N.I.N.A.-Instruktion Trained Flat Exposure macht das nämlich alles selbst: Sie schlägt die Werte nach, schließt die Klappe, stellt die Helligkeit ein, schaltet das Licht an, belichtet, schaltet das Licht wieder aus und öffnet die Klappe zum Schluss – letzteres nur, wenn keep closed nicht gesetzt ist. Ihr Gegenstück Trained Dark Exposure verhält sich genauso, nur lässt es das Licht aus.

Damit bleibt für mich das hier übrig:

Die Flat-Darks in After Flats sind meine eigene Ableitung; in der Dokumentation stehen sie nirgends. Die Begründung: Ein Flat-Dark hängt nicht am Filter, sondern nur an Belichtungszeit, Gain, Offset und Temperatur. Im mittleren Kasten fiele es mit jeder einzelnen Kombination erneut an – sieben Filter, sieben identische Serien. Als einmaliger Durchlauf in After Flats reicht einer für alles.

Das funktioniert allerdings nur unter einer Bedingung, und die ist bei mir zufällig erfüllt: Trained Dark Exposure zieht seine Belichtungszeit ebenfalls filterabhängig aus der Tabelle, und Astro PM schreibt außerhalb des mittleren Kastens nichts hinein. Ein einziger Durchlauf trifft also nur deshalb für alle Filter zu, weil ich mich beim Flat Wizard für Dynamic Brightness entschieden habe – eine feste Belichtungszeit für alle sieben. Wer mit Dynamic Exposure arbeitet, kann das so nicht machen.

Zwei Dinge muss man außerdem wissen. Die Funktion ist standardmäßig aus und will über Enable Flats Sequence eingeschaltet werden – die Einstellung steht an drei Stellen, maßgeblich ist die im Desktop-Simulator, die synchronisiert pro Rig über die Cloud. Und die Flats landen unter dem Namen des jeweiligen Ziels; mit dem üblichen N.I.N.A.-Dateimuster heißt das: im FLAT-Unterordner neben den Lights, die sie kalibrieren.

Der Dialog, mit dem der Flat Wizard vor den Flat-Darks stehenbleibt und auf einen Klick wartet, entfällt dabei komplett – keine der beiden Trained-Instruktionen fragt irgendetwas.

Ein Detail am Rande, das zeigt, wie durchdacht das ist: Die Schleifenbedingung Astro PM Nightly Loop hält den Container so lange offen, bis die Flats am Ende der Nacht fertig sind. Sonst würde die Schleife nach dem letzten Light abbrechen und den Flat-Durchlauf mitnehmen.

Was noch aussteht