Code: Berechnung von Sonnenauf- und Untergang mit einem uC

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 :-(

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

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 :-)

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.