Benutzer-Werkzeuge

Webseiten-Werkzeuge


project:hgg:timing_and_synchronization:dcf77

Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

Link zu dieser Vergleichsansicht

Beide Seiten der vorigen RevisionVorhergehende Überarbeitung
Nächste Überarbeitung
Vorhergehende Überarbeitung
project:hgg:timing_and_synchronization:dcf77 [2011-12-29 18:46] reloc0project:hgg:timing_and_synchronization:dcf77 [2012-05-12 17:44] (aktuell) – [Code] 93.231.147.84
Zeile 65: Zeile 65:
 Then it does not realise the minute ended at all... Then it does not realise the minute ended at all...
  
 +
 +===== And now for some nice imagery ===== 
 +
 +images of the signal we expected (top line) and the signal we got (bottom one) can be found in this schematic. 
 +
 +{{:project:hgg:timing_and_synchronization:dcf77_signal.png|}}
 +
 +As you can see, the fails of the module in a bad place can greatly screw up reading the signal.
  
 ====== Description of the Algorithm ======  ====== Description of the Algorithm ====== 
Zeile 72: Zeile 80:
 Note: We decided to use the inverted input (for no apparent reason). Note: We decided to use the inverted input (for no apparent reason).
  
-====== Starting phase ====== +===== Starting phase ===== 
  
 We wait for down edges and store the internal time when the pulse comes into a ringbuffer. We stay in this phase until the ringbuffer is full of valid entries. Entries are valid if the time delta between all the entries are 1 second +/- 10 msec appart.  We wait for down edges and store the internal time when the pulse comes into a ringbuffer. We stay in this phase until the ringbuffer is full of valid entries. Entries are valid if the time delta between all the entries are 1 second +/- 10 msec appart. 
Zeile 79: Zeile 87:
  
  
-We use this phase to predict when the next valid signal should come. This helps us to filter out random spikes in between the seconds and elliminates FAIL#1. +We use this phase to predict when the next valid signal should come. This helps us to filter out random spikes in between the seconds and elliminates FAIL#1.   
 + 
 + 
 +===== Running Phase =====  
 + 
 +In the running phase we wait for the DOWN edge of the signal. If it's within the predicted timeframe we assume it's a valid peak. A state transition to a state that detects the zero. 
 + 
 +===== ZERO-Detection Phase =====  
 + 
 +In this phase over a time of about 80 msecs reading the signal for 15 times is tried. Thus we can find out if the down edge was just a short peak that was randomly in the predicted time. This solves FAIL#1 (partly) and FAIL#2. It then goes to a ONE-Detection-Phase. It basically makes the signal sampling robust against peaks within the 100 msec time the signal should be down. 
 + 
 + 
 +===== ONE-Detection Phase =====  
 + 
 +In this phase the same as in the ZERO-Detection phase but if it detects the signal to be down in most samples for this timeframe, we note that we got a ONE-bit here, otherwise we got a ZERO-bit. 
 + 
 + 
 +===== The minute break =====  
 + 
 +If the peak was once ommited, we have a minute break. When the minute break comes up, we can decode the time for the current minute. 
 + 
 + 
 + 
 +===== About the algorithm =====  
 + 
 +I don't think you'll get it from the explanation, it's probably not good enough for that. Please read it, try to read the code and help improve it. Since I was part of writing the code, maybe i'm not the best person to tell other's what the point was. I hope i could anyway help with understanding what we did for this project.
  
  
  
 +===== Code ===== 
 +The code can be found in the [[https://github.com/shackspace/hgg/blob/master/hgg/modules/obsolete/dcf77/dcf77.pde|HGG repository]] 
  
-to be continued  
  
  
project/hgg/timing_and_synchronization/dcf77.1325180814.txt.gz · Zuletzt geändert: 2011-12-29 18:46 von reloc0