Berechnungs fehler bei Horizonthöhe und Azimut.

Status
Es sind keine weiteren Antworten möglich.

Olaf_Geistert

Aktives Mitglied
Hallo folk's <img src="/phpapps/ubbthreads/images/icons/crazy.gif" alt="" />
weiß einer von euch was ich falsch mache.
Ich habe ein kleines PC Programm geschrieben nach dem Buch von Montenbruck/Pfleger, es ist auch alles I.O.
Sternenzeit ,Stundenwinkel und so die Daten habe ich mit den Programm AstroWin überprüft.
Jetzt möchte ich aber noch den Aktuellen Azimut und Horizonthöhe mit berechnen und da bekomme ich jedesmal falsche Winkelwerte raus ??????

Formel nach Montenbruck/Pfleger
sinH = sin(phi)*sin(Dek)+cos(phi)*cos(Dec)*cos(tau)
phi =>Breitegrad*Rad
Dek =>Deklination*Rad
tau =>Stundenwinkel*Rad

Kennt einer eine andere Formel um ans richtige Ziel zu kommen, oder was mach ich falsch
Grüße Olaf. <img src="/phpapps/ubbthreads/images/icons/confused.gif" alt="" />
 
Hallo Olaf,

hast du bedacht, dass der Stundenwinkel (Sternzeit - Rektaszension) vom Zeitmaß (24 Stunden) ins Winkelmaß (360 Grad bzw. 2*pi rad) umzurechnen ist?

Viele Grüße,
Thomas Pfleger
 
Hi Thomas,
danke erst mal, ja ich habe den Stundenwinkel in Winkelmaß umgerechnet da kam aber erst recht sch... Zahlen raus .
Und im Buch steht auch nichts beschrieben das ich den Stundenwinkel in Grad angeben soll.
tau = GMST(MjdUT)+ Lambda - RA // Stundenwinkel in Rad
und unter Borland C++ wird der cos. wert so oder so nur in Rad ausgegeben.
Grüße Olaf <img src="/phpapps/ubbthreads/images/icons/confused.gif" alt="" /> .
 
Hallo Olaf,

vielleicht haben wir ein Missverständnis: nicht nur bei Borland wird das Argument der Winkelfunktionen immer in rad angegeben. Eigentlich ist das überall so. Du rufst eine Winkelfunktion also *nie* mit einem Argument in Grad oder Stunden auf.

Aber: wenn du einen Stundenwinkel von z.B. 18h hast, dann musst du den mit einem Faktor 15 *pi/180 = pi/12 ins Bogenmaß umrechnen. Die 15 steht da, weil 24h eben 360 Grad entsprechen. Und mit pi/180 kommst du von Grad zu rad.

Wird der Winkel nicht im Zeitmaß angegeben (wie bei Deklination, Höhe oder Azimut) sondern in Grad, dann kommt da natürlich keine 15 dran.

Wenn du mit C++ arbeitest kann du die Funktion EquHor() aus der "Astronomie mit dem PC" benutzen. Im Kapitel über Auf- und Untergangsrechnung ist auch ein Rechenbeispiel im Text, an dem du dich orientieren kannst.

Gruß,
Tom
 
HI Thomas,
ja ich rechne alles erst in sec/Bruchteile um und dann * 360/86400sec so kommst du auf den genaue 16 stellen nach komma wert.
Also genau genommen ist jetzt der wert +- 10% Richtig jetzt muß ich nur mal mit einen Astrofreund der eine Goto steuerung hat vergleichen, hoffen wir auf besseres Wetter.
Danke noch mal olaf. <img src="/phpapps/ubbthreads/images/icons/smile.gif" alt="" />
 
Hallo Olaf, Hallo Tom,

Vielleicht kann ich auch helfen.

Ich schlage vor, daß wir ein typisches Beispiel stufenweise durcharbeiten, um den Fehler zu isolieren. Ich habe zahlreiche astronomische Software Anwendungen in C++ entwickelt und möglicherweise kann ich helfen.

Grüße,

Harrison
 
Hi Harrison ,
ja das können wir ein mal machen ,aber zu erst schreibe ich mal meine Formeln auf du kannst ja mal sehen ob du einen Fehler siehst.
Diese Formel ist für die Höhe in Grad°.
(Hoehe*Grad)=sin(((sinDec*Rad)*(sinBreit*Rad))+((cosDec*Rad)*(cosStdW*Rad)*(cosBreit*Rad)));
Diese Formel ist für den Azimut in Grad°.
(AZM*Grad)=tan((sinStdW*Rad)/(cosStdW*Rad)*(sinBreit*Rad)-(tanDec*Rad)*(cosBreit*Rad));

Rad=(PI/180);
Grad=(180/PI);
Danke in vorraus Olaf. <img src="/phpapps/ubbthreads/images/icons/crazy.gif" alt="" />
 
Hi Olaf,

Tja, du bist auf der richtigen Spur. <img src="/phpapps/ubbthreads/images/icons/smile.gif" alt="" /> Es gibt noch einige Pünkte.
Erstens du mußt die umgekehrten Funktionen asin und atan bei der Lösung der Gleichungen. Außerdem muß StdW schon in Winkelmaß (Grad) sein, wenn du gebrauchtst Rad als geschrieben. Ich würde die erste gleichung schreiben:

Hoehe = Grad*asin(sin(Dec*Rad)*sin(Breit*Rad)+cos(Dec*Rad)*cos(StdW*Rad)*cos(Breit*Rad));

Im Falle der zweiten Gleichung, du sollst die 2-Argument Funktion atan2 benutzen, um nicht in dem falschen Quadrant zu geraten. Also:

AZM = Grad*atan2(sin(StdW*Rad), (cos(StdW*Rad)*sin(Breit*Rad)-tan(Dec*Rad)*cos(Breit*Rad)));

Als ich habe oben erwähnt, StdW muß in Grad gegeben sein. Sonst, wenn StdW in Zeitmaß (Stunden) gegeben ist, kannst du schlechthin pi/12 statt Rad=pi/180 in den jeweiligen Termen gebrauchen.

Gruß,

Harrison



 
Hi Harrison,
also die Hoehe ist jetzt I.O, nur macht mir Azimut noch kein Spaß. Da ist noch ein großer fehler ,je nach wert kann ich von 360° oder 180° abziehen um an den richtigen wert zu kommen .
Zum Beispiel ist mein errechneter wert -78 , muß ich 360+(-78) rechnen um den richtigen wert zu haben, ist mein wert 78, muß ich 180 - 78 rechnen .
So bald aber wie bei IC 434 die Dec. sehr klein ist (-2°28'00'') stimmt der wert gleich ,das ist aber auch nicht bei jeden so.....
Grüße Olaf <img src="/phpapps/ubbthreads/images/icons/crazy.gif" alt="" />
 
Hallo Olaf,

Ja, in allen Rechnungen muß man unbedingt behutsam, jedes Vorzeichen zu betrachten und nicht zu ändern. Zum Beispiel, wenn ein Objekt liegt östlich von dem Meridian, sin(StdW*Rad) ist negativ, aber doch bleibt cos(StdW*Rad) positiv. Die Funktion atan2() ergibt Werte zwischen -pi und +pi; das heißt zwischen -180° und +180° nach Konversion. Wenn du wollst Werte zwischen 0° und 360°, kannst du die Zeile

while (Azm < 0.0) Azm += 360.0;

hinzufügen.

Kleine negative Dec. Werte können ein bischen heikel sein. Besonders bemerkungswert sind Fälle wie z.B. -0° 28' 01". Wenn man -0 als Nummer einstellt, diese Einstellung wird schlicht als 0 interpretiert, und ebenfalls werden die 28' und 01" als positiv Werte angenommen! Man muß jedenfalls Vorsorgen machen in seinem Programm um diese Fehler zu vermeiden.

Grüße

Harrison
 
Re: Berechnungs fehler bei Horizonthöhe und Azimut

> nur macht mir Azimut noch kein Spaß. Da ist noch ein großer fehler ,je nach wert kann ich von 360°
> oder 180° abziehen um an den richtigen wert zu kommen .
> Zum Beispiel ist mein errechneter wert -78 , muß ich 360+(-78) rechnen um den richtigen wert zu
> haben,

Hier ist ja alles in Ordnung, und dein Ergebnis ist nicht falsch. Bitte beachte, dass
die Winkel sich nach 360° wiederholen, d.h. ein Winkel von z.B. 370° ist physikalisch und
mathematisch dasselbe wie ein Winkel von 10°. Wir können also nach Belieben zu jedem Winkel
360° (oder auch 720° oder 1080°...) addieren und bekommen wieder denselben Winkel,
der jetzt nur durch einen anderen Zahlenwert ausgedrückt ist. Ebenso dürfen wir von jedem
Winkel beliebige Vielfache von 360° abziehen.

Da es bequemer ist, mit Winkeln zwischen 0° und 360° zu arbeiten, macht man sich das gerne
zunutze und addiert oder subtrahiert so lange 360°, bis der Winkel in jenem Bereich liegt.

Übrigens hast du nicht den Winkel von 360° abgezogen (das wäre falsch), sondern (richtig) 360°
zum Winkel addiert, denn du hast ja gerechnet 360 + (-78).


> ist mein wert 78, muß ich 180 - 78 rechnen .

Dann bekommst du den Winkel im falschen Quadranten. Ich kopiere mal meine
Erklärung aus einem anderen Forum hier herein, wo es um einen ähnlichen
Fall ging. In deinem Fall mit dem Azimut geht es um eine etwas andere
Formel, das mit dem Arcustangens verbundene Problem ist aber dasselbe, so
dass du die Lösung leicht auf deinen Fall übertragen kannst:



> l=acos(cos(u)/cos(b))+Knotenlaenge=133.4627309 grad

Brööööp. Falscher Quadrant.

=====================================================================================

Exkurs: Winkelfunktionen und Quadranten.

Der volle Winkel von 360° läßt sich in vier Quadranten aufteilen:

I: 0.. 90°
II: 90..180°
III: 180..270°
IV: 270..360°

Die Winkelfunktionen sin, cos, tan (und andere) liefern jeweils
für Winkel aus zwei verschiedenen Quadranten dasselbe Ergebnis.
Beispiele:

cos(10°) = cos(350°)
sin(40°) = sin(140°)
tan(50°) = tan(230°) etc.

Konsequenz: bei der Ausführung der Umkehrfuktion gibt es stets
_zwei_ Winkel als Lösung. Die normalen Implementationen der
Winkelfunktionen liefern _einen_ davon, das kann aber gerade
der falsche sein. Der arcsin z.B. liefert standardmäßig Winkel
zwischen -90° und 90°, also aus dem I. und IV. Quadranten.
Wenn nun der Sinus des Winkels 150° gegeben ist und der Winkel
rekonstruiert werden soll, dann liefert der arcsin stattdessen
arcsin(0.5) = 30°.

Die Sinusse der Winkel aus dem I. und II. Quadranten haben
positives Vorzeichen, die Sinusse der Winkel aus dem III.
und IV. Quadranten haben negatives Vorzeichen. Ist ein positiver
Sinuswert gegeben, so stammen die beiden zugehörigen Winkel
also aus dem I. und II. Quadranten, aber es läßt sich nicht
entscheiden, welcher der richtige ist.
Entsprechend gehört zu negativen Sinuswerten je ein Winkel
aus dem III. und einer aus dem IV. Quadranten.

Die Cosinusse der Winkel aus dem I. und IV. Quadranten haben
positives Vorzeichen, die Cosinusse der Winkel aus dem II.
und III. Quadranten haben negatives Vorzeichen. Ist ein positiver
Cosinuswert gegeben, so stammen die beiden zugehörigen Winkel
also aus dem I. bzw. IV. Quadranten. Zu negativem Cosinuswert
gehören zwei Winkel aus dem II. bzw. III. Quadranten.

Der Sinuswert eines Winkels genügt also nicht, den Winkel eindeutig
zu rekonstruieren, es gibt stets zwei Lösungen; dasselbe gilt
für gegebene Cosinuswerte.

Ist aber sowohl der Sinus als auch der Cosinus eines Winkels
gegeben, dann läßt sich der gemeinte Winkel anhand der Vorzeichen
der gegebenen Werte eindeutig bestimmen.
Sei z.B. der Sinuswert negativ, der Cosinuswert positiv.
Negativer Sinus bedeutet: der Winkel stammt aus dem III. oder
IV. Quadranten; positiver Cosinuswert bedeutet: der Winkel
stammt aus dem I. oder IV. Quadranten. Insgesamt kann der Winkel
also nur aus dem IV. Quadranten stammen.

Übersicht: sin cos: Quadrant
+ + : I
+ - : II
- - : III
- + : IV

Anwendung: die Transformationsformeln aus den Bahnkoordinaten in
heliozentrische ekliptikale Koordinaten lauten:

cos(b) cos(L) = cos(u)
cos(b) sin(L) = sin(u) cos(i)
sin(b) = sin(u) sin(i)

l, b, r: heliozentrische ekliptikale Koordinaten
u, r : Bahnkoordinaten
K : aufsteigender Knoten,
L := l-K

Du hast nun die erste Gleichung genommen und umgestellt:

cos(L) = cos(u)/cos(b),

und kannst den Cosinuswert von L aus den bekannten u und b bestimmen.
Aber: es gibt zwei Winkel, die diesen Cosinuswert haben, und du
weißt nicht, welcher der richtige ist. Im Fall der Erde hat dir der
Arccos zielgerichtet den falschen der beiden möglichen Winkel
untergeschoben.

Glücklicherweise liefern dir die Transformationsformeln aber auch
den Sinus des Winkels und damit hinreichende Information, um den
Winkel eindeutig zu bestimmen:

sin(L) = sin(u) cos(i) / cos(b).

Im Prinzip könntest du jetzt sowohl für den Sinus- als auch für den
Cosinuswert jeweils die beiden möglichen Winkel bestimmen, und der
Winkel, der in beiden Fällen auftritt, ist der richtige.

In der Praxis geht man folgendermaßen vor: man merkt sich die
Vorzeichen von sin(L) und cos(L) und dividiert dann beide durch-
einander:

tan(L) = sin(L)/cos(L) = (sin(U) cos(i)/cos(b))/(cos(u)/cos(b))
= tan(u) cos(i).

Mit dem Arcustangens bestimmt man dann _einen_ Winkel, der diesen
Tangenswert hat:

L = arctan( tan(u) cos(i) )

und benutzt dann die gemerkte Information in den Vorzeichen, um
diesen Winkel in den richtigen Quadranten zu bringen. Das kann
man entweder so machen:

Sei A = sin(L) und B = cos(L). Berechne den Arcustangens von A/B
(das Ergebnis wird konventionellerweise zwischen -90° und +90°
ausgegeben) und addiere zum Ergebnis 180°, wenn B<0 (vgl. J. Meeus:
Astronomical Algorithms, Kap. 1).

Oder du benutzt die folgende "arctan2"-Prozedur, die alles
automatisch macht (vgl. Montenbruck/Pfleger: Astronomie mit
dem Personal Computer):

(*-------------------------------------------------------------------------*)
(* atn2: Arcustangens von y/x fuer zwei Argumente *)
(* (quadrantenrichtig mit -180° <= atn2 <= +180°) *)
(*--------------------------------------------------------------------MoPfl*)
function atn2(y, x: extended): extended;

const raddeg = 180/pi;
var ax, ay, phi: extended;

begin
if (x=0) and (y=0)
then atn2 := 0
else
begin
ax := abs(x); ay := abs(y);
if (ax>ay)
then phi := arctan(ay/ax) * raddeg
else phi := 90 - arctan(ax/ay) * raddeg;
if (x<0) then phi := 180-phi;
if (y<0) then phi := -phi;
atn2 := phi;
end
end;

Man beachte, daß der Sinus- und der Kosinuswert als _getrennte_ Parameter
übergeben werden. Würdest du sie vorher durcheinander dividieren, so ginge
die Information über die einzelnen Vorzeichen teilweise verloren (am Vor-
zeichen des Quotienten könnte man nur noch sehen, ob sie gleiche oder
verschiedene Vorzeichen hatten).

Jetzt haben wir L quadrantenrichtig bestimmt, und daraus kannst du
nun die Länge l berechnen.

Von b weißt du nur den Sinus:

sin(b) = sin(u) sin(i)

aber da b nur zwischen -90° und +90° liegen kann, gibt es hier keine
Zweideutigkeiten, und der Arcsin liefert den Winkel eh in diesem
Bereich, so daß man nichts mehr weiter tun muß.

Auf dieselbe Weise behandelt man auch andere sphärische Transformationen:
wenn der Winkel uneingeschränkt irgendwo zwischen 0..360° liegen kann, isoliert
man immer den Sinus und den Cosinus des gesuchten Winkels und bestimmt den
Winkel selbst quadrantenrichtig mit den beschriebenen Methoden.
Wenn der Winkel nur in einem eingeschränkten Bereich liegen kann, reicht
i.A. eine Winkelfunktion aus.

Im vorliegenden Fall ist A = sin(u) cos(i) und B = cos(u).
Arctan(A/B) liefert 46.537433°, und wegen B<0 müssen wir 180 addieren,
das liefert 226.53743°. Die heliozentrische Länge der Erde war zu
jenem Zeitpunkt also praktisch identisch mit der des Merkur. Wie
ich mich heute mittag selbst überzeugen konnte, entspricht dieses
Ergebnis den Tatsachen und die Rechnung ist offenbar richtig.

Exkurs Ende
=====================================================================================


Tschau,
Thomas
 
Re: Berechnungs fehler bei Horizonthöhe und Azimut

Hallo Tom,

Deine Bemerkungen stimmen. Dennoch liegt der wesentliche Punkt hier darin, daß wenn man in den falschen Quadranten mit der C++ 2-Argument Funktion atan2() geriet, wie in dem +78° Falle, handelt es sich höchstwahscheinlich um einem Vorzeichen Fehler. Diese Funktion löst die Gleichung w = arctan(n/d) und ist so angewendet:

w = atan2(n,d);

Sie normalerweise garantiert daß w liegt in dem richtigen Quadranten (wenn n und d richtig bewertet werden), obwohl der gegebene Wert liegt zwischen -pi und +pi. Selbstverständlich kann diese Wert leicht in Gradmaß konvertiert werden und zwischen 0° und 360° ausgedrückt, wie früher geschildert.

Gruß,

Harrison
 
Zuletzt von einem Moderator bearbeitet:
Re: Berechnungs fehler bei Horizonthöhe und Azimut

Hi Harrison und Thomas,
erst mal Danke ,ja jetzt kann ich den Fehler schon besser verstehen und mal sehen wie ich alles hin bekomme.
Ich habe aber auch schon viel unter google.de gesucht aber nichts gefunden, hat den jemmand einen guten Buch vorschlag auser Astro mit dem PC Mo/Pfl.
Grüße olaf. <img src="/phpapps/ubbthreads/images/icons/wink.gif" alt="" />
 
Re: Berechnungs fehler bei Horizonthöhe und Azimut

Hallo Olaf,
ich habe die Koordinatenumrechnung mal vor längerem im Rahmen der 2-Star-Alignment Methodik abgeleitet. Dabei habe ich den allgemeinen Fall mit schiefer Aufstellung behandelt. Bei exakt waagrechter und genordeter Aufstellung ergeben sich die oben genannten Formeln als Spezialfall.
Auch Montierungsfehler (nicht rechtwinklige Achsen,...) werden berücksichtigt. Das Ganze findet sich hier . (Solide mathematische Kenntnisse zu Vektorrechnung <img src="/phpapps/ubbthreads/images/icons/ooo.gif" alt="" /> und Trigonometrie <img src="/phpapps/ubbthreads/images/icons/smirk.gif" alt="" /> sind nicht von Nachteil, aber bitte nicht abschrecken lassen! <img src="/phpapps/ubbthreads/images/icons/grin.gif" alt="" /> )
Nebenbei: Seit kurzem habe ich auch eine sehr gute Abhandlung von R.Leifert über das Scheinerverfahren auf meine Homepage mit aufgenommen.

Trigonometrische Grüße
Karl-Heinz
 
Re: Berechnungs fehler bei Horizonthöhe und Azimut

Hallo Olaf,

Ich kann zwei hervorragende Bücher empfehlen von Jean Meeus. Leider sind sie wahrscheinlich nur in der englischen Sprache verfügbar. Das erste ist Astronomical Algorithms und das andere ist Astronomical Formulae for Calculators. Das zweite ist wesentlich eine verkürzte Version der erste, deshalb wenn du eines kaufst, Astronomical Algorithms ist vorzüglich. Der Verleger ist Willmann-Bell, Inc.. Jemand hat auch ein Buch Astronomie mit dem PC erwähnt. Ich habe dieses Buch nicht gesehen, aber es ist möglicherweise auch sehr gut. <img src="/phpapps/ubbthreads/images/icons/smile.gif" alt="" />

Viele Grüße,

Harrison
 
Re: Berechnungs fehler bei Horizonthöhe und Azimut

Hallo Karl-Heinz,

Danke für deine Bemerkungen. Ich habe deine Referat gesehen, und ich glaube daß das ein Bedeutender Beitrag ist. Viele dieselben Prinzipien können sogar bei Alt-Azimutalen Montierungen verwendet werden wie, zum Beispiel, bei Dobson Teleskopen, wenn es ein Computergesteurter Antrieb auf die beide Achsen gibt!

Gruß

Harrison
 
Re: Berechnungs fehler bei Horizonthöhe und Azimut

Hi Karl-Heinz und alle anderen <img src="/phpapps/ubbthreads/images/icons/crazy.gif" alt="" /> ,
danke für deine HP die ist ja echt gut, eigentlich brauche ich nur die Berechnung von Höhe und Azimut um das es in meinen Programm mir anzeigt ob das Objekt schon Aufgegangen oder schon Untergegangen ist, dazu reicht auch schon die Höhe alleine, aber jetzt überlege ich echt ob ich es nicht doch so nach 2 Sternen einordnen umschreibe .
Eine Frage ist das nicht das selbe Prinzip wie bei der Meade LXD55 steuerung ,wo sich die Gotosteuerung nach 2 Sternen ausrichtet.
Grüße Olaf. <img src="/phpapps/ubbthreads/images/icons/smile.gif" alt="" />
 
Re: Berechnungs fehler bei Horizonthöhe und Azimut

Hallo Olaf, Harrison und alle anderen,

genau für eine geplante Alt-Az Ansteuerung habe ich die Ableitung gemacht! Dazu habe ich auch schon die passende Schrittmotorsteuerung entwickelt (Mikroschritt, auch auf meiner Homepage). Den Alignment- und Transformationsalgorithmus habe ich derzeit noch nicht umgesetzt ("gut Ding will Weile haben <img src="/phpapps/ubbthreads/images/icons/cool.gif" alt="" /> ).
Mit dem 2-Star-Alignment arbeiten alle mir bekannten Methoden, die Unterschiede liegen vor allem in der bequemen Identifikation der beiden Referenzsterne (möglichst alles automatisch mit GPS, Kompass, Motivklingel etc; damit der unbedarfte Hobbyastronom nicht mehr die einzelnen Sterne kennen muss, sondern nur noch den Himmel zu finden braucht <img src="/phpapps/ubbthreads/images/icons/grin.gif" alt="" /> ). Aber wenn man die Referenzsterne kennt und deren Koordinaten (RA+Dec) irgendwie der Steuerung mitteilen kann, braucht weder die genaue Sternzeit noch Breiten- oder Längengrad zur Ausrichtung bekannt zu sein. Durch wenigstens ungefähre Kenntnis dieser Größen kann man aber auf fast beliebige (helle) Sterne zielen und das System identifizert sie anhand der relativen Winkeldistanz und der ungefähr erwarteten Position. Die Feinheiten der einzelnen Hersteller liegen aber weniger in technischen Möglichkeiten als in der jeweiligen Patentsituation begründet...

Ausgerichtete Grüße
Karl-Heinz
 
Re: Berechnungs fehler bei Horizonthöhe und Azimut

Hallo Karl-Heinz ,
ja gestern hatte ich mir mal richtig viel Zeit genommen und dein Programm 2-Star Alignment in ein C konsolen Programm anzuwenden und habe aber festgestellt das du am ende das selbe Problem hast wie ich auch .
Der 1 Quadrant 0....90° wird super gerechnet der 2 Quadrant 90°....180° geht auch einfach aber der 3 und 4 läst sich nicht einfach zuweisen, vielleicht habe ich ja auch ein Fehler gemacht.
Grüße Olaf.
 
Re: Berechnungs fehler bei Horizonthöhe und Azimut

Hallo Olaf,
ich hab's nicht extra erwähnt, aber es sollte klar sein, dass bei allen Azimut und RA Berechnungen (also überall dort, wo der gesamte 360° Winkelbereich eine Rolle spielt) die atan2()-Funktion zu verwenden ist. Bei Höhe und Deklination geht der Bereich von -90°...+90°, das wird von asin() eindeutug abgedeckt (oder alternativ bei der üblichen Darstellung in Kugelkoordinaten von 0...180° vom acos() ). Damit bist du all der Sorgen ledig <img src="/phpapps/ubbthreads/images/icons/smile.gif" alt="" />, die ich nie hatte!
Kleiner Trick am Rande: Überall, wo der volle Winkelbereich 0...360° herauskommen kann, wird in den Formeln mit Sicherheit auch der Arcustangens (oder eine ähnliche abgeleitete Funktion) auftauchen und der _muss_ natürlich als atan2() berechnet werden. Die Mathemtik ist da ziemlich schlau und weiß Bescheid <img src="/phpapps/ubbthreads/images/icons/cool.gif" alt="" /> - man muss es nur richtig umsetzen <img src="/phpapps/ubbthreads/images/icons/wink.gif" alt="" />.
Die atan2() Form löst nicht nur das Quadrantenproblem, sondern auch den Fall, dass das Ergebnis auch mal zufällig 90° lauten könnte, das wäre dann 90°=atan(1/0) <img src="/phpapps/ubbthreads/images/icons/shocked.gif" alt="" /> .
Zwischen mathematischen Formeln und programmiertechnischer Umsetzung liegen manchmal Welten - man sieht es den Formeln meist nicht an, dass Fallunterscheidungen zwischen Wertebereichen, Prüfungen (z.B. auf Division by Zero, Sqrt(x<0), log(x<eps), ...), kunstvolle Fehlerbehandlung, geschicktes Umgruppieren von Funktionsblöcken und trickreiche numerische Algorithmen zur Optimierung von Rundungsfehlern verwendet werden, wo in der Theorie eigentlich nur eine harmlose, schlichte Formel steht...

Numerische Grüße
Karl-Heinz
 
Re: Berechnungs fehler bei Horizonthöhe und Azimut

Hallo Karl-Heinz ,
also das ist mir schon bewußt das ich mit atan2 rechnen mußte ,aber dabei kamen bei manschen Gradzahlen werte bei 855° grad raus und einmal zugar bei M13 2344° ja ich weiß ich hatte nur 9 mal 360° abgezogen und ich hatte den richtigen wert gehabt .
Ich muß aber auch sagen unter Borland 6.0 C++Builder steht extra das die Funktion atan2 nicht so richtig einsetz bar ist ,wenn ich jetzt am Wochenende zeit habe suche ich mal diese Funktion atan2 über eine Formel her zu leiten und werde diese dann direkt einbauen.
Grüße olaf. <img src="/phpapps/ubbthreads/images/icons/crazy.gif" alt="" />
 
Re: Berechnungs fehler bei Horizonthöhe und Azimut

Hallo Olaf,
da gibt's nicht viel herzuleiten, du musst nur Bereichsunterscheidungen machen. Hier mal ein Beispiel:
<pre><font class="small">code:</font><hr>
double atan2(double y, double x) {
// returns an angle in the range 0<=a<2*Pi
double a, Pi=3.141592654;

if (x * x + y * y < 1E-20) return 0.0; // x,y too small
if (fabs(x) >= fabs(y)) {
a = atan(y/x);
if (x < 0) a+=Pi;
if ((y < 0) && (x > 0)) a+=2*Pi;
} else { // if abs(x)<abs(y)
a = Pi/2 - atan(x/y);
If (y < 0) a+=Pi;
}
return a;
} </pre><hr>
(ich hab's auf die Schnelle aus vorhandenem und ausgetesteten VBasic Code übersetzt und nicht mehr extra überprüft).
Voraussetzung ist dass atan() Werte im Bereich -Pi/2...+Pi/2 liefert, was alle mir bekannten Implementierungen auch machen.

doppeltgenaue Grüße
Karl-Heinz
 
Re: Berechnungs fehler bei Horizonthöhe und Azimut

Hallo Karl-Heinz,
ja ab heute furzt es I.O.
Ich habe es geschaft, die ersten Test zufolge rechnet er gegen über TheSky Astrosoftware +/- 1% mit dem kann ich leben .Ich möchte ja nur Höhe und Winkel anzeigen so das ich die Richtung habe .
Meine Steuerung ist ja Equatorial und wird über Dek. und Stundenwinkel gesteuert und der ist I.O.
Das einzige Problem was ich noch habe ,wie alles mit dem LX200 Protokoll furzt .
Grüße Olaf. <img src="/phpapps/ubbthreads/images/icons/smile.gif" alt="" /> <img src="/phpapps/ubbthreads/images/icons/confused.gif" alt="" /> <img src="/phpapps/ubbthreads/images/icons/blush.gif" alt="" /> <img src="/phpapps/ubbthreads/images/icons/laugh.gif" alt="" /> <img src="/phpapps/ubbthreads/images/icons/wink.gif" alt="" />
 
Status
Es sind keine weiteren Antworten möglich.
Zurück
Oben