Manche RTC Module (China DS3231,
https://datasheets.maximintegrated.com/en/ds/DS3231.pdf) haben ein 4kB
EEPROM mit dabei, das würde locker reichen, um für 365 Tage Stunde (5
bits) und Minute (6 bits) von Sonnenauf- und Untergang abzulegen, um die
Berechnung zu sparen.
Mit CR2032 und einer Laufzeit von 10 Jahren (?) und einer Ungenauigkeit
von 1 min/Jahr wäre das für mich eine gute Lösung.
2x am Tag:
- mit Alarmsignal MCU starten,
- EEPROM lesen
- Alarmzeit in RTC schreiben
- Ausgang schalten
Tagsüber müsste nur die RTC aus der Batterie laufen, nachts wäre die
Schaltung aus dem Stromnetz versorgt. Die Energie zum Einschalten (SSR,
einige mA für einige 10 ms) müsste also aus einem Puffer kommen (der den
Tag über halten muss).
Dann ist evtl. ein Superkondensator besser als die Lithium-Batterie.
Oder eine Kombination, da keine Einschränkung der Gangreserve.
Die eigentliche Frage ist aber die nach den Tabellendaten.
Was gibt es bei der Erstellung dieser Tabelle außer Schaltjahren
(https://de.wikipedia.org/wiki/Schaltjahr) noch zu berücksichtigen?
Wie erfolgt der Lookup am günstigsten?
Der DS3231 berücksichtigt Schaltjahre bis 2100.
Allerdings sehe ich nicht, wie man ein Schaltjahr erkennt (Status bit?).
Ansonsten sollte es einfach sein, Monat und Tag auf EEPROM Index zu
mappen.
struct day {
uint8_t rise_hour;
uint8_t rise_min;
uint8_t set_hour;
uint8_t set_min;
};
// struct day eeprom[366];
Theoretisch würde auch ein Viertel der Daten reichen.
Die Daten von 21.12. bis 20.6. spiegeln, und dann erhält man die Daten
für 21.6 bis 20.12.
Und die Daten 21.12. bis 20.3. sind die gleichen wie von 21.3. bis 20.6.
, wenn man die Differenz vom Mittelwert (also 21.3.) betrachtet.
Also würden die Daten 21.12 bis 20.3. reichen, der Rest kann einfach
berechnet werden.
Idefix schrieb:> um die Berechnung zu sparen.
Warum sollte man sich die Berechnung sparen, kein uC zu Hand ? Berechnet
passt die Tabelle wenigstens zum eingegebenen Breitengrad. Der uC hat
24 Stunden Zeit, so langsam kann er gar nicht rechnen.
Übrigens wird es bei den allermeisten Fällen nichts aus machen, wenn die
Uhrzeit nur wôchentlich nachgestellt wird.
Idefix schrieb:> Die eigentliche Frage ist aber die nach den Tabellendaten.> Was gibt es bei der Erstellung dieser Tabelle außer Schaltjahren> (https://de.wikipedia.org/wiki/Schaltjahr) noch zu berücksichtigen?
Die Sonnenauf- und -untergangsdaten ändern sich nicht erratisch, d.h. du
brauchst nur ein paar Eckdaten und kannst dazwischen interpolieren. Wenn
dein Dämmerungsschalter 5 Minuten falsch geht, stört das selbst in den
Tropen nicht so wirklich. Für die Sonnenhöhe würde das einen Fehler von
gerade mal gut 1° bedeuten (halbe Daumenbreite am ausgestreckten Arm).
Die maximale tägliche Änderung von Aufgangs- bzw. Untergangszeit hast du
bei Tag- und Nachtgleiche und die beträgt dort auch nur gut 2 Minuten.
Und das Schaltjahr spielt auch keine Nennenswerte Rolle, weil das
sowieso nur das langfristige Aufsummieren von Rundungsfehler zwischen
Jahreslänge und Rotationsdauer vermeidet. Um das auch zu
berücksichtigen, bräuchtest du eine Tabelle über 4 Jahre.
Kurz: Auf einen Tag kommt es für einen Dämmerungsschalter nicht an.
Was ist denn das für ein Controller, auf dem die Sonnenstandrechnung
nicht unterzubringen ist. Sobald eine Float-Bibliothek von vielleicht 1k
rein passt, ist es doch einfacher die Rechnung direkt dort
durchzuführen.
PittyJ schrieb:> Theoretisch würde auch ein Viertel der Daten reichen.> Die Daten von 21.12. bis 20.6. spiegeln, und dann erhält man die Daten> für 21.6 bis 20.12.
Dann verwendest du eine falsche Theorie.
Praktisch ist die Erdbahn elliptisch und entsprechend verschieben sich
die Zeiten (Stichwort: Zeitgleichung)
https://de.wikipedia.org/wiki/Zeitgleichung
Das war's dann mit der Symmetrie
Wolfgang schrieb:> Das war's dann mit der Symmetrie
Allerdings ist das auch ziemlich unwichtig, denn die Astronomie
ignoriert im Weiteren völlig, wie hell es denn tatsächlich ist.
Es kann durchaus sein dass es heute dank stammer Bewölkung abends um 6
schon richtig dunkel, es aber tags drauf eine halbe Stunde später bei
einem schönen Sonnenuntergang noch ziemlich hell ist.
Einen Dämmerungsschalter würde ich deshalb nur ganz grob nach der Zeit
und in der Summe vorrangig nach der tatsächlichen Helligkeit steuern.
Lothar M. schrieb:> Allerdings ist das auch ziemlich unwichtig, denn die Astronomie> ignoriert im Weiteren völlig, wie hell es denn tatsächlich ist.
Das war aber nicht die Frage des TO.
Sonst könnte er einfach einen Helligkeitssensor zur Steuerung verwenden.
Idefix schrieb:> Was gibt es bei der Erstellung dieser Tabelle außer Schaltjahren> (https://de.wikipedia.org/wiki/Schaltjahr) noch zu berücksichtigen?
Der Ort, für den diese Tabelle gelten soll. Sonnenauf- und
untergänge sind ortsabhängig.
Wolfgang schrieb:>> Der Ort, für den diese Tabelle gelten soll. Sonnenauf- und>> untergänge sind ortsabhängig.>> Aach - das ändert aber nichts am Prinzip
Das heisst, man muss die ortsabhängigen Korrekturen zusätzlich
selbst berechnen?
Habe nur 2k Flash, das wird eher nichts mit float.
Eine Integer-Berechnung habe ich noch nicht gesehen.
Die beiden C Funktionen, die ich gefunden habe, liefern abweichende
Ergebnisse. Dann gibt's noch einige CPP Klassen, die ich erst umbauen
müsste...
Hardware-Upgrade möchte ich auch vermeiden.
RTC samt Eeprom ist bezahlt, da könnte ich ihn auch nutzen..
Die 17 min der Zeitgleichung sind mir egal, sonst ist vielleicht noch
Platz für 4 Jahre Offset-Daten, oder eine platzsparende Näherung.
Die Witterungseinflüsse nehme ich in Kauf, man kann ja ne halbe Stunde
auf der sicheren Seite schalten.
Dafür hat man keine Sorgen mit Fremdlicht, Schmutz, Flora & Fauna,
Alterung & Korrosion.
Harald W. schrieb:> Das heisst, man muss die ortsabhängigen Korrekturen zusätzlich> selbst berechnen?
Wenn die Tabelle für den Ort korrekt aufgestellt wurde, muss nichts
zusätzlich berechnet werden.
Oder muss jetzt auch noch erwähnt werden, dass die Erde keine Scheibe
ist? ;-)
Wolfgang schrieb:> Das war aber nicht die Frage des TO.
Ich wollte es nur erwähnt haben, weil schon so einige TO mit ihrem
Lösungansatz nicht auf dem Weg zum Ziel waren.
Und er redet eben von "tags" und "nachts" und von einem
"Dämmerungsschalter". Das hat für mich eindeutig mehr mit realer
Helligkeit als mit einer berechneten Sonnenkurve zu tun.
Idefix schrieb:> Allerdings sehe ich nicht, wie man ein Schaltjahr erkennt (Status bit?).
Welchen Fehler machst du, wenn du einfach immer von einem normalen
Nichtschaltjahr ausgehst?
Das geht dann in 3 von 4 Jahren gut. Und im verbleibenden Schaltjahr
hast du nicht viel mehr Abweichung, als deine Tabellenauflösung im
Minutenbereich hergibt.
Idefix schrieb:> Die 17 min der Zeitgleichung sind mir egal, sonst ist vielleicht noch> Platz für 4 Jahre Offset-Daten, oder eine platzsparende Näherung.
Die Zeitgleichung macht dir die einfache, von PittyJ angeführte
Symmetrie kaputt, weil das Perihel der Erde etwa am 4 Januar liegt.
Du kannst beide Komponenten getrennt betrachten und dann aufsummieren.
Das ist kein Grund, die max. 17 min der Zeitgleichung zu
vernachlässigen. Die 4 Jahre vom Schaltjahreszyklus sind eher zu
verschmerzen, weil das nur einen Fehler von 2 min erzeugen würde.
Lothar M. schrieb:> Welchen Fehler machst du, wenn du einfach immer von einem normalen> Nichtschaltjahr ausgehst?
Schrieb ich bereits:
Wolfgang schrieb:> Die maximale tägliche Änderung ...
Wolfgang schrieb:> Und das Schaltjahr spielt auch keine Nennenswerte Rolle, weil das> sowieso nur das langfristige Aufsummieren von Rundungsfehler zwischen> Jahreslänge und Rotationsdauer vermeidet. Um das auch zu> berücksichtigen, bräuchtest du eine Tabelle über 4 Jahre.
Ok, wenn es in 20 Jahren 5 Tage falsch liegt und dann 10 min zusätzliche
Abweichung entstehen, wäre das tatsächlich kein Problem.
Also bleibt es bei einer Tabelle mit 365 Tagen und der 29.2. wird wie
der 28.2. behandelt.
@wolfgang
Wie kann ich denn die Zeitgleichung für die nächsten zb 20 Jahre mit dem
verbleibenden Tabellenplatz berücksichtigen?
1464 Bytes für die Zeiten eines Jahres und ebensoviel für vier Jahre
Zeitgleichung.
Dann brauche ich zum Aufstellen der Tabelle noch eine Funktion, die die
Zeitgleichung nicht berücksichtigt, und eine, die nur die
Zeitgleichung für vier Jahre ausgibt.
Oder vier Jahre berechnen, und die Zeitgleichung herausholen...
Evtl. astropy.
Idefix schrieb:> Wie kann ich denn die Zeitgleichung für die nächsten zb 20 Jahre mit dem> verbleibenden Tabellenplatz berücksichtigen?
Das Jahr hat eine Länge von etwa 365.2422 Tagen, die Erdrotation bezogen
auf den Sonnenstand dauert 24h. Nach 1461 Tagen (eigentlich 1460d 23h
15m) wiederholt sich daher Datum und Uhrzeit des Frühlingsanfangs als
Bezugspunkt halbwegs genau. Darum die 4-Jahres Regelung für die
Schaltjahre mit den Ausnahmenregeln für die vollen Jahrhunderte. Das hat
nichts mit der Zeitgleichung zu tun, die die Verschiebung des
Mittagszeitpunktes (=Sonne steht am höchsten) durch Neigung der Erdachse
und elliptische Erdumlaufbahn berücksichtigt.
Wenn du deine Tabelle auf 366 Tage auslegst und ggf. den letzten Tag weg
lässt, hast du halt den Fehler von max gut 2min, was für einen
Dämmerungsschalter zu verschmerzen ist ;-)
Ist die Zeitgleichung einmal für einen Ort ausgerechnet, (zur
Fehlerminimierung für 2022, also genau zwischen zwei Schaltjahren),
sieht man, dass die maximale Änderung von Tag zu Tag < 30 Sekunden
beträgt.
Liegt man also im Schaltjahr einen Tag (eigentlich nur +/- 1/2 Tag)
daneben ist der Fehler deutlich unter 30 Sekunden.
Der DS3231 mit 2 ppm Genauigkeit bei 0...40° C darf nach einem Jahr 1
Minute daneben liegen.
Die "Leap-Year Compensation Valid Up to 2100" ist übrigens ein Lacher,
erst ab 2100 kommt die 100/400-Jahr-Regel zum Zuge, die im Jahr 2000 zu
Verwirrung führte.
Wendels B. schrieb:> Doch natürlich, denk einfach an Nordpol oder Äquator.
Unsinn. Die Zeitgleichung beschreibt die Abweichung der mittleren
Ortszeit von der wahren Ortszeit.
Wolfgang, du hast schon recht mit der ortsunabhängigen Differenz von
mittlerer zu wahrer Ortszeit.
Ich habe mich ungenau ausgedrückt:
Die Auf- und Untergangszeiten, die man (mit Hilfe der Zeitgleichung) für
einen Ort mit Länge, Breite über ein Jahr errechnet hat, kann man
getrost jedes Jahr wieder benutzen.
Selbst Jean Meeus, anerkannter Experte für genaue astronomische
Berechnungen, rät davon ab, Auf- und Untergangszeiten genauer, als auf
die Minute anzugeben. - Auch Temperatur und Luftdruck haben darauf
Einfluss.
https://www.volker-quaschning.de/datserv/sunpos/index.php spuckt die
Zeiten für ein ganzes Jahr aus (Schaltjahren fehlt der 31.12.).
Da wird die Zeitgleichung ja wohl schon drin stecken, wie auch bei
timeanddate.com etc.
Sie ist wohl nur interessant, wenn man selbst rechnen möchte oder eine
hohe Genauigkeit braucht. Das versuche ich ja zu vermeiden.
Ich sehe in den Daten nächsten 10 Jahren keine nennenswerten (mehrere
Minuten) Abweichungen für meine Koordinaten!
Den Schalttag werde ich doch nicht ignorieren, stattdessen den 366 Tag.
Sonst gibt es einen kleinen Sprung und dann den Rest des Jahres einen
kleinen Fehler.
Dazu muss stets ermittelt werden, ob es den 29.2. gab (Schaltjahr ist),
um den Tag (1-365) anhand des Datums, und damit den Tabellenindex zu
ermitteln.
Peter, danke, aber da lese ich lieber direkt die Zeit aus, anstatt im
Mittel 182 Lesevorgänge (über I2C) und Additionen zu machen.
Wie du deine Daten berechnet hast, interessiert mich aber!
astropy bestätigt die Zeiten von quaschning eher als die von
timeanddate.
Hallo Idefix,
Idefix schrieb:> https://www.volker-quaschning.de/datserv/sunpos/index.php spuckt
DER Quaschning?! :(
> die> Zeiten für ein ganzes Jahr aus (Schaltjahren fehlt der 31.12.).> Da wird die Zeitgleichung ja wohl schon drin stecken, wie auch bei> timeanddate.com etc.> Sie ist wohl nur interessant, wenn man selbst rechnen möchte oder eine> hohe Genauigkeit braucht. Das versuche ich ja zu vermeiden.> Ich sehe in den Daten nächsten 10 Jahren keine nennenswerten (mehrere> Minuten) Abweichungen für meine Koordinaten!> Den Schalttag werde ich doch nicht ignorieren, stattdessen den 366 Tag.> Sonst gibt es einen kleinen Sprung und dann den Rest des Jahres einen> kleinen Fehler.> Dazu muss stets ermittelt werden, ob es den 29.2. gab (Schaltjahr ist),> um den Tag (1-365) anhand des Datums, und damit den Tabellenindex zu> ermitteln.
Ja.
> Peter, danke, aber da lese ich lieber direkt die Zeit aus, anstatt im> Mittel 182 Lesevorgänge (über I2C) und Additionen zu machen.
Das wusste ich nicht - bin µc-inkompetent!
> Wie du deine Daten berechnet hast, interessiert mich aber!
Du hast die Daten für die einfache, jahresunabhängige Version bekommen,
wie Du Sie auf der verlinkten Seite findest mit den Parametern
Hannover-Koordinaten und Zeitzone 1.
Berechnet habe ich das in Excel.
Es gab früher auf der Seite mehr Informationen und die Links
funktionierten auch.
Anbei findest Du noch ein Bild, wie sich im Jahre 2022 die einfache
Berechnung und die genauere Berechnung (früher auf der Webseite zu
finden) gegenüber dem Code von Duffett schlägt.
Peter M. schrieb:> Du hast die Daten für die einfache, jahresunabhängige Version bekommen,> wie Du Sie auf der verlinkten Seite findest mit den Parametern> Hannover-Koordinaten und Zeitzone 1.>> Berechnet habe ich das in Excel.> Es gab früher auf der Seite mehr Informationen und die Links> funktionierten auch.>> Anbei findest Du noch ein Bild, wie sich im Jahre 2022 die einfache> Berechnung und die genauere Berechnung (früher auf der Webseite zu> finden) gegenüber dem Code von Duffett schlägt.
Ich sehe auf der Seite nichts, d.h. alle "hier"s sind keine Links.
Du hast also die Formeln in Excel realisiert?
Ein Duffet wird da auch nicht erwähnt.
Eine "genauere Berechnung", die es nicht mehr gibt, nützt mir auch nicht
wirklich was.
Aber eigentlich ist das Thema für mich abgeschlossen - nur Schaltjahre
haben einen kleinen Einfluss, ansonsten bleiben die Zeiten jährlich fast
auf die Minute gleich.
Die Daten kann man sich notfalls von den Online-Anbietern
zusammenklauben.
Also, vielen Dank für die Hinweise.
Och, die Daten vom Quaschning sind garnicht so schlecht:
Außer die nach dem SUNRAE-Verfahren: Fehler bis zu 10 Minuten
Die Daten nach DIN 5034 und NREL SOLPOS sind schon besser, aber
berücksichtigen nicht so richtig, dass die Lichtbrechung am Horizont zu
real beobachtbaren (Ellipsenform der auf-/untergehenden Sonne)
Verlagerungen des Zeitpunkts von Auf- und Untergang führt. Fehler bis
etwa 3 Minuten.
Die Aufgangszeiten von Peter M. (r2d3) sind sehr gut berechnet!
Der Algorithmus dahinter ist bestimmt von Jean Meeus inspiriert!
Als Referenzjahr sollte man aber zur Fehlerminimierung ein Jahr wie
2018, oder 2022 in der Mitte zwischen 2 Schaltjahren wählen!
Peter M. schrieb:> Das Beispiel ist nur eine primitive Variante einer Look-Up-Tabelle. Es> sind noch viel ausgefallenere, schlauere und kompaktere Varianten> möglich.> 01.01.24 0 8:30:08 0> 02.01.24 1 8:29:54 -14> 03.01.24 2 8:29:37 -17> ...
Was bitte soll dieser Zahlensalat hier im Text?
Was für Sourcecode gilt, sollte mit ein bisschen Nachdenken auch auf
längere Zahlenkolonnen zutreffen.
Warum kannst du die Tabelle nicht als Dateianhang beifügen?
@ Peter M. (r2d3)
Glaub mir bitte: Sonnen-auf/unter-gang mit Sekundenangabe ist unnütz!
Temperatur und Luftdruck können über die ÄNDERUNG der Lichtbrechung am
Horizont den Zeitpunkt gern mal um +/-15...30 s verschieben. Die
MITTLERE Lichtbrechung am Horizont von gut 0,6° verlängert den Tagbogen
sowieso!
Dazu ist die Sonne kein Punkt, sondern hat etwa 1/2° Durchmesser, was
den Aufgang vom Erscheinen der Oberkante bis zur voll sichtbaren Scheibe
auf etwa 3 (Frühjahr, Herbst) bis 5 (Sommer, Winter) Minuten ausdehnt...
Welcher Zeitpunkt darf's denn sein?
Lies mal die Tipps der guten (an der Praxis orientierten) Experten etwas
aufmerksamer: Gute Experten protzen nicht mit sinnlosen Stellen hinterm
Komma!
Gute Nacht.
Also ich hatte dafür vor Jahren eine Routine geschrieben um den
Sonnenauf- und Untergang zu berechnen, war soweit ich mich erinnere auf
ein paar Sekunden genau und passte in einen kleinen Attiny.
Die eigentliche Funktion steckt in der sonnenverlauf.c, die main.c ist
nur ein Wrapper um die Funktion auf dem PC mit sinnvollen Daten zu
füttern und das Ergebnis anzuzeigen.
Nach einem ersten Drübersehen liege ich mit dem Algorithmus innerhalb
einer Sekunde vom v2005 (wobei das im Beispiel die gleichen Werte wie
beim v2000 sind). Und nochwas zum Duffett-Smith, das ist nicht der
Genauste sondern der Einfachste, eben das was gut mit Taschenrechner
oder Excelsheet geht...
Achja, in der hochgeladenen Version werden die Sekunden nicht angezeigt,
weil es wie Kurt schon sagte einfach unsinnig ist (kann man natürlich in
der sonnenverlauf.c ändern, wenn man es unbedingt braucht). Abgesehen
von der Refraktion gibts es aber auch noch Geländegegebenheiten die den
Sonnenaufgang so weit verschieben, dass es einfach nichts bringt da auf
die Sekunde genau sein zu wollen.
Ich hab das mal nach Duffet ausgerechnet, bin so bei +- 90 sec gelandet,
sehr viel genauer dürfte es auch nicht werden; Refraktion,
Betrachtungshöhe und noch 1 - 2 weitere Punkte.
Hallo Kurt,
Kurt schrieb:> @ Peter M. (r2d3)> Glaub mir bitte: Sonnen-auf/unter-gang mit Sekundenangabe ist unnütz!> Temperatur und Luftdruck können über die ÄNDERUNG der Lichtbrechung am> Horizont den Zeitpunkt gern mal um +/-15...30 s verschieben. Die> MITTLERE Lichtbrechung am Horizont von gut 0,6° verlängert den Tagbogen> sowieso!
erst lobst Du die Genauigkeit, jetzt beschwerst Du Dich? Wahrscheinlich
hat jetzt einer von der Stänkerfraktion Deinen Gastnamen übernommen!
Ich dachte, Dich würden diese Daten interessieren und alle anderen
hätten eine Möglichkeit, ihre Ergebnisse mit meinen zu vergleichen.
Ich habe zum Spaß damals alle Methoden implementiert. Mir ging es nie um
Sekunden.
Spätestens wenn man als Parameter in seine Funktion die Art der
Dämmerung aufnimmt (bürgerliche, nautische und astronomische Dämmerung)
und die Abweichungen dazwischen betrachtet, reicht die simpelste
Methode.
> Dazu ist die Sonne kein Punkt, sondern hat etwa 1/2° Durchmesser, was> den Aufgang vom Erscheinen der Oberkante bis zur voll sichtbaren Scheibe> auf etwa 3 (Frühjahr, Herbst) bis 5 (Sommer, Winter) Minuten ausdehnt...> Welcher Zeitpunkt darf's denn sein?
Diesem Aspekt wird von keinem der Codeschreiber Rechnung getragen -
scheint wohl nicht wichtig zu sein!
> Lies mal die Tipps der guten (an der Praxis orientierten) Experten etwas
Welche denn?
> aufmerksamer: Gute Experten protzen nicht mit sinnlosen Stellen hinterm> Komma!
Sinnlose Unterstellungen - typisches µc-Gemäkel.
Hallo Tim T.,
Tim T. schrieb:> Achja, in der hochgeladenen Version werden die Sekunden nicht angezeigt,> weil es wie Kurt schon sagte einfach unsinnig ist (kann man natürlich in> der sonnenverlauf.c ändern, wenn man es unbedingt braucht). Abgesehen
die Werte wurde von mir einfach im Format hh:mm:ss ausgegeben.
Wenn man den Speicherbedarf für seine Stützstellen trickreich minimieren
will, ist die Angabe der Sekunden sinnvoll.
Für meine persönlichen sportlichen Aktivitäten habe ich in meinem Hirn
1.0 eine Tabelle mit den Monatswerten des Sonnenuntergangs abgelegt -
alle Angaben auf eine Viertelstunde gerundet. :)
Hab es jetzt mal kurz mit meinem Algorithmus durchgerechnet. Die
maximale Abweichung der täglichen Sonnenaufgangs Zeitpunkte bei 52.37 N
und 9.73 O, in den nächsten 10 Jahren beträgt weniger als 2 Minuten. Mit
optimiertem Mittelwert wären es dann entsprechend weniger als 1 Minute
Abweichung, ich denke damit kann man leben. Somit müsste man nur die
365(366) Tage speichern und hätte noch viel EEPROM frei.
Idefix schrieb:> Danke, sag ich ja.> Wie groß wäre denn deine funktion im avr mit float / math lib?> Hab's noch nicht ausprobiert.
Meine es passte in einen AtTiny45 also kleiner 4kB, hab aber das Projekt
gerade nicht zur Hand. Wobei wenn du noch 10 Minuten hast, ich habe
gleich die Main soweit angepasst das sie dir die (arithmetischen)
Mittelwerte für die nächsten 10 Jahre berechnen kann. Hatte mich aus
Spaß einfach mal dran gesetzt.
Peter M. schrieb:> Datum v2000 v2005 Duffett> 01.01.22 8:30:01 8:30:01 8:31:03> 02.01.22 8:29:52 8:29:52 8:30:54> 03.01.22 8:29:38 8:29:38 8:30:42
Was soll der Sch..ß?
Kannst du das Zeugs nicht als Dateianhang hochladen?
PS: Hat länger gedauert weil ich nicht bemerkt hatte, dass ich im
bearbeiten Modus war und beim Absenden war dann alles weg, weil
zwischenzeitlich ein neuer Post kam, so dass ich nochmal anfangen konnte
alles zu schreiben...
Peter M. schrieb:
> Ich dachte, Dich würden diese Daten interessieren und alle anderen> hätten eine Möglichkeit, ihre Ergebnisse mit meinen zu vergleichen.
Kaum kommt zum Lob etwas berechtigte Kritik dazu, ist man von der
Stänkerfraktion.
Dann erklär mir doch mal, warum deine Daten für Hannover "nach Duffet"
im ersten Halbjahr näher an den Daten in astronomischen Jahrbüchern
liegen, während sie im 2. Halbjahr geringfügig schlechter werden und die
Zeiten aus v2000 und v2005 (siehst du da einen Unterschied?), die im
ersten Halbjahr auch mal 3 Minuten daneben liegen, besser passen.
Zugegebenermaßen ist mein 20 Jahre altes C-Programm nach Jean Meeus auch
heute noch nicht in einen µC mit 8K Flash zu implementieren (benötigt
etwa 50 K im 80x86) - aber eine damit generierte Tabelle für den
Jahresablauf stimmt heute noch auf +/- 1 Minute mit astronomischen
Jahrbüchern überein.
> Diesem Aspekt wird von keinem der Codeschreiber Rechnung getragen -> scheint wohl nicht wichtig zu sein!
Ich denke mal, der Herr Duffet wird den Sonnendurchmesser und die
mittlere Lichtbrechung am Horizont auch berücksichtigt haben sonst gäbe
es in mittleren Breiten jeden Tag einen Fehler von 2...3 Minuten - aber
wer nur den Code abtippt, hat wohl die Erklärungen nicht gelesen...
Kurt schrieb:> Zugegebenermaßen ist mein 20 Jahre altes C-Programm nach Jean Meeus auch> heute noch nicht in einen µC mit 8K Flash zu implementieren (benötigt> etwa 50 K im 80x86) - aber eine damit generierte Tabelle für den> Jahresablauf stimmt heute noch auf +/- 1 Minute mit astronomischen> Jahrbüchern überein.
Hättest du mal ein paar Beispieldatensätze, sowohl von dir als auch die
zugehörigen aus den Jahrbüchern für mich, würde die gerne mal gegen mein
Programm laufen lassen. Hatte zuerst auch nach Jean Meeus - Astronomical
Algorithms gerechnet, bin dann aber auf J. Laskar "Secular terms of
classical planetary theories using the results of general theory"
umgestiegen weil die Werte besser zu den Beispielen passten.
Anschließend hatte ich aber noch die Konstanten mit neueren Werten von
der Nasa ersetzt und würde mich jetzt doch mal dafür interessieren wie
es abschneidet.
>> Diesem Aspekt wird von keinem der Codeschreiber Rechnung getragen ->> scheint wohl nicht wichtig zu sein!>> Ich denke mal, der Herr Duffet wird den Sonnendurchmesser und die> mittlere Lichtbrechung am Horizont auch berücksichtigt haben sonst gäbe> es in mittleren Breiten jeden Tag einen Fehler von 2...3 Minuten - aber> wer nur den Code abtippt, hat wohl die Erklärungen nicht gelesen...
Also den Sonnendurchmesser hatte ich berücksichtigt aber nicht die
Refraktion, da diese einfach von zu vielen Faktoren abhängig ist und die
gefundenen Algorithmen, glaube auch die im Astronomical Algorithms Buch
von Meeus wirklich genau zu keinem der verfügbaren Beispieldatensätzen
passten.
Glaube die letzte Formel die ich da hatte war
Tim T. schrieb:> Glaube die letzte Formel die ich da hatte warRefraktion = 1.02 /> TAN(Hoehenwinkel + (10.3 / (Hoehenwinkel + 5.11)));> Hoehenwinkel += Refraktion / 60.0;> und die passte nur leidlich.
Da fehlen Luftdruck und Temperatur. In Horizontnähe gehen die kräftig in
die Refraktion ein.
Dein Programm aus Beitrag "Re: Sonnenaufgang/Sonnenuntergang in Tabelle (Astro-Uhr/Dämmerungsschalter)?"
läuft, deine main.c aus
Beitrag "Re: Sonnenaufgang/Sonnenuntergang in Tabelle (Astro-Uhr/Dämmerungsschalter)?" braucht andere
Strukturen (Sonnenverlauf_t).
Die erste main.c habe ich console.c genannt.
gcc sonnenverlauf.c zeit.c zeitgleichung.c console.c -o console.exe
console.exe -b 52.37 -l 9.73 -z 1
01.01.2022 08:30 16:17
02.01.2022 08:30 16:18
03.01.2022 08:30 16:19
...
Hannover ist nett, aber wie wär's mit
https://en.wikipedia.org/wiki/Royal_Observatory,_Greenwich auf etwa
51.5,0 - leicht zu merken und stets UTC (GMT)?
console.exe -b 51.5 -l0 -z0
01.01.2022 08:05 16:01
02.01.2022 08:04 16:02
03.01.2022 08:04 16:03
https://www.timeanddate.com/sun/@51.5,0.0?month=1&year=2022
1 08:05 ↑ (128°) 16:01
2 08:05 ↑ (127°) 16:02
3 08:05 ↑ (127°) 16:03
https://www.volker-quaschning.de/datserv/sunpos/index.php
DIN5034 1 08:12:32 15:54:36
SUNAE 1 08:05:10 15:54:16
NREL SOLPOS 08:08:02 15:59:17
// http://souptonuts.sourceforge.net/code/sunrise.c.html
// modifiziert, damit UTC rauskommt
// gcc sunrise.c -o sunrise.exe -DDEBUG=1 -Wall -W -O2 -s -pipe -lm
sunrise.exe 2022 1 1 51.5 0.0
Julian Date 2459580.500000
Sunrise timeUTC 485.626020
Sunset timeUTC 961.691341
Number of seconds 1640991600
Number of year 2022
Number of seconds 1640991600
Sunrise 01-01-2022 08:05:37 Sunset 01-01-2022 16:01:41
(c) Paul Schlyter, 1992
sunriset.exe
Longitude (+ is east) and latitude (+ is north) : 0 51.5
Input date ( yyyy mm dd ) (ctrl-C exits): 2022 1 1
Day length: 7.94 hours
With civil twilight 9.26 hours
With nautical twilight 10.69 hours
With astronomical twilight 12.05 hours
Length of twilight: civil 0.66 hours
nautical 1.38 hours
astronomical 2.05 hours
Sun at south 12.06h UT
Sun rises 8.09h UT, sets 16.03h UT
Civil twilight starts 7.43h, ends 16.69h UT
Nautical twilight starts 6.71h, ends 17.41h UT
Astronomical twilight starts 6.04h, ends 18.08h UT
astroplan / astropy
<SkyCoord (AltAz: obstime=2022-01-01 12:00:00.000,
location=(3978648.5306648, 0., 4968362.45729103) m, pressure=0.0 hPa,
temperature=0.0 deg_C, relative_humidity=0.0, obswl=1.0 micron): (az,
alt, distance) in (deg, deg, AU)
(179.1543046, 15.51462109, 0.98333876)>
rise ISO: 2022-01-01 08:12:28.107, JD: 2459580.8419919796
set ISO: 2022-01-01 15:54:48.506, JD: 2459581.1630614074
Wie kann man vermeiden, dass GCC das hier alles wegoptimiert, und nur 54
Bytes programm erzeugt?
Also erstmal war das tm Struct noch ein Überbleibsel aus einer Version
wo das Datum über eine Time-Funktion kam und kann einfach mit int16_t
Jahr, int8_t Monat, Tag ersetzt werden, ist dann übersichtlicher.
Hab aber jetzt mal eine konsistente Version zusammengezippt und
angehangen (und prompt vergessen die zeit.* Dateien zu entfernen, die
werden nicht mehr gebraucht).
Das Problem ist dass der Compiler erkennt, dass mit dem Wert nichts
gemacht wird, also beim µC einfach auf einem PORT ausgeben oder beim PC
eben printf.
Wenn du versuchen solltest meine Aussage von oben, wo ich vermutet hatte
das es in 4 kB Flash passt, überprüfen zu wollen, muss ich dich leider
Enttäuschen, war hinterher doch auf einen Tiny85 umgestiegen weil es zu
groß wurde (7,x kB).
Bin aber immer noch dabei eine Möglichkeit zu finden ob man das Ganze
nicht in Festkomma rechnen kann, aber bislang mit wenig Erfolg.
Hab dann auch noch einen Fehler im Programm gefunden, also nochmal neu
im Anhang. Zu blöd das man hier angehängte Dateien nicht mehr
austauschen kann, zumindest in einem gewissen Zeitfenster
(Bearbeitungszeitraum) wäre das manchmal hilfreich.
EDIT: Kann eventuell ein Mod die Datei aus dem letzten Post löschen?
Tim T. schrieb:> EDIT: Kann eventuell ein Mod die Datei aus dem letzten Post löschen?
Dann bitte auch die unnütz langen Tabellen von Peter kürzen.
Tim T. schrieb:> Das Problem ist dass der Compiler erkennt, dass mit dem Wert nichts> gemacht wird, also beim µC einfach auf einem PORT ausgeben oder beim PC> eben printf.>> Wenn du versuchen solltest meine Aussage von oben, wo ich vermutet hatte> das es in 4 kB Flash passt, überprüfen zu wollen, muss ich dich leider> Enttäuschen, war hinterher doch auf einen Tiny85 umgestiegen weil es zu> groß wurde (7,x kB).>> Bin aber immer noch dabei eine Möglichkeit zu finden ob man das Ganze> nicht in Festkomma rechnen kann, aber bislang mit wenig Erfolg.
Habe einiges ausprobiert, auch "PORTB = dummy;" bringt nichts.
Allerdings benutze ich PlatformIO (ohne framework). Er schmeißt alles
raus, nur als Debug-Build bekomme ich etwas mit 4268 bytes.
Aber du hast ja schon gesagt, dass es nicht in 4 k passt.
Damit ist es deutlich größer, als die benötigten Daten, und da sie bei
mir nicht verändert werden, ist es hinfällig.
Anhand der anderen Berechnungen sieht man, dass es für einen
Dämmerungsschalter praktisch egal ist, welche man benutzt.
Anders wäre es wohl bei einem Heliostaten.
Bestimmt kann man die Daten mit ein bisschen Rechnerei noch
"komprimieren", hier ist eine Annäherung mit Kosinus auf 20 min:
https://www.instructables.com/Calculating-Sunset-and-Sunrise-for-a-Microcontroll/
(und ein paar Links auf andere Berechnungen/Bibliotheken).
Ähnliche Auflösung dürfte eine Tabelle mit Mittelwerten für jede Woche
bringen.
Ich bau jetzt erstmal dein letztes Programm für die Mittelwerte; falls
mir noch Nenneswertes auffallen sollte, melde ich mich nochmal.
@Alle: Vielen Dank für die Beteiligung!
Idefix schrieb:> Bestimmt kann man die Daten mit ein bisschen Rechnerei noch> "komprimieren", hier ist eine Annäherung mit Kosinus auf 20 min:> https://www.instructables.com/Calculating-Sunset-and-Sunrise-for-a-Microcontroll/> (und ein paar Links auf andere Berechnungen/Bibliotheken).> Ähnliche Auflösung dürfte eine Tabelle mit Mittelwerten für jede Woche> bringen.
Also bevor man dafür den Cosinus und damit die math.h oder eine Taylor
Reihenentwicklung einbindet, kann man lieber direkt die paar Werte im
EEprom oder Flash ablegen; die Genauigkeit der gemittelten Werte liegt
dann wie bereits gesagt auch unter 1 Minute Abweichung (zumindest für
Hannover^^) zu jedem Zeitpunkt in den nächsten 10 Jahren und schneller
(=weniger Strom) ist es auch. Und warum nur Wochenwerte ablegen? Ob man
jetzt 212 Byte EEprom/Flash verbrät oder 1464 Byte, macht den Braten
ansich nicht mehr Fett.
Tim T. schrieb:> Warum zur Hölle packst du die Daten nicht in eine Datei und hängst diese> an? Ist ja nicht so dass du den Hinweis dazu noch nicht bekommen hast.
Warum sollte ich das?
Auf unfreundliche anonyme Pöbler reagiere ich nicht.
Fluchen ist auch kein Ersatz für eine Begründung.
Gibt es bei Dir ein Bandbreitenproblem im Kilobyte-Bereich?
Idefix schrieb:> Hannover ist nett, aber wie wär's mit> https://en.wikipedia.org/wiki/Royal_Observatory,_Greenwich auf etwa> 51.5,0 - leicht zu merken und stets UTC (GMT)?
Für Testzwecke sind Fälle, bei denen die Länge ungleich null ist, besser
geeignet.
Peter M. schrieb:> Tim T. schrieb:>> Warum zur Hölle packst du die Daten nicht in eine Datei und hängst diese>> an? Ist ja nicht so dass du den Hinweis dazu noch nicht bekommen hast.>> Warum sollte ich das?
Weil praktisch jeder der deine Textwand sieht sich nicht dafür
interessiert und dafür erstmal ellenlang scrollen muss.
> Auf unfreundliche anonyme Pöbler reagiere ich nicht.
Das war so ziemlich das freundlichste was du von mir dazu erwarten
kannst, ab hier geht es nur noch bergab.
> Fluchen ist auch kein Ersatz für eine Begründung.
Du bist anscheinend merkbefreit, ansonsten hätte es dir klar sein
sollen.
> Gibt es bei Dir ein Bandbreitenproblem im Kilobyte-Bereich?
Es geht doch nicht um die verdammte Bandbreite, wobei Kilobyte auch
schon wieder falsch ist; bei Bandbreite (im IT Bereich) geht es um
Datenmenge pro Zeit. Es geht viel mehr darum, dass du den Leuten mit dem
Verunstalten des Threads auf den Senkel gehst anstatt deine Daten
einfach Anzuhängen. Stell dir einfach mal vor ich hätte den Quelltext
oben jedesmal hintereinander weg im Betrag geschrieben, auch blöd oder?
Wolfgang schrieb:> Tim T. schrieb:>> Glaube die letzte Formel die ich da hatte warRefraktion = 1.02 />> TAN(Hoehenwinkel + (10.3 / (Hoehenwinkel + 5.11)));>> Hoehenwinkel += Refraktion / 60.0;>> und die passte nur leidlich.>> Da fehlen Luftdruck und Temperatur. In Horizontnähe gehen die kräftig in> die Refraktion ein.
Fast vergessen hierauf zu antworten. Das Problem ist, der Luftdruck ist
einfach nicht über alle Höhen konstant und eben sowenig die Temperatur.
Ich erinnere mich noch als ich mal auf dem Segelboot den Sextanten im
Mittelmeer bemüht habe um die Refraktion genau zu ermitteln. Egal welche
Temperatur und Luftdruck ich in egal welches Modell eingesetzt habe,
sobald der Höhenwinkel sich merklich änderte, passte wieder nichts. Ich
gehe davon aus das die Temperatur der verschiedenen Höhen, ebenso wie
der unterschiedliche Luftdruck einem da immer einen Strich durch die
Rechnung macht wenn man einfach nur eine mittlere Temperatur und
Luftdruck annimmt. Da gleichzeitig die Refraktion aber bei größeren
Höhenwinkeln praktisch keine Rolle mehr spielt, habe ich es aufgegeben
diese exakt zu bestimmen, es passt(e) einfach nie.
Peter M. schrieb:> Fluchen ist auch kein Ersatz für eine Begründung.
Du spamst hier den Thread, den Leute lesen wollen, unter Missachtung der
Forenregeln mit "endlosen" Zahlenkolonnen zu.
Das IST die Begründung, nur um es auch für dich deutlich zu formulieren.
@tim_taylor Danke nochmal, das mit der RTC funktioniert soweit!
Wer die "Bürgerliche Dämmerung" berechnen will, muss
1
constdoubleh=-50.0/60.0;// Sonnenaufgang beginnt sobald der Rand der Sonne über dem Horizont ist, nicht der Mittelpunkt!
durch -6 ersetzen (zumindest stimmen die Zeiten dann mit timeanddate gut
überein).
Sind das 50 Winkelminuten in Grad? Wo kommt der Wert her?
Laut Wikipedia ist der scheinbare Sonnendurchmesser ca. 32' - müssten es
demnach nicht -16/60 sein?
Ah, hier steckt der Wert, aber wie kommt er zustande?
https://de.wikipedia.org/wiki/Sonnenuntergang> Der mittlere scheinbare Durchmesser der Sonne beträgt 31′59,3″.> Der scheinbare Sonnenuntergang wird daher für eine geometrische Horizonthöhe von
−0,833° berechnet.
Als Quelle angegeben ist
https://www.astronomie.info/zeitgleichung/> Das Licht der Sonne wird in der Atmosphäre gebeugt. Es läuft besonders in
Horizontnähe auf einer leicht zum Boden hin gekrümmten Bahn. Deshalb kann man die
Sonne auch noch sehen, wenn sie rein geometrisch schon untergegangen ist. Deshalb
wird der Untergang und auch der Aufgang der Sonne für eine geometrische
Horizonthöhe h von -50 Bogenminuten berechnet (-50 Bogenminuten sind
-50/60°=-0.833° und -50/60/57.29578 rad=-0.0145 rad). Von bürgerlicher Dämmerung
spricht man, wenn h= -6° ist, nautische Dämmerung entspricht h = -12° und
schliesslich astronomische Dämmerung entspricht h = -18°.
Ich dachte, das wird bei der "Refraktion" berücksichtigt.
Aber gut, Fall gelöst.
Hier noch ein paar Links:
https://de.wikipedia.org/wiki/Sonnenaufganghttps://de.wikipedia.org/wiki/Sonnehttps://de.wikipedia.org/wiki/Sonnenstandhttps://de.wikipedia.org/wiki/Dämmerung> Die bürgerliche Dämmerung beginnt mit dem Sonnenuntergang und endet nach
astronomischer Definition, wenn der Mittelpunkt der Sonnenscheibe 6 Grad unter dem
wahren Horizont steht.
>> durch -6 ersetzen (zumindest stimmen die Zeiten dann mit timeanddate gut> überein).>> Sind das 50 Winkelminuten in Grad? Wo kommt der Wert her?> Laut Wikipedia ist der scheinbare Sonnendurchmesser ca. 32' - müssten es> demnach nicht -16/60 sein?>> Ah, hier steckt der Wert, aber wie kommt er zustande?
Ja genau, die 50 Winkelminuten setzen sich aus 16 Winkelminuten
Sonnenradius und etwa 34 Winkelminuten Refraktion zusammen. Aber wie
bereits geschrieben ist das mit der Refraktion nicht immer so einfach...
Entschuldigung, ich hätte gerne mein Geld zurück!
$ wget
https://www.mikrocontroller.net/attachment/548174/Sonnenaufgang.zip
$ unzip Sonnenaufgang.zip
$ cd Sonnenaufgang/
$ gcc *.c -lm
$ ./a.out -b0 -l0 -z0 | grep 60
05;60;18;07;
...
Lösung:
Bei der Ausgabe von main.c entweder floor() statt round() benutzen, oder
Überläufe für Stunden (und Datum) einbauen, wenn eine höhere Genauigkeit
gewünscht ist.
Leider ist mir das bislang nicht aufgefallen... hätte ich doch eine
Prüfung auf zulässige Wertebereiche eingebaut... :-/
Mein Controller schreibt also gelegentlich "60" Minuten ins
Alarmregister: "Configurations not listed in the table result in
illogical operation."
Weiss jemand, was dann passiert? Gibt es keinen Alarm oder irgendeinen?
Aber gut, dass es mir im Sommer aufgefallen ist ;-)
Hier noch ein Rechner, aber die Zeiten könnten GMT+1 sein, da
Norwegisch.
Und nur für einzelne Zeitpunkte. Und ich kriege es nicht hin, Daten
herauszukopieren.
http://astro.met.no/astro/
Na und? An praktisch brauchbaren Daten bist du doch schon seit Februar
nicht interessiert.
Ein amateurmäßig-mieser Online-Rechner mit Koordinaten-Eingabe im
GGG.ggggg-Format von 7.-Klässlern, der nur für einen Tag irgendwas
außerhalb jeder Zeitzone liefert ist nun wirklich nichts, womit du uns
noch überraschen
kannst.
Unbrauchbare Daten gibt es überall für (oft auch) umsonst. Ich könnte
dir aber eine Menge unbrauchbarer Daten für viel Geld verkaufen!
Gib Bescheid, wenn du das willst.
Kurt schrieb:> Ein amateurmäßig-mieser Online-Rechner mit Koordinaten-Eingabe im> GGG.ggggg-Format ...
Du verwechselst klicky bunty GUI mit Rechnen. Hast du die Algorithmen
überprüft, bevor du solche Kommentare ablässt?
Die Dämmerung hängt nicht nur vom Sonnenauf- und -untergang ab, sondern
auch von Bewölkung, Niederschlag, Sonnenfinsternissen, etc.
Deshalb ist es besser, die reale Helligkeit mit einem Sensor zu messen,
auszuwerten und entsprechend zu reagieren.
auf der Suche nach einer Funktion für den Sonnenaufgang _ zwecks
Einschalten der PV-Anlage bin ich hier gelandet.
Alles sehr kompliziert. Vielleicht hilft jemandem mein Lösungsansatz:
Karl K. schrieb:> Alles sehr kompliziert.
Ja, dafür universell.
> Vielleicht hilft jemandem mein Lösungsansatz:
Jemandem aus Rostock, der nur dieses Jahr das Problem hat, bestimmt.
Mario M. schrieb:> Jemandem aus Rostock, der nur dieses Jahr das Problem hat, bestimmt.
da bleibe ich lieber bei meiner Rechnung aus Geokoordinaten
Beitrag "Re: Sonnenaufgang/Sonnenuntergang in Tabelle (Astro-Uhr/Dämmerungsschalter)?"
ist genauer aber ohne Lichtsensor, noch eins:
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
und die war nicht auf Rostock bezogen
Thread beobachten
Seitenaufteilung abschalten