Forum: Mikrocontroller und Digitale Elektronik DCF und Mondphase


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Leerling (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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?

von mondphasen (Gast)


Bewertung
0 lesenswert
nicht lesenswert

von Sebastian S. (amateur)


Bewertung
0 lesenswert
nicht lesenswert
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
von Johann L. (gjlayde) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
In der Wetterstation kann man sich das Rechnen sparen wenn die Mondphase 
mit den Wetter-Bits geschickt wird :-)

von Leerling (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Sven S. (boldie)


Bewertung
0 lesenswert
nicht lesenswert
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?

von npn (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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?

von Leerling (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Teo D. (teoderix)


Bewertung
0 lesenswert
nicht lesenswert
Für 100Jahre und 16Phasen, sollte doch ein Korrekturwert pro Monat 
ausreichen.
Bei 16Phasen = 4bit = 600Einträge.

von H.Joachim S. (crazyhorse)


Bewertung
0 lesenswert
nicht lesenswert
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
von Anja (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von H.Joachim S. (crazyhorse)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Anja (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von chris (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Bärchen (Gast)


Bewertung
0 lesenswert
nicht lesenswert
chris schrieb:
> Ich weiss nicht wie man die (e)patta auf Deutsch nennt.

Epakte?
https://de.wikipedia.org/wiki/Epakte

von Leerling (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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?

von Leerling (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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???

von Anja (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Leerling schrieb:
> modulo 30 = 13, oder 14 und dann???

Dann ab in eine Tabelle die daraus das passende Symbol berechnet.

Gruß Anja

von Dieter S. (dolivo)


Bewertung
0 lesenswert
nicht lesenswert
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
von Jakob (Gast)


Bewertung
3 lesenswert
nicht lesenswert
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

von Leerling (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von Marek N. (bruderm)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Dieter S. (dolivo)


Bewertung
0 lesenswert
nicht lesenswert
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

von Peter D. (peda)


Bewertung
0 lesenswert
nicht lesenswert
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

von chris (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Nosnibor (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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).

von LostInMusic (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Leerling (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von LostInMusic (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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 :-)

von eProfi (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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!

von Teo D. (teoderix)


Bewertung
0 lesenswert
nicht lesenswert
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

von c-hater (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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...

von Teo (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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?

von Jakob (Gast)


Bewertung
0 lesenswert
nicht lesenswert
@ 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.

von Jakob (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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!

von Teo (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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)

von Jakob (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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. ;-)

von Teo D. (teoderix)


Bewertung
0 lesenswert
nicht lesenswert
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"?

von c-hater (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Teo D. (teoderix)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Chris S. (schris)


Bewertung
0 lesenswert
nicht lesenswert
@eprofi
Bekomme die Kopie der pm  nicht,
Ansonsten scx drei eins eins eins vier  @ yahoo  dot com
In Nummern.

von Route_66 H. (route_66)


Bewertung
0 lesenswert
nicht lesenswert
Teo schrieb:
> Wie willst du 2000 von 2100 UNTERSCHEIDEN?
> Wenn nur 99 MÖGLICHE Jahre ÜBERTRAGEN werden?

Am Wochentag?

von Teo (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Route 6. schrieb:
> Am Wochentag?

Auch nich schlecht :)

von Ziegenpeter (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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 :(

von c-hater (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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...

von Leerling (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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...

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.