Mein holpriger Einstieg mit dem Green Swamp Server (GSServer), N.I.N.A und PHD2 (inkl. Einsteiger Workflow)

Mit dem Wechsel von meiner alten azimutalen LX200R Montierung, zu einer auf der Skywatcher EQ6 beruhenden Eigenbaumontierung, musste ich auch den vorhandenen Treiber für die ASCOM Schnittstelle ersetzen. Von überaus exotischen Softwares abgesehen, bleibt einem im Prinzip nur die Wahl zwischen dem Platzhirschen EQMod und dem immer bekannter werdenden GSServer (Green Swamp Server).

Gleich auf dem ersten Blick könnten die Programme nicht unterschiedlicher aussehen. Während „EQMod“ noch auf die seit 1998 nicht mehr wirklich weiterentwickelte Programmiersoftware Visual Basic 6.0 von Microsoft setzt und dementsprechend auch aussieht, nutzt der GSServer die deutlich jüngere Programmsprache C# und den Quasistandard NET Frameworks für die visuelle Darstellung. Da ich schon mit BASIC in der Version 2 meine Schwierigkeiten hatte und bei den ersten Seiten von „C64 Assemblerprogrammierung für Anfänger“ ausstieg, ist mein Wissen um Programmiersprachen sehr begrenzt. Aus diesem Grund habe ich mich einfach für den deutlich weniger gruselig aussehenden GSServer entschieden, ohne wirklich zu wissen was ich da tue.

Sobald man auf der Herstellerseite unter Downloads den GSServer heruntergeladen und installiert hat, oder einen der wirklich stabil laufenden Betas, wird man mit einer modernen, aber noch sehr ausgegrauten Oberfläche begrüßt.

Zu Anfang gibt es hier nur zwei Reiter am oberen Fensterrand die angeklickt werden können. Einer mit der Aufschrift Haupt und einer mit Optionen. Unter Haupt findet später die eigentliche Steuerung der Montierung und unter Optionen öffnet man die Grundeinstellungen des GSServer.

Im Reiter Optionen kann unter anderem die Sprache ändern (auch auf deutsch), dass Farbthema wechseln oder weitere Funktionen in Form von weiteren Reitern aktivieren.

Darüber hinaus bietet die Grundeinstellung des GSServer eine Sprach- und Tonausgabe und die Möglichkeit bestimmte Einstellung wieder zurücksetzen zu können.

Teleskopsteuerung mit dem GSServer

Bevor man seine parallaktische Montierung mit dem GSServer verbindet, muss man diese zumindest in die Grundstellung gebracht haben. Dazu wird die Montierung möglichst genau auf den Himmelspol ausgerichtet. Im Idealfall ist diese aber schon fertig eingenordet.

Wechselt man im GSServer vom Reiter Optionen in den Reitet Haupt, findet man in der linken oberen Ecke ein kleines Hamburger Symbol. Klickt man drauf, landet man in den Einstellungen für die Montierung.

Hier müssen wir dem GSServer zunächst den COM Anschluss der Montierung mitteilen. Dieser wird von Windows automatisch zugewiesen sobald man die Montierung über USB mit dem PC Verbunden und eingeschaltet hat.

Zunächst lassen wir aber die Montierung ausgeschaltet und öffnen in Windows den Gerätemanager (Tastenkombi: Windows-Logo + X). Dort angekommen erweitern wir den Bereich „Anschlüsse (COM & LPT)“ und bekommen so die bisher angeschlossenen USB Gerätschaften aufgelistet.

Schaltet man nun seine Montierung ein, erscheint ein paar Sekunden später ein weiteres angeschlossenes Gerät – Das ist unsere Montierung.

Hier merkt man sich dann den in der Klammer stehenden Port, in meinem Fall „COM3“ , wechselt wieder zurück zum GSServer und wählt diesen auch als COM Anschluss aus.

Neben dem COM-Anschluss sollte noch die passende Baud Rate ausgewählt werden. Laut Online Handbuch benutzen die meisten Skywatcher Montierungen ohne USB Anschluss den Wert 9600 und Montierungen mit USB-Anschluss 19200. Bei mir haben beide Werte nicht funktioniert und so musste ich alle 12 Möglichkeiten durchtesten bis sich meine Montierung (EQ6 Pro) mit 115200 Boud verbinden ließ.

Ob die gewählte Baud Rate die richtige ist, erfährt man spätestens wenn man die Einstellungen wieder schließt (Linkspfeil) und unten rechts unter Montierungstyp „Skywatcher“ auswählt und auf „Verbinden“ klickt.

Verbindet sich der GSServer mit der Montierung, hat man alles Richtig gemacht. Sollte eine Fehlermeldung erscheinen, ist vermutlich der COM Port falsch, die gewählte Baud Rate verkehrt oder das USB Kabel defekt.

Hat man nun seine Montierung erfolgreich verbunden, muss diese mit einem klick auf „Entparken“ noch aufgeweckt werden.

Nach dem Entparken kann die Montierung auch schon genutzt werden. Entweder manuell über die Steuerungstasten oder mit eine der vielen über ASCOM verbundenen Astroprogrammen. Bevor wir aber das tun, sollten wir nochmals einen Blick in die Einstellungen der Montierung werfen.

Persönliche Einstellungen im GSServer

Zurück in den Einstellungen der Montierung (Hauptreiter), findet man noch so einiges was man konfigurieren kann. Vieles davon habe ich zwar auf den Standardwerten belassen, aber einige musste ich dann doch noch anpassen.

Ausrichtungsmodus (Haupt-Einstellungen)

Der Ausrichtungsmodus sollte bei den meisten auf GermanPolar, also deutsche Montierung stehen. Alt AZ wäre demnach für azimutale Montierungen und Polar vermutlich für Montierungen die auf einer Polhöhenwiege montiert sind.

Viel Wirbel um den Meridian Flip

Beim richtigen Umgang mit dem Umkehrwinkel (Meridianflip) bin ich so völlig ausgestiegen! Im Online Handbuch kann man folgendes darüber lesen:

Online Handbuch

Entweder liegt das an der deutschen Übersetzung oder aber ab einer alten Version den Handbuchs, denn bei mir reagieren Programme wie CdC oder Stellarium sehr wohl auf diesen eingegeben Wert. Je nachdem wie hoch dieser eingestellt ist, reagiert die Montierung über Stellarium früher oder später mit dem Meridian Flip?

An einer ganz anderen Stelle im Handbuch konnte ich dann folgendes lesen!

„…Anwendungen wie NINA oder SGP können die Flip-Zone nutzen, indem sie den Flip mit dem Befehl „Seite des Piers“ vor oder nach dem Erreichen des Meridians erzwingen. Es wird empfohlen, dass die Flips lange vor dem Erreichen der Flip-Winkel-Einstellung erfolgen…“

Online Handbuch

So wie ich das jetzt lese, ist der Meridian Flip des GSServer ein Art „Notfallflip“. Sprich den Flip selber übernimmt die Software, also NINA, und sollte dieser aus irgendeinen Grund nicht stattfinden, wechselt GSServer die Richtung bevor das Teleskop irgendwo anstößt.

Also habe ich den Meridianflip unter NINA zeitlich vor dem Meridianflip des GSServer eingestellt. Bei NINA wählte ich unter „max. Minuten nach Meridian“ 1 und beim GSServer beließ ich die Zahl bei 20 Grad. Also müsste NINA noch weit vor dem GSServer meine Montierung in den Meridian-Flip zwingen.

Das Resultat war aber ein anderes. NINA hat zwar den Regeln entsprechend pünktlich in den Modus „Meridian Flip“ gewechselt und nacheinander seine Punkte abgearbeitet, aber den Punkt „flippen“ einfach übersprungen.

Nachdem NINA dann den nur scheinbar ausgeführten Meridianflip durchgeführt und das Autoguiding fortgesetzt hat, begann die Software auch schon mit den ersten Aufnahmen. Eine kurze Zeit darauf vollzog NINA dann ein zweites mal den Meridianflip, wiederholte die ganze Prozedur und führte diesmal einen echte. physischen Meridianflip durch.

Meine Vermutung ist daher das NINA einfach nur die Aufnahmen unterbricht, auf den Meridianflip der Montierung vertraut (sprich den GSServer) und dann wider weiter macht. Dazu würde auch die dritte zu findende Aussage des Online Handbuchs passen:

„…Um Anwendungen, die ein Goto verwenden, richtig zu unterstützen, stellen Sie den Flip-Winkel entweder auf 0 oder 1…“

Online Handbuch

Jedenfalls funktioniert bei mir der Meridianflip fehlerfrei wenn ich bei NINA den Wert auf 2 setze und beim GSServer auf 1.

Fehlerhaftes Autoguiding nach Meridianflip

In diesem Zug fiel mir dann ein weiteres Problem mit PHD2 auf. Wenn NINA nun den Meridianflip vollzogen hatte und anschießend den Autoguider PHD2 startet, schmierte meine DEC Achse gnadenlos ab. Es war PHD2 nicht mehr möglich ein Autoguiding durchzuführen und erst das erneute kalibrieren führte zum erfolgreichen Guiding.

Im Online Handbuch habe ich darüber nichts finden können, aber dafür auf der hauseigenen Hilfeseite (Link). Hier wurde beschrieben das man in PHD2 unter „Advance Settings“ den Haken bei „DEC Ausgabe nach dem Umschwenken (Meridian Flip) umkehren“ setzten muss. Das war dann auch schon die Lösung, seither gab es keine Probleme mehr mit dem erneuten Autoguiding nach dem Meridianflip.

Mehrere Park Positionen bestimmen

Eine weitere Parkposition ist vor allem bei festaufgestellten Montierungen hilfreich. Im Normalfall wird beim Parken das Teleskop in die Grundstellung (Ziel Richtung Polarstern) gebracht. In einer Sternwarte kann es aber sein, dass sich so das Dach nicht mehr schließen lässt. So kann man mit einem klick auf das „+“ Symbol die aktuell Montierungsposition als eine weitere Parkposition mit freiwählbaren Namen abspeichern.

Meine Einstellungen unter Optionen

Das Gamepad und der Kundenservice

Ein kleine Odyssee war die Verbindung mit dem Gamepad. Hierfür muss zuerst unter „Optionen“ einen extra Reiter Namens „Gamepad“ aktiviert werden. Öffnet man diesen Reiter muss auch noch ein Haken bei „Gamepad Ein“ gesetzt werden.

Im Handbuch vom GSServer kann man über das verbinden mit einem Gamepad folgendes lesen:

„Beim Konfigurieren eines Gamepads oder Joysticks wird empfohlen, keine Verbindung zu einer Halterung herzustellen.
Schalten Sie das Gamepad ein und klicken Sie mit der Maus in das Feld, in dem Sie die Gamepad-Steuerung auswählen möchten. Klicken Sie auf Speichern, um die neuen Einstellungen auszuprobieren…“

Online Handbuch

Also fix in den Keller und das angestaubte Gamepad aus PreSteam Zeiten geholt und angestöpselt – Aber nix passiert! Das Gamepad wurde zwar unter Windows korrekt als solches erkannt, aber unter dem GSServer einfach ignoriert.

Vielleicht lag’s ja auch am Alter des Gamepads, dachte ich mir und so habe ich mir einen neuen geilen Retro-Controller* bestellt. Aber auch hier das gleiche Problem. Das Gamepad wurde von Windows angenommen, aber unter GSServer verweigert.

Im Folge dessen habe ich den Kundenservice kontaktiert und tatsächlich auch einen Tag später eine Antwort erhalten. Wir schrieben uns einige Male hin und her, wobei ich auch das ein oder andere Log-File mitschicken musste und klärten mein Problem. Das Problem bestand nämlich darin, dass ein Gamepad nur dann von GSServer akzeptiert wird, wenn es als „XBox 360 Controller für Windows“ erkannt wird.

Warum das so ist, weiß ich nicht. Jedenfalls habe ich mir diesen* Controller bestellt und angeschlossen. Windows hat den Controller dann auch als XBOX Controller erkannt und der GSServer hat diesen auch anstandslos akzeptiert.

Also merken! Die Gamepad Funktion des GSServer benötigt einen XBox 360 kompatiblen Controller. Davon abgesehen das ich nicht verstehen kann warum das so ist, war ich super beeindruckt von der Hilfsbereitschaft der Entwickler.

(Fern)Steuern mit der Maus

Neben dem Gamepad gibt es auch die Möglichkeit die Montierung mit der Maus zu steuern. Hierzu klickt man in der Steuerkonsole (Peiltasten für die Montierungsbewegung) einfach nur auf das Maussymbol und schon wird die Maus in ihrer Bewegung blockiert. Das Scrollrad und die Tasten der Maus funktionieren weiterhin, besitzen aber eine neue Funktion.

Mit der mittleren Taste (Jog Dial, Mausrad) wird zwischen der DEC und RA Achse gewechselt, bewegt wird die Montierung dann mit der linken oder rechten Maustaste und drehen am Mausrad bewirkt eine Veränderung der Montierungsgeschwindigkeit.

Die Möglichkeit die Montierung über die Maus oder ein Gamepad zu steuern ist zumindest für mich unbezahlbar. Zum einen kann ich so über den Sucher auch Ziele manuell anfahren (z.B. Planeten und Mond) und zum anderen kann ich während der Planetenaufnahme Korrekturen vornehmen, ohne das ich immer wieder zwischen Tastenfeld und Aufnahmesoftware wechseln muss.

Zwar gibt es die Möglichkeit das Steuerungsfeld als eigenes kleines Fenster zu öffnen, aber dann verdeckt diese immer etwas von meinem Aufnahmefenster.

Fazit

Ich denke das ich mit dem GSServer aufs richtige Pferd gesetzt habe. Zwar gab es anfänglich ein paar Probleme, siehe Meridianflip und Gamepad, aber letztendlich wurde das Problem gelöst und die Montierung lief seither stabil. Optisch wirkt der GSServer zeitgemäß und logisch aufgeräumt. Nach einer kurzen Einarbeitungszeit findet man sich ganz gut zurecht, wie ich finde.

Richtig beeindruckt hat mich aber die Hilfsbereitschaft der Entwickler. Zwischenzeitlich wurden sogar angepasste Betas mit verändernden LOG-Files veröffentlicht, nur damit sie den vermeintlichen Fehler bei mir finden konnten. Das es letztlich an ein Problem mit XBox360 Kompatibilität lag, ist wieder eine andere Sache.

Schreibe einen Kommentar

Cookie Consent mit Real Cookie Banner