Autor: tschodde

Zu meinem Astronomie-Setup gehört eine ganze Reihe von Windows-Programmen: Stellarium, N.I.N.A., ASTAP, ASCOM und die passenden Kamerakomponenten von ZWO und SVBONY. Beim Blick auf meine installierte Software wird deutlich, wie unterschiedlich ihre Aufgaben sind. Manche Programme helfen beim Planen, andere organisieren Aufnahmen oder stellen die Verbindung zur Hardware her.

Hier stelle ich die Astro-Software aus meinem aktuellen Softwarebestand vor und ordne ein, wie die Bausteine zusammenpassen. Die Liste ist eine Bestandsaufnahme, kein vollständiger Erfahrungsbericht über jede Funktion und keine Empfehlung, sämtliche Komponenten auf jedem Astro-PC zu installieren.

Stellarium: den Himmel vor der Aufnahme erkunden

Stellarium ist das Planetarium in dieser Zusammenstellung. Es zeigt den Himmel für einen gewählten Standort und Zeitpunkt. Damit lässt sich beispielsweise nachvollziehen, wann ein Objekt über dem Horizont steht und wo es zwischen den Sternbildern zu finden ist. Für die Vorbereitung eines Beobachtungsabends ist das eine andere Aufgabe als die spätere Steuerung einer Aufnahmeserie.

N.I.N.A.: Aufnahmen planen und automatisieren

N.I.N.A. steht für „Nighttime Imaging ’N’ Astronomy“ und ist die Aufnahmesoftware in meinem Bestand. Das Programm bietet unter anderem Zielauswahl, Bildausschnittplanung und Aufnahmesequenzen. Mit passender, korrekt eingerichteter Hardware kommen Funktionen wie automatisches Fokussieren und das Zentrieren eines Motivs hinzu.

Eine Sequenz beschreibt etwa, welches Ziel aufgenommen werden soll, wie lange die einzelnen Belichtungen dauern und wie viele Bilder entstehen sollen. Welche Automatik tatsächlich verfügbar ist, hängt von den angeschlossenen Geräten, Treibern und Einstellungen ab. Eine installierte N.I.N.A.-Version allein macht deshalb noch keine fertig eingerichtete Aufnahmestation.

ASTAP: erkennen, wohin das Teleskop schaut

ASTAP ergänzt die Zusammenstellung um Plate Solving, Bildbetrachtung und weitere Auswertungsfunktionen. Beim Plate Solving wird das Sternmuster einer Aufnahme mit Katalogdaten verglichen. Daraus lässt sich bestimmen, welcher Himmelsausschnitt auf dem Bild zu sehen ist. Eine Aufnahmesoftware kann dieses Ergebnis verwenden, um die tatsächliche Position mit dem gewünschten Ziel abzugleichen.

In meinem Bestand findet sich außerdem der V50-Sternkatalog. Er ist eine Datenbank für ASTAP mit zusätzlichen Helligkeits- und Farbinformationen für die Photometrie, also die Messung von Helligkeiten. Er ist kein eigenständiges Aufnahmeprogramm. Welcher ASTAP-Katalog für ein konkretes Bildfeld sinnvoll ist, sollte anhand der Herstellerangaben und der eigenen Aufnahmen entschieden werden.

ASCOM und OnStep: die Verbindung zu den Geräten

Die ASCOM Platform stellt die gemeinsame Schnittstellenbasis für viele astronomische Anwendungen und Geräte bereit. Dazu kommen gerätespezifische Treiber. In meiner Liste steht beispielsweise der ASCOM OnStep Driver für die Anbindung einer OnStep-Steuerung an ASCOM-kompatible Anwendungen.

Plattform und Gerätetreiber erfüllen also unterschiedliche Aufgaben. Für die Fehlersuche ist diese Trennung hilfreich: Startet das Aufnahmeprogramm, lässt sich der passende Treiber auswählen und erreicht dieser anschließend das Gerät? Die tatsächliche Kommunikation mit einer Kamera oder Montierung muss immer an der angeschlossenen Hardware geprüft werden.

ASIStudio und Kameratreiber von ZWO und SVBONY

Mit ASIStudio ist auch die Software-Sammlung von ZWO vertreten. Sie umfasst Werkzeuge für Planeten- und Deep-Sky-Aufnahmen, Live-Stacking und Bildverarbeitung. Daneben ist der ZWO-ASI-Kameratreiber als eigene Komponente installiert. Aufnahmeprogramm und Treiber sind dabei nicht dasselbe.

Für SVBONY enthält mein Export einen allgemeinen SVBONY-Eintrag sowie einen Image-Treiber. Der allgemeine Eintrag benennt seine genaue Funktion nicht eindeutig. Deshalb lässt sich daraus allein weder das konkrete Kameramodell noch das richtige Paket für eine Neuinstallation ableiten. Maßgeblich bleibt die Zuordnung auf der SVBONY-Downloadseite.

Meine Bestandsaufnahme im Überblick

Auswertung vom 25. September 2026. Die Versionsangaben beschreiben den vorliegenden Export und sind keine Liste der jeweils neuesten Hersteller-Versionen. Doppelte Einträge für N.I.N.A. und ASCOM wurden zusammengefasst.

Wie die Bausteine zusammenspielen

Ein möglicher Ablauf mit dieser Software beginnt bei der Himmelsplanung in Stellarium. N.I.N.A. organisiert anschließend eine Aufnahmesequenz, passende Schnittstellen und Treiber verbinden die Geräte, und ASTAP kann die Position anhand einer Aufnahme bestimmen. ASIStudio bietet zusätzliche Aufnahme- und Auswertungswerkzeuge im ZWO-Umfeld.

Damit ist die Rollenverteilung klarer als bei einer bloßen Liste installierter Programme. Mein nächster Schritt ist, diese Zusammenstellung reproduzierbar einzurichten und das Zusammenspiel gezielt zu prüfen. Die Softwareinstallation lässt sich vorbereiten und testen; ob Kamera, Montierung und Aufnahmeablauf gemeinsam zuverlässig funktionieren, zeigt erst der Test am tatsächlichen Astro-Setup.

Mein Teltonika RUTX50 liefert seine GPS-Positionen jetzt über AVL an meine eigene Stationskarte. Dort erscheinen sie zusammen mit APRS-Stationen und den Traccar-Clients auf unseren iPhones.

Bisher hatte ich den Router per HTTPS angebunden. Das funktionierte grundsätzlich, allerdings übertrug er alle fünf Minuten einen ganzen Block NMEA-Rohdaten. Ein solches Paket war rund 361 kB groß – genug, um die ursprünglich eingestellte Empfangsgrenze zu überschreiten. Die Folge: Der Router sendete weiter, aber auf der Karte kamen keine neuen Positionen an.

Nach einer Anpassung am Server lief der Empfang wieder. Trotzdem wollte ich eine sparsamere Lösung, die ohne eigenes Skript auf dem Router auskommt.

AVL statt NMEA-Rohdaten

AVL ist im RUTX50 bereits eingebaut und überträgt kompakte GPS-Datensätze. Mein Kartenserver läuft als LXC unter Proxmox und kann diese Daten direkt empfangen. Ein zusätzlicher Traccar-Server ist dafür nicht nötig.

Die Verbindung läuft über meine DynDNS-Adresse und einen eigenen TCP-Port direkt zum LXC. Für diesen Einsatz habe ich mich bewusst für unverschlüsseltes AVL entschieden. Die Zuordnung erfolgt über die IMEI; diese ist allerdings kein geheimer Zugangsschlüssel.

Zwei Einstellungen machten den Unterschied

Beim ersten Versuch blieb die Verbindung erfolglos. In der Routerkonfiguration waren noch „Static Navigation“ und eine Mindestanzahl von 20 gespeicherten Datensätzen eingestellt. Zusätzlich liefen zwei Nebenregeln mit anderen Intervallen.

Jetzt gilt eine einheitliche Hauptregel:

• Position alle 30 Sekunden erfassen.
• Sendeintervall auf 60 Sekunden einstellen.
• Mindestanzahl auf einen Datensatz setzen.
• TCP-Verbindung offen halten und bei Fehlern erneut versuchen.
• Auch im Stillstand weiter Positionen erfassen.

Gerade der letzte Punkt ist für meine Bewegungswache wichtig: Sie soll erkennen, wenn ein Gerät längere Zeit stillsteht und sich anschließend wieder entfernt.

Der Empfang läuft

Nach der Umstellung zeigte der Router „Up“, und der Server bestätigte echte AVL-Positionsmeldungen. Anschließend habe ich den bisherigen HTTPS-Versand abgeschaltet, damit nicht beide Verfahren parallel Daten übertragen.

Die bestehenden Tracks bleiben erhalten. Auf der Live-Karte werden weiterhin die letzten 36 Stunden angezeigt; über die Tagesansicht lassen sich gespeicherte Strecken innerhalb der 90-tägigen Aufbewahrung ansehen.

Wie viel Mobilfunkvolumen AVL im Alltag tatsächlich spart, werde ich noch messen. Die umfangreichen NMEA-Pakete fallen jetzt jedenfalls weg – und der Router nutzt dafür eine bereits vorhandene Funktion.

Technische Grundlage: Teltonika-Dokumentation zum RUTX50 und AVL.