N.I.N.A und Platesolving mit dem Rahmungsassistent | Seite 2 | Astronomie.de - Der Treffpunkt für Astronomie

N.I.N.A und Platesolving mit dem Rahmungsassistent

pete_xl

Mitglied
...ja, eigentlich meinte ich die "Direct Guider" mit "built-in dithering" ;) (danke Alex!)
...hier steht noch etwas dazu https://nighttime-imaging.eu/docs/master/site/advanced/dithering/und es gibt auch noch englischsprachige Diskussionen darüber im Netz.

Meine Idee war doch, das Pointingmodell zunächst mal abzuschalten oder zu reduzieren, um erstmal festzustellen, ob am Target ein Konflikt zwischen dem Modell und den Sync-Befehlen des Platesolvers entsteht (so wie es bei mir selber passiert war). Dann kann man den Konflikt auflösen und sich bei jeder Session frei entscheiden, ob man mit oder ohne Guider arbeiten will. Das Dithern kann wahlweise über die Software oder den MGEN (unter NINA) erfolgen.
 

mfelsch

Mitglied
Hallo Dieter, hallo Peter,
Meine Idee war doch, das Pointingmodell zunächst mal abzuschalten oder zu reduzieren, um erstmal festzustellen, ob am Target ein Konflikt zwischen dem Modell und den Sync-Befehlen des Platesolvers entsteht (so wie es bei mir selber passiert war). Dann kann man den Konflikt auflösen und sich bei jeder Session frei entscheiden, ob man mit oder ohne Guider arbeiten will. Das Dithern kann wahlweise über die Software oder den MGEN (unter NINA) erfolgen.

das Modell ist doch (da Dieter ModelCreator verwendet) durch Solving mit demselben Platesolver an
zig Punkten überhaupt erst entstanden.
Das klappt bei der 1000HPS verblüffend gut.
Eigentlich darf es zu nennenswerten Pointing-Abweichungen dann gar nicht kommen.
Wenn man wie Dieter entweder unguided arbeiten will oder beim guiding von einer besseren
"Grundgenauigkeit" der Montierung profitieren will, braucht man aber auf jeden Fall ein Modell.

Da man - im Fall von Abweichungen - hier erstmal nicht weiss, ob das Modell untauglich ist oder es
an Nina liegt, würde ich erst mal den Framingwizzard beiseite lassen und die Gültigkeit des Modells
überprüfen durch Anfahren einiger Objekte, z.B aus dem Sternkartenprogramm heraus oder mit der
Handsteuerung der Montierung. Sollte es sich als untauglich erweisen, muss man es halt nochmal machen
(und sich Gedanken machen, warum es nichts taugte).

Grüße
Matthias
 

echni

Mitglied
Komme nach dem gestrigen, frustrierendem Abend wieder auf mein Problem zurück.
Wollte nochmals die Unterschiede zwischen den Koordinaten der Montierung und dem Ausrichtungsassistent herausfinden.
Dabei bin ich folgender maßen vorgegangen:
1. In NINA bei Optionen/Teleskop "kein Sync", also "On" angewählt und in der Montierung das bestehende Modell mit 100 Sternen verwendet.
Nach dem Schwenken und Platesolving wurde folgendes angezeigt:
NINA RA 03h 59m 25s DEC 36d 41m 39s
Montierung RA 04h 02m 27,9s DEC 37d 36m 51s
Also ein ziemlich großer Unterschied zumindest in DEC, fast 1°!
Danach wieder "Kein Sync" auf "Off" gestellt. Hier das selbe Ergebnis bzgl. der Daten.
2. "Kein Sync" auf "Off" belassen und das bestehende Modell in der Montierung gelöscht. Danach sah es so aus:
NINA wie oben (ist ja immer noch die gleiche Ausrichtung)
Montierung RA 04h 02m 10,8s DEC 38d 03m 33s
Hier lag also der Unterschied noch höher, nämlich bei fast 1,5°
3. "Kein Sync" auf "Off" und ein anderes Sternmodell, ebenfalls mit 100 Sternen verwendet:
Montierung RA 04h 02m 551,1s DEC 37d 28m 55,1s
Unterschied in DEC fast 1°
4. "Kein Sync" auf "Off" und weiteres Sternmodell mit 100 Sternen:
Montierung RA 03h 59m 21,9s DEC 38d 14m 34s
Also auch hier in DEC 1,5° Abweichung.

Klar ist, dass bei unterschiedlichen Sternmodellen immer Differenzen vorliegen können. Dieser fällt aber nicht so groß aus, wie der zum Ausrichtungsassistent in NINA.
Bin da jetzt mit meinem Latein am Ende. Heißt also, dass ich bisher keine Lösung gefunden habe.

Da ich für das derzeitige Teleskop noch kein Modell zur Verfügung habe, wollte ich das anschließend mit dem ModellCreator2 nachholen.
Ging total daneben. Bei sämtlichen angefahrenen Objekten kam eine Meldung, dass nicht gesolvt wurde. Den genauen Text weiß ich jetzt nicht mehr.
Kann natürlich daran liegen, da die Ausrichtung des Teleskops total daneben liegt.
Werde heute Abend nochmals einen Versuch zur Ausrichtung des Teleskops starten.

Wenn ich weitere Erkenntnisse habe, melde ich mich wieder.

CS
Dieter
 

pete_xl

Mitglied
Hallo Dieter,

ist den klar, welches die "richtigen" Koordinaten waren? Hast du vielleicht Aufnahmen gemacht, die man bei astrometry.net referenzieren könnte?

Eigentlich ich mir aber nicht klar, wie ein Solver wie ASTAP zu einem falschen Ergebnis kommen sollte.
 

echni

Mitglied
Hallo Peter und alle Interessierten

das mit astrometry.net ist ein guter Vorschlag. Werde ich mal durchführen.
Bei einer anderen Session, dem Herz- und Seelennebel lag das gleiche Problem vor. Musste da manuell auch noch nachjustieren.
Das Bild befindet sich auf Astrobin. Dort wird ja auch astrometiert. Werde da mal nachschauen, was dort angezeigt wird und mit dem Fitsheader, in welchem die Daten der Monti ja ebenfalls vorliegen, mal vergleichen.
Könnte aber auch mal einen anderen Solver ausprobieren.

Viele Grüße
Dieter
 

echni

Mitglied
Habe jetzt mal die Daten der Aufnahme des Herz- und Seelennebels angeschaut.
Da sieht es dann so aus:
Fitsheader (also Teleskop) Astrobin NINA
RA 02h 44m 7,5s 2h 43m 21s 2h 43m 15s
DEC 62d 06m 37,9s 61d 12m 46s 61d 11m 44s
Zwischen NINA und dem astrometierten Bild in Astrobin ist der Unterschied marginal. Kommt aber wahrscheinlich daher, dass ich den Rohstack aufgrund des Dithering etwas gecroppt habe.
Nehme daher an, dass die Ausrichtung des Teleskopes in DEC rund 1° daneben liegt. Muss daher in dieser Richtung etwas unternehmen. Durch unterlegen irgendwie höher kommen. Vielleicht bietet sich heute Abend wieder die Gelegenheit, das in den Griff zu bekommen.
Was mir nicht ganz klar ist, dass das beim Solven in NINA nicht entsprechend korrigiert wird. Bei der Orientierung, also Drehung funktioniert das ja auch.
Vielleicht benutze ich doch mal einen anderen Solver. Die sind halt alle langsamer als ASTAP.

CS
Dieter
 

pete_xl

Mitglied
Ich kann mir nicht vorstellen, dass es an ASTAP liegt. Das kann entweder richtig rechnen oder gar nicht. Bei erfolgreichem Verlauf wird der Montierung der berechnete, tatsächliche Bildmittelpunkt mitgeteilt und dann ein neuer Befehl gegeben, die Zielkoordinaten anzusteuern. Das wiederholt sich iterativ bis es passt. Wie groß ist denn die bei NINA eingestellte Zieltoleranz? Nicht, dass da 1° statt 1' steht ;) .

Auch, wenn die Montierung 1° aus der Richtung steht sollte das kein Problem sein. Ich muss meine Säule auch 1-2 Mal im Jahr neu ausrichten, weil sich das Haus/der Balkon mit den Jahreszeiten bewegt. Vorgestern musste ich mit Sharpcap 47' Fehler in der Einnordung neu korrigieren, die vielleicht auch daher kamen, dass ich irgendwann gegen die Gewichtsstange gestoßen bin. Der Guider musste ackern, aber der Platesolver und das Synchronisieren waren trotz des großen Fehlers schnell und exakt

Versuch doch zur Absicherung mal Astrotortilla. Das ist auch einigermaßen schnell und dazu ein Blind Solver. Die Einstellungen kann man "trocken" an einem Bild testen, damit man nachts keine Zeit und keine Nerven verliert...

...und...kannst du unter ASTAP/NINA nicht mal "von Hand" einen Leitstern zentrieren, solven und dann schauen, was tatsächlich danach passiert? Wenn die Montierung tatsächlich irgendwo anders hinfährt, als ihr "angewiesen" wurde ist doch noch "Eigenleben" in der Montierung. Ich konnte das damals "live" in Stellarium nachverfolgen. Die Montierung fuhr z. B. auf den Stern zu, wich aus und endete irgendwo anders - das lag an zu vielen widersprüchlichen Modellpunkten in der Nähe des Ziels. Sie hat das Ziel auch bei Wiederholungen immer wider verfehlt.

CS
Peter
 

echni

Mitglied
Moin Peter,

die Zieltoleranzen stimmen.
Rotation 1°
Ponting Toleranz 1´
Gestern Abend aufgrund der Witterungsbedingungen leider keine weiteren Versuche, das in den Griff zu bekommen.

CS
Dieter
 

mfelsch

Mitglied
Hallo Dieter,

Peter hat recht, wenn er Dir im Grunde rät, etwas systematischer vorzugehen.

Die Koordinaten, die Nina nach dem Solven nennt, sollten wohl stimmen.
Unrecht hat eher Deine Montierung, glaube ich.
Ich vermute, Deine Modelle sind einfach daneben. Woher kommen die denn?
Wenn Du schreibst, Du hättest für das verwendete Teleskop noch kein Modell
erstellt, dann helfen die älteren auch nicht weiter. Die passen wohl kaum.

Also würde ich erst einmal ein stimmiges Modell erstellen.
Wenn ASTAP unter Nina solvt, unter MC2 aber nicht, dann stimmen die Parameter in MC2 wahrscheinlich
nicht (vor allem Pixelgrösse bei "Kamera" und Brennweite bei "Teleskop" im MC2-Profil).
Ein vernünftiges Modell hat einen mittleren Positionierungsfehler ("Exp. RMS" unter "Align Info") von 10" RMS oder
weniger, wenn man einen steifen Aufbau hat.

Dieses Modell würde ich sicherheitshalber noch an ein paar Objekten auf Plausibilität überprüfen und dann erst mit
Nina weitersehen.

Vorher solltest Du Dich aber entscheiden, ob Du eigentlich von einem genauen Modell in der Monti profitieren willst,
oder nicht. Denn im ersten Fall sollte man jegliches Synchronisieren abstellen, und zwar im 10Micron Ascom Treiber
("Enable Sync" im Reiter "Sync Settings" deaktivieren, aber erst nach dem Modellieren mit MC2).
Wenn Du aber Nina unbedingt zum Synchronisieren verwenden willst (also die Montierung
auf eher herkömmliche Art nutzen willst), dann musst Du im Ascom Treiber "Enable Sync" aktivieren
und darunter "Use Sync as Refine" deaktivieren. Ein Modell brauchst Du dann nicht.
Ausserdem darfst Du Nina dann natürlich nicht das Syncen verbieten (also "Kein Sync" auf "off"
in Nina).
(Nach Deinen Beschreibungen klappen die sync-Befehle aber auch gar nicht richtig. Ist im Ascom Treiber
vielleicht "Use Sync as Refine" noch angehakt (evtl. vom MC2 Modelllauf)?
Das wäre dann kontraproduktiv, da dann nur ein neuer Punkt zu einem bereits danebenliegenden
Modell hinzugefügt würde, wenn Nina eigentlich syncen will).

Also muss man sich m. E. entscheiden, ob man mit Modell arbeitet und ohne Sync - oder halt andersherum.
Für mich ist die erste Variante überlegen, aber jedem sein Himmelreich.
Eine Mischung beider Verfahren führt dagegen immer tiefer in ein Dickicht aus Unwägbarkeiten.

Ein anderer Platesolver wird Dein Problem eher nicht lösen, das sehe ich wie Peter.
Natürlich ist gegen einen Test von Astrotortilla trotzdem nichts einzuwenden, vom
Aufwand mal abgesehen... aber ASTAP solvt entweder, und dann stimmt es auch,
oder es kann nicht solven, dann stimmen irgendwelche Parameter nicht.

Grüße
Matthias
 

echni

Mitglied
Noch eine Verständnisfrage:
In den Platesolveeinstellungen kann der Suchradius eingegeben werden. Der Wert beträgt bei mir 30. Was für eine Einheit ist das? Bogensekunden, Bogenminuten oder Grad?

Grüße
Dieter
 

pete_xl

Mitglied
Noch eine Verständnisfrage:
In den Platesolveeinstellungen kann der Suchradius eingegeben werden. Der Wert beträgt bei mir 30. Was für eine Einheit ist das? Bogensekunden, Bogenminuten oder Grad?

Grüße
Dieter
Es sind sicher Grad, alles andere macht keinen Sinn. Ich habe auch die 30 stehen gelassen. An den Einstellungen musst du ja nichts ändern, der Solver löst ja perfekt.

LG
Peter
 

echni

Mitglied
Hallo Matthias,

habe mir soeben mal die RMS-Werte der diversen Modelle in der Montierung angeschaut.
Das beste Modell hat 7,2 das schlechteste 19.
Mir ist schon klar, dass diese Modelle nicht zu dem Teleskop passen. Wollte daher ja auch eines für dieses (EDPH61) erstellen. Da kam aber bei jedem Punkt die Meldung, dass nicht gesolvt werden kann, oder so ähnlich. Habe das dann nach etwa 20 Punkten abgebrochen. Macht keinen Sinn.
Nächste Maßnahme ist dann, dass ich die Montierung ohne Modell mal auf einen Stern fahren lasse und dann schaue, ob dieser überhaupt im Gesichtsfeld zu sehen ist. Dann werde ich versuchen, diesen in die Bildmitte zu bekommen durch entsprechendes Verstellen der Prismenschiene in der Aufnahme. Sofern sich das überhaupt bewerkstelligen lässt. Mal abwarten.
Momentan ist ja Vollmondphase. Jetzt muss nur noch das Wetter einigermaßen mitspielen.

Vielen Dank schon mal an alle, welche sich hier mit der Thematik auseinandersetzen!

CS
Dieter
 

mfelsch

Mitglied
Hallo Dieter,

die RMS-Werte der Modelle in Deiner Montierung gelten ja gar nicht mehr, wenn
Du ein anderes Teleskop montiert hast.

Natürlich weißt Du selber am besten, was Du machen willst und was Dir sinnvoll erscheint,
aber wäre es nicht einfacher, mit dem neuen Rohr ein neues Modell zu machen?
Das Modell sagt Dir dann hinterher auch, ob die Polachsenausrichtung noch hinreichend stimmt.
Eine Abweichung in der Schienenmontage (wie auch einen Keilfehler) kann das Modell doch
perfekt kompensieren, wenn es hinreichend Punkte hat (dafür ist es u.a. da).

Du kommst doch eh nicht darum herum, in MC2 einen Solver ans Laufen zu kriegen, oder
willst Du für immer weiter mit ungültigen Modellen hantieren? Natürlich kann man immer probieren,
ob man in einer Notsituation mit einem alten Modell "davonkommt", aber Deine Versuche zeigen doch
eigentlich deutlich, dass das hier nicht hinhaut.

Schau doch im Log von MC2 mal, warum nicht gesolvt werden konnte. Vielleicht steht
da ja ein Grund drin.
Das Log ist im Dokumente-Ordner, Unterordner \Astromi\ModelCreator\Log.
Darin steht auch, ob MC2 ASTAP überhaupt findet beim Programmstart.

Aber ist alles auch nur so'ne Idee...

Matthias
 
Zuletzt bearbeitet:

echni

Mitglied
Moin Matthias,
ist auch meine Idee zunächst mal ein neues Modell für dieses Teleskop zu erstellen.
Wie ich aber bereits geschrieben habe, ist das bereits zweimal gescheitert.
Werde mir die Datei mal anschauen.
Wusste nicht, dass das nachträglich noch geht.
Grüße
Dieter
 

echni

Mitglied
Hallo Matthias,
hier die Fehlermeldung von MC2, vielleicht kannst du was damit anfangen:

22:20:26: Mount - Error - Failed to execute Method SyncToCoordinates
22:20:26: Mount - Error - Ein Aufrufziel hat einen Ausnahmefehler verursacht.
System.Reflection.TargetInvocationException: Ein Aufrufziel hat einen Ausnahmefehler verursacht. ---> ASCOM.MethodNotImplementedException: Method ASCOM.tenmicron_mount.Telescope SyncToCoordinates is not implemented in this driver. ---> System.Reflection.TargetInvocationException: Ein Aufrufziel hat einen Ausnahmefehler verursacht. ---> System.Runtime.InteropServices.COMException: Method SyncToCoordinates is not implemented in this driver.
--- Ende der internen Ausnahmestapelüberwachung ---

So ging es im Prinzip immer weiter bis ich abgebrochen habe.

Viele Grüße
Dieter
 

mfelsch

Mitglied
Hallo Dieter,

ich bin kein Ascom-Experte, aber das sieht für mich nicht aus wie ein Problem mit dem
Solver (also mit ASTAP), sondern wie eins beim Übermitteln des Sync-Befehls
(der Bestandteil des Model Building bei MC2 ist) an den Ascom Treiber der Montierung.
Der Treiber scheint zu sagen: " Ich nehme keinen Sync an".
Um mit MC2 ein Modell zu machen, muss im Ascom Treiber von 10Micron
auf der Reiterkarte "Sync Settings"
1."Enable Sync" und
2. "Use Sync as Refine"
angehakt sein.
(Steht auch im Manual von MC2, S.13 und 14...)

Ist es das bei Dir?

Matthias
 

Hanibal

Mitglied
Hmmmm.
Kenn ich jetz von MC2 so nicht. Da is irgendwas mit dem Ascom-Treiber. Gab mal einen, der bei Einigen nicht richtig funktionierte. Lad Dir mal den neuen runter. Ansonsten Einstellungen im Treiber wie in der Anleitung zu MC2. Sonst wird das nix. Wenn die Montierung kein richtiges Modell hat, funktioniert nix. Wenn Du neu aufgebaut hast oder das Teleskop wechselt, MUSS das Modell neu gemacht werden. 12 Punkte reichen da völlig.
 

echni

Mitglied
Glaube, dass ich den Fehler gefunden habe, weshalb MC2 kein neues Modell erstellt, bzw. diese Fehlermeldung kam.
Ich muss da wahrscheinlich nicht den ASCOM-Treiber 10Micron verwenden, sondern den der GM2000.
Hoffentlich klappt es damit.

Gruß
Dieter
 

mfelsch

Mitglied
Hallo Dieter,

mir ist nicht bekannt, dass 10Micron je nach Montierung unterschiedliche Ascom Treiber hätte.
Den richtigen bekommst Du hier.

Wie Christian und ich oben schrieben, sind für MC2 die richtigen Einstellungen im Treiber
wichtig, und für den aktuellsten Treiber solltest Du Ascom 6.5SP1 verwenden.

Grüße
Matthias
 

echni

Mitglied
Folgendes:
Wenn ich im ASCOM-Profileexplorer nachschaue, sehe ich dort zwei Treiber, den ASCOM GM2000HPS sowie den ASCOM.tenmicron_mount.telescope.
In NINA stehen ebenfalls diese beiden zur Auswahl.
Im MC2 stehen ebenfalls diese beiden zur Verfügung. Wenn ich aber den 10Micron aufrufe und dort "Properties" anwähle, hängt sich MC2 auf.
Von ASCOM ist die Version 6.5SP1 installiert.
Woher ich den GM2000er habe, kann ich momentan nicht nachvollziehen.

CS
Dieter
 

Hanibal

Mitglied
ASCOM GM2000HPS sowie den ASCOM.tenmicron_mount.telescope
Das ist sehr merkwürdig. Einen GM2000-Treiber kenn ich jetz nicht. Deinstalliere beide Treiber, mach nen Neustart und lad Dir den aktuellen ASCOM-Treiber vom 10micron-Forum runter. Von dem hört man nix Schlechtes. Ich hatte allerdings noch keinerlei Probleme mit den 10micron ASCOMtreibern. Irgendein älterer Treiber verträgt sich allerdings nicht mit ASCOM 6.5. Hier könnte auch ein Problem vergraben sein. Immer die Treiber verwenden, die für die jeweilige ASCOMversion gedacht ist.
Irgendwer hat auch nochmal den ASCOM-Treiber von Per Frejvall im Forum eingestellt. Der soll stabiler sein. Getestet hab ich das jedoch nicht.
 

echni

Mitglied
War ein Irrtum mit dem "Aufhängen"!
In der Taskleiste kann ich dann die entsprechenden Einstellungen des Treibers vornehmen.
Hatte auch noch den Treiber 1.5 drauf. Inzwischen auf 1.6 geändert.
 

echni

Mitglied
Hier mal die neuesten Wasserstandsmeldungen:
Problem behoben!
Grund für die ganze Malaise war, dass das Teleskop in der Ausrichtung gewaltig daneben lag.
Habe die Montierung ohne Sternmodell mal auf Sirius gefahren und da lag er ca. 2,5° daneben.
Nach einiger herumschrauberei, was sich auch etwas aufwändig gestaltet, vor allem in der Höhe, gelang es mit letztendlich ihn zu zentrieren.
Danach mittels MC2 ein Modell mit 100 Sternen erstellt. Das hat ja vorher auch nicht geklappt. Lag wahrscheinlich daran, dass der Platesolver das aufgrund der zu großen Differenz nicht auflösen konnte.
Im ASCOM-Treiber war auch nicht der Haken bei "Use J2000.0 ICRS Coordinates" gesetzt. Was das aber für Auswirkungen hatte, weiß ich momentan aber nicht. Müsste das mal ohne ausprobieren. Momentan bin aber froh, dass es damit funktioniert.
Nach dem ganzen Prozedere mal diverse Objekte angefahren. Diese lagen dann alle, wie im Rahmungsassistenten angezeigt in der Bildmitte.
Was mir immer noch nicht klar ist, weshalb der Platesolver die Abweichung nicht korrigiert hat. Lag wahrscheinlich daran, dass hier die zu große Abweichung die Ursache war.
Sei´s drum. Bin froh, dass ich das, auch mit eurer Unterstützung hinbekommen habe!
Jetzt steht einem entspannten Arbeiten eigentlich nichts mehr im Weg.

CS
Dieter
 

Hanibal

Mitglied
Ganz exakt wirds, wennst erst ein 10-Sternemodell machst, damit Polaralign, danach Dein eigentliches Modell. Den Haken bei J2000 setzt Du, wenn der Solver J2000 Koordinaten benutzt. Die Montierung rechnet aber, soviel ich weiß, in Jnow um. Gibts einen Thread im 10micron Forum drüber.
Aber freut mich, wenns jetzt funktioniert. :y:
 

echni

Mitglied
Na ja,
Polaralignement brauche ich eigentlich nicht mehr machen. War, als ich die Montierung aufstellte eine der ersten Aktionen welche ich durchgeführt habe.
Alle Modelle zeigen mir an, dass ich die Montierung um 0,02 Umdrehungen hochstellen und um 0,01 Umdrehungen nach links bewegen soll. Das ist, laut der Anleitung von Baader schon eine äußerst genaue Polausrichtung.
Da werde ich nichts mehr dran verändern.
Muss mir nur noch etwas einfallen lassen wegen der Fixierung des Teleskops (EDPH61) in der Aufnahme. Habe da zunächst einfach mal einen Kabelbinder unterlegt. Der ist ja am Beginn der Lasche etwas keilförmig. Damit konnte ich das ausgleichen. Das kann natürlich kein Dauerzustand sein. Will ja auch mal das Setup ggf. ändern.

Viele Grüße
Dieter
 

pete_xl

Mitglied
Hi Dieter,

wenn ich dich recht verstehe, kannst jetzt ohne Platesolver mit einem Rutsch auf das Ziel fahren. Dann willst du ja den Solver in NINA ja bestimmt trotzdem noch für den Rotationswinkel einsetzen. Konntest du denn testen, ob NINA und die Monti sich jetzt nach dem Solven einig sind? Ich glaube nicht, dass ASTAP ein Problem mit ein paar Grad Missweisung des Teleskops hatte, insbesondere, wenn die Monti so sauber eingerichtet war.
 
Oben