Vor nicht so langer Zeit habe ich als erstes grösseres AVR-Projekt eine DCF-Uhr fertiggestellt. Läuft recht gut, aber jetzt habe ich bei Freunden eine Wetterstation gesehen. Nichts Teures - keine 40 EU. Mit DCF und Mondphasen! Die will ich jetzt auch anzeigen! Für den Preis steckt bestimmt keine große Rechenleistung in der Wetterstation. Es gibt 8 Abwandlungen des Mondsymbols, das ändert sich nur alle 3 bis 4 Tage. Aber im Internet heisst es nur: Total schwer, großer Rechenaufwand mit 32 Bit Fliesskomma, riesige Tabellen! Nix für einen µC. Gibt es keine µC-kompatible Näherung, die über einige Jahre auf weniger, als +/-2 Tage genau ist?
Die Berechnung der Mondphasen ist an 100-ten Stellen im Netz aufgeführt. Die Kalendermenschen benötigen die Mondphasen zur Berechnung von Ostern und den davon abgeleiteten Feiertagen. Gurgel also mal nach "ostern mond". Hast Du den Anfang der Mondphase erst mal im Kasten, so sollte der Scheibenkleister (1/4, 2/2, 3/4 oder 'ne ganze Scheibe), für die nächsten 28 Tage wohl eine der einfachsten Übungen sein. Wenn Du richtig angeben willst, so kannst Du das Ganze auch mit 1/28-stel Auflösung hinbiegen. Muss aber nicht sein. Du kannst auch weiterhin über Fließkommaarithmetik jammern, denn um die kommst Du aus prinzipiellen Gründen (vielleicht Fixkommaarithmetik) nicht herum. Beschwerden bitte an Herrn Euler.
:
Bearbeitet durch User
In der Wetterstation kann man sich das Rechnen sparen wenn die Mondphase mit den Wetter-Bits geschickt wird :-)
Dankeschön - ging ja schnell! > http://www.die-seite.eu/wm-mondphasen.php define('ZYCLUS', floor(29.530588861 * 86400)); geht gleich mit GENAUEN Fliesskomma los. > Gurgel also mal nach "ostern mond". Wäre ein Ansatz - im Jahr könnte man vor und zurück rechnen. Aber die Osterformel vom ollen schlauen (!) Gauss ist etwas mehr, als das kleine 1 x 1... Mal sehen, ob ich noch Platz für passende Divisions-Routinen habe. > Wetter-Bits Habe ich nicht zur Verfügung.
Wie oft willst du denn die Mondphase neu berechnen? 1000 mal die Sekunde? Also ehrlich, einmal am Tag kann der uC durchaus mal eine Rechnung mit floats machen, das sollte ihn nicht komplett lahmlegen. Da kannste selbst mit sin und cos ohne Tabelen mit Näherungsformeln rechnen, oder ist dein AVR bis zum letzten kb voll?
Johann L. schrieb: > In der Wetterstation kann man sich das Rechnen sparen wenn die > Mondphase mit den Wetter-Bits geschickt wird :-) Sag bloss, du hast die Codierung geknackt?
Als Anfänger habe ich erst mal mit Tiny-AVRs und dem Mega8 losgelegt. Maximal 8 KB Flash. Habe aber nur noch < 1 KB Code frei. Ich dachte, eine Berechnung pro Stunde sollte bei +/-2 Tagen Genauigkeit reichen.
Für 100Jahre und 16Phasen, sollte doch ein Korrekturwert pro Monat ausreichen. Bei 16Phasen = 4bit = 600Einträge.
Ich habe mir mal ne Tabelle mit allen folgenden Neumonden berechnen lassen (da gibts tools im Internet). Die in Minuten seit dem 1.1.2000 umgerechnet, das macht Excel prima. Für die nächsten 20 Jahre war das gerade mal 1kB (21*20*4byte). Und so kann man ziemlich leicht den aktuellen Mondstand interpolieren. Synchronisiert sich bei jedem Neumond neu und ist damit langzeitstabil.
:
Bearbeitet durch User
Hallo, das ganze läßt sich auch prima mit Integer-Arithmetik lösen. (mit wenigen Stunden Toleranz). z.B. kann man die mittleren 29.5 Tage in 4,8 oder sogar 32 gleiche Teile (für die Anzeige) normieren. Z.B. 32 Teile zu 22.x Stunden. Jetzt braucht man nur eine Tabelle die für Stunden (Einer, Zehner), Tage, Monate und Jahre sowie Schaltjahre die Reste der Mondphasen für die Jahre 2000-2099 abspeichert. 16-Bit Werte reichen hier völlig aus. Die Werte werden in einem 16 Bit Phasenakku z.B. jede Minute aufsummiert. Die höchstwertigen 2-5 Bits enthalten also die aktuelle Mondphase je nach benötigter Anzeigenauflösung. Das ganze kostet gerade mal 100 Bytes für die Tabelleneinträge und ein bischen Integer Arithmetik. Gruß Anja
Es stellt sich noch die Frage, wofür man das ganze eigentliche braucht? Bei mir waren es Tierchen, die angeblich einen Mondzyklus brauchen, um ordentlich Nachwuchs zu erzeugen, wahrscheinlich hätte den ein simples Verfahren mit 28 oder 29 Tagen auch völlig genügt :-) Menschen kümmern sich i.a. nicht mehr um den Mond. Wenn man mal einen schönen Vollmond sieht, freut man sich kurz, das wars dann auch. Was hilft mir eine Anzeige der aktuellen Mondphase? Inzwischen können viele nicht mal mehr zwischen abnehmendem und zunehmendem Mond unterscheiden. Ist ja letztlich wirklich egal.
H.Joachim S. schrieb: > Es stellt sich noch die Frage, wofür man das ganze eigentliche braucht? Z.B. damit du weist wann die nächst Springflut ist. Gruß Anja
15(tag)+8(monat bei März beginnend)+21(epatta) = 44
44-30=14 ( mod 30)
Heute ist der 14 Tag im Mondkalender, Vollmond ist Morgen.
Epatta wird jedes Jahr um 11 incrementiert und jedes 19te Jahr eins
dazugezählt.
2016 = ( 2016*11+2016%19) %30=22
Da es nie ein Jahr 0 gegeben hat muss man 1 wegzählen.
epatta=21
Ich weiss nicht wie man die (e)patta auf Deutsch nennt.
Wenn man sich z.b merkt, 2014 ist epatta 29 braucht man weder Division
geschweige denn Fliesskomma.
chris schrieb: > Ich weiss nicht wie man die (e)patta auf Deutsch nennt. Epakte? https://de.wikipedia.org/wiki/Epakte
Das klingt schon mal gut! Goldene Zahl GZ = (j + 1) mod 19 dann die Epakte mit Epakte = ((GZ - 1) x 11) mod 30 Für das MODULO brauche ich wohl nur den REST einer 16/16-Bit-Division, wenn es um Jahr 2000 bis 2100 geht. Klingt, als ob ich damit leicht auf +/- 1 Tag komme. Liege ich da richtig?
15(tag)+8(monat bei März beginnend)+21(epatta) = 44
44-30=14 ( mod 30)
Samstag: 15 + 10-3 (Monat ab März) = 18 + 21 (epatta) = 43
Sonntag: 16 + 10-3 (Monat ab März) = 19 + 21 (epatta) = 44
modulo 30 = 13, oder 14 und dann???
Leerling schrieb: > modulo 30 = 13, oder 14 und dann??? Dann ab in eine Tabelle die daraus das passende Symbol berechnet. Gruß Anja
ich habe in meiner Uhr folgendes Programmteil für die Momdphase. Ist in BASCOM-AVR, aber wohl leicht verständlich. Ich habe gemerkt, dass eine Ungenauigkeit von einem Tag nach 4 Jahren auftritt. Deswegen werde ich wohl auf die Schaltjahrkorrektur verzichten.
1 | 'mondtest 13.4./25.8.12 |
2 | $crystal = 1000000 |
3 | $regfile = "m48def.dat" |
4 | $hwstack = 32 |
5 | $swstack = 10 |
6 | $framesize = 40 |
7 | |
8 | Dim Mondphase As Single |
9 | Dim Tagzahl As Integer , Anzahl As Integer |
10 | Dim X As Integer , Zusatz2 As Integer , Y As Integer |
11 | Dim Year As Byte , Zusatz1 As Byte , Zusatz As Byte |
12 | |
13 | Anfang: |
14 | Input "Tag_im_Jahr" , Anzahl |
15 | Input "Jahr: " , Year |
16 | |
17 | Y = Year / 4 |
18 | Y = Y - 3 'ab 2012 |
19 | Zusatz = Year Mod 4 'Schaltjahr ermitteln |
20 | If Zusatz = 0 Then |
21 | Zusatz1 = 1 |
22 | End If |
23 | Zusatz1 = Zusatz1 * Y |
24 | |
25 | Zusatz2 = Year - 13 |
26 | Zusatz2 = Zusatz2 * 365 |
27 | |
28 | Tagzahl = Anzahl + 48 'Basis ist 13.11.2012, Neumond |
29 | Tagzahl = Tagzahl + Zusatz1 |
30 | Tagzahl = Tagzahl + Zusatz2 |
31 | |
32 | Mondphase = Tagzahl / 29.53 |
33 | Mondphase = Frac(mondphase) 'ganze Mondzyklen abziehen |
34 | X = Mondphase * 100 'ganze Zahl |
35 | |
36 | Select Case X |
37 | Case 0 To 2 : Print "Neumond" |
38 | Case 3 To 23 : Print "zunehmend viertel" |
39 | Case 24 To 26 : Print "Halbmond zun." |
40 | Case 27 To 48 : Print "zunehmend dreiviertel" |
41 | Case 49 To 51 : Print "Vollmond" |
42 | Case 52 To 73 : Print "abnehmend dreiviertel" |
43 | Case 74 To 76 : Print "Halbmond abn." |
44 | Case 77 To 98 : Print "abnehmend viertel" |
45 | Case 99 To 100 : Print "Neumond" |
46 | End Select |
47 | |
48 | Goto Anfang |
49 | |
50 | End |
:
Bearbeitet durch User
Es geht! - Genau dieser Wunsch kam bei mir Anfang des Jahres. Zu Weihnachten gab es eine neue Wetterstation... Näherungsformeln für Ganzzahlrechnung im Netz? - Fehlanzeige! Also eine Mondtabelle für 1900 - 2100 mit Exxel genauer betrachtet: Von Neumond bis Neumond vergehen durchschnittlich 29,53062 Tage. Das sind 708,734448 Stunden. Summiert man alle Stunden seit einem Referenz-Neumond und multipliziert diesen Wert mit 0,011287726, so erhält man die 8-fache Anzahl der seit dem Ref- Neumond vergangenen Mondzyklen. Diese Anzahl modulo 8 ist die aktuelle Monpdhase. 0 = Neumond, 4 = Vollmond, etc. Der Mondlauf ist diversen periodischen Schwankungen ausgesetzt. Daher kann diese einfache lineare Rechnung nur auf +/-15 Stunden genau sein. - Ist sie aber auch noch in 100 Jahren! Die krummen Zahlen lassen es nicht vermuten, aber es werden beim AVR < 200 asm-Befehle gebraucht: Etwas Kalenderrechnung und eine 24 x 24 Bit Ganzzahl-Multiplikation. Dazu <= 20 Byte Daten für eine Tabelle der Tage im Monat und ein Übergabe-Array für Datum/Uhrzeit. Der Faktor 0,011287726 wird um x 2^30 "aufgeblasen": 12.120.103 (passt in 24 Bit) um dann vom Ergebnis die unteren 30 Bit zu ignorieren. Fließkomma voll überflüssig! Ablauf: Mit Kalenderrechnung die Tage seit dem 1.1.2000 ermitteln. Stunden = Tage x 24 Stunden = Stunden + Uhrzeit + 619 (619 für den Referenz-Neumond) - Das passt für 100 Jahre locker in 24 Bit. Stunden mit 12120103 multiplizieren. (24 x 24 Bit) Vom 6 Byte Ergebnis die Bits 30,31,32 per AND ausfiltern: Der Wert 0...7 ist die aktuelle Mondphase. Noch was: Um die +/-15 Stunden nicht zu verschlechtern: Datum/Zeit muss in utc eingesetzt werden. Sommer: Stunden-2, Winter: Stunden-1
Der Vorschlag von Jakob klingt erst mal nicht schlecht! Genauer als +/- 1 Tag in 100 Jahren. Da gibts bestimmt kein DCF mehr. ;-) Ein Array für Datum und Zeit habe ich schon für die DCF-Decdierung. Bevor die Zeit angezeigt wird. Die Tabelle für die Tage im Monat dient wohl der Kalenderrechnung. 12 Monate = 12 Byte. - Könnte noch in's DSEG passen. - Kalenderrechnung mit Schaltjahren? - Bei "AVR 24 x 24 Bit Multiplikation" liegen die GUGL-Treffer immer genau daneben. Hardware? Signed...? Hat der Mega8 doch nur für 8x8-Bit
Schau dir mal die Programme Moontool und HomePlanet an von John Walker: http://www.fourmilab.ch/ Die Quellcodes sind Public Domain und sehr ausführlich dokumentiert inkl. Quellenangabe zur verwendeten Literatur.
Hallo, Leerling, warum nicht auch noch die Sonnenauf- und -untergangszeit anzeigen lassen? Natürlich gültig für deinen Ort. Vielleicht dient mein Projekt als Anregung: http://www.sprachmelder.homepage.t-online.de/astrouhr.html Dort ist auch die Quelle der Berechnung angegeben. Vorgesehen war auch die Anzeige des Sternzeichens, aber da fehlte der Platz. dolivo
Leerling schrieb: > Total schwer, großer Rechenaufwand mit 32 Bit Fliesskomma, > riesige Tabellen! Nix für einen µC. Naja, man muß ja nicht immer alles in einen ATtiny13 quetschen. Float braucht einmalig ~1kB Flash, das ist selbst für den alten ATmega8 nur Pillepalle. Float-Angst ist heutzutage völlig unbegründet. Und was meinst Du mit riesigen Tabellen, etwa MByte? Ist auch kein Problem, da gibt es SPI-Flash, z.B. 4MByte: S25FL032P0XMFI011 http://de.farnell.com/spansion/s25fl032p0xmfi011/speicher-flash-32mb-3v-spi-8soic/dp/1972442
Leerling schrieb: > 15(tag)+8(monat bei März beginnend)+21(epatta) = 44 > 44-30=14 ( mod 30) > Samstag: 15 + 10-3 (Monat ab März) = 18 + 21 (epatta) = 43 > Sonntag: 16 + 10-3 (Monat ab März) = 19 + 21 (epatta) = 44 > > modulo 30 = 13, oder 14 und dann??? Monat ab März, da nicht ab 0 sondern 1 gezählt wird ist Oktober der 8te Monat, Zahl einfach mal nach: Mar, Apr. Mai Juni Juli Aug Sep Okt Samstag ist dann 14. Mondphasen: 0 Neumond 1-14 Wachsend 15 Vollmond 16-29 Abnehmend 11 Tage ist der Unterschied von SonnenJahr und Mondjahr. Am 1 Marz sind 59 bzw 60 Tage seit Jahresbeginn vergangen. Der Differenz des Restes ist wenn man alle 19 Jahre eins incrementiert, also 12 und nicht 11. Wenn man Ostern ausrechnet, und der Vollmond ist vor dem 21, dann muss man 30 dazu zählen um den nächsten zu bekommen. Sollte die patta aber 24 oder 25 sein darf man nur 29 dazu zählen. Dies ist eine Sonderregel und hat mit der Rundung des Restes zu tun.
Erwähnen sollte man auch noch die Möglichkeit der Simulation: Ausgehend von einem festgelegten Anfangsdatum mit bekannter Mondphase zählt man Tag für Tag bis zum gesuchten Datum vorwärts. Dabei muß man die Mondphase ja nur inkrementieren können, also von einem Tag auf den nächsten weitersetzen. Das braucht zwar bei der Anwendung (also wenn die Uhr gestellt wird) viel Rechenzeit, aber dafür sehr wenig Flash, Code und geistige Anstrengung beim Programmierer. Vor allem aus letzterem Grund war das vor Zeiten meine bevorzugte Methode zur Wochentagsberechnung (keine Lust BCD-Punktrechnung in 6502-Asm zu implementieren).
Auch eine datenintensive Lösung (statt einer codeintensiven) wäre durchaus realisierbar: Da während der nächsten 43 Jahre "nur" etwa 16000 Tage vergehen werden, würden 16 kByte Flash- oder EEPROM-Speicher ausreichen, um die Mondphasen z. B. mit zwei Einträgen pro Tag (0 Uhr und 12 Uhr, jeweils als Zahl zwischen 0 und 7) für diesen Zeitraum vorzuhalten. Würde mich nicht wundern, wenn es in der kommerziellen Uhr tatsächlich so oder so ähnlich (also geradezu abstoßend langweilig und banal...) gemacht ist. Der Preis eines 16 kByte-EEPROMs liegt heute bei Abnahme großer Stückzahlen im einstelligen Centbereich.
16 K Tabellen, oder float-Rechnung, oder < 200 Programmzeilen? Ehrlich gesagt, macht mir am µC Spaß, Problemstellungen durch etwas Nachdenken mit dem geringsten technischen Aufwand zu lösen. Wofür man das braucht? Zur Übung! Zur Freude am brauchbaren Ergebnis! - Mit esoterischem Kram gebe ich mich nicht ab. Wahrscheinlich auch die Wenigsten, die so eine Wetterstation mit Mondanzeige ganz nett finden. In grauen Novemberwochen kann man das auch nicht vor der Tür selbst erkunden. Am kompaktesten sieht die Epakten-Rechnung aus! Leider finde ich keine Quelle im Netz, die mehr, als die Osterdatumsberechnung nachvollziehbar erläutert. Ist die Genauigkeit besser, als ein Tag? Die 24-Bit-Geschichte mit +/-15 Stunden ist nachvollziehbar. Sie ist MINIMAL und genauer, als gewünscht. Mal sehen, ob ich die 24-Bit Multiplikation hinbekomme. Schaltjahre sollten auch lösbar sein. Die Float-Rechnung auf einem µC kostet nur 1 KB Flash? Schön - aber wenn ich mir die Berechnung bei http://www.die-seite.eu/wm-mondphasen.php ansehe, braucht die Rechnung auch noch viel Tabellenplatz.
Alternative Idee, etwas codeaufwendiger, aber deutlich datensparsamer: Man lässt einen PC für jeden ersten Tag (0 Uhr) im Monat ausrechnen, wieviele Achteltage der Mond zu diesem Zeitpunkt schon "alt" ist, wobei das Alter immer vom letzten Neumondzeitpunkt ab gerechnet wird. Dieser Wert liegt stets zwischen 0 und etwa 240 (der Mond kann maximal 30 Tage alt sein und weil ein Tag aus 8 Achteltagen besteht ergibt das 30·8 = 240), d. h. man kann ihn gerade noch in einem Byte abspeichern (deshalb fiel die Wahl auf Achteltage als Raster). Eine Tabelle für die nächsten 50 Jahre wäre also gerade mal 50·12 = 600 Byte groß. In einer zweiten Tabelle ist für alle möglichen Achteltagewerte von 0 bis etwa 240 + 8·31 = 488 die entsprechende Mondphase als Wert von 0 bis 15 aufgelistet. Bringt man in jedem Byte zwei solche Werte unter, wird die Tabelle nur 244 Byte belegen. Für eine bestimmte Uhrzeit eines bestimmten Tages (gegeben durch j, m, d, h) berechnet man zunächst die Summe a := a0[j, m] + 8·d + h/3 wobei a0 den Wert aus der ersten Tabelle bezeichnet. Achtung: a kann größer als 255 werden ==> Addition mit 16 bit ausführen. 8·d sind drei Linksshifts und "h/3" ist auch kein Problem; das kann man gleichwohl mit einer Minitabelle machen, oder wenn der Controller "mul" kann: h/3 = (h·86)/256). Im zweiten Schritt benutzt man a als Index zum Auslesen der zweiten Tabelle und das wars dann auch schon. Auf diese Weise dürfte die Sache simpel, schnell, ziemlich genau und mit weniger als 1 KByte Flash Memory (inklusive des Codes) erledigt sein. Wenn Du das mit irgendwelchen float-Rechnungen oder 24-24-bit-Multiplikationen toppen kannst, lass es mich bitte wissen. Viel Spaß beim coden :-)
Es freut mich, dass sich hier die echten Tüftler ein Stelldichein geben. Hier meine 10 Jahre alte Version der 32x32-Mul: Beitrag "Re: Rechnen mit AVR" Es gibt für den gcc eine 64-bit-Erweiterung. Damit sollte es direkt ohne Verrenkungen funktionieren. Off Topic: Chris, ich brauche mal Deine Hilfe. Bitte sei so gut und schreibe mir bitte eine Nachricht: mikrocontroller.net/user/show/eprofi (Dazu musst Du angemeldet sein.) Oder wie kann ich Dich erreichen? Gerne als Rätsel!
ICH bin mir nicht sicher, aber schießt ihr hier nicht weit übers ziel hinaus? Plus minus 1-2 Tage... Scheiß drauf... DCF funst nur 99Jahre und wer will schon mit nem Tele. die mm nachmessen??? PS. Ausnahmen vorbehalten :P
Teo D. schrieb: > DCF funst nur 99Jahre Unsinn. DCF könnte prinzipiell bis in alle Ewigkeit funktionieren. Man muss nur darauf achten, dass der Client einen plausiblen Startwert für die Ära mitbekommt und selber dann auch ununterbrochen bis in alle Ewigkeit läuft. Naja, und er muss genug fehlerfreie Telegramme empfangen, dass sein Eigenfehler niemals über 100 Jahre anwächst...
c-hater schrieb: > Teo D. schrieb: > >> DCF funst nur 99Jahre > > Unsinn. DCF könnte prinzipiell bis in alle Ewigkeit funktionieren. Man > muss nur darauf achten, dass der Client einen plausiblen Startwert für > die Ära mitbekommt und selber dann auch ununterbrochen bis in alle > Ewigkeit läuft. > > Naja, und er muss genug fehlerfreie Telegramme empfangen, dass sein > Eigenfehler niemals über 100 Jahre anwächst... c-hater schrieb: > Teo D. schrieb: > >> DCF funst nur 99Jahre > > Unsinn. DCF könnte prinzipiell bis in alle Ewigkeit funktionieren. Man > muss nur darauf achten, dass der Client einen plausiblen Startwert für > die Ära mitbekommt und selber dann auch ununterbrochen bis in alle > Ewigkeit läuft. > > Naja, und er muss genug fehlerfreie Telegramme empfangen, dass sein > Eigenfehler niemals über 100 Jahre anwächst... Wie willst du 2000 von 2100 UNTERSCHEIDEN? Wenn nur 99 MÖGLICHE Jahre ÜBERTRAGEN werden?
@ LostInMusic (Gast) < 1 KB gesamt ist doch ein halbwegs passender UND sogar halbwegs nachvollziehbarer Vorschlag! Ich muss das mal nachrechnen. - Wie kommst du auf 488? Das sind 30,5 statt der 29...30 Tage pro Mondzyklus. Was heißt hier toppen? Ich hatte ziemlich genau den Wunsch vom TO und wollte in meine DCF mit Tiny861 noch die Mondphasen in 8 Schritten unterbringen. Meine Lösung kostet exakt 326 Byte Code, 12(20) Byte Daten und etwa 800 Rechenschritte. Weniger, als eine ms bei 1 MHz. Bei +/-15 Stunden Genauigkeit (getestet) über die nächsten 50 Jahre reicht es natürlich, die einmal pro Stunde aufzurufen. +/-15 Stunden sind < 1/3 jeder der 8 angezeigten Mondphasen, also niemals falsch, oder grenzwertig. Mehr wollte ich nicht. Und vielleicht der TO auch nicht. @ Leerling (Gast) Was die 24x24 Bit Multiplikation angeht: Das ist nur eine Erweiterung von (bitte gugeln): "mpy16u" - 16x16 Bit Unsigned Multiplication Braucht nur 3 Register und die Rechenschritte für diese Register mehr. Kann ich auch reinstellen. Die Schalttage ST der vergangenen Jahre seit 01.01.2000? JJ = JAHR - 2000 (also zweistellig, wie es vom DCF kommt) ST = ((JJ-1) / 4) + 1 Das braucht nur Decrement, Shift und Increment.
Oha, hier sind auch junge Leute! Schön! Klar, dass da Bandsalat, Telefonzelle und DCF vor 2000 nur Fragezeichen hervorrufen... Lasst euch sagen: DCF hat schon im vorigen Jahrhundert funktioniert, nur der Jahrhundertwechsel hat schlechten Programmen echt Probleme bereitet. Sollte es DCF in hundert Jahren noch geben, sollte man ab 2050 schlau genug programmieren, damit alle Jahreszahlen JJ < 50 als 2100 + JJ interpretiert werden. 100 Jahre läuft wohl kein Programm, aber manchmal zig Jahre länger, als gedacht!
Jakob schrieb: > 100 Jahre läuft wohl kein Programm, aber manchmal zig Jahre > länger, als gedacht! OK, Hundert PLUS START mag funzen, aber mehr??? Aber egal, es geht hier ja um max 1/16 (?) Mondphase und nicht um Minuten/Stunden! (Oder dem Arsch der das um mm in Real Überprüft)
Meine Rechnung ist getestet bis 2070, ohne dass sich die zyklische Abweichung von +/-15 Stunden merklich verändert. Verglichen habe ich mit den Monddaten nach JAN MEEUS, die auch von Astronomischen Jahrbüchern benutzt werden. Damit dürfte das auch über vielleicht 250 Jahre nutzbar sein. Die paar Schaltsekunden pro Jahrzehnt kann man dabei ignorieren. Aber Vorsicht Teo: Falls du es noch erlebst - 2100 ist KEIN Schaltjahr. ;-)
Jakob schrieb: > Aber Vorsicht Teo: > Falls du es noch erlebst - 2100 ist KEIN Schaltjahr. ;-) Geht MIR und DCF am Arschvorbei! PS: was is eigentlich mit den "Schaltsekunden"?
Teo schrieb: > Wie willst du 2000 von 2100 UNTERSCHEIDEN? > Wenn nur 99 MÖGLICHE Jahre ÜBERTRAGEN werden? Das schrieb ich doch: Man setzt beim Start die zum Startzeitpunkt korrekte Ära (also die ersten zwei Stellen der Jahreszahl). Und dann läßt man eine eigene Zeitbasis mitlaufen, die immer wieder durch DCF synchronisiert wird. Und schon weiss man jederzeit (aus dem Fortschreiten der Eigenzeit), welches Jahrhundert ist. Jedenfalls solange das System läuft und häufig genug Telegramme empfängt, um die Eigenzeit synchron zu halten. Der Code für ein dafür hinreichendes Kalendersystem kostet weniger als 200 Byte Flash.
c-hater schrieb: > Und dann > läßt man eine eigene Zeitbasis mitlaufen Boo... wie unrealistisch! Aber Du hast recht, es funst. Wenn's die 99 erreicht hat, diese mehrfach bestätigt wurden, ein Flag in's EEPROM und gut is :) c-hater schrieb: > Der Code für ein dafür hinreichendes Kalendersystem kostet weniger als > 200 Byte Flash. Das läuft sowieso, ich mag's nicht wenn das Datum Amok läuft, nur weil ein paar Tage kein DCF empfangen wird.
@eprofi Bekomme die Kopie der pm nicht, Ansonsten scx drei eins eins eins vier @ yahoo dot com In Nummern.
Teo schrieb: > Wie willst du 2000 von 2100 UNTERSCHEIDEN? > Wenn nur 99 MÖGLICHE Jahre ÜBERTRAGEN werden? Am Wochentag?
Route 6. schrieb: > Teo schrieb: >> Wie willst du 2000 von 2100 UNTERSCHEIDEN? >> Wenn nur 99 MÖGLICHE Jahre ÜBERTRAGEN werden? > > Am Wochentag? Spätestens 2400 geht das aber auch nicht mehr :(
Ziegenpeter schrieb: > Spätestens 2400 geht das aber auch nicht mehr :( Richtig, spätestens ab da geht es garantiert nicht mehr eindeutig. Und auch schon deutlich vorher muss man u.U. jahrelang DCF lauschen, bis man die Ära bestimmen kann. Ich hatte keine Lust, darüber nachzudenken, wie viele Jahre das im schlimmsten Fall sein mögen, auf jeden Fall wird es aber zumindest etliche Situationen geben, wo man ganze vier Jahre braucht, um zu einer Entscheidung zu kommen...
Lustig hier: Man erklärt sein Problem und es kommen sofort einige mehr, oder weniger am Problem orienterte Lösungen. Die Vorschläge von LostInMusic und Jakob kommen mir am nächsten: Vielen Dank! chris erklärt seinen vielversprechenden Lösungsweg leider nicht genauer. Und irgendwann löst sich alles in Spinnerstreit auf...
Thread beobachten
Seitenaufteilung abschaltenBitte 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.