Umrechnung von äquatoriales in horizontales Koordinatensystem

[h_c_greier]

Es reicht mM wenn ich einfach 2 Werte im Abstand von 1s berechne und von einander abziehe (Computer ist eh schnell genug).

Das könnte gehen, ich hab solche Hardware nicht in realiter und weiß auch nicht, wie die programmiert wird. So wie's aussieht macht Frank das in VisualBasic. Deswegen habe ich meinen JS auf VB umgemodelt und oben gepostet.

Es ist ja auch klar, dass die Winkelgeschwindigkeit konstant ist.

Welche Winkelgeschwindigkeit meinst du genau?
Es ist nämlich mitnichten so, dass die Änderungsraten in Höhe und Azmiut konstant wären. Bei der Höhe ist das anschaulich klar, die ist ja quasi "sinusförmig" über den Tagesverlauf und die Ableitungen dem entsprechend wechselnd. Die Grafiken gelten für den Ort 50N /10E:

[Quelle: selbst erstellte Grafiken]

Auch der Azimut verläuft nicht genau linear, wie man zuerst vielleicht vermuten könnte:

Im linken Teil, also vor dem Meridiandurchgang kurz vor 09:00, verläuft der Azimut annähernd linear, im rechten Teil ist das schon weniger klar.

[Quelle: selbst erstellte Grafiken]

Ich habe die Funktionen aber nicht abgeleitet, war zu faul , die Änderungsraten sind aus den Differenzwerten in minütlichem Abstand berechnet.

cs,
harald

--

 

[efbe68]

Mal eine kurze Rückmeldung von mir.

Und funktioniert es?

Ja! Ich kann alle Zwischenwerte in meinem Programm reproduzieren.

Zum besseren verständniss...
Meine Idee ist, dass ich das VB-Programm verwende um den Arduino (der steuert letztendlich die Montierung) initialisiere. Also alle Daten, die zur umrechnung nötig sind dem Arduino übergebe. Ab da läuft der interne Timer und rechnet erst einmal das aktuelle JD.
Danach wird das VB-Programm geschlossen und Stellarium gestartet.
Stellarium verbindet sich über die COM-Schnittstelle mit dem Arduino und sendet RA/DEC über LX200 an den Arduino.
Die Umrechnung von Äquatorial auf Horizontal erfolgt dann auf dem Arduino und setzt die Koordinaten auf Schrittmotor-Pulse um.

Vermutlich muss der Arduino dann auch das ganze wieder an Stellarium zurückmelden. Aber das ist eine andere "Baustelle".

Was mich immernoch irritiert ist, das die Berechnung von Azimut/Höhe nicht dem entspricht, was mir in Stellarium angezeigt wird...

Die Anpassung, dass der Azimut von Süden aus berechnet wird, habe ich gemacht.
Auch ist das entgegen der Aussage, "Ost negativ, West positiv" in Stellarium genau anders herum.

Ich möchte mich noch einmal herzlich bedanken, für die Mühe, die ihr euch macht.
Wenn ich das so, wie ich mir das vorstelle, hinbekomme, stelle ich gerne den Programmcode des Arduino hier ein. Das VB-Programm dürfte etwas den Rahmen sprengen. Als Zip-Datei wäre das möglich. Da braucht es aber eigentlich VisualStudio.

 

[AstroPZ]

Hi @efbe68 ,

klar, bitte den ganzen Programm Code reinstellen.
Da bin ich super dran interessiert.
Ich programmiere allerdings auf dem PC in Java/Eclipse. Sollte aber kein Problem sein.

Visual Studio bzw. Visual Studio Code benutze ich für den Arduino.
Für den Arduino braucht man in VSC die Extension PlatformIO.
Das ist aber super empfehlenswert, da man dann die ganze Visual Studio Umgebung nutzen kann, zB die Extension GitHub Pull Requests für GitHub Integration. Oder auch andere Sprachen wie Python.

Gruß
Peter

 

[AstroPZ]

Hi Harald,

Welche Winkelgeschwindigkeit meinst du genau?
Es ist nämlich mitnichten so, dass die Änderungsraten in Höhe und Azmiut konstant wären. Bei der Höhe ist das anschaulich klar, die ist ja quasi "sinusförmig" über den Tagesverlauf und die Ableitungen dem entsprechend wechselnd. Die Grafiken gelten für den Ort 50N /10E:

da war ich wieder etwas vorschnell.
Die fast konstante Winkelgeschwindigkeit gilt natürlich nur für kurze zeitliche Abstände zB im Sekundenbereich.
Ich wollte damit nur Ausdrücken, dass man nicht unbedingt die mathematisch korrekte Ableitung braucht und man auch einfach numerisch die Winkelgeschwindigkeit für kurze Zeitunterschiede berechnen kann.

Vielen Dank auch für die tollen Grafiken. Damit wird einiges klarer.

Wobei ich schon am Überlegen bin, ob sich der Aufwand für das Tracking in Alt/Az für die Dobson-Montierungen überhaupt lohnt.
Das Problem ist ja, dass man gerade im Zenit, wo es am sinnvollsten ist Aufnahmen zu machen, Probleme mit dem Tracking bei Alt/Az hat.
Deswegen wäre es wahrscheinlich für Astro-Fotografie sinnvoller, wenn ich den Realisierungs/Programmier-Aufwand in eine bessere Unterstützung meiner EQ-Plattform mit Schrittmotor reinstecke.

Gruß
Peter

 

[AstroPZ]

Vermutlich muss der Arduino dann auch das ganze wieder an Stellarium zurückmelden. Aber das ist eine andere "Baustelle".

Klar, das ist im LX200 Protokoll so vorgesehen. Da findet man auch Dokumentation, bzw. entsprechende Realiserungen dazu.
Siehe auch im Anhang.

Was mich immernoch irritiert ist, das die Berechnung von Azimut/Höhe nicht dem entspricht, was mir in Stellarium angezeigt wird...

Das kann nicht sein. Damit würde ich auch definitiv testen. Stellarium macht das sicherlich korrekt, bis auf unterschiedliche Konventionen.

Gruß
Peter

 

[efbe68]

Visual Studio bzw. Visual Studio Code benutze ich für den Arduino.
Für den Arduino braucht man in VSC die Extension PlatformIO.

Die IDE (v1.8.19) des Arduino ist gruselig, aber ich habe nur VS2010 und Win7. Da bin ich froh, das das noch läuft.
Vermutlich sind die aktuellen Versionen von VS in der Lage auch mit dem alten Zeug umzugehen.
Beim Arduino sehe ich da kein Problem. Ist halt C für einen Uno-V3.

Den Code stelle ich gerne ein. Sollte das mal vernünftig funktionieren.
CNC-Fräsen ist ja heute durch ESTL-CAM auch eher "nur" noch ein mechanisches Problem geworden.

 

[h_c_greier]

Hi Frank,

Das mit Ost/West ist schließlich nur eine Konvention, ist eine alte "Streitfrage" . Es ist schließlich ja wurst, du kannst auch Ost+ nehmen, musst dann aber beim Stundenwinkel des Objekts das Vorzeichen ändern.

Meeus rechnet die östliche Länge negativ, dann hast du für den Stundenwinkel theta = lmst - RA = gwst - lon - RA
Nimmt man Ost+, dann muss man halt das Vorzeichen bei "lon" umdrehen.

In deinem Screenshot hast die Länge -10.0° eingestellt. Ost oder West? Unten links sieht man ja nur: Erde +50°00'00", -10°00'00", aber ohne N/S bzw. O/W! Ein Lapsus von Stellarium meiner Meinung nach.
Im Einstellungsfenster kann man das ja vor der Zahl angeben! Eine Bitte: Wenn du Screenshots präsentierst, bitte immer genaue Angaben, z.B. könnte man das Zeit-Fensterchen unten rechts dazu einblenden, ich mache das immer so, dann hat man alle wichtigen Daten beisammen.

Ich muss auch gleich über die Standorteingabe in Stellarium ablästern: Die ist nämlich echt mühsam. Warum muss man jedesmal einen neuen Ort kreieren, und kann nicht schnell mal was anderes eingeben, nur um etwas zu testen? Auch ist es mir nicht gelungen, die kleine westliche Länge von W 0.001475° einzugeben. Man muss auf °'" ausweichen. Brrr.

Da braucht es aber eigentlich VisualStudio.

Nein, braucht man nicht, es geht auch VSCode, mit dem von Peter erwähnten AddOn/PlugIn, BlaBlubb....

cs,
harald

--

 

[efbe68]

Das mit Ost/West ist schließlich nur eine Konvention, ist eine alte "Streitfrage" . Es ist schließlich ja wurst

Naja... Ich baue zwar keine Marssonde (Schiaparelli) aber eine Einigung auf Standards hilft ungemein.

Ich habe den Standort so eingestellt, dass es zu deinen Werten im VB-Code passt. Also halt so...

Ich "klebe" auch nicht an Stellarium. Für das, was ich gerne machen möchte ist es besser als "Red-Shift". Sollte aber nicht zu teuer werden.

Eine Bitte: Wenn du Screenshots präsentierst, bitte immer genaue Angaben, z.B. könnte man das Zeit-Fensterchen unten rechts dazu einblenden, ich mache das immer so, dann hat man alle wichtigen Daten beisammen.

Alles was euch hilft, mir zu helfen das Projekt umzusetzen und dann als "Open-Source" anderen zu geben mache ich gerne! Ich muss nur wissen, was gebraucht wird und wo ich das finde/einstelle.

Ich muss auch gleich über die Standorteingabe in Stellarium ablästern: Die ist nämlich echt mühsam. Warum muss man jedesmal einen neuen Ort kreieren, und kann nicht schnell mal was anderes eingeben, nur um etwas zu testen? Auch ist es mir nicht gelungen, die kleine westliche Länge von W 0.001475° einzugeben. Man muss auf °'" ausweichen. Brrr.

Ich bin mir nich sicher ob du das meinst, aber unter Konfiguration -> Werkzeuge (da wo auch Azimut von Süd eingestellt werden kann), kann man auch die "Verwende Dezimalgrad" angeben. Das erspart die Umrechnung.
Ansonsten muss man hat mit dem auskommen, was einem (mir) zur Verfügung steht.

Ich finde es spannend und ich lerne so viel dazu. Wobei es an vielem bei mir hapert (Was genau ist jetzt der Unterschied zwischen Grad- und Bogenmaß ;-)

Es bleibt bei mir nach wie vor die Frage, warum die Daten, zwischen Berechnung und dem, was mir in Stellarium angegeben wird, so Eklatant auseinander laufen. Da hilft es auch nicht mal hier ein/zwei Stunden auf UT drauf oder runter zu rechnen oder mal da Ost mit West zu tauschen.

Spannend wird es nochmal, wenn ich die Berechnung versuche auf den Microcontroller zu heben. Der tut sich mit Fließkommazahlen eher schwer. Besser sind ganze Zahlen.

Viele Grüße, Frank

 

[h_c_greier]

Ich habe den Standort so eingestellt, dass es zu deinen Werten im VB-Code passt. Also halt so...

Nein, hast du nicht. Meine Daten waren N50° und E10°, nicht W10°!

Ich bin mir nich sicher ob du das meinst, aber unter Konfiguration -> Werkzeuge (da wo auch Azimut von Süd eingestellt werden kann), kann man auch die "Verwende Dezimalgrad" angeben. Das erspart die Umrechnung.
Ansonsten muss man hat mit dem auskommen, was einem (mir) zur Verfügung steht.

Das habe ich immer angehakt. Nur funktioniert es nicht. Wenn ich z.B. deine Daten eingebe, also

N 51.47781111°
W 0.001475°

dann schnupft mir das Programm die 5.31 Bogensekunden West (zugegeben nicht viel) weg und schreibt W 0.00000° hin! Ich werd' noch weich

Also nochmal:

Dein Standort              Mein Test-Standort
N 51.477811111111116°      N 50.0°
W 0.001475°                E 10.0°

cs,
harald

--

 

[h_c_greier]

Spannend wird es nochmal, wenn ich die Berechnung versuche auf den Microcontroller zu heben. Der tut sich mit Fließkommazahlen eher schwer. Besser sind ganze Zahlen.

Hat dein Controller kein FPU? Nur mal so weil ich mich da nicht so auskenne...

 

[AstroPZ]

Hi Frank,

Spannend wird es nochmal, wenn ich die Berechnung versuche auf den Microcontroller zu heben. Der tut sich mit Fließkommazahlen eher schwer. Besser sind ganze Zahlen.

ich hatte meinen Arduino Code auch so aufgebohrt, dass dort alles berechnet wurde.
Man läuft übrigens dann auch sehr schnell in Memory Probleme.

Aktuell mache ich das nicht mehr so. Ich habe die prinzipielle Architektur geändert.
Auf dem Arduino läuft nur noch die simple direkte Ansteuerung der Schrittmotoren über die AccelStepper Library.

Alles andere, also zB Schrittmotor- und Alt/Az-Berechnungen für GoTo oder zB die geplanten Berechnungen für das Tracking wird auf dem PC/Notebook (in Java) gemacht. Das Java Programm sendet dann über USB an den Arduino nur noch simple Schrittmotor Befehle.

Diese Architektur bewirkt selbstverständlich, dass man zusätzlich einen PC/Notebook am Teleskop haben muss.
Aber das ist bei mir sowieso und bestimmt bei vielen anderen auch so, da der PC/Notebook die Aufnahmen macht und auch Stellarium oder NINA zur Steuerung darauf läuft.

Was ich schon geplant hatte, ist, auf dem PC/Notebook das LX200 Protokoll von Stellarium oder einem ASCOM Treiber über eine virtuelle serielle Schnittstelle abzufangen und alles umzusetzen und damit dann den Arduino mit Schrittmotor-Befehle zu versorgen. Damit kann man dann auch viel besser das Protokoll analysieren und debuggen.
Aber ich habe nur mal die Machbarkeit über die virtuelle serielle Schnittstelle geprüft, weiter bin ich nicht gekommen und es ist bei mir wieder eingeschlafen.

Ich brauche das LX200 Protokoll auch nicht wirklich, da ich Stellarium einfach direkt über seine HTML Schnittstelle abfrage.

Gruß
Peter

 

[efbe68]

Nun, solange du noch ein "ROLF" hinter deine Antworten stellst, vermute ich, das du noch nicht zu genervt bist.
Um aus dem Hören/Lesen/Sagen etwas verwertbares zu machen muss ich mir erst einmal das Blockdiagramm vom AtMega328P ansehen.
In einem Buch (AVR-Mikrocontroller) werden jedenfalls keine Fließkomma-Datentypen erwähnt.
Vielleicht gibt es aber Bibliotheken, die das Umrechnen.

Irgendwie muss das funktionieren. In den käuflichen Montierungen funzt das ja auch. Und da muss ich die Daten umständlich über das Handgerät einpuzzeln.
Vielleicht ist da auch ein Spezialchip drin. So recht mag ich das aber nicht glauben.

Nein, hast du nicht. Meine Daten waren N50° und E10°, nicht W10°!

Das wäre noch zu klären

To be continue...

PS: Was bedeutet cs?

 

[P_E_T_E_R]

Was mich immernoch irritiert ist, das die Berechnung von Azimut/Höhe nicht dem entspricht, was mir in Stellarium angezeigt wird...

Naja, kein Wunder, da dürfte wohl ein Missverständnis bei der Standorteingabe vorliegen:

Mit einem Standort 50°N / 10°W landet man jedenfalls im Atlantik:

Credit: Google-Earth

Gruß, Peter

 

[h_c_greier]

Das wäre noch zu klären

Ich verstehe nicht, wo dein Problem liegt?

Diphda, Koord. zum Datum
RA = +11.19765
DEC = -17.8535

Zeitpunkt
13.05.2025, 12:40:12 MESZ = 10:40:12 UT
In Stellarium wird 12:40:12 MESZ eingestellt!

Ergebnisse
================================================
N50°, W10° (lon = +10 im VB Script)     N50°, E10° (lon = -10 im VB Script)
JD = 2460443.94458333                   JD = 2460443.94458333
lon = 10                                lon = -10
lat = 50                                lat = 50
RA = 11.19765                           RA = 11.19765
DEC = -17.8535                          DEC = -17.8535
gwst= 3212671.7319328                   gwst= 3212671.7319328
gwst ° = 31.7319328035228               gwst ° = 31.7319328035228
gwst h = 2.11546218690152               gwst h = 2.11546218690152
lmst °= 21.7319328035228                lmst °= 41.7319328035228
lmst h= 1.44879552023485                lmst h= 2.78212885356819
theta = 10.5342828035228                theta = 30.5342828035228
h = 21.5100279439362                    h = 16.985537890317
az = 10.7804915249616                   az = 30.3741595768538
                                       
GUIDE:                                  GUIDE:
h = 21.5, az = 10.8                     h = 17.0, az = 30.4

Stellarium:                             Stellarium:
h = 21.5098, az = 10.7830               h = 16.9848, az = 30.3765

cs bedeutet "clear skies!", der fromme Wunsch der Astronomen.

cs,
harald

--

 

[h_c_greier]

Sorry, 13.05.2024, 12:40:12 MESZ = 10:40:12 UT

 

[Ehemaliges Mitglied]

Das Thema interessiert mich auch sehr, da ich immer wieder mal daran denke mein bestehendes setup mit EQ Plattform dahingehend zu erweitern das ein motorischer Antrieb der Alt/Az Achsen zusätzlich möglich ist.

Wenn die Plattform nach einer Stunde in Endlage ist wird sie automatisch zurückgestellt, und das Objekt über die beiden Achsen der Rockerbox wieder angefahren.

Langzeitbelichtungen wären dadurch viel effizienter als mit dem manuellen Anfahren des Objekts nach jedem Rückstellen, bzw könnte sogar mittels einer Software wie NINA ein komplett automatisierter Betrieb erfolgen.

Zusätzlich müsste dafür natürlich noch ein Rotator die Kamera mitdrehen bei jedem Rückstellen.

Man könnte das ganze noch weiter spinnen und die Plattform um eine Unterkonstruktion erweitern die sich selbstständig horizontal ausrichtet, und die Plattform nach Norden stellt.

Somit hätte man ein auflösungsstarkes 10“ Smart-Teleskop.

Wobei ich mir schon die Frage gestellt habe ob eine Motorisierung von Alt/Az Achse + mitrotierender Kamera nicht dasselbe bewerkstelligt, mit deutlich weniger Bauteilen

Das Problem ist ja, dass man gerade im Zenit, wo es am sinnvollsten ist Aufnahmen zu machen, Probleme mit dem Tracking bei Alt/Az hat.

Welche Schwierigkeiten gibt es denn da, neben der Bildfeldrotation natürlich?

Gruß

Simon

 

[AstroPZ]

Hi Simon,

Wobei ich mir schon die Frage gestellt habe ob eine Motorisierung von Alt/Az Achse + mitrotierender Kamera nicht dasselbe bewerkstelligt, mit deutlich weniger Bauteilen

Im Prinzip ja. Ich habe mir das auch schon oft überlegt. Ein Rotator wäre ja auch nicht so kompliziert.
Aber man kann halt nicht gut im Zenit fotografieren, wo das Licht der Objekte am wenigsten geschwächt wird.

Welche Schwierigkeiten gibt es denn da, neben der Bildfeldrotation natürlich?

die Winkelgeschwindigkeiten werden sehr gross und die Positionier-Genauigkeit wird sehr schlecht.
Deswegen kann man ja bei einer motorischen Alt/Az-Montierung meistens nur bis zu einer bestimmten Höhe fahren.

Gruß
Peter

 

[Ehemaliges Mitglied]

Ok verstehe, das ist einleuchtend.

Vielleicht macht die Idee das Prinzip der azimutalen Dobson Montierung mit der für eine Stunde wie eine parallaktische Montierung nachführenden EQ Plattform zu kombinieren dann doch einen Sinn.

Auf jeden Fall ist die Plattform in Sekundenschnelle aufgebaut, ist steif und hat keine großen Hebel und trägt daher auch sehr schwere Teleskope schwingungsarm und Foto-tauglich.

Wenn ich mal Zeit habe gehe ich das an (falls ich die jemals haben werde )

 

[efbe68]

Mal eine kurze Rückmeldung von meiner Seite...
Die Sternzeit rechnet mein Arduino jetzt eigenständig richtig weiter. Das Hochzählen war für mich dann noch mal etwas tricky, da der Arduino-Uno für Fließkommazahlen nur 4 Byte verwendet.
Altitude/Höhe rechnet er auch so wie es mit in Stellarium angezeigt wird.
Bei Azimut passt es noch nicht. Da muss ich noch etwas mehr lernen/experimentieren.

@h_c_greier : Noch mal vielen Dank. Ohne deine Hilfe hätte ich das nie so weit hinbekommen.

 

[h_c_greier]

Die Sternzeit rechnet mein Arduino jetzt eigenständig richtig weiter. Das Hochzählen war für mich dann noch mal etwas tricky, da der Arduino-Uno für Fließkommazahlen nur 4 Byte verwendet.

Na super! Gibt's da nicht eine FPU-Version von den Dingern? Habe nur mal kurz geschaut, aber ich kenne mich in dem Thema nicht aus...

Bei Azimut passt es noch nicht. Da muss ich noch etwas mehr lernen/experimentieren.

Kann es sein, dass hier der Arctan2 Probleme macht? In VB hat man diese Funktion ja zur Verfügung, damit man den arctan im richtigen Quadranten geliefert bekommt.

Es könnte auch sein, dass du (momentan) Werte zurückgeliefert bekommst, die du dann auf das Intervall [0°-360°] beschränken solltest, und dann erst weiterrechnest.

@h_c_greier : Noch mal vielen Dank. Ohne deine Hilfe hätte ich das nie so weit hinbekommen.

Sehr gerne. Würde mich interessieren, ob du's dann geschafft hast...

cs,
harald

--

 

[h_c_greier]

Hallo Leute,

ich will mal kurz nachfragen, ob diese Diskussion gefruchtet hat bzgl. der Programmierung eurer Steuereinheiten?

cs,
harald

--

 

[AstroPZ]

Hi Harald,

ich will mal kurz nachfragen, ob diese Diskussion gefruchtet hat bzgl. der Programmierung eurer Steuereinheiten?

für mich war das super interessant, da ich ja meine SW-Steuerung der Schrittmotoren mit einem alt/az Nachführ-Modus erweitern will.
Dafür benötige ich die Berechnung der Winkelgeschwindigkeiten in Alt/Az nach Koordinate und Standort.

Mein erster Schritt wäre, wenn ich dazu komme, eine kleine Java Funktion/Package zu schreiben, dass Alt/Az für einen Standort und Koordinate berechnet.
Natürlich gleich mit entsprechenden Unit-Tests zur Überprüfung der korrekten Funktion. Korrekte Daten würde ich aus Stellarium nehmen.

Bin aber noch nicht dazu gekommen.

Gruß
Peter

 

[h_c_greier]

Hallo Peter,

Dafür benötige ich die Berechnung der Winkelgeschwindigkeiten in Alt/Az nach Koordinate und Standort.

Das wäre ja mit den bereits geposteten Scripten möglich. Man müsste halt das VB-Script in ein Modul packen. Als Input die Zeit, der Beobachtungsort und die Objektdaten (Ra/Dec). Die Az/h Berechnung muss dann 2mal gemacht werden, für die "Echtzeit" und für diesen Zeitpunkt plus x Sekunden. Aus der Differenz dieser beiden Daten erhält man die "Geschwindigkeit" und auch deren Richtung. Das müsste doch machbar sein? Soweit die Theorie. (Grau ist alle Theorie, aber schwarz seh'n wir erst in der Praxis.)

Ich weiß aber nicht, welche Hardware Stolpersteine hier noch liegen. Soweit ich das Gelesene verstanden habe werden die Berechnungen ja an einem Laptop gemacht (JAVA... oder whatever) und die Daten dann an die Steuereinheit verwurstet, wie auch immer dieser Vorgang genau passieren mag.

Natürlich gleich mit entsprechenden Unit-Tests zur Überprüfung der korrekten Funktion

Hm, bitte um Erklärung, was mit "Unit-Tests" gemeint ist.

Korrekte Daten würde ich aus Stellarium nehmen.

Welche "Korrekten Daten" sind hier gemeint? Die Ra/Dec des Objekts?

cs,
harald

--

 

[h_c_greier]

Hier ein rudimentäres VB zur Ermittlung von Azimut und Höhe zweier um Δsecs Sekunden auseinanderliegender Zeitpunkte.

Public Module Program
  ' JD berechnen im Zeitraum 1.3.1900 - 28.2.2100
  Public Function GetJD(ByVal yrs As Integer, ByVal mth As Integer, ByVal dys As Double, ByVal hrs As Double, ByVal mins As Double, ByVal secs As Double) As Double
    Dim jd As Double
    If mth <= 2 Then
        yrs -= 1
        mth += 12
    End If
    dys += (hrs + mins / 60 + secs / 3600) / 24
    jd = Math.Floor(365.25 * (yrs + 4716)) + Math.Floor(30.6001 * (mth + 1)) + dys - 1537.5
    Return jd
  End Function
 
  Public Function getSiderialTime(ByVal jd As Double) As Double
    Dim T As Double, theta As Double
    T = (jd - 2451545.0)/36525
    theta = 280.46061837 + 360.98564736629 * (jd - 2451545.0) + 0.000387933*T*T - (T*T*T)/38710000
    Return theta Mod 360
  End Function
 
  Public Sub Main()
    Const DEGS As Double = Math.PI/180
    ' Standortdaten = konstant
    Dim lon As Double = -10.0 ' Ost negativ, West positiv
    Dim lat As Double = 50.0
    Console.WriteLine("lon = " & lon)
    Console.WriteLine("lat = " & lat)
   
    ' Sterndaten (zum Äquinoktium des Datums) = konstant
    ' am Beispiel Beteigeuze
    Dim RA As Double = (5 + 55/60 + 10.35/3600) * 15
    Dim DEC As Double = +(7 + 24/60 + 25.7/3600)
    Console.WriteLine("RAobj = " & RA)
    Console.WriteLine("DECobj = " & DEC)
   
    Dim Δsecs As Integer = 5
   
    ' Zeitpunkt
    Dim JD1 As Double = GetJD(2024, 10, 22, 0, 0, 0)
    Console.WriteLine("JD1 = " & JD1)
    Console.WriteLine("Δsecs = " & Δsecs)
   
    ' Zeitpunkt eine Sekunde später
    Dim JD2 As Double = GetJD(2024, 10, 22, 0, 0, 0+Δsecs)
    Console.WriteLine("JD2 = " & JD2)
   
    ' Sternzeit in Greenwich in GRAD
    ' Für Zeitpunkt UND 1 Sekunde danach
    Dim gwst1 As Double = getSiderialTime(JD1)
    Dim gwst2 As Double = getSiderialTime(JD2)
    Console.WriteLine("gwst1 = " & gwst1)
    Console.WriteLine("gwst2 = " & gwst2)
    Console.WriteLine("gwst1 h = " & gwst1 / 15)
    Console.WriteLine("gwst2 h = " & gwst2 / 15)
   
    ' Ortssternzeit
    Dim lmst1 As Double = gwst1 - lon
    Dim lmst2 As Double = gwst2 - lon
    Console.WriteLine("lmst1 °= " & lmst1)
    Console.WriteLine("lmst2 °= " & lmst2)
    Console.WriteLine("lmst1 h= " & lmst1 / 15)
    Console.WriteLine("lmst2 h= " & lmst2 / 15)
   
    ' Stundenwinkel des Objekts
    Dim theta1 As Double = lmst1 - RA
    Dim theta2 As Double = lmst2 - RA
    Console.WriteLine("theta1 = " & theta1)
    Console.WriteLine("theta2 = " & theta2)
   
    ' Alle Winkel in RAD umrechnen
    lat *= DEGS
    lon *= DEGS
    DEC *= DEGS
    theta1 *= DEGS
    theta2 *= DEGS
    Console.WriteLine("lon = " & lon)
    Console.WriteLine("lat = " & lat)
    Console.WriteLine("DEC = " & DEC)
    Console.WriteLine("theta1 = " & theta1)
   
    ' Höhe
    Dim h1 As Double = Math.Asin(Math.Sin(lat) * Math.Sin(DEC) + Math.Cos(lat) * Math.Cos(DEC) * Math.Cos(theta1))/DEGS
    Dim h2 As Double = Math.Asin(Math.Sin(lat) * Math.Sin(DEC) + Math.Cos(lat) * Math.Cos(DEC) * Math.Cos(theta2))/DEGS
    Console.WriteLine("h1 = " & h1)
    Console.WriteLine("h2 = " & h2)
   
    ' Azimut (von Südpunkt)
    Dim az1 As Double = Math.Atan2(Math.Sin(theta1), Math.Cos(theta1) * Math.Sin(lat) - Math.Tan(DEC) * Math.Cos(lat))/DEGS
    Dim az2 As Double = Math.Atan2(Math.Sin(theta2), Math.Cos(theta2) * Math.Sin(lat) - Math.Tan(DEC) * Math.Cos(lat))/DEGS
    Console.WriteLine("az1 = " & az1)
    Console.WriteLine("az2 = " & az2)
   
    ' Differenzwerte für Höhe und Azimut
    Dim Δh As Double = h2 - h1
    Dim Δaz As Double = az2 - az1
    Console.WriteLine("Δh° = " & Δh)
    Console.WriteLine("Δh'' = " & Δh*3600)
    Console.WriteLine("Δaz° = " & Δaz)
    Console.WriteLine("Δaz'' = " & Δaz*3600)
   
   
  End Sub
End Module

Natürlich sollte man die konstanten Daten wie die Objektkoordinaten oder den Beobachtungsort als Paramter übergeben. Wie oft die Funktion dann aufgerufen werden muss hängt vom Parameter Δsecs ab. Wie die Daten dann weiter verwurstet werden (können) entzieht sich meiner Kenntnis.
Hab's gecheckt, dass du mit "Unit-Tests" einen Modul-Test meinst. Ich hab den obigen Code mit VS Code geschrieben, aber nur online hier getestet (Copy/Paste).

cs,
harald

--

 

[AstroPZ]

Hi Harald,

danke für dein Script.

Tja, jetzt muss ich nur die Zeit und Motivation finden, das in Java umzusetzen.
Java ist bei mir gesetzt, da einiges an Erfahrung da ist und es noch einige andere Vorteile gibt.

Ich hoffe ich komme mal dazu.

Das wäre ja mit den bereits geposteten Scripten möglich. Man müsste halt das VB-Script in ein Modul packen. Als Input die Zeit, der Beobachtungsort und die Objektdaten (Ra/Dec). Die Az/h Berechnung muss dann 2mal gemacht werden, für die "Echtzeit" und für diesen Zeitpunkt plus x Sekunden. Aus der Differenz dieser beiden Daten erhält man die "Geschwindigkeit" und auch deren Richtung. Das müsste doch machbar sein? Soweit die Theorie. (Grau ist alle Theorie, aber schwarz seh'n wir erst in der Praxis.)

Ja, genau das war ja auch mein Vorschlag.
Man könnte natürlich auch die Ableitung nach der Zeit der Berechnungsformeln machen. Aber ich muss sagen, obwohl ich so etwas im Studium gelernt habe ist mir das im Moment zu "komplex".

Ich weiß aber nicht, welche Hardware Stolpersteine hier noch liegen. Soweit ich das Gelesene verstanden habe werden die Berechnungen ja an einem Laptop gemacht (JAVA... oder whatever) und die Daten dann an die Steuereinheit verwurstet, wie auch immer dieser Vorgang genau passieren mag.

Bei mir ist es relativ einfach. Der Arduino steuert die Schrittmotoren und der bekommt nur einfache Schrittmotor Befehle vom Java Programm auf dem PC.
Das Java Programm macht die ganzen astronomischen und sonstigen Umrechnungen.

Hm, bitte um Erklärung, was mit "Unit-Tests" gemeint ist.

Welche "Korrekten Daten" sind hier gemeint? Die Ra/Dec des Objekts?

Nur zur Erklärung: Mit Unit Tests teste ich, wenn ich nicht zu faul bin , meinen Java-Code, automatisch.
Unit-Tests sind automatische Tests und sind bei Java sehr schön in Eclipse unterstützt.
Im Prinzip benötigt man Ausgangsdaten und die dazu passenden, korrekten Ergebnisdaten aus dem getesteten Programmteil.
Die Ausgangsdaten wären hier Ort, Zeit, Koordinaten. Das Ergebnis wäre Alt und AZ.
Alt und AZ würde ich einfach aus Stellarium für die gewählten Ausgangsdaten nehmen.

Gruß
Peter

 

[h_c_greier]

Hier mal JAVA, nicht perfekt, aber funktioniert:

import java.lang.Math;

public class Program {

    // JD berechnen im Zeitraum 1.3.1900 - 28.2.2100
    public static double getJD(int yrs, int mth, double dys, double hrs, double mins, double secs) {
        if (mth <= 2) {
            yrs -= 1;
            mth += 12;
        }
        dys += (hrs + mins/60 + secs/3600)/24;
        return Math.floor(365.25*(yrs + 4716)) + Math.floor(30.6001*(mth + 1)) + dys - 1537.5;
    }

    public static double getSiderialTime(double jd) {
        double T = (jd - 2451545.0)/36525;
        double theta = 280.46061837 + 360.98564736629*(jd - 2451545.0) + 0.000387933*T*T - (T*T*T)/38710000;
        return theta % 360;
    }

    public static void main(String[] args) {
        final double DEGS = Math.PI/180;

        // Standortdaten = konstant
        double lon = -10.0; // Ost negativ, West positiv
        double lat = 50.0;
        System.out.println("lon = " + lon);
        System.out.println("lat = " + lat);

        // Sterndaten (zum Aequinoktium des Datums) = konstant
        // Beispiel: Beteigeuze
        double RA = (5 + 55/60.0 + 10.35/3600)*15;
        double DEC = +(7 + 24/60.0 + 25.7/3600);
        System.out.println("RAobj = " + RA);
        System.out.println("DECobj = " + DEC);

        int deltaSecs = 5;

        // Zeitpunkt
        double JD1 = getJD(2024, 10, 22, 0, 0, 0);
        System.out.println("JD1 = " + JD1);
        System.out.println("deltasecs = " + deltaSecs);

        // Zeitpunkt eine Sekunde spaeter
        double JD2 = getJD(2024, 10, 22, 0, 0, deltaSecs);
        System.out.println("JD2 = " + JD2);

        // Sternzeit in Greenwich in GRAD
        double gwst1 = getSiderialTime(JD1);
        double gwst2 = getSiderialTime(JD2);
        System.out.println("gwst1 Grad = " + gwst1);
        System.out.println("gwst2 Grad = " + gwst2);
        System.out.println("gwst1 Stunden = " + gwst1/15);
        System.out.println("gwst2 Stunden = " + gwst2/15);

        // Ortssternzeit
        double lmst1 = gwst1 - lon;
        double lmst2 = gwst2 - lon;
        System.out.println("lmst1 Grad= " + lmst1);
        System.out.println("lmst2 Grad= " + lmst2);
        System.out.println("lmst1 Stunden = " + lmst1/15);
        System.out.println("lmst2 Stunden = " + lmst2/15);

        // Stundenwinkel des Objekts
        double theta1 = lmst1 - RA;
        double theta2 = lmst2 - RA;
        System.out.println("theta1 = " + theta1);
        System.out.println("theta2 = " + theta2);

        // Alle Winkel in RAD umrechnen
        lat *= DEGS;
        lon *= DEGS;
        DEC *= DEGS;
        theta1 *= DEGS;
        theta2 *= DEGS;
        System.out.println("lon = " + lon);
        System.out.println("lat = " + lat);
        System.out.println("DEC = " + DEC);
        System.out.println("theta1 = " + theta1);

        // Hoehe
        double h1 = Math.asin(Math.sin(lat)*Math.sin(DEC) + Math.cos(lat)*Math.cos(DEC)*Math.cos(theta1))/DEGS;
        double h2 = Math.asin(Math.sin(lat)*Math.sin(DEC) + Math.cos(lat)*Math.cos(DEC)*Math.cos(theta2))/DEGS;
        System.out.println("h1 = " + h1);
        System.out.println("h2 = " + h2);

        // Azimut (von Suedpunkt)
        double az1 = Math.atan2(Math.sin(theta1), Math.cos(theta1)*Math.sin(lat) - Math.tan(DEC)*Math.cos(lat))/DEGS;
        double az2 = Math.atan2(Math.sin(theta2), Math.cos(theta2)*Math.sin(lat) - Math.tan(DEC)*Math.cos(lat))/DEGS;
        System.out.println("az1 = " + az1);
        System.out.println("az2 = " + az2);

        // Differenzwerte fuer Hoehe und Azimut
        double deltaH = h2 - h1;
        double deltaAz = az2 - az1;
        System.out.println("deltah grad = " + deltaH);
        System.out.println("deltah arcsec = " + deltaH*3600);
        System.out.println("deltaaz grad = " + deltaAz);
        System.out.println("deltaaz arcsec = " + deltaAz*3600);
    }
}

cs,
harald

--

 

[AstroPZ]

Hi harald,

danke schön. Das ist aber nett.

Das muss ich jetzt wohl ausprobieren und testen.

Gruß
Peter

 

[h_c_greier]

Das muss ich jetzt wohl ausprobieren und testen.

Und zwar flott, wenn's geht! Hurtig!
Möchte wissen, ob das verdammte Ding funktioniert!

cs,
harald

--

 

[AstroPZ]

Hi Harald,

super Arbeit!

Hat gleich funktioniert und du hast alles sehr schön dokumentiert.

Werde ich erst mal ein paar JUnit Tests schreiben, damit man auch gut "Refactor'n" kann.

Vielen Dank, damit bin ich defintiv einen grossen Schritt weiter mit meinem Langzeitprojekt, meine Dobsons nachführtauglich zu machen.
Der 12 Zöller ist ja schon mit Schrittmotoren ausgestattet. Da werde ich zuerst dran gehen.


Gruß
Peter