next topic »

[Reply #60 on:]

Die Feldstärke in DB zu ermitteln ist mit den einfachen Modulen nicht möglich. Die finale Ausbaustufe meiner Uhr wird aber die Qualität des dekodierten Signals ermitteln. Aktueller Stand ist, daß ich jetzt auch die Sekunden dekodieren kann. Ich bin exakt im Plan
 
http://blog.blinkenlight.net/2013/02/01/the-second-decoder/

[Reply #61 on:]

Die nächste Ausbaustufe ist fertig und dokumentiert: http://blog.blinkenlight.net/2013/04/01/what-time-is-it/. http://blog.blinkenlight.net/experiments/dcf77/decoding-time-data/. Die aktuell in Entwicklung befindliche Ausbaustufe hat auch die Sommerzeitumstellung richtig hinbekommen, ist aber noch nicht fertig dokumentiert

[Reply #62 on:]

Die nächste Ausbaustufe ist fertig und dokumentiert: http://blog.blinkenlight.net/2013/04/01/what-time-is-it/. http://blog.blinkenlight.net/experiments/dcf77/decoding-time-data/. Die aktuell in Entwicklung befindliche Ausbaustufe hat auch die Sommerzeitumstellung richtig hinbekommen, ist aber noch nicht fertig dokumentiert

Bekommst Du am Ende eigentlich mit Deinem DCF-Sketch den Speicher eines UNO voll, oder bleibt noch ein Rest an Speicher für was anderes übrig?  

Irgendwie verstehe ich das mit dem Hamming-Code nicht ganz. Einerseits wird das DCF-Signal nur mit einem einfachen Parity-Code gesendet, und Du konstruierst aus erwarteten Daten (bei bereits korrekt laufender Uhr?) und eintreffenden Daten ein Scoring, mit dem Du auch bei ständig falschen Parity-Codes aus der Abfolge mehrer Minuten nacheinander trotzdem die richtigen Werte auslesen willst?

Irgendwie wird mir das alles zu hoch, was Du da machst.  

[Edit] Jetzt habe ich mir mal den Sketch heruntergeladen und getestet: Huch, der ist ja gar nicht so groß?!
Und die exponentielle Filterung mit Sampling des Eingangssignals ist auch gar nicht mehr drin?!

Und wie lange braucht der Sketch, um die Uhrzeit zu bekommen? Habe hier mal gerade mit meinem Pollin-Modul und leichten Störungen getestet. Die "Quality"-Zeilen (die mir nichts sagen), habe ich mal dazwischen entfernt.

Dein Sketch fängt an mit:
Decoded time: ??:??:00
Wechselt nach einer Weile auf die richtige Sekunde:
Decoded time: ??:??:20
Decoded time: ??:??:21
Decoded time: ??:??:22
Decoded time: ??:??:23
...

Irgendwann wird wohl Stunde und Minute zu 00 und 00 erkannt (was nicht korrekt ist, Sekunde stimmt):
Decoded time: 00:00:26
Decoded time: 00:00:27
Decoded time: 00:00:28
Decoded time: 00:00:29
Decoded time: 00:00:30
Decoded time: 00:00:31

Dann wird die Stunde wieder unbekannt, die Minute zählt hoch (immer noch falsch), die Sekunde stimmt weiterhin:
Decoded time: ??:01:00
Decoded time: ??:01:01
Decoded time: ??:01:02
Decoded time: ??:01:03
Decoded time: ??:01:04
Decoded time: ??:01:05
Decoded time: ??:01:06
Decoded time: ??:01:07

Dann wird die Stunde wieder (falsch) zu 00 erkannt, die Minute unbekannt, die Sekunde stimmt weiterhin:
Decoded time: 00:??:20
Decoded time: 00:??:21
Decoded time: 00:??:22
Decoded time: 00:??:23
Decoded time: 00:??:24
Decoded time: 00:??:25
Decoded time: 00:??:26

Dann kommt wieder die Minute (Stunde falsch, Minute geht um wenige Minuten falsch):
Decoded time: 00:22:05
Decoded time: 00:22:06
Decoded time: 00:22:07
Decoded time: 00:22:08
Decoded time: 00:22:09
Decoded time: 00:22:10
Decoded time: 00:22:11
Decoded time: 00:22:12

Dann merkt er wieder, dass mit der Minute was nicht stimmt:
Decoded time: 00:??:14
Decoded time: 00:??:15
Decoded time: 00:??:16
Decoded time: 00:??:17
Decoded time: 00:??:18
Decoded time: 00:??:19

Nach ca. 15 Minuten stimmen dann Minuten und Sekunden:
Decoded time: 00:31:01
Decoded time: 00:31:02
Decoded time: 00:31:03
Decoded time: 00:31:04
Decoded time: 00:31:05

Na ja.

[Reply #63 on:]

Naja, am Ende wird die Uhr wohl so 22kBytes verpulvern. Das ist ziemlich wenig im Vergleich zur Leistungsfähigkeit. Einfache DCF77 Uhren (insbesondere alle kommerziellen) Uhren werden ja nicht einmal mit 1 Bitfehler pro Minute fertig. Meine Uhr wird locker mit mehr als 15 Bitfehler pro Minute fertig.

Das mit dem Hamming Code ist so, daß es keinen "Hamming Code" gibt. Es gibt eine "Hamming Metrik". Im Prinzip ist es ganz einfach. Stell Dir vor jede Minute würde das gleiche Signal gesendet. Dann wäre der Durchschnitt der empfangenen Werte eine naheliegende Schätzung für die richtige Zeit. Jetzt ändert sich die Zeit aber jede Minute. Was aber gleich bleibt ist der Zeitverlauf. Ich muß also nur die Phase erkennen. D.h. für verschiedene Startzeiten ergeben sich verschiedene aber jeweils vorbestimmte Zeitverläufe. Ich muß also nur den "naheliegendsten" Zeitverlauf bestimmen. "Naheliegend" zum empfangenen Signal eben. Die Frage ist wie man "Nähe" bei Signalen misst --> da kommt die Hamming Metrik ins Spiel. Das ist alles.

Probleme Dir dabei macht vermutlich, daß Dir nie jemand verraten/gezeigt hat, daß man "Abstand" auch anders festlegen kann als "euklidischer Abstand im 3-dimensionalen Raum".

Und ich will das nicht nur können, meine Uhr funktioniert bereits bestens. Wie gesagt, 15 Bitfehler pro Minute (und zwar JEDE Minute) sind kein besonders großes Problem. Bei 10 Bitfehlern pro Minute braucht die Uhr weniger als 15 Minuten um die korrekte Zeit zu ermitteln UND danach dauerhaft auf die Sekunde verriegelt zu bleiben.