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