komisches Verhalten mit azimut()

[Uwe!]

das Delta von 5 passt recht gut zu meinen Beobachtungen. Und ja, das Delta schwankt sehr stark über den Tagesverlauf. Abends nahe 0, morgens die 5°

[enertegus]

@Michi: Wir hatten das Thema schon mal (Stichwort Updatefrequenz des Wertes)... Ja, der EIBPC errechnet den Wert meine ich nur alle 5 Minuten, aber das macht m.E. in der Nacht keine +5 als Unschärfe.

Ich hatte das damals einfach in die Entwicklung eingespeist. Nach welchem Algorithmus genau berechnet wird, weiß ich gerade auch nicht, gehe aber davon aus, dass es stimmt.
Die Sache mit dem Zeitraster stimmt zwar, könnte jedoch auch ein Gradraster sein - dann wäre die Abweichung zumindest nicht konstant, da der cos z.b. bei O° den minimalen Gradienten aufweist, und das könnte dann die Erklärung sein.

[Uwe!]

Michael,

noch mal langsam für mich zum mitschreiben....

Heißt das jetzt aus Deiner Sicht ist alles in Ordnung und das bleibt so????

Eine Genauigkeit auf drei Stellen nach dem Komme hift hier sicher niemandem weiter, aber ob die Sonne grad bei 0° oder -5° Elevation ist, ist doch schon ein Unterschied, den man wissen sollte, oder?

Uwe

[Sandman60]

Du meinst den Azimut, nicht die Elevation, oder? Die Elevation passt doch, oder?
Cheers, Oliver

[Uwe!]

äähm nö! Hab mich zwar am Anfang des Themas leider damit vertan, aber ich meine Elevation! Den Höhenwinkel der Sonne.

[Sandman60]

Hmmm. Elevation passt bei mir exakt zu dem, was die Wetterstation liefert. Bei mir läuft aber der Azimut gegen Abend weg und in der früh wieder langsam zur Richtung der Wetterstation.

[Uwe!]

ok. Azimut prüf ich bei mir nicht, weil ich derzeit keine Verwendung dafür habe.

Kannst Du Deine Werte mal mit denen von hier vergleichen:
Einfache Formeln für Berechnung von Sonnen-, Mondposition und Mondphase in JavaScript

Vielleicht liegt bei Dir ja auch die Wetterstation daneben?

Elevation weicht bei mir aktuell zwichen -2,3° (20:00) und +1.4° (6:00) ab. Erscheitn nciht gigantisch viel sind aber in Summe über 20 Minuten daneben. Das macht bei der Frage wann es dunkel ist enorm viel aus.
An dem 5-Minuten-Berechnungs-Rhythmus liegt es nicht. 5 Min machen nur ca. 0,4° aus. Die Schwankungsbreite ist aber 3,8°.

Werd den EibPC mal so programmieren, dass er alle 15 Min einen Wert ausgibt. Derzeit prüf ich immer nur "bei Gelegenheit" über den Webserver.

[Tessi]

Werd den EibPC mal so programmieren, dass er alle 15 Min einen Wert ausgibt.

Warum nicht einfach immer dann, wenn der EibPC selbst den Wert aktualisiert? Sind doch nur drei mal so viele Werte und im Bereich der Dämmerung wären mir 15 Minuten deutlich zu grob aufgelöst...

[Uwe!]

ich kann auch alle 5 Min.
Um die Abweichungen zu veranschaulichen würden die 15 Min aber locker reichen.

[Uwe!]

aus der "manuellen" Mitschrift, also ab und an Ablesen vom Webserver, ergibt sich folgendes Bild:

[bmx]

Moin zusammen,

@Uwe!: Welche Formel nutzt Du denn zur Berechnung? Quellenangabe?

@enertex: Wenn es kein Staatsgeheimnis ist, warum postet ihr nicht einfach den Quelltext von azimuth und elevation?

@all: Warum geht nicht mal einer dabei und implementiert einen alternativen Algorithmus im EibPC?

Gruß,
Bernd

[Uwe!]

@Uwe!:

Sorry, hatte ich vergessen:
Einfache Formeln für Berechnung von Sonnen-, Mondposition und Mondphase in JavaScript

@all:

Ja, hab ich auch schon überlegt. Die Formeln dazu sind zwar nicht ganz leichte Kost, aber ganz gut dokumentiert. Da fehlt bisher nur die Zeit.
Außerdem erwarte ich (ich glaube zu Recht), dass eingebaute Funktionen korrekte Werte liefern. Ich kann ja nciht jeden Befehl noch mal als Makro nachbauen...

[enertegus]

@enertex: Wenn es kein Staatsgeheimnis ist, warum postet ihr nicht einfach den Quelltext von azimuth und elevation?

Das leiher ich mal an, wenn ich wieder im Büro bin, also nicht vor morgen.

[enertegus]

Außerdem erwarte ich (ich glaube zu Recht), dass eingebaute Funktionen korrekte Werte liefern. Ich kann ja nciht jeden Befehl noch mal als Makro nachbauen...

Seh ich auch so. Was nun nicht korrekt, Rundungen und Fehler dabei betrifft muss geklärt werden.

[Tessi]

@all: Warum geht nicht mal einer dabei und implementiert einen alternativen Algorithmus im EibPC?

Nun, zum einen will man ja das Rad nicht immer wieder noch mal neu erfinden. Dann ist der Algorithmus ja so trivial auch nicht und es kostet einiges an Zeit ihn zu implementieren und wahrscheinlich noch mehr Zeit, ihn zu debuggen. Hinzu kommt, das an einigen Stellen explizit darauf hingewiesen wird, das man genaue Ergebnisse nur bekommt, wenn man mit entsprechend hoher Genauigkeit rechnet und Taschenrechner mit "nur" 8 signifikante Stellen wurden dort als nicht ausreichend angesehen! (siehe z. B. "Sonnenstand", Abschnitt "Rechenbeispiel", Zitat "Die Rechnungen sind mit einer ausreichenden Stellenzahl zu führen (z.B. doppelter Genauigkeit, bei achtstelligen Taschenrechnern ist Vorsicht geboten...")
Und dann soll man den EibPC das mit f32 rechnen lassen? Da bekommt man dann sicherlich andere Werte, aber genau so sicher sind die auch nicht genauer.
Falls die integrierte Funktion des EibPCs tatsächlich mit f32 arbeitet, sind die Abweichungen verständlich - und möglicherweise auch nicht kleiner zubekommen. Falls...
Aber auch ich empfinde diese Abweichungen absolut betrachtet als zu groß und gehe davon aus, das intern auch ein EibPC mit deutlich höherer Genauigkeit als f32 rechnen kann.
<Tagtraum=an> Da fände ich es wünschenswert, wenn der EibPC für Rechnungen, die derartig hohe Genauigkeit benötigen um noch sinnvoll verwendbare Ergebnisse zu liefern, auch f64 anbieten würde... </Tagtraum>