Platesolving: Zielobjekt wandert langsam raus

Status
Es sind keine weiteren Antworten möglich.

Byrial

Aktives Mitglied
Hallo Leute!

Hab mich letzte Nacht intensiv dem Pferdekopfnebel gewidmet. Auf den ersten Augenblick hat auch alles ganz gut geklappt.
Beim Sichten der Rawframes ist mir aber aufgefallen, dass sich das Ziel über einen Zeitraum von 2,5 h langsam in einer Richtung aus dem Bildzentrum herausbewegt.

Aber zuerst mal das Setup:
Optik: C8 mit Celestron FocalReducer f/6,3
Montierung: Skywatcher AZ-EQ5.
Kamera: Omegon veTEC 571c
Software: EQMOD, SharpCap, NINA, Platesolver: ASTAP , Stellarium (in der jeweils aktuellsten Version)

Vorgehensweise:
1. Aufbau, Abkühlphase und Inbetriebnahme
2. Scharfstellen an Teststern mit SharpCap und Bahtinov
3. Polaralignment (ohne Sicht auf den Polarstern) mit NINA's Three Point-Polar Alignment (dabei schaue ich, dass ich im Gesamtfehler unter 1' bleibe)
4. Anfertigen von Flats & Darks mit SharpCap
5. Star-Alignment mit SharpCap und einer automatisierten Sequenz über 9 Punkte. (funktioniert wunderbar: Ein Objekt, das ich nachher mit Stellarium anfahre, ist exakt im Zentrum)
6. Zielobjekt mit Stellarium anfahren
7. Aufnahme in SharpCap starten: Die automatische Sequenz läuft 100x durch eine Schleife mit je 10 Schnappschüssen (zu je 8 Sek.). Am Ende jeder Schleife wird geplatesolved und synchronisiert und dann 5 Sek gewartet, um dem System Zeit zum Ausschwingen zu geben. (Für Interessierte: Beispiel-Sequenz im Anhang als TXT)

Nun meine (menge) Fragen:
1. Kann das Herauswandern trotz Platesolving an mangelhaftem Polar-Alignment liegen? Eigentlich sollte doch diese Vorgehensweise mit Synchronisation recht robust gegenüber einem Ausrichtungsfehler sein (dachte ich zumindest)?
2. Durch die ständige Synchronisation sollten doch Ausrichtungsfehler im Laufe der Session zunehmend kompensiert werden, oder?
3. Wie gut bzw. ernst zu nehmen ist das Three Point Polar-Alignment von NINA? Ist meine Toleranz von < 1' illusorisch? Ich hab keine Lust, die Montierung vor jeder Session mit PHD stundenlang einzuscheinern.
4. ASTAP bzw. SharpCap melden während des Vorgangs desöfteren, dass die Abweichung so gering ist (unter 0,01°), dass keine Korrektur notwendig ist. Ist es besser, diese Toleranz dann zu verkleinern oder ist das sinnlos (weil z.B. die Montierung so kleine Korrekturbewegungen nicht durchführen kann). Oder sollte man die Toleranz eher nach oben setzen bzw. das Platesolving nur alle 20 Aufnahmen durchführen anstatt alle 10?
5. Aber wenn die Abweichungen immer so gering sind, warum wandert mir das Zeilobjekt langsam raus? Kann es sein, das hier "überkorrigiert" wird?
6. Da meine Montierung noch relativ neu ist, hatte ich noch keine Gelegenheit ein PEC-Training durchzuführen. Könnte es daran liegen?
7. (Zusatzfrage): Kann man beim Platesolving auch Dithern (bzw. wie könnte ich das in SharpCap hinbekommen)?

Puh, mir schwirrt der Kopf!
Danke euch trotzdem schon mal!
Grüße!
Byri
 

Anhänge

Hallo Byri,

spontan habe ich keine perfekte Lösung, aber warum nutzt Du nicht auch N.I.N.A für die Aufnahmesequenz, Du nutzt es ja auch zum Einnorden?
Das 3-Point-Aligment funktioniert bei mir einwandfrei, und Platesolven würde ich nicht in einer laufenden Sequenz verwenden, dafür ist ja das Guiding da.

Die Idee hinter meiner Antwort:
- wenn es mit N.I.N.A funktioniert (ohne Platesolve in der Sequenz), ist es ein Softwareproblem -> dann einfach weiter mit N.I.N.A und glücklich sein.
- wenn das Problem weiterhin besteht, ist es ziemlich sicher ein Hardware-Problem (Montierung).
- die richtige Nachführgeschwindigkeit (sideral) hast Du ja bestimmt eingestellt, oder ?

Viele Grüße,
Martin
 
Hallo Byri,
Das Ganze hört sich nach Bildfeldrotation wegen nicht sauberer Einnordung an. Je weiter man sich dann von der Polposition in tiefere Breitengrade begibt (wie in deinem Fall IC434 ) um so stärker fällt dieser Effekt auf.
Außerdem :
1. Für die Last und der Brennweite scheint mir die EQ5 doch leicht überfordert.
2. Ohne Nachführung mit einer Guidinglösung kann eine Poldrift nicht ausgeglichen werden. Das Platesolving korrigiert nur für den Anfahr-Moment die Position.
3. Ich norde immer auf unter 30" ein, obwohl ich akiv Guide. Nutze dafür aber ASIAir. NINA sollte es eigentlich ähnlich komfortabel können. Bei mir dauert dieser Vorgang keine 5min.
4. Ein PEC wird dein geschildertes Wegdriften nicht korrigieren sondern nur wiederkehrende gleichbleibende Abweichungen durch das Getriebe.

CS,
Franz
 
Hallo Byri,
ich kenne mich mit SharpCap nicht aus. Ich nutze die ASIair und NINA.

Dumme Frage: Platesolving und Sync heisst für mich: die Software ermittelt anhand einer Aufnahme die tatsächliche Center-Koordinate der Aufnahme und synchronisiert die Montierung, d.h. der "interne Zeiger" (wohin die Montierung gerade schaut) wird auf die via Plate Solving ermittelte Koordinate korrigiert.

Damit ist aber doch kein erneutes GoTo zur gewünschten Aufnahme-Koordinate verbunden. Das fehlt m.E.? Aber vielleicht ist das in SharpCap auch anders umgesetzt.

In NINA kann ich im Sequencer ein Platesolving anstoßen und z.B. ein "Recenter" starten, wenn die gewünschte Aufnahme-Koordinate zu weit von der tatsächlich via Plate Solving ermittelten Koordinate entfernt liegt.

Viele Grüße

Markus
 
Hallo Byri,

Deine Fragen und Vorgehensweise klingt sehr ähnlich, wie das Prozedere was ich mache. Ebenfalls AZ-EQ5 aber ich betreibe sie im AZ-Mode, Teleskope wahlweise Skywatcher 200PDS oder Skywatcher Quattro 150P. Du bist nach Deiner Beschreibung im EQ-Mode unterwegs und hast das Ziel Astrofotografie, ich mache EAA und hebe die einzelnen Aufnahmen gar nicht auf, sondern mich interessiert nur der laufende bzw. finale Stack.

Mit dem Auswandern kämpfe ich auch. Ich kann Dir aber nicht direkt helfen, da mir völlig der Background zum verhalten AZ-EQ5 im EQ Modus und Polaralignment etc. fehlt. Ich arbeite für das Alignemnt komplett automatisiert mit Celestron Starsense und habe an der AZ-EQ5 deshalb auch den Starsense Handkontroller und deshalb auch ASCOM mäßig alles Celestron basiert.

Aber Du hast einen ähnlichen Gedanken mit Deiner Sharpcap Sequenz umgesetzt wie ich auch. Und genau an der Stelle habe ich vermutlich ähnliche Probleme wie Du. Kurz erzählt, mit meiner Sequenz, die vermutlich ganz ähnlich zu Deiner ist, habe ich es nie hinbekommen. Bei etlichen Versuchen war mein Eindruck, dass das Sync Kommando für die Füße ist. Warum keine Ahnung. Ein auch beobachteter Effekt ist, wenn ich mit Stellarium ein Objekt anfahre und dann optisch visuell in Sharpcap kontrolliert daneben liege, würde ich erwarten, dass nach einem Plate-Solve Vorgang mit Sync-Befehl im Sharpcap das Objekt in Sharpcap im Zentrum liegt. Das tut es auch fast immer. ABER! Stellarium kriegt davon nichts mit. Das bedeutet wenn ich nach so einem Plate-Solve&Sync im Stellarium nachschaue, ist die Anzeige im Stellarium nicht mehr punktgernau auf dem Zielobjekt, sondern eben leicht daneben. Aber warum habe ich einen Sync Befehl im System verschickt, wenn die per ASCOM angeschlossene Software es nicht mitbekommt? Es gibt im Stellarium auch ein Sync Kommando, was dann dazu führt, dass Stellarium quasi die Karte verrutsch und dann passt die Anzeige im Stellarium. Aber durch den Sync im Stellarium ändert sich umgedreht nichts im Sharpcap. Frage, wer ist "Master of Desaster"?

Ich weiß nicht und verstehe nicht, was, wer, wie bei einem Sync Befehl tun sollte. Nur nachvollziehbar und erklärlich ist das beobachtete Verhalten für mich nicht.

Deshalb war meine Interpretation, dass deshalb die Sequenz mit dem Sync eben auch nicht funktioniert. Was ich dann probiert habe und das war Zeil-führend. Wenn ich händisch das Stacken pausiere, dann Sharpcap Plate-Solve und dann im Sharpcap Annotation Fenster den Knopf Center in View anklicke

plate-solve-sync-03.jpg

- damit erreiche ich das Ziel, dass das Objekt nicht auswandert sondern nimmer schön mittig bleibt. Nur genau dafür scheint es keinen Sequnzer Befehl zu geben.

Ich habe mir bis jetzt damit beholfen, dies eben händisch abzuwickeln. Aber wirkliche, automatisierte Lösung ist es nicht.

Servus - MünchenBeiNacht - Ewald
 
Hi,

ich denke es liegt daran, dass ein PS erstmal nur die aktuellen Koordinaten des Bilds bestimmt und darauf die Montierung nur synced.
Es wird dabei nicht wieder auf das ursprüngliche Ziel korrigiert. Das ist ein zusätzlicher Schritt.

In SharpCap gibt es dazu den Schritt "Plate Solve ... and re-goto ...". Gibt es in NINA bestimmt auch.
Hab's aber nicht ausprobiert, da ich wie Ewald @MünchenBeiNacht je nach Bedarf einfach manuell korrigiere.

Gruß
Peter
 
Hallo Byri,

wenn du nicht guidest, wird das Abdriften m. E. wahrscheinlich eine Folge des Einnordungsfehlers sein, wie oben schon gesagt wurde. Der PE der Montierung ist zyklisch und führt nicht zu einer kontinuierlichen Drift in nur eine Richtung, wie ebenfalls oben schon gesagt. Außerdem wäre eh nur die DEC Achse betroffen. Du könntest vielleicht mal einige Aufnahmeserien analysieren und feststellen, ob Driftrichtung und -betrag sich zwischen den Serien ändern. Wie sähe denn z. B. eine Langzeitaufnahme aus? Kannst du die vorhandenen Aufnahmeserien mal quick & dirty mit Modus "Maximum" stacken?

Als einzige alternative Ursache statt Einnordungsfehler fällt mir eine Bewegung der Montierung oder eines Teleskopbauteils während der Aufnahmezeit ein (z. B. Einsinken des Stativs, Spiel im Auszug, Flexur durch Kabelzug etc.).

@MünchenBeiNacht Hallo Ewald, kann es sein, dass du in Stellarium und Sharpcap unterschiedliche Epochen eingestellt hast, was dann zu dem von dir beobachteten Versatz führt?

CS Peter
 
Hallo! Also erst mal danke für die ersten Antworten...

Dass das Platesolving mit dem Sync und dem Re-GoTo funktioniert, sehe ich an den Aufnahmen, denn er hüpft immer wieder ein Stückchen zurück. Aber offenbar nicht so weit, denn trotzdem läuft mir das Objekt auf Dauer raus.

@ Martin & Franz: Bildfeldrotation konnte ich jetzt nicht feststellen. Das Objekt wandert mir gerade in eine Richtung aus dem Zentrum raus. Meine AZ-EQ5 kann mit 15 kg ein bisserl mehr als eine noramle EQ5 trage. Mit meinem 5kg Tubus plus Kamera lieg ich da glaub ich ganz gut. Guiding wäre schon was, doch mit einem SC ist das so eine Sache mit der exakt parallelen Ausrichtung. Darum eben diese Lösung über Platesolving, die übrigens letztes Jahr in SuW vorgestellt wurde. Siderische Geschwindigkeit läuft. Verfeinern könnte man das sicher noch mit PEC-Korrektur.

@Markus: Stimmt, das Re-GoTo habe ich vergessen zu erwähnen, aber das scheint zu funktionieren

@Ewald: Es beruhigend zu wissen, dass noch jemand anderes mit dem Problem kämpft. ;) Ich lassen nebenher immer Livestacking zur Kontrolle in SharpCap mitlaufen, stacke aber später sauber in ASTAP, weil ich da die Möglichkeiten (z.B. Filterung schlechter Aufnahmen) besser finde. Das StarSense habe ich mir in gewisser Weise in SharpCap nachprogrammiert und das funzt recht gut: Er fährt mir 9 Positionen vollautomatisch ab und synchronisiert.
Wegen deinem Problem: Jede Software kommuniziert für die Ausrichtung mit EQMOD, sowohl SharpCap als auch Stellarium. Stellarium scheint bei einem SYNC über SharpCap nicht mitzuhorchen und bekommt eine Veränderung nicht mit. Hier muss man wohl die Verbindung EQMOD von Stellarium aus kurz kappen und neu verbinden. Jedenfalls trägt der SYNC über SharpCap die Alignments-Points sauber in EQMOD ein.
Der entsprechende Befehl im SharpCap-Sequencer heißt "Plate solve a single frame, sync the mount and re-goto the target coordinates".
Welchen Platesolver verwendest du?

Byri
 
@ Peter: Du könntest recht haben mit der Einnordung, jedenfalls hab ich in den Einzelframes von je 8 Sek. bereits leichte Eiersterne, die in die gleiche Richtung wie die Drift gehen.

Andererseits, als ich nach den 2,5h ein vollkommen anderes Objekt (ohne komplett neues Alignment) neu angefahren habe, war dieses perfekt im Bildzentrum. Hätte es dann nicht auch falsch positioniert sein müssen?
 
@ Peter: Du könntest recht haben mit der Einnordung, jedenfalls hab ich in den Einzelframes von je 8 Sek. bereits leichte Eiersterne, die in die gleiche Richtung wie die Drift gehen.

Andererseits, als ich nach den 2,5h ein vollkommen anderes Objekt (ohne komplett neues Alignment) neu angefahren habe, war dieses perfekt im Bildzentrum. Hätte es dann nicht auch falsch positioniert sein müssen?
Das, was du beschreibst, spricht schon gegen Ursachen wie eine nachträgliche Schiefstellung des Setups, aber nicht generell gegen einen Einnordungsfehler oder gegen eine Flexur im System. Wenn das neue Ziel in Alt/AZ einigermaßen in der Gegend des Startpunktes des ersten Ziels lag, ist bei einem Einnordungsfehler oder einer Flexur im System meiner Meinung nach auch nichts anderes zu erwarten.

Mich würde wirklich mal interessieren, wie es aussieht, wenn du eine ganze Session einfach mit Maximum oder wie auch immer das in deinem Programm heißt, übereinander stapeln würdest. In so einem Bild würde man die Drift durch den Einnordungsfehler deutlich sehen und vielleicht auch noch etwas anders, das auf die Ursache deutet. Ich habe so etwas mal mit meinem ersten Star Adventurer gemacht. man sah deutlich die gerichtete, kontinuierliche DEC-Drift und die sinusförmigen Auslenkungen der Driftlinie durch den periodischen Fehler der Montierung. Das war der Moment, an dem ich mich zum Kauf eines MGEN und einer AZ EQ5 entschloss. Leider habe ich die sehr anschauliche Aufnahme nicht mehr.
 
Stretch.png
Na ja, wenn ich die Frames ohne Alignment übereinander lege (und ohne Flats and Darks) ud das ganze stretche, dann siehts man die Drift recht deutlich! Sieht aus wie ein Meteor-Regen! ;)

Zur Orientierung: Der helle Fleck links oben ist Alnitak.

Nachdem ich die Montierung nur im EQ-Modus betreibe, stelle ich mir die Frage, wie ich das verhindern bzw. minimieren kann...
Mit NINA hatte ich das Polar-Alignment so durchgeführt, dass ich bei einem Gesamtfehler von etwa 50" lag. Aber das sich das so krass auswirken soll!?

Irgendwie wirds mir dann schon klarer, warum das Ganze rauswandert: Es wird zwar geplatesolved und synchronisiert, wenn aber die Achsausrichtung nicht korrekt ist, sind die angefahrenen Re-GOTO-Coordinaten nicht ganz richtig


Pferdekopf.jpg
Ich werd mal mit ASTAP eine Mount-Analyse der Bilder durchführen...
Links übrigens das Resultat der Bearbeitung:
 
Zuletzt bearbeitet:
Hallo!

Wir müssen aufpassen was wir miteinander vergleichen, da es viele Freiheitsgrade gibt.

Wegen deinem Problem: Jede Software kommuniziert für die Ausrichtung mit EQMOD, sowohl SharpCap als auch Stellarium
Ich betreibe die AZ-EQ5 in ALtAZ Modus. Daher gibt es bei mir kein EQMOD. Und um die Verwirrung noch komplett zu machen, habe ich Celestron Starsense. An der Montierung hängt deshalb zwingend der Celestron Starsense Handkontroller. Die Verbindung zwischen ASCOM und der Montierung erfolgt über die USB-Schnittstelle LAPTOP <-> Celestron Handkontroller. Stellarium redet über ASCOM mit der Montierung. Sharpcap redet über Ascom mit der Montierung.
Bei Dir, ist es aber geraten von mir, ganz anders. Du hast vermute ich eine USB Verbindung direkt von der Montierung zum Laptop und brauchst überhaupt keinen Handkontroller mehr, außer Du willst etwas direkt an der Montierung machen. Und Du verwendest EQMOD. EQMOD wie der Name schon sagt unterstützt nur EQ-Modus. Anders wäre es wenn Du von Skywatcher die entsprechende Windows APP einsetzen würdest, dort kann man bei m Start des Programms zwischen ALtAZ und EQ Modus auswählen und dann hat man auch kein EQMOD.

Jede Software kommuniziert für die Ausrichtung mit EQMOD
Nein. So einfach ist es nicht. Ich habe gar kein EQMOD am laufen ....



Andererseits, als ich nach den 2,5h ein vollkommen anderes Objekt (ohne komplett neues Alignment) neu angefahren habe, war dieses perfekt im Bildzentrum. Hätte es dann nicht auch falsch positioniert sein müssen?
Byri, vom Prinzip her sind dies völlig verschiedene Dinge. Das eine ist Goto. Das bedeutet die Montierung verfährt über zwei Achsen Dein Teleskop zur richtigen Position. Wenn es dort angekommen ist, greift das Tracking/Nachführung dabei wird nur noch eine Achse bewegt. An dieser Stelle könnte die Montierung auch von einer Eieruhr angetrieben werden. Da tickert die Montierung dümmlich 15° pro Stunde der Erddrehung entgegen und kümmert sich um nichts anderes mehr. Das funktioniert aber nur, wenn die Teleskop Achse perfekt parallel zur Erdachse ist. (=Einnordung)

Hallo Pete!
Wenn das neue Ziel in Alt/AZ einigermaßen in der Gegend des Startpunktes des ersten Ziels lag, ist bei einem Einnordungsfehler oder einer Flexur im System meiner Meinung nach auch nichts anderes zu erwarten.
"Schlau-Bauch-Modus-ON" Das kapiere ich nicht. Ich dachte Byri ist in EQ-Modus unterwegs? Aber ich gebe Dir recht, dass die Probleme von Byri vermutlich durch mangelhaftes Einnordnung kommen. Bei AltAZ-Modus braucht man keine Einnordnung. "Schlau-Bauch-Modus-OFF"

@MünchenBeiNacht Hallo Ewald, kann es sein, dass du in Stellarium und Sharpcap unterschiedliche Epochen eingestellt hast, was dann zu dem von dir beobachteten Versatz führt?
Was meinst Du mit unterschiedlichen Epochen von Stellarium / Sharpcap? Ich bin froh über jeden Tipp!

Servus - MünchenBeiNacht - Ewald
 
Also nach meinem Gefühl ist das ein Alignment-Drift in DEC. Die Astrometrierung sagt "Up is 48.6 degrees E of N", das dürfte dazu passen. Von PE ist nichts oder nicht viel zu sehen. Allerdings sieht es so aus, als sei während der Session wenigstens ein Versatz in der Driftachse erfolgt, denn es gibt eine Doppelspur" mit einem leichten Versatz "rückwärts und nach links". Die Doppelspuren verlaufen jedoch nicht parallel, was seltsam ist. Kann es sein, dass du gegen die Montierung gestoßen bist oder hast du eine Katze :ROFLMAO: ? Es gibt auch eine dritte, kurze Spur, die etwas nach rechts versetzt ist und auch einen etwas anderen Winkel zu haben scheint.

1677164675210.png

CS
Peter
 
Hallo Ewald! Du hast natürlich recht, was die Vergleichbarkeit anbelangt. Trotzdem, nachdem mir das eine Objekt aufgrund mangelnder Ausrichtung aus dem Zentrum gewandert ist, sollte bei einem GOTO zu einem komplett anderen Objekt in einer völlig anderen Himmelsregion dieses dann doch eigentlich auch nicht mehr ganz zentral sein. In meinem Fall war das aber kein Problem...

Was die Epochen anbelangt: Peter mein hier wahrscheinlich J2000 und JNOW. In SharpCap wird man diese Einstellungallerdings vergeblich suchen, da dieses über ASCOM mit der Montierung kommuniziert. Ich selber mache diese Einstellung in EQMOD, aber das gibts ja bei dir nicht. In diesem Fall müsstest Du nachsehen, was deine Handsteuerbox unterstützt bzw. was da eingestellt ist und dies dann in Stellarium anpassen. Ansonsten hast du Korrdinatenabweichung.
 
Hallo Peter!

Hochinteressant! Eine Katze hab ich zwar, aber die hat zu dieser Zeit "fleißig" geschlafen! :LOL:
Dieser Versatz ist vielleicht sogar dem Platesolving und dem anschließenden Re-GOTO mit angepassten Achsgeschwindigkeiten geschuldet, kann das sein?

Ich hab das Teleskop am Balkon stehen und diesen dann während der Session auch nicht mehr betreten...
 
"Schlau-Bauch-Modus-ON" Das kapiere ich nicht. Ich dachte Byri ist in EQ-Modus unterwegs? Aber ich gebe Dir recht, dass die Probleme von Byri vermutlich durch mangelhaftes Einnordnung kommen. Bei AltAZ-Modus braucht man keine Einnordnung. "Schlau-Bauch-Modus-OFF"


Was meinst Du mit unterschiedlichen Epochen von Stellarium / Sharpcap? Ich bin froh über jeden Tipp!

Servus - MünchenBeiNacht - Ewald
Hallo Ewald,

das "schlaue Buch" brauchst du hier nicht ;). Gemeint war nicht eine Alt-AZ Montierung, sondern Höhe (Alt[itude]) und Winkel (Azimut) des Startpunktes der ersten und der zweiten Aufnahmesequenz.

Mit den Epochen meine ich das gewählte Koordinatensystem, also z. B. J2000 oder JNow. J2000 hat als Basis die Sternpositionen des Jahres 2000 und JNow die heutigen. Welches System man nimmt, ist egal, aber es muss in allen Programmen und auch im ASCOM Treiber dasselbe sein. Hier https://www.astrobin.com/forum/c/as...now-what-should-i-be-doing/?page=1#post-48945 steht etwas dazu. Hier auch (Sharpcapforum): https://forums.sharpcap.co.uk/viewtopic.php?t=4860. Interessant für Sharpcap ist vielleicht dieses Zitat aus dem vorgenannten Link, an dem mein Auge gerade kleben blieb:

1677166148090.png


CS Peter
 
Hallo Peter!

Hochinteressant! Eine Katze hab ich zwar, aber die hat zu dieser Zeit "fleißig" geschlafen! :LOL:
Dieser Versatz ist vielleicht sogar dem Platesolving und dem anschließenden Re-GOTO mit angepassten Achsgeschwindigkeiten geschuldet, kann das sein?

Ich hab das Teleskop am Balkon stehen und diesen dann während der Session auch nicht mehr betreten...

Sieht vielleicht auch deshalb etwas merkwürdig aus, weil ich vor dem Stacking einige Frames manuell rausgeschmissen hab...
 
Sieht vielleicht auch deshalb etwas merkwürdig aus, weil ich vor dem Stacking einige Frames manuell rausgeschmissen hab...
Hallo Byri,

ja, da ist ein Längsversatz wegen fehlender Frames, aber ich finde etwas anderes spannender. Ich habe mal einen Ausschnitt gemacht und die 3 Trails, die zusammengehören farbig markiert:

1677170241949.png

Der gelbe und der rote Trail sind leicht versetzt, aber parallel. Der blaue Trail hingegen ist nicht parallel, sondern es gibt eine Winkeldiskordanz. Das Prinzip kann man im ganzen Bild beobachten. Der parallele Versatz kann ja die Folge eines sync/goto sein, aber der geänderte Winkel des blauen Trail ist nicht damit zu erklären. Ob das mit deinen Eiersternen bzw. dem Driftproblem ursachlich zusammenhängt, weiß ich aber auch nicht :rolleyes:.

CS Peter
 

Anhänge

  • 1677169630222.png
    1677169630222.png
    516,9 KB · Aufrufe: 72
Hier mal eine Abbildung des SharpCap Drift-Graphen dieser Aufnahmesequenz:
DriftGraph.jpg


Das sieht den Sternstrichspuren schon sehr ähnlich! Auffällig ist, dass mir der Graph beim Stacking abschnittsweise stark hin und her springt: links oben zur Mitte und wieder zurück. Das dürfte am Platesolving mit dem anschließenden Re-GOTO liegen...
 
Das würde im Grunde bedeuten, dass mir über Platesolving die Position (zumindest teilweise) korrekt zurückgesetzt wird, sich dann im Laufe der Zeit die Sternspuren schneiden würden.
Was könnte diesen Effekt auslösen? Parallelversatz könnte dann (wie du schon sagtest) über Korrektur in der RA-Achse entstehen.
Wenn das ganze aber schief wird, würde das doch bedeuten, dass einer der Achsmotoren plötzlich mit einer anderen Geschwindigkeit läuft oder?

Nachtrag: Was auch sein kann: Dass das vielleicht nur schief aussieht, denn im Graphen liegen mehrere Trails sehr eng beieinander und überlagern sich mehrfach. Evtl. macht das den Eindruck einer schiefen Sternspur?
 
Hallo! Also erst mal danke für die ersten Antworten...

Dass das Platesolving mit dem Sync und dem Re-GoTo funktioniert, sehe ich an den Aufnahmen, denn er hüpft immer wieder ein Stückchen zurück. Aber offenbar nicht so weit, denn trotzdem läuft mir das Objekt auf Dauer raus.

@ Martin & Franz: Bildfeldrotation konnte ich jetzt nicht feststellen. Das Objekt wandert mir gerade in eine Richtung aus dem Zentrum raus. Meine AZ-EQ5 kann mit 15 kg ein bisserl mehr als eine noramle EQ5 trage. Mit meinem 5kg Tubus plus Kamera lieg ich da glaub ich ganz gut. Guiding wäre schon was, doch mit einem SC ist das so eine Sache mit der exakt parallelen Ausrichtung. Darum eben diese Lösung über Platesolving, die übrigens letztes Jahr in SuW vorgestellt wurde. Siderische Geschwindigkeit läuft. Verfeinern könnte man das sicher noch mit PEC-Korrektur.

@Markus: Stimmt, das Re-GoTo habe ich vergessen zu erwähnen, aber das scheint zu funktionieren

@Ewald: Es beruhigend zu wissen, dass noch jemand anderes mit dem Problem kämpft. ;) Ich lassen nebenher immer Livestacking zur Kontrolle in SharpCap mitlaufen, stacke aber später sauber in ASTAP, weil ich da die Möglichkeiten (z.B. Filterung schlechter Aufnahmen) besser finde. Das StarSense habe ich mir in gewisser Weise in SharpCap nachprogrammiert und das funzt recht gut: Er fährt mir 9 Positionen vollautomatisch ab und synchronisiert.
Wegen deinem Problem: Jede Software kommuniziert für die Ausrichtung mit EQMOD, sowohl SharpCap als auch Stellarium. Stellarium scheint bei einem SYNC über SharpCap nicht mitzuhorchen und bekommt eine Veränderung nicht mit. Hier muss man wohl die Verbindung EQMOD von Stellarium aus kurz kappen und neu verbinden. Jedenfalls trägt der SYNC über SharpCap die Alignments-Points sauber in EQMOD ein.
Der entsprechende Befehl im SharpCap-Sequencer heißt "Plate solve a single frame, sync the mount and re-goto the target coordinates".
Welchen Platesolver verwendest du?

Byri
'Guiding wäre schon was, doch mit einem SC ist das so eine Sache mit der exakt parallelen Ausrichtung'
ok, das mit der Tragkraft nehme ich zurück.
Verstehe nicht warum bei einem Guidingscope die optische Achse exakt zum Teleskop liegen muss. Da passe ich schon lange nicht mehr auf und das Guiding läuft absolut fehlerfrei. Du möchtest damit ja nur einen Stern in der Nähe des FOV fixieren.
Ich glaube nach wie vor an einen Einnordungsfehler. Evtl. ist der Wert den dir NINA sagt auch recht optimistisch.

CS
Franz
 
Nachtrag: Was auch sein kann: Dass das vielleicht nur schief aussieht, denn im Graphen liegen mehrere Trails sehr eng beieinander und überlagern sich mehrfach. Evtl. macht das den Eindruck einer schiefen Sternspur?
Ja, es kann auch eine Täuschung sein und vielleicht tut es bezüglich deines Themas auch nichts zur Sache. Trotzdem noch ein Ausschnitt, weil es so schön schief ist:
1677174362487.png

Für meine alten Augen ist das winkelig o_O :ROFLMAO:...

Was könnte diesen Effekt auslösen? Parallelversatz könnte dann (wie du schon sagtest) über Korrektur in der RA-Achse entstehen.
Wenn das ganze aber schief wird, würde das doch bedeuten, dass einer der Achsmotoren plötzlich mit einer anderen Geschwindigkeit läuft oder?

Wenn die Teilspuren bei ohne Guiden nicht parallel laufen, muss sich die Ausrichtung der Montierung geändert haben, oder was kann es sonst sein? Kann es sein, dass die Alt-Schrauben oder der Alt-Block (oder wie das bei Skywatcher heisst) sich im Laufe der Nacht etwas "gesetzt" haben. Ich hab in Erinnerung, dass die letzte Einstellung "aufwärts" sein soll, damit so etwas nicht passiert.
 
Hallo!

Was die Epochen anbelangt: Peter mein hier wahrscheinlich J2000 und JNOW. In SharpCap wird man diese Einstellungallerdings vergeblich suchen, da dieses über ASCOM mit der Montierung kommuniziert. Ich selber mache diese Einstellung in EQMOD, aber das gibts ja bei dir nicht. In diesem Fall müsstest Du nachsehen, was deine Handsteuerbox unterstützt bzw. was da eingestellt ist und dies dann in Stellarium anpassen. Ansonsten hast du Korrdinatenabweichung.
Mit den Epochen meine ich das gewählte Koordinatensystem, also z. B. J2000 oder JNow. J2000 hat als Basis die Sternpositionen des Jahres 2000 und JNow die heutigen. Welches System man nimmt, ist egal, aber es muss in allen Programmen und auch im ASCOM Treiber dasselbe sein.
Ihr Zwei macht mich fertig! ;) Nicht, dass ich glaube schon alles zu wissen ... es gibt immer was neues zum dazu lernen ... Da muss ich mich erst mal reinfuchsen.

Danke Euch Zwei, dass Ihr mich auf die richtige Spur gebracht habt!

Servus - MünchenBeiNacht - Ewald
 
Wenn die Teilspuren bei ohne Guiden nicht parallel laufen, muss sich die Ausrichtung der Montierung geändert haben, oder was kann es sonst sein? Kann es sein, dass die Alt-Schrauben oder der Alt-Block (oder wie das bei Skywatcher heisst) sich im Laufe der Nacht etwas "gesetzt" haben. Ich hab in Erinnerung, dass die letzte Einstellung "aufwärts" sein soll, damit so etwas nicht passiert.
Hmm, reicht da eine einmalige Änderung aus? Dann hätte man ja einen Parallelversatz. Wenn es wirklich schief ist, dann würde es sich um eine kontinuierliche Veränderung handeln müssen, oder?

Mit der Alt-Schraube hast du übrigens Recht, da muss zum Schluss eine Aufwärtsbewegung stehen, aber darauf hatte ich geachtet! Auch die Blockschraube habe ich wieder angezogen, weil ich da selber schon mal gründlich aufgelaufen bin.
 
Hmm, reicht da eine einmalige Änderung aus? Dann hätte man ja einen Parallelversatz. Wenn es wirklich schief ist, dann würde es sich um eine kontinuierliche Veränderung handeln müssen, oder?
Meiner Meinung nach reicht eine einzige Veränderung der Ausrichtung der Montierung. Ohne Guiding laufen die Trails (die Drift) ab dann konstant in einem anderen Winkel.

Aber wie schon gesagt, das spielt für deine ursprüngliche Frage keine große Rolle, sondern war nur eine Auffälligkeit. Unter dem Strich denke ich, dass das Auswandern durch Einnordungs-Restfehler verursacht wird und eine Veränderung der Montierungsausrichtung während der Session nur zu einem anderen Fehlerbetrag führt, was die Driftrichtung leicht verändert.
 
Ahhh, jetzt hab ich durch Zufall was im SharpCap-Forum gefunden: Plate Solve in Sequence Loop

Hochinteressant!
Kurzzusammenfassung: Offenbar ist das Re-Goto nach dem Platesolving und dem Sync das Problem, denn manche Montierungen "überfahren" das Ziel leicht und machen dann eine Rückwärtsbewegung mit einer finalen Aufwärts/Rechts-Bewegung (wahrscheinlich, um Spiel zu vermeiden) und diese Bewegung dauert!
SharpCap liest die Koordinaten aber offenbar bereits aus, wenn die Montierung noch mit der GOTO-Bewegung beschäftigt ist.
Bei einer manuellen Re-Zentrierung besteht das Problem offenbar nicht (weil die Bewegung da ja bereits aufgehört hat! @Ewald: Ich hoffe, du liest mit! Das war doch auch genau dein Fall, oder?)

Aus diesem Grund erhält SharpCap schon "falsche" Koordinaten, obwohl die Zentrierung noch nicht vollständig abgeschlossen wurde und "korrigiert" diese. Dabei wandert das Ziel mit jeder durchgeführten Schleife (mal mehr, mal weniger) langsam aus dem Zentrum raus. Da könnte mein Polar-Alignment wahrscheinlich noch so gut sein...

Nebenbemerkung: Mir ist schon aufgefallen, dass auf manchen Frames direkt nach dem Platesolving der Stern zu einer leichten Spur verwischt war, obwohl ich nach diesem Schritt eine 5s-Pause eingefügt hatte, bevor weiter gecaptured wurde. Offensichtlich kann das Re-GOTO etwas länger dauern...

Eine Lösung dafür muss ich noch finden, aber das wird schwierig, weil das im SharpCap-Sequencer ein elementarer Schritt ist, bei dem ich keine Wartezeit einfügen kann.
Es sei denn, jemand von euch hätte auf die Schnelle eine Idee parat!?

Weiß jemand von euch, ob die Skywatcher-Montierungen bei einem GOTO tatsächlich so wie oben beschrieben reagieren?

Grüße!
Byri
 
Hi Byri,

muss ich mir merken, falls ich auch mal damit Probleme bekomme.

Ich denke du müsstest das im SharpCap Sequencer hinbekommen, mit dem save coordinates, plate solve sync, goto saved coordinates, wait seconds, repeat, usw..

Gruß
Peter
 
Hallo Peter!

Gute Idee, ich werd mal rumprobieren und auch den Autor von SharpCap kontaktieren, was er dazu meint...
 
Status
Es sind keine weiteren Antworten möglich.
Zurück
Oben