Hallo, nur fürs Google Archiv, anbei sehr gut aproximierter Code (2min) für die Berechnung dieser beiden Größen für einen beliebigen Ort und Tag des Jahres. Verifiziert mit professionellen Berechnungen, die erheblich komplexer sind: http://lexikon.astronomie.info/java/sunmoon/ Eingabe: Breite, Länge, Zeiger auf RTC Struct Ausgabe: Struct mit den entsprechenden Zeiten im Ganzahlen und Fliesskommaformat
Warum verwendest Du double? Mit der von Dir genutzten Sekundenauflösung passt die Zeit problemlos in einen uint32_t, und mit dem rechnet ein µC doch deutlich einfacher (deutlich geringere Codegröße und deutlich höhere Geschwindigkeit).
Hallo, Vielleicht war es für AVR geschrieben: https://gcc.gnu.org/wiki/avr-gcc >Deviations from the Standard >double >double is only 32 bits wide and implemented in the same way as float Ein so große Rolle wird die Geschwindigkeit bei der Berechnung nicht spielen. Eventuell sollte man die Sommerzeitstart/ende Konstante anpassen. // Sommerzeiten 2000 - 2019, Beginnend im März, endend im Oktober
@ Christian J. (hobel) : Danke für die Routinen, sowas kann ich gelegentlich ganz gut brauchen. @ Horst Hahn (horha) : Rufus Τ. Firefly meinte damit, dass man die Berechnungen auch mit Integer-Arithmetik machen könnte (und zwar vorzugsweise mit 32 bit breiten Integers), um den Zeit- und vor allem Speicheraufwand mit Float-Berechnungen zu vermeiden. Dass beim AVR ein double 32 bit breit ist, bedeutet nicht, dass es ein Integer ist.
Rufus Τ. F. schrieb: > Warum verwendest Du double? double ist als float bei mir in der IDE definiert. Gewohnheit.... und bei einem 180 Mhz STM32 spielt es keine Rolle, wieviele Mikrosekunden diese Routinen brauchen. Sie wurden von mir auch direkt auf einem LPC2368 geschrieben und nach STM32 grad übernommen, werden 1 x pro Tag berechnet. Im Header ist noch ein Fehler durch die Autoergänzung des ifdef aber man muss das alle sowieso anpassen ans eigene Projekt.
Horst H. schrieb: > Eventuell sollte man die Sommerzeitstart/ende Konstante anpassen. > // Sommerzeiten 2000 - 2019, Beginnend im März, endend im Oktober Nicht ist so schnell veraltet, wie Kommentare im Programm ;-)
Wolfgang schrieb: > Nicht ist so schnell veraltet, wie Kommentare im Programm ;-) Als ich das 2009 schrieb dachte ich bis 2019 würde erstmal reichen .... tja, man wird älter :-(
Magst Du in die Lib ggf. noch eine Höhenkorrektur einbauen? Vom Berg/Flieger aus ist der Horizont weiter weg, deswegen findet der Sonnenuntergang später statt. In 2500m Höhe über Grund sind das in unserer Gegend schon 10min. Das kostet dann ggf. eine Zusatzgebühr, wenn die Luftaufsicht bei Sunset den Platz zumachen will und man sich gerade gemütlich den Sonnenuntergang anschaut. Jetzt kein Witz, ist mir gestern passiert. :D Ich hab Dir eine passende Exceltabelle hergeleitet, hoffentlich ohne Fehler.
:
Bearbeitet durch User
Marcus H. schrieb: > In 2500m Höhe über Grund sind das in unserer Gegend schon 10min. Daran ist neben der Augeshöhe natürlich auch schuld, dass die Sonne wegen der Refraktion in den Luftschichten der Atmosphäre erst erheblich nach dem geometrischen Sonnenuntergang hinter dem Horizont verschwindet. In der astronomischen Navigation findet man Formeln für den Refraktionsfehler, bei denen genau genommen auch Temperatur und Luftdruck eingehen, meist aber mit Standardwerten gerechnet wird. Unterhalb weniger Grad wird es dann für Navigationszwecke allerdings sowieso zu ungenau ;-) http://www.astrosail.de/de/static/tutorial/beschick1.php
@Wolfgang, danke für den Link. Habe ich die Formel für den Refraktionsfehler bei hs < 3° übersehen? Den bräuchten wir doch bei Sonnenuntergang, oder? Danke für den Anstoß, der mich hierhin gebracht hat: https://archive.org/stream/handbuchdermath00gngoog/handbuchdermath00gngoog_djvu.txt Danach hierhin: https://de.wikipedia.org/wiki/Astronomische_Refraktion Mit den dort gegebenen ca. 0,6° kommen zu den 178km in 2500m Höhe noch 67km. 599s -> 823s Aber denselben Refraktionsfehler hatte in meinem Beispiel auch der Flugleiter am Boden. Ist sehr lehrreich zu sehen, welche Randeffekte in diese ganzen Tabellen reinwirken.
Marcus H. schrieb: > Den bräuchten wir doch bei Sonnenuntergang, oder? Im Prinzip ja, aber da wird es sehr abhängig von der Wetterlage, i.e. aktuellen Luftschichtung. Darum meidet man den Bereich in der Navigation und kann den Bereich höchstens unter Zuhilfenahme aktueller Wetterballondaten modellieren. Aus diesem Grund wird man da keine geschlossene verlässliche Formel finden. Für die hier angestrebte Genauigkeit sollte aber eine Überschlagsformel reichen. Man muss nur aufpassen, dass die auch für Beobachtung aus großer Augeshöhe gilt. Meist beziehen die sich auf wenige Meter Beobachterhöhe. Ich stecke da im Moment aber auch nicht tief genug drin, um einen vernünftigen Link angeben zu können ;-( Marcus H. schrieb: > Danke für den Anstoß, der mich hierhin gebracht hat: > https://archive.org/stream/handbuchdermath00gngoog/handbuchdermath00gngoog_djvu.txt Danke für den Link. Da muss ich mal in Ruhe drin stöbern
Marcus H. schrieb: > Magst Du in die Lib ggf. noch eine Höhenkorrektur einbauen? Nö :-) Einfach weil ich nicht mal die Bohne Ahnung von sowas habe - nur stur Formeln rausgesucht und es mir reicht, dass bei meiner Anwendung die Hintergrundbeleuchtung des Displays zeitrichtig eingeschaltet wird und wieder aus. Und den Platz finde ich auch so wieder :-)
Für die Anwendung ist das dann wirklich genau genug. Ich bin ja einer von denen, denen warm wird, wenn vorne der Ventilator ausfällt. Und bitte Energiesparbirnen nehmen, damit Dein FLARM und die Funke weiterlaufen. :)
Horst H. schrieb: > Ein so große Rolle wird die Geschwindigkeit bei der Berechnung nicht > spielen. Die Berechnung der ganzen Salats dauert bei mir übrigens 24.570 Takte, was umgerechnet 1,4 Mikrosekunden sind. Denke mal, die Zeit muss sein :-)
Christian J. schrieb: > Die Berechnung der ganzen Salats dauert bei mir übrigens 24.570 Takte, > was umgerechnet 1,4 Mikrosekunden sind. Flotter Controller.
Bernd schrieb: > Flotter Controller. Häh? Ist doch normal. Die Kapelle des STM32F407 spielt mit 168 Mhz Beats per Second. Systick spuckte 24570 Ticks bei Verwendung der FP Unit aus, ergo sind das 1,4 us.
Christian J. schrieb: > Bernd schrieb: >> Flotter Controller. > > Häh? Ist doch normal. Die Kapelle des STM32F407 spielt mit 168 Mhz Beats > per Second. Systick spuckte 24570 Ticks bei Verwendung der FP Unit aus, > ergo sind das 1,4 us. Wer so schlampig-frivol argumentiert wie du, kommt auch zu den entsprechenden Ergebnissen.
Bernd schrieb: > Wer so schlampig-frivol argumentiert wie du, kommt auch zu den > entsprechenden Ergebnissen. 146,25 us.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.