Amateurfunk Forum - Archiv

Hallo,
aus Interresse versuche ich gerade alles nötige zu lernen, um die Bahn eines Sateliten zu berechnen. Am anfang, hab ich es mittels dem Tutorial von [url:3w3shhyj]http://www.dc9zp.homepage.t-online.de/page6.htm[/url:3w3shhyj] dc9zp probiert, was aber schon bei den ersten formeln fehlgeschlagen ist, auch wusste ich nicht woher ich keppler-daten bekommen sollte, und bei den armis will ich auch keine genauen informationen lassen .
Deswegen versuch ich gerade das ganze mittels Wikipedia zu lösen, die benutzen beim Beispiel das NORAD (TLE) Format wo ich auch schon diverse quellen gefunden habe.
Ich hab aber leider bei der formel für T (umlaufzeit) probleme. Entweder ich mach was falsch oder in Wikipdia steht was falsches drinnen.

[url:3w3shhyj]http://de.wikipedia.org/wiki/Satellitenbahnelement#Berechnungsbeispiel[/url:3w3shhyj]
[url:3w3shhyj]http://de.wikipedia.org/wiki/Mittlere_Bewegung#Umrechnungen[/url:3w3shhyj]

Ich habe dabei aus den NORAD-Datensatz die mittlere Bewegung n, in diesem Fall 15,74622749 d^-1

die formel lautet dabei (2*PI)/n :

mein Ergebnis wäre dann 0,399027977d, also 9,57667h, 574,60m oder 34.476,017s, bei wikipdia stehen aber aber 5.487,029 s.

Das ist ein unterschied im Faktor 6!

Wisst ihr was das Problem ist?

mfg. pointhi

NACHTRAG: mit einer anderen Formel funktoiniert es, 1440/n*60

[quote]... Deswegen versuch ich gerade das ganze mittels Wikipedia zu lösen, die benutzen beim Beispiel das NORAD (TLE) Format wo ich auch schon diverse quellen gefunden habe.
Ich hab aber leider bei der formel für T (umlaufzeit) probleme. Entweder ich mach was falsch oder in Wikipdia steht was falsches drinnen.
[url:o37hadsm]http://de.wikipedia.org/wiki/Satellitenbahnelement#Berechnungsbeispiel[/url:o37hadsm]
[url:o37hadsm]http://de.wikipedia.org/wiki/Mittlere_Bewegung#Umrechnungen[/url:o37hadsm]
Ich habe dabei aus den NORAD-Datensatz die mittlere Bewegung n, in diesem Fall 15,74622749 d^-1
die formel lautet dabei (2*PI)/n :
mein Ergebnis wäre dann 0,399027977d, also 9,57667h, 574,60m oder 34.476,017s, bei wikipdia stehen aber aber 5.487,029 s. Das ist ein unterschied im Faktor 6! ....[/quote]Das Problem ist eine kleine Schlamperei -- bei Wiki nicht ganz unüblich, man muß genau hinsehen (nicht Dein Fehler, sonder Wiki's). Deine 5487,029 sec als Umlaufzeit werden aus den Umläufen/Tag und den 86400 sec/Tag errechnet (PI*Daumen spielt da nicht mit rein ...). Ein Tag mit 86400 sec / 15,7..... ergibt 5487,029 sec/Umlauf. Die mittlere Bewegung in Radians bekommst Du dann per 2pi/Umlaufzeit in sec = 0.00114509.... = 1,15 *10e-3 rad/sec.

Laß Dich nicht durch inkonsistente Formelzeichen ins Boxhorn jagen. Die Dinger laufen auf einer Ellipse und es ist "normale" sphärische Trigonometrie, solange Du keine Störungsberechnung machst (Bahndrehung etc.).

73 Peter

Nachtrag: ich hatte das "gelöst" im Header überlesen, vielleicht nutzt es trotzdem. Schau auch mal bei :
.. http://de.wikipedia.org/wiki/Mittlere_Anomalie .. um deren Berechnung es dabei eigentlich geht.

ich hab da einfach die seite von dc9zp noch einmal nach der formel durchsucht , Das Projekt wird sicher nicht einfach werden, und ich brauch sicher noch jede menge hilfe dabei. Es geht nämlich um eine C++ Bibliotek für die Bahnberechnung die ich dann ins internett stellen will.

Der TLE-Datensatz wird bis auf einen kleine Bug schon richtig ausgelesen, die Ermittlung der Umlaufdaten funktioniert auch schon bis auf die exzentrische Anomalie.
Weißt du wie ich die Berechnen kann?, [url:3kbgs947]http://de.wikipedia.org/wiki/Kepler-Gleichung#Berechnung_der_exzentrischen_Anomalie[/url:3kbgs947]

Auch mit meinen mathematischen Kenntnissen weiß ich dass man die Gleichung nicht normla lösen kann, und numerische Lösungsansätze hab ich noch nie benutzt. Falls das Thema zu komplex sein sollte, warte ich einfach bis Freitag, und Frage meinen Mathelehrer darüber aus.

mfg. pointhi

So ungefähr (aus einer alten VB-Anwendung rauskopiert...):
[code:za12pv5z]
eccentricAnomaly = meanAnomaly //Startwert

Do
eccentricAnomalyOld = eccentricAnomaly //letztes E merken
eccentricAnomaly = meanAnomaly + eccentricity * Sin(eccentricAnomaly) //neues E berechnen
Loop Until Abs(eccentricAnomaly - eccentricAnomalyOld) < epsilon //solange bis Differenz < epsilon
[/code:za12pv5z]

Als epsilon wählte ich 0.0000001 Radians.

also die methode versuch und irrtum? . Kann mich dann da gleich in der erstellung rechenschonender algorithmen probieren.

mfg. pointhi

[quote]also die methode versuch und irrtum?[/quote]
Nein, [url=http://de.wikipedia.org/wiki/Iteration:yl1fjfb2]Iteration[/url:yl1fjfb2]. Mit "raten" hat das nichts zu tun.

Die o.g. Methode ist nur eine von vielen, um die Kepler-Gleichung zu lösen. Insbesondere ist sie für große Exzentrizitäten nicht gut geeignet. Als "universelle" Implementierung verwende ich beispielsweise:
[code:yl1fjfb2]
Public Sub MeanAnomToExAnom(ByVal meanAnomaly As Double, ByVal eccentricity As Double, ByRef eccentricAnomaly As Double, ByRef noConvergence As Boolean)
Const MAX_ITERATIONS As Long = 100
Const PERIHEL_SURROUND As Double = 30#

Dim eccentricAnomalyOld As Double
Dim diff As Double
Dim diffOld As Double
Dim alpha As Double
Dim beta As Double
Dim z As Double
Dim s0 As Double
Dim s As Double
Dim iterationsCounter As Long

If eccentricity < 0.25 Then
eccentricAnomaly = meanAnomaly

Do
eccentricAnomalyOld = eccentricAnomaly
eccentricAnomaly = meanAnomaly + eccentricity * Sin(eccentricAnomaly)
Loop Until Abs(eccentricAnomaly - eccentricAnomalyOld) < EPSILON_KEPLER
Else
If eccentricity > 0.975 Then
If meanAnomaly < PERIHEL_SURROUND * radian Or meanAnomaly > (ANG360 - PERIHEL_SURROUND) * radian Then
alpha = (1# - eccentricity) / (4# * eccentricity + 0.5)
beta = meanAnomaly / (8# * eccentricity + 1#)
z = CubeRoot(beta + Sgn(beta) * Sqr(beta * beta + alpha * alpha * alpha))
s0 = z - alpha / 2#
s = s0 - 0.078 * s0 * s0 * s0 * s0 * s0 / (1# + eccentricity)
eccentricAnomaly = meanAnomaly + eccentricity * (3# * s - 4# * s * s * s)
Else
eccentricAnomaly = meanAnomaly
End If
Else
eccentricAnomaly = meanAnomaly
End If

iterationsCounter = 0
diff = MAX_DOUBLE
noConvergence = False

Do
iterationsCounter = iterationsCounter + 1
diffOld = diff
diff = (meanAnomaly + eccentricity * Sin(eccentricAnomaly) - eccentricAnomaly) / _
(1# - eccentricity * Cos(eccentricAnomaly))
eccentricAnomaly = eccentricAnomaly + diff

If diff >= diffOld And iterationsCounter > MAX_ITERATIONS Then
noConvergence = True
End If
Loop Until Abs(diff) < EPSILON_KEPLER Or noConvergence
End If
End Sub
[/code:yl1fjfb2]

Ist natürlich ohne Kenntnis gewisser Hintergründe und Randbedingungen bzw. Programmvariablen nicht sehr aufschlussreich. Es verdeutlicht aber, dass die Lösung der Kepler-Gleichung nicht trivial ist.

Du kannst dich ja mal in diverse Fachliteratur einlesen.
Online z. B. hier: [url=http://books.google.de/books?id=VS69q_13w6YC&lpg=PA64&ots=P4nmI6b6Kc&dq=keplergleichung&hl=de&pg=PA61#v=onepage&q=keplergleichung&f=false:yl1fjfb2]Astronomie Mit Dem Personal Computer[/url:yl1fjfb2]. Oder auch mit dem "Meeus" (Astronomische Algorithmen).

Deine erste formel:

[code:6vtwpjwi] eccentricAnomaly = meanAnomaly //Startwert

Do
eccentricAnomalyOld = eccentricAnomaly //letztes E merken
eccentricAnomaly = meanAnomaly + eccentricity * Sin(eccentricAnomaly) //neues E berechnen
Loop Until Abs(eccentricAnomaly - eccentricAnomalyOld) < epsilon //solange bis Differenz < epsilon [/code:6vtwpjwi]

hat bei meiner interpretation:

[code:6vtwpjwi]ttu_dhelp = tuhse_umlbout->umlb_mano;
std::cout.precision(15);
do
{
ttu_dhelpold = ttu_dhelp;
ttu_dhelp = tuhse_umlbout->umlb_mano + tuhse_umlbout->umlb_exz * std::sin(ttu_dhelp*M_PI/180);
std::cout << ttu_dhelp << std::endl;
}
while((ttu_dhelp - ttu_dhelpold)<= 0.0000001);[/code:6vtwpjwi]

nur Fehler gemacht.

tuhse_umlbout->umlb_mano ist die Mittlere Anomalie Μ
tuhse_umlbout->umlb_exz ist die numerische Exzentrizität der Umlaufbahn.

Ich werd meinen Mathematikleherer mal deswegen fragen und versuchen das Newton Verfahren zu verstehen.
[url:6vtwpjwi]http://tmech.mechatronik.uni-linz.ac.at/staff/gerstmayr/gerstm_web/Kapitel34.pdf[/url:6vtwpjwi]

mfg. pointhi

Welche Fehler waren das denn?
Mir ist übrigens aufgefallen, dass du beim Prüfen der While-Bedingung nicht den Betrag der Differenz prüfst, sondern die Differenz direkt.

Abs(eccentricAnomaly - eccentricAnomalyOld)

Das Abs könnte das Problem sein. Ich behersche leider nur Visual Basic und das auch nicht besonders gut(c find ich einfach besser).

Der Fehler ist dass sich bei 0.0000001 das ergebniss von:

251,742760971732707 nach der ersten berechnung
auf:
251,742760975785814 und dann auf
251,742760975785785 feststeckt.

Es kommt am schluss also eine endlosschleife mit:

251,742760975785785
251,742760975785785
251,742760975785785
251,742760975785785
251,742760975785785
...

Das ist das Problem.

Der Datensatz den ich berechne ist der von der ISS aus dem jahre 2006, der in Wikipedia ist.

Ich hab das ganze noch einmal in Excel geschrieben. Wenn die numerische Exzentrizität der Umlaufbahn ε positiv ist enfernt sich der wert immer mehr vom gewollten ergebniss, wenn ich die exzentritität aber negativ mache komm ich aber nach etwa 150 Berechnungen zum ungefähren ergebnis von 251,695683

mfg. pointhi

[quote]Das Abs könnte das Problem sein.[/quote]Das Abs muss auf jeden Fall mit rein. Ansonsten hast du statistisch gesehen bei jedem zweiten Aufruf der Funktion Murks.

[quote]c find ich einfach besser[/quote]Naja, warum nicht was moderneres? Java oder C# z. B.

Und zum Problem mit dem 251,742760975785785: Schon der erste Iterationsschritt liefert einen Differenzbetrag, der kleiner ist als der von dir gewählte Wert 0.0000001, nämlich 0.000000004053106. Demnach kann die Schleife schon nach dem ersten Schritt abgebrochen werden.

Unabhängig davon kann es aber passieren, insbesondere bei hohen Exzentrizitäten, dass die Iteration nicht konvergiert. Z. B. wenn letzter und vorletzter Wert oszillieren und munter ihre Vorzeichen wechseln. Das muss das Boot dann abkönnen, sprich die Implementierung muss das erkennen und ggf. etwas anderes versuchen (anderer Algorithmus, anderer Startwert, ...).

Jetzt erst gesehen:
[quote]Wenn die numerische Exzentrizität der Umlaufbahn ε positiv ist enfernt sich der wert immer mehr vom gewollten ergebniss, wenn ich die exzentritität aber negativ mache komm ich aber nach etwa 150 Berechnungen zum ungefähren ergebnis von 251,695683[/quote]
Auf welchen Quellentext beziehst du dich eigentlich? Ich frage deshalb, weil üblicherweise die numerische Exzentrizität nicht mit ε, sondern mit e abgekürzt wird. Und sie kann auch niemals negativ sein.

Das mit den Alternativen formeln werde ich nachher sowieso machen müssen. Aber jetzt geht es erstmal darum das diese eine Formel funktioniert

Ich hab die formel so verändert:

[code:2o66ox8s]ttu_dhelp = tuhse_umlbout->umlb_mano;
std::cout.precision(15);
do
{
ttu_dhelpold = ttu_dhelp;
ttu_dhelp = tuhse_umlbout->umlb_mano + tuhse_umlbout->umlb_exz * std::sin(ttu_dhelp*M_PI/180);
std::cout << ttu_dhelp << std::endl;
}
while(std::abs(ttu_dhelp - ttu_dhelpold)< 0.0000001);

tuhse_umlbout->umlb_exano = ttu_dhelp;[/code:2o66ox8s]

[quote]//solange bis Differenz < epsilon [/quote]

aber müsste ich nicht ein > reinschreiben? die While wird ja solange ausgeführt bis sie 0 ist. Das wäre schon gegeben wenn die diferenz 0.00000011 wäre. Anders gesagt, sie würde sofort abgebrochen wenn die diferenz größer als epsilon ist.

Und C# behersche ich auch , nur diese Bibliotek soll in ANSI C++ geschrieben sein und nur die standardbibliotek verwenden, damit man sie auch in Linux, Mac, "Handy",... verwenden kann, solange das Programm in C++ geschrieben ist.
Die Bibliotek soll sozusagen später eine Erleichterung darstellen damit man das Rad nicht immer neu erfinden muss und sich gleich aufs wesentliche konzentrieren kann. Und für mich ist die Bibliotek eine gute Übung für Mathe und Programmieren. Ist ja komplett OOP gehalten.

mfg. pointhi

[quote][quote]//solange bis Differenz < epsilon [/quote]
aber müsste ich nicht ein > reinschreiben? die While wird ja solange ausgeführt bis sie 0 ist. Das wäre schon gegeben wenn die diferenz 0.00000011 wäre. Anders gesagt, sie würde sofort abgebrochen wenn die diferenz größer als epsilon ist.[/quote]. Ja: > und nicht <, weil du aus "meiner" Loop Until- eine While-Schleife gemacht hast. Da dreht sich natürlich die boolesche Logik um.

ich hab mich auf meinem quelltext bezogen, bzw. auf die interprettation von ihrem, epsilon hab ich von wikipedia übernommen (numerische Exzentrizität: \epsilon = 0,0008835)
[url]
http://de.wikipedia.org/wiki/Satelliten ... d_Position[/url]

Nachtrag:

meine Formel ist jetzt:
[code:36seafsg]
ttu_dhelp = tuhse_umlbout->umlb_mano;
std::cout.precision(15);
do
{
ttu_dhelpold = ttu_dhelp;
ttu_dhelp = tuhse_umlbout->umlb_mano + tuhse_umlbout->umlb_exz * std::sin(ttu_dhelp*M_PI/180);
std::cout << ttu_dhelp << std::endl;
}
while(std::abs(ttu_dhelp - ttu_dhelpold)> 0.0000001);

tuhse_umlbout->umlb_exano = ttu_dhelp;[/code:36seafsg]

Sie macht 2 durchläufe:

251.742760971732707
251.742760975785814

immer noch zu weit vom "erwünschten "ergebniss entfernt

mfg. pointhi

Nimmst du denn auch sämtliche Winkel im Bogenmaß? Z. B. wird ja zu tuhse_umlbout->umlb_mano in der Schleife immer aufaddiert.

--
Gerade mit meiner Funktion getestet: Nach 3 Schleifendurchläufen komme ich zum Ergebnis 251,695540539908.