Code: Berechnung von Sonnenauf- und Untergang mit einem uC

[Christian J. (Gast)]

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

[Rufus Τ. F. (rufus)]

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

[Horst H. (horha)]

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

[Edi R. (edi_r)]

@ 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.

[Christian J. (Gast)]

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.

[Wolfgang (Gast)]

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

[Christian J. (Gast)]

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. (Firma: www.harerod.de) (lungfish)]

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.

[Wolfgang (Gast)]

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. (Firma: www.harerod.de) (lungfish)]

@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.

[Wolfgang (Gast)]

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

[Christian J. (Gast)]

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

[Marcus H. (Firma: www.harerod.de) (lungfish)]

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

[Christian J. (Gast)]

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

[Bernd (Gast)]

Christian J. schrieb:

> Die Berechnung der ganzen Salats dauert bei mir übrigens 24.570 Takte,
> was umgerechnet 1,4 Mikrosekunden sind.

Flotter Controller.

[Christian J. (Gast)]

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.

[Μαtthias W. (matthias)]

Hi

Rechne nochmal nach ;-)

Matthias

[Bernd (Gast)]

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.

[Christian J. (Gast)]

Bernd schrieb:
> Wer so schlampig-frivol argumentiert wie du, kommt auch zu den
> entsprechenden Ergebnissen.

146,25 us.