6. August 2026  ·  🔭 Astronomie

Mein erster Komet mit dem N.I.N.A.-Orbitals-Plugin – und warum ich 19 Grad danebenlag

Einen Tag nach dem Falcon-9-Einschlag, wieder am Vormittag im dänischen Ferienhaus, wieder Nacht über Texas – aber diesmal keine Uhrzeit, auf die es ankam. Eine ganz normale Session, dafür mit etwas, das ich noch nie gemacht habe: ein Komet. Genauer 10P/Tempel 2, der gerade durch sein Perihel geht.

Dafür gibt es in N.I.N.A. das Plugin Orbitals. Am Ende der Nacht hatte ich eine Handvoll Aufnahmen – von einem Himmelsausschnitt, in dem der Komet nie stand. 19 Grad daneben. Gemerkt habe ich es erst am Nachmittag, beim Sichten und Nachbearbeiten der Aufnahmen.

Warum dieser Komet, und warum jetzt

10P/Tempel 2 geht gerade durch sein Perihel – die True Anomaly im Plugin steht bei 0,24°, also praktisch exakt am sonnennächsten Punkt. Von der Erde ist er dabei 0,41 au entfernt, gut 61 Millionen Kilometer.

Die Bahnelemente darunter sahen unauffällig aus. Bis auf eine Zahl, an der ich hätte hängenbleiben müssen: Epoch 09/19/2016. Die Bahnelemente tragen eine zehn Jahre alte Bezugsepoche. Ich habe sie gesehen, kurz gestutzt – und weitergemacht. Das war der folgenschwerste Blick des Abends. Dazu am Ende mehr.

Dass ich überhaupt bei JPL gelandet bin, war übrigens keine Entscheidung: Im Plugin lässt sich die Quelle zwischen JPL und MPC umschalten, und MPC lief in eine Zeitüberschreitung. Also JPL – um 01:17 Uhr heruntergeladen, fünf Minuten vor dem ersten Fehlversuch. Warum ausgerechnet das ein Problem ist, steht am Ende.

Stolperstein 1: „Frame“ – weil sonst nichts da war

Im Orbitals-Panel sah ich genau eine Knopfreihe: Frame, daneben Set Tracking Rate und Set Offset. Dass darunter eine zweite Reihe liegt – mit Slew and Track, dem eigentlichen Startknopf – habe ich erst viel später gemerkt. Man muss im Fenster nach unten scrollen, sonst existiert sie schlicht nicht.

Also Frame. Ergebnis um 01:22 Uhr:

ASTAP - Plate solve failed.

Der Fehler stand da, aber die Ursache stand woanders – nämlich in der Bildstatistik daneben: HFR 0,00 und MAD 8,00. Zum Vergleich: Meine normalen Luminanz-Subs haben ein MAD von 28. Das Bild war praktisch leer. Und ohne Sterne kann kein Plate Solver arbeiten. ASTAP war also gar nicht das Problem, ASTAP bekam nur nichts zu lösen.

Warum war nichts drauf? Der wahrscheinlichste Grund stand im selben Panel – ein Versatz, den ich vorher versehentlich gesetzt hatte:

Fast achtzig Grad neben dem Ziel. Der Knopf „Set Offset“ speichert die Differenz zwischen aktueller Teleskopposition und Ziel – gedacht, um einen Kometen bewusst außermittig zu platzieren, damit der Schweif ins Bild passt. Drückt man ihn, während die Montierung noch in der Home-Position steht, speichert er den Unterschied zwischen Home-Position und Komet. Also Unsinn.

Die Lehre: Erst einmal scrollen. Der richtige Ablauf ist:

1. Slew and Track – schwenkt auf den Kometen und folgt ihm
2. Frame – und darin dann „Slew, Center & Image“, nicht einfach belichten lassen

Der Unterschied bei Schritt 2 ist entscheidend: „Slew, Center & Image“ schwenkt, belichtet, löst das Bild und zentriert nach. Wer stattdessen nur belichtet, fotografiert, wohin das Teleskop gerade zufällig zeigt.

Stolperstein 2: Die AM5 verweigert den Sync

Offset gelöscht, nächster Versuch. Um 01:51 Uhr dann ein anderer Fehler – und das war ein Fortschritt, denn das Plate Solving hatte diesmal funktioniert.

ASCOM Driver Error
Failed to SyncToCoordinates, error code: The distance between the
synchronization target point and the device itself is too large

Was hier passiert: N.I.N.A. löst das Bild und will der Montierung anschließend mitteilen „du stehst in Wahrheit hier“. Der ZWO-Treiber lehnt das ab, wenn die Korrektur zu groß ausfällt. Ein bekanntes Problem der AM5 mit N.I.N.A., das in den einschlägigen Foren seit Jahren diskutiert wird.

Die N.I.N.A.-Einstellung, die alles löst

Gelöst wird das weder an der Montierung noch im ZWO-Treiber, sondern in N.I.N.A. selbst – mit einem einzigen Schalter:

Damit ändert sich der Ablauf:

Das Ergebnis ist dasselbe zentrierte Objekt. Nur wird die Montierung dabei nie angefasst – und der Fehler kann gar nicht mehr entstehen.

Dass Zentrieren ohne Sync überhaupt funktioniert, trennt die N.I.N.A.-Dokumentation sauber: Sync teilt der Montierung ihre wahre Position mit, Reslew to Target schwenkt dorthin, wo sie eigentlich stehen sollte, und Repeat until error < wiederholt das bis zur gewünschten Genauigkeit. Sync macht nur die folgenden Schwenks präziser – fürs Zentrieren selbst braucht es ihn nicht.

Und das Sync-Problem der AM5 ist real. Im ZWO-Forum beschreibt ein Nutzer genau diesen Fehler, und ZWO antwortet: „Please give me run logs to help me fix the bug.“ Es ist also ein Bug, an dem gearbeitet wird. Dokumentiert ist außerdem eine harte Sperre – Syncs näher als 5° am Pol lehnt der Treiber grundsätzlich ab – und ein neuer Sync ersetzt den vorherigen, statt ein Pointing-Modell aufzubauen. Die Korrektur gilt damit nur in der Nähe des synchronisierten Punktes.

„Coordinates sync OFF“ ist deshalb keine Verbesserung, sondern eine Umgehung. Sie funktioniert, solange N.I.N.A. zentriert – mehr behaupte ich nicht.

Der Preis ist überschaubar: gelegentlich ein Schwenk mehr, und die RA/Dec-Anzeige der Montierung bleibt ungenau, weil sie ihren Fehler nie erfährt. Für die Automatik egal – N.I.N.A. kennt die wahre Position aus dem Plate Solving.

Stolperstein 3: Die Falle direkt daneben

Direkt darunter, in derselben N.I.N.A.-Maske, steht „Location sync“, und den habe ich bei der Gelegenheit gleich mit umgestellt – von „Sync to application“ auf „Sync to telescope“.

Der Unterschied ist die Richtung: „Sync to application“ bedeutet, dass N.I.N.A. den Standort aus der Montierung übernimmt. Steht dort etwas Falsches, rechnet danach alles falsch – und das wäre eine plausible Erklärung für einen zu großen Sync-Abstand gewesen.

Achtung, hier lauert die Falle: Mit „Sync to telescope“ wird die Richtung umgedreht. Jetzt schreibt N.I.N.A. seinen eigenen Standort in die Montierung. Ist der im Profil falsch, überschreibt man einen korrekten Wert mit einem falschen. Vor dem nächsten Verbinden also unbedingt unter Options → General → Astrometry prüfen, ob dort die Koordinaten der Sternwarte stehen – bei mir 31,5471° N und 99,3825° W.

Und: Der Location-Sync greift erst beim Verbinden. Montierung einmal trennen und neu verbinden, sonst passiert nichts.

Was ich über die Zahlen gelernt habe

Max Exposure ist keine Empfehlung, sondern eine Rechnung

Das Plugin zeigt Max Exposure 97,8 s an. Woher kommt das? Aus den beiden Shift Rates: 0,009 ″/s in Rektaszension und 0,019 ″/s in Deklination ergeben zusammen 0,0202 ″/s Eigenbewegung. Mal 97,8 Sekunden sind das 1,98 Bogensekunden – bei meinen 2,03 ″/px also genau ein Pixel.

Das Plugin rechnet also schlicht: „Wie lange darf ich belichten, bis der Komet ein Pixel gewandert ist?“ Und es kennt dafür meinen Abbildungsmaßstab.

Man kann die Zahl aber auch andersherum lesen – dazu am Ende mehr.

Das ganze Kometen-Tracking brauche ich gar nicht

Das war die Erkenntnis, die den meisten Ballast abgeworfen hat. Bei 0,0202 ″/s wandert der Komet in einer 60-Sekunden-Belichtung 1,2 Bogensekunden – das sind 0,6 Pixel. Sieht man nicht.

Also: normale siderische Nachführung, normale Sequenz. Die Knöpfe „Set Tracking Rate“ und „Set Guider Shift Rate“ kann ich ignorieren. Die braucht man bei langen Subs oder schnellen Kometen, nicht bei diesem Maßstab und diesem Objekt.

Genau daran hing meine Verwirrung: Ich hatte angenommen, ein Komet erfordere zwingend Kometen-Nachführung, und mich an Knöpfen abgearbeitet, die ich überhaupt nicht drücken muss.

Zum Schluss: die Bewegung als Motiv

Und dann kam mir beim Hinschauen ein Gedanke. Der ganze Abend drehte sich darum, die Eigenbewegung des Kometen zu vermeiden – Belichtung kurz genug halten, damit er punktförmig bleibt, Max Exposure als Obergrenze. Aber diese Bewegung ist ja das Besondere an dem Objekt. Warum sie also nicht zeigen?

Also lief zum Abschluss das Gegenteil: eine einzelne Aufnahme über 15 Minuten.

Die Sterne bleiben punktförmig – die Montierung führt ja siderisch nach. Der Komet dagegen sollte eine Spur ziehen, gut fünfmal so lang wie ein Stern breit. Kein spektakulärer Strich quer durchs Bild, aber unübersehbar, und in einem einzigen Frame stünde damit das, worum es beim ganzen Plugin geht: Das Ding bewegt sich.

Die 97,8 Sekunden aus dem Plugin sind also keine Regel, sondern eine Weiche: Darunter bekommt man einen Kometen, darüber seine Bahn.

Zwei Dinge muss man dafür in Kauf nehmen. Das Guiding muss eine Viertelstunde am Stück halten. Und die Aufnahme läuft über das manuelle Imaging-Panel, das weder Dithering noch Autofokus noch Meridianflip kennt – vor allem aber kein Plate Solving und keine Zentrierung. Es belichtet dorthin, wo das Rohr gerade steht.

Soweit der Plan.

Der eigentliche Fehler – und er stand die ganze Zeit auf dem Bildschirm

Gemerkt habe ich in der Nacht nichts. Die Aufnahmen liefen durch, das Guiding hielt, die Sterne waren rund.

Dann am Nachmittag in Siril: kein Komet. Nirgends. Ich habe gestreckt, gesucht, das Feld abgefahren – nichts, was nach einem diffusen Fleck aussah. Also habe ich das Bild plate-solven und annotieren lassen, um wenigstens zu wissen, wo ich überhaupt bin.

Damit lagen plötzlich drei Koordinatenpaare auf dem Tisch:

Und daraus wurden zwei Fehler, die sich addiert haben:

Erstens lag das Plugin falsch. Zwischen seinem Ziel und dem echten Kometen liegen 9,3 Grad – dazu gleich die Erklärung.

Zweitens stand das Teleskop nicht einmal auf dem Ziel des Plugins. Die Bildmitte ist davon noch einmal 17,6 Grad entfernt, und zwar fast ausschließlich in Deklination: In Rektaszension stimmt es auf drei Bogenminuten genau, in Deklination fehlen 17,6 Grad. Nach den gescheiterten Zentrierversuchen stand die Montierung eben irgendwo – und die 15-Minuten-Aufnahme lief über das manuelle Imaging-Panel, das kein Plate Solving und keine Zentrierung kennt. Sie belichtete schlicht dorthin, wo das Rohr gerade hinsah.

Unterm Strich: 18,9 Grad zwischen Bildmitte und Komet. Mein Bildfeld misst 1,7° – der Komet stand also elf Bildfelder entfernt, oder 38 Vollmonddurchmesser.

Warum die JPL-Daten „alt“ sind – obwohl sie aktuell sind

Das Verwirrende zuerst: Die Bahnelemente sind korrekt. Ich habe sie gegen die JPL Small-Body Database geprüft, sie stimmen auf jede angezeigte Stelle. Die Lösung K265/43 stammt vom 28. Juli 2026, gerechnet aus 6.347 Beobachtungen über einen Datenbogen von 2003 bis 2026. Frischer geht es nicht.

Und trotzdem steht als Epoche 2016 da. Der Grund: JPL-Elemente sind Startwerte für einen numerischen Integrator, nicht für eine Kepler-Formel. Horizons nimmt diesen Zustandsvektor und integriert ihn vorwärts – mit den Störungen aller Planeten und mit einem Ausgasungsmodell, das JPL eigens mitliefert (die Parameter A1 = 2,50 × 10−10 und A2 = 8,12 × 10−12 au/d² stehen in derselben Datei). Bei so einem Verfahren darf die Bezugsepoche beliebig alt sein.

Das Orbitals-Plugin rechnet aber zweikörperlich – Sonne und Komet, sonst nichts. Über zehn Jahre geht das schief, und bei einem Kometen der Jupiterfamilie ganz besonders.

Wie sehr, lässt sich exakt beziffern. Rechnet man die 2016er-Elemente keplersch fort, fällt das Perihel auf JD 2461258,45. Tatsächlich war es JD 2461254,62 – 3,84 Tage früher. Nahe dem Perihel läuft 10P/Tempel 2 mit 0,0179 au pro Tag, in 3,84 Tagen also 0,069 au. Aus 0,409 au Entfernung gesehen sind das 9,6 Grad.

Genau die 9,3 Grad, die zwischen dem Plugin-Ziel und dem echten Kometen liegen. Der Komet läuft dem Plugin schlicht vier Tage voraus.

Warum MPC die bessere Quelle wäre – und warum sie nicht ging

Und damit zurück zur Fehlermeldung vom Anfang. Das MPC führt die Epoche seiner Kometenelemente laufend nach, statt sie beim Bahnfit stehen zu lassen. Das Plugin müsste dann nur über Tage statt über Jahre fortrechnen – und dafür reicht Zweikörper mühelos. Genau deshalb bietet das Plugin zwei Quellen an, und für Kometen ist MPC die richtige.

Nur kommt beim Update das hier – am Vormittag während der Session in Texas und noch einmal am Nachmittag bei den Nacharbeiten:

Auf der Statusseite des MPC steht die Erklärung: Pro IP-Adresse ist ein Download derselben Datei alle 12 Stunden erlaubt. Weitere Versuche liefern eine leere Datei – und, das ist die Falle: Ein abgebrochener Download löst die Sperre bereits aus. Wer nach einem Timeout nochmal klickt, sperrt sich also selbst weiter aus. Dazu kommt, dass die MPC-Server für ihre Gemütlichkeit bekannt sind; ich habe es selbst versucht und keine Datei bekommen.

Richtig ist also: einmal klicken, laufen lassen, bei Fehlschlag zwölf Stunden warten. Nicht nachklicken.

Und morgen?

Ich trage die Koordinaten von Hand ein. Aus JPL Horizons, für die kommende Nacht in Texas:

In diesen Stunden wandert der Komet ganze zwei Bogenminuten – bei 1,7° Bildfeld ist die Wahl der Uhrzeit also völlig unkritisch. Framing Assistant auf, Zahlen rein, fertig.

Fazit

Vier Fehler an einem Abend:

1. Nicht gescrollt – und die übrigen Knöpfe deshalb erst viel später gesehen
2. Einen Offset gesetzt, während die Montierung noch in der Home-Position stand
3. Eine Standardeinstellung beibehalten, mit der diese Montierung nicht zurechtkommt
4. Eine Datenquelle benutzt, die für dieses Verfahren nicht taugt

Die ersten drei haben laut protestiert: Fehlermeldung, Abbruch, nochmal von vorn. Der vierte hat geschwiegen. Und er hätte die Nacht auch dann gekostet, wenn alles andere sauber gelaufen wäre – 9,3 Grad Ephemeridenfehler sind bei 1,7° Bildfeld unrettbar.

Dass am Ende sogar 19 Grad daraus wurden, weil die Montierung nach den Fehlversuchen irgendwo stand, ist fast schon nebensächlich. Beide Fehler waren für sich genommen tödlich.

Das ist die eigentliche Lehre: Die Fehler, die einen anschreien, findet man. Der entscheidende war der, den ich in der Bahnelementen-Tabelle bereits gesehen und für unwichtig gehalten hatte.

Und ein zweiter Punkt gehört dazu: Ohne Plate Solving in Siril wüsste ich bis heute nicht, was schiefgelaufen ist. Ich hätte auf die Belichtungszeit geschimpft, auf den Filter, auf die Helligkeit des Kometen. Ein einziger Solve hat die Frage in zehn Sekunden beantwortet – nicht am Teleskop, sondern hinterher am Schreibtisch.

Was bleibt: Mein Rig ist mit 2,03 ″/px für Kometen entspannter, als ich dachte. Kein Sondertracking, keine Sonderbelichtung, ein Stacking-Schritt mehr am Ende. Und für dieses eine Objekt eben Koordinaten von Hand.