Binäre DCF77 Uhr mit exponentiellem Filter und Blinkenlighty

jurs:
Hast Du ein Oszilloskop und mit Deinem Conrad-Modul tatsächlich bei DCF-Störungen einen solchen Signalverlauf am Ausgang per Oszilloskop zu sehen bekommen?

Oder ist das ein rein von Dir angenommener Signalverlauf bei Störungen, der nicht mit einem Oszilloskop an einem realen DCF-Modul verifiziert wurde?

Hallo, ich bin fleißiger Mitleser, allerdings beruflich bedingt noch nicht viel zum Testen meiner DCF-Module (von Pollin und Conrad) gekommen. Ein 2-Kanal-50MHz-Oszilloskop hätte ich, wenn es konkrete Signalverläufe (z.B. beide Module an jeweils einem Kanal) darzustellen gilt, könnte ich die wohl auch liefern.

Meine damaligen Erkenntnisse habe ich hier festgehalten: sth77 | Arduino Blog: Projekt Analoguhr - Teil 3 Auf den viel zu kleinen Bildern erkennt man den Signalverlauf nicht besonders gut, das Video im Vollbildmodus scheint mir da besser geeignet.

sth77:
Hallo, ich bin fleißiger Mitleser, allerdings beruflich bedingt noch nicht viel zum Testen meiner DCF-Module (von Pollin und Conrad) gekommen. Ein 2-Kanal-50MHz-Oszilloskop hätte ich, wenn es konkrete Signalverläufe (z.B. beide Module an jeweils einem Kanal) darzustellen gilt, könnte ich die wohl auch liefern.

Meine damaligen Erkenntnisse habe ich hier festgehalten: sth77 | Arduino Blog: Projekt Analoguhr - Teil 3 Auf den viel zu kleinen Bildern erkennt man den Signalverlauf nicht besonders gut, das Video im Vollbildmodus scheint mir da besser geeignet.

Hallo, danke fürs Posten! Die von Dir gezeigten Signalverläufe passen eher zu dem, was mein Conrad-Modul auch liefert:

  • Einschwingfehler bzw. "Prellen": Beim Wechsel des Pegels kann es sein, dass ganz kurze Zeit danach der Pegel noch ein- oder mehrmals ganz kurz zurückschwingt und den Pegel mehrmals wechselt, bevor der Pegelwechsel endgültig vollzogen ist.

  • Spikes: Kurze, oft nur einzelne Störungen während ein Pegel gesetzt ist, die nach wenigen Millisekunden wieder verschwinden

Das von Udo in Bild http://blinkenlightblog.files.wordpress.com/2012/11/c05_simple_pulse_train_noise_60_1000.png gezeigte Störverhalten, mit ständigen und extrem kurzfristigen Pegelwechseln als ein dem Signal überlagertes "stochastisches Rauschen mit hoher Frequenz" kann ich für keines meiner Module nachvollziehen.

Anyway, wer selber Testen möchte, für den habe ich mein DCF-Modul-Testprogramm nochmal etwas weiter aufgebohrt.

Mit demselben Sketch kann man nun durch Setzen eines #define Statements sowohl zwei DCF-Module anschließen und deren Signale gegeneinander vergleichen. Oder man kann ein DCF-Signal vom DCF-Modul gegen das per Softwarefilter gefilterte Signal vergleichen.

Folgende Daten werden angezeigt (erste vier Spalten):
A/B: Signale der beiden DCF-Module, oder ein DCF-Modul und dessen gefiltertes Signal
0/1: Es wurde ein 0-Bit oder 1-Bit erkannt
xxx: Zahl zwischen 50 und 250 mit der erkannten Dauer des Bits
Die vierte Spalte gibt die Anzahl der fehlerhaften (<50ms) Impulse an, die zuvor seit dem letzten gültigen Bit aufaddiert wurden

Folgende Fehler im Signalverlauf werden angezeigt:

  • Summe der kurzen Pegelfehler (<50ms Pegelwechsel) zwischen zwei korrekten Impulsen (50 ... 250 ms)
  • Bitfehler '#': Derselbe Eingang liefert zwei Bits nacheinander, das Bit des anderen Eingangs fehlt dazwischen
  • Bitfehler '*': Ein Eingang liefert innerhalb von weniger als 500ms ein anderes Bit als der andere Eingang
    (wobei aber nicht sicher ist, dass der mit * gekennzeichnete Eingang tatsächlich das falsche Bit geliefert hat)
  • SYNC-Fehler: Ein Eingang liefert für mehr als 1500 ms überhaupt kein Bit (normal beim Minuten-Marker zur vollen Minute)

Die fünfstellige Zahl sind die letzten fünf Ziffern des millis() Timers

Beispiel:
B 0 124 0 24197
A 0 139 0 25168
B 1 178 0 25257*
A 1 218 1 26236
A 0 122 8 27148#
B 0 121 0 27197 SYNC
A 0 128 0 28149
B 0 129 0 28199

Erklärung:
In Sekunde 25xxx hat das B-Modul ein 1-Bit geliefert, aber das A-Modul ein 0-Bit, daher Bitfehler *

Bei Timer 27148 hat das A-Modul zweimal hintereinander gefeuert, daher Bitfehler #

Bei Timer 27197 tritt ein Sync-Fehler an Modul B auf, da das vorherige Bit von Modul B älter als 1500ms ist
(Modul B hatte davor zuletzt bei Timer 25257 gefeuert, und in Sekunde 26xxx gar nicht)

Na ja, das ist das beste, was ich als Auswertung herausholen konnte. Die Messung und Ausgabe der Werte verfälscht natürlich immer etwas das, was eigentlich genauestens vermessen werden soll. So dauert die Formatierung mit "printf" recht lange, Pegelwechsel werden also automatisch etwas "entprellt", ohne dass dies gewollt ist. Dadurch sieht das Signal des Conrad-Moduls etwas besser aus als es tatsächlich ist.

So wie das Programm unten einkopiert ist, dient es zum Testen von Udos Exponentialfilter.
Einfach DCF-Modul an Pin-2 hängen und Sketch laufen lassen mit Ausgabe über den seriellen Monitor.

Was man deutlich sieht: Der Exponentialfilter verzögert das DCF-Signal am gefilterten (B) Ausgang um ca. 50 ms.

Eine Verbesserung des Signals durch den Filter kann ich allerdings nicht feststellen, weder an einem mittelstark noch an einem stark gestörten Signal. Sobald der Störpegel hoch genug ist, dass die "High"-Pegel von Störsignalen zerhackt werden, so dass das Conrad-Modul keine einwandfreien Signale mehr liefert, ist auch das gefilterte Signal fehlerhaft (Sync-Fehler beim ungefilterten und beim gefilterten Signal in derselben Sekunde).

Nur sehr selten läßt sich durch das Filter eine gute Fehlerkorrektur erkennen wie hier:
A 0 70 1 68087
B 0 70 0 68137
A 0 51 0 69069
A 0 108 0 69186#
B 1 165 0 69233*
A 0 89 0 70087
B 0 90 0 70138

In Sekunde 69xxx feuert das Conrad-Modul zwei gültige Bits (51 und 108ms lang) in derselben Sekunde (Bitfehler #), aber das gefilterte Signal gibt nur ein einziges Bit aus, und zwar ein langes 1-Bit statt zweier kurzer 0-Bits, daher Bitfehler * angezeigt. Da man weiß, dass im DCF-Protokoll nur ein Bit pro Sekunde übertragen wird, kann man also davon ausgehen, dass das am gefilterten Ausgang(B) gelieferte 1-Bit korrekt ist und die zwei davor am A-Ausgang signalisierten 0-Bits falsch.

Im Schnitt ist auf dem gefilterten Signal zwar weniger Gezappel durch weniger Flankenwechsel, aber dabei gehen praktisch genau so viele Bits von Sekundenpulsen verloren wie bei der Auswertung des ungefilterten Signals. Denn das Gezappel durch Flankenwechsel tritt bei gestörtem Signal nicht gleichverteilt über das gesamte Signal auf, sondern bevorzugt um die Zeit herum, um die tatsächlich ein Flankenwechsel stattfindet. Und das läßt sich eigentlich auch durch ein einfaches Entprellen des Signals von wenigen ms gut herausfiltern.

Was ergeben Eure Tests?

Also meine anfängliche Euphorie über den Exponentialfilter und dass damit das Signal viel besser aussieht, konnte ich durch meine Messungen nun nicht mehr bestätigen. Zwar sind gefilterte Signale immer mindestens 50 ms lang, während ungefilterte Signale oft sehr zappelig sein können, aber da die Zappeligkeit fast nur um den eigentlichen Flankenwechsel herum auftritt, ist eigentlich auch das Originalsignal gut auswertbar.

Hier das Testprogramm zum vorherigen Beitrag:

/************************************************************************* 
 Testprogramm zum Testen von DCF-Modulen und DCF-Softwarefiltern
 
 Es können entweder zwei DCF-Module gegeneinander getestet werden
 Dazu die zwei Dateneingänge mit den Pins DCF_A_MODULE und DCF_B_MODULE verbinden
 und die Zeile "#define B_IS_FILTERED_A" auskommentieren
 
 Oder es kann ein DCF-Modul gegen einen Softwarefilter getestet werden
 Beispielhaft ist der hier vorgestellte Filter eingebaut:
 http://arduino.cc/forum/index.php?topic=135153.0
 Dazu das DCF-Modul an den Pin DCF_A_MODULE anschliessen und
 die Zeile "#define B_IS_FILTERED_A" in den Code einfügen
 (Der Pin DCF_B_MODULE bleibt dann frei.)
  
**************************************************************************/

// Pin fuer DATA-Ausgang des DCF-Moduls
#define DCF_A_MODULE 2

// Pin fuer DATA-Ausgang des zweiten DCF-Moduls oder den Software-Filter
#define DCF_B_MODULE 3

// die nachfolgende Zeile auskommentieren, wenn zwei Module getestet werden sollen
#define B_IS_FILTERED_A
// (wenn "#define B_IS_FILTERED_A" gesetzt ist, den Pin für das DCF_B_MODULE freilassen!)

// legt fest, an welchem Pin eine LED blinken soll
#define LED 13

#ifdef B_IS_FILTERED_A
  #include <MsTimer2.h>
#endif

char error[]="SYNC";
char noerror[]="";

void setup() {
  Serial.begin(9600);
  Serial.println();
  pinMode(DCF_A_MODULE, INPUT);
  pinMode(DCF_B_MODULE, INPUT);
  pinMode(LED, OUTPUT);
#ifdef B_IS_FILTERED_A
  pinMode(DCF_B_MODULE, OUTPUT);
  MsTimer2::set(1, low_pass_filter);
  MsTimer2::start();
#endif
}

#ifdef B_IS_FILTERED_A
void low_pass_filter() {
    // http://en.wikipedia.org/wiki/Low-pass_filter#Continuous-time_low-pass_filters
    // I will use fixed point arithmetics with 5 decimals
    const uint16_t decimal_offset = 10000;
    static uint32_t smoothed = 0*decimal_offset;
    const uint32_t input = digitalRead(DCF_A_MODULE) * decimal_offset;
//    const uint32_t input = analogRead(dcf77_analog_sample_pin)>200? decimal_offset: 0;
    // compute N such that the smoothed signal will always reach 50% of
    // the input after at most 50 samples (=50ms).
    // N = 1 / (1- 2^-(1/50)) = 72.635907286
    const uint16_t N = 72;
    smoothed = ((N-1) * smoothed + input) / N;
    // introduce some hysteresis
    static uint8_t square_wave_output = 0;
    if ((square_wave_output == 0) == (smoothed >= decimal_offset/2)) {
        // smoothed value more >= 50% away from output
        // ==> switch output
        square_wave_output = 1-square_wave_output;
        // ==> max the smoothed value in order to introduce some
        //     hysteresis, this also ensures that there is no
        //     "infinite memory"
        smoothed = square_wave_output? decimal_offset: 0;
      digitalWrite(DCF_B_MODULE, square_wave_output);   //changed jurs
    }
}
#endif


boolean 
  BdcfState,AdcfState,
  lastBdcfState=false,
  lastAdcfState=false;

byte
  AdcfBitval,BdcfBitval;

long 
  looptime,
  lastAdcfH,lastAdcfL,
  lastBdcfH,lastBdcfL,
  AdcfShortPulses,BdcfShortPulses,
  AdcfLastPulse,BdcfLastPulse,
  AdcfHighcycle, BdcfHighcycle;

void loop() {
//  looptime=millis()%100000L; // last 5 digits
  looptime=millis();
  AdcfState=digitalRead(DCF_A_MODULE);
  BdcfState=digitalRead(DCF_B_MODULE);
  digitalWrite(LED,BdcfState);
  CheckForHighCycle(looptime, AdcfState, lastAdcfState, AdcfHighcycle, lastAdcfH, lastAdcfL, AdcfShortPulses);
  CheckForHighCycle(looptime, BdcfState, lastBdcfState, BdcfHighcycle, lastBdcfH, lastBdcfL, BdcfShortPulses);
  printIfValidPulse('A', looptime, AdcfHighcycle, AdcfLastPulse, AdcfShortPulses, AdcfBitval, BdcfBitval, BdcfLastPulse);
  printIfValidPulse('B', looptime, BdcfHighcycle, BdcfLastPulse, BdcfShortPulses, BdcfBitval, AdcfBitval, AdcfLastPulse);
}

void printIfValidPulse(char c, long ltime, long &Highcycle, long &LastPulse, long &ShortPulses, byte &Bitval, byte OtherBitval, long LastOtherPulse)
{
  char *msg;
  char bitError;
  char buf[32];
  if ((Highcycle>=50)&&(Highcycle<=250))
  {
   // Falls mehr als 1500 ms kein Impuls ==> SYNC (Minutenimpuls oder Sync-Error) 
   if (looptime>LastPulse+1500) msg=error; else msg=noerror;
   // > 150 ms HIGH => 1-Bit, 50...150 ms HIGH => 0-Bit
   if (Highcycle>150) Bitval=1; else Bitval=0;
   // Biterror falls innerhalb der letzten 500 ms ein anderes Bit am anderen Eingang gemeldet wurde
   bitError=' ';
   // Biterror erkennen, falls weniger als 500 ms vorher ein anderes Bit am anderen Eingang erkannt wurde
   if ((looptime<LastOtherPulse+500)&&(Bitval!=OtherBitval)) bitError='*';
   // Biterror erkennen, falls der letzte Pulse vom selben Eingang kam
   if (LastPulse>LastOtherPulse) bitError='#';

   LastPulse=looptime;
   sprintf(buf,"%c %d %3ld %3ld %05ld%c%s", c, Bitval, Highcycle, ShortPulses,looptime%100000L,bitError,msg);
   Serial.println(buf);
   Highcycle=0;
   ShortPulses=0;
 }
}

void CheckForHighCycle(long looptime, boolean &State, boolean &lastState, long &Highcycle, long &lastH, long &lastL, long &ShortPulses)
{
  if (State!=lastState)
  {
    if (State==LOW)
    {
      Highcycle=looptime-lastH;
      if (Highcycle<50) ShortPulses++;
      lastL=looptime; 
    }
    else lastH=looptime;
    lastState=State;
  }
}

Interessanter Beitrag! Bin aber leider ebenfalls aus Zeitgründen noch nicht zum Testen gekommen. Hoffentlich schaffe ich das noch vor den nächsten Semesterferien :fearful:

Aber eine Frage kommt mir doch auf:
Du tastest mit einer Frequenz von 1 kHz ab. Fehlt da nicht noch irgendeine Form von analogem Tiefpass vor der digitalisierung, damit höherfrequente Störungen nicht in den niederfrequenten Teil des Spektrums rutschen?
Soetwas haben wir jedenfalls zum Thema Analog-Digitalwandlung in Verbindung mit digitaler Regelung in einer Vorlesung gehört...

Ich habe am Wochenende auch mal den DCF-Empfänger aus dem Conrad-Wecker ausgeschnitten. Die beiden Leiterbahnen die zum MC des Weckers gingen habe ich auf zwei digitale Eingänge gelegt. Einer liefert eine 1, der andere eine 0, daher vermute ich mal Signal und invertiertes Signal. Allerdings habe ich bisher noch keinerlei Änderungen an den Ausgängen feststellen können, ich muss mir noch eine bessere Position für den Aufbau suchen, zur Zeit sind da zu viele Netzteile und Monitore in der näheren Umgebung.

mkl0815:
Die beiden Leiterbahnen die zum MC des Weckers gingen habe ich auf zwei digitale Eingänge gelegt. Einer liefert eine 1, der andere eine 0, daher vermute ich mal Signal und invertiertes Signal. Allerdings habe ich bisher noch keinerlei Änderungen an den Ausgängen feststellen können, ich muss mir noch eine bessere Position für den Aufbau suchen, zur Zeit sind da zu viele Netzteile und Monitore in der näheren Umgebung.

Es ist zwar richtig, dass die DCF-Module von Conrad auch einen invertierten ausgang haben, so recht kann ich mir das bei einer Funkuhr jedoch nicht vorstellen. Da halte ich es eher für einen Eingang, um das Modul zu Stromsparzwecken ein- und ausschalten zu können.
Die Wikipedia schreibt im Funkuhr-Artikel dazu:

Obwohl das Zeitsignal kontinuierlich gesendet wird, wird es aus Stromspargründen oft nur ab und zu zum Nachstellen abgefragt. Bei Uhren, die mit größeren Zellen betrieben werden, ist ein Empfang jede volle Stunde üblich, bei Armbanduhren mit Knopfzellen oder mit Solarzellen nur einmal pro Tag, meistens zwischen 2:00 und 4:00 Uhr morgens.

Einen entsprechenden Eingang haben bspw. auch die Pollin-Module.

Hmm, guter Tipp. Bei den Pollin-Modulen wird der ON/OFF Eingang glaub ich auf Masse gezogen, um das Modul zu aktivieren. Ich werde das heute Abend mal testen.

Du tastest mit einer Frequenz von 1 kHz ab. Fehlt da nicht noch irgendeine Form von analogem Tiefpass vor der digitalisierung, damit höherfrequente Störungen nicht in den niederfrequenten Teil des Spektrums rutschen?

Wieso sollte es einen analogen Tiefpass brauchen? Der exponentielle Filter ist doch ein Tiefpass. "Analoge" Filter sind nicht auf magische Weise besser.

Kann der Digitale Filter denn die Aliaseffekte ausgleichen, die BEIM Abtasten entstehen?

And1G: ich dachte Du hast eine Vorlesung zu dem Thema gehört. Wieso fragst Du dann mich? Und vor allem wieso stellst Du Dich dumm? Selbstverständlich kann überhaupt kein Filter Alias Effekte ausgleichen die ins Passband rutschen. Die Frage ist nur: treten die tatsächlich auf? in meinem Fall also: gibt es Überlagerungen die nahe bei 500 Hz oder einer Oberwelle davon sind? Bei einem Empfänger der eine Bandbreite von wohel eher <300 Hz hat? Ich würde sagen nein. Wenn Du aber anderer Meinung bist, dann belege das doch bitte etwas genauer. Auf die Begründung bin ich mal gespannt.

Warum ich frage? Na weil meine bisherigen Kenntnisse etwas anderes sagen als das was du realisiert hast. Da wundert man sich und stellt dann halt eine Frage, ganz normaler Vorgang. Es hätte ja durchaus sein können, dass irgendetwas da zwischendurch eingekoppelt wird.
Kein Grund sich gleich angegriffen zu fühlen oder so genervt zu reagieren.

Dir ist aber schon klar, daß meine Implementation funktioniert? Von daher ist die Frage

Kann der Digitale Filter denn die Aliaseffekte ausgleichen, die BEIM Abtasten entstehen?

schon etwas offensiv. Dass dich das wundert war aus der Frage nicht zu ersehen. Die hat sich vom Ton eher angehört wie: "Du hast nur Glück und weisst vermutlich nicht was Du tust". Hast Du Dir die Quellen auf meiner Seite angesehen. Ich habe die gelesen und ausreichend weit verstanden.

Ich habe mal eine blöde Frage.
Ich experimentiere gerade mit dem Filter rum und hätte aber gerne den I2C frei.
Deshalb wollte ich den Eingangspin für das DCF77-Modul ändern.
Ich dachte dies geht hier:

const uint8_t dcf77_sample_pin = 19; // A5

19 = Analog 5
Wenn ich, sagen wir mal Analog 1 haben will:

const uint8_t dcf77_sample_pin = 15; // A1

Aber dann macht er nichts mehr.

Wo denke ich falsch?

MueThoS:
Aber dann macht er nichts mehr.

Wo denke ich falsch?

Wenn Du Dich auf den Original-Code beziehst:

const uint8_t dcf77_sample_pin = 19; // A5
const uint8_t dcf77_analog_sample_pin = 5;
...
//const uint32_t input = digitalRead(dcf77_sample_pin) * decimal_offset;
const uint32_t input = analogRead(dcf77_analog_sample_pin)>200? decimal_offset: 0;

Deklariert sind sowohl dcf77_sample_pin als auch dcf77_analog_sample_pin.

Die auskommentierte Codezeile bezieht sich auf dcf77_sample_pin und die ausgeführte Codezeile aber auf dcf77_analog_sample_pin.

Wenn Du den Code so verwendest, mußt Du entweder

  • die Deklaration für dcf77_analog_sample_pin ändern.
    oder
  • die Codezeile verwenden, in der dcf77_sample_pin verwendet wird und die andere auskommentieren.

Jetzt wo Du es sagst. :astonished:

Hab ich nicht gesehen.

Danke!

Ich glaube ich werde das nie lernen mit den Variablen Typen.
Ich versuche gerade das Funkuhrsignal in eine RTC zu schreiben.
von der Funkuhr bzw der Time.h bekomme ich ja :

sekund() minute() hour() year() month() day()

Das sind int wenn ich mich nicht irre. Diese werden mir auch schön im seriellen Monitor angezeigt:

17.12.2012 16:31:02

So die RTC (ich habe hier eine softI2C) nimmt die Daten richtig an wenn ich sie so schreibe:

uint8_t d[4];
d[3]=0x12; // Jahr
d[2]=0x12; // Monat
d[1]=0x16; // Tag
d[0]=0x01; // Wochentag

Das ist HEX-Schreibweise wenn ich mich nicht irre.
Wenn ich jetzt einfach die ints versuche zu übergeben sieht meine ausgelesene RTC so aus;

RTC: 11.0C.2001 01:1F:01

Das ist irgendwie falsch!
Gehe ich recht in der Annahme das ich aus dem int ein HEX machen muss?
Und wenn ja, wie?

MueThoS:
Gehe ich recht in der Annahme das ich aus dem int ein HEX machen muss?
Und wenn ja, wie?

Nein, Du mußt nur Deine RTC-Library korrekt anwenden!

Dazu schaust Du nach, welche RTC-Library Du installiert hast (da gibt es wohl viel mehr als nur eine).
Dann lädst Du Dir das Beispielprogramm zu dieser RTC-Library in Deine Arduino-Software.
Dann studierst Du das Beispielprogramm.

Beispielprogramme sind kommentiert und in den Programmkommentaren stehen die notwendigen Hinweise, wie die Library angewendet wird.

Mit 0x beginnende Zahlen sind unter C die Hex-Schreibweise im 16er System
0x12 = 116 + 2 = 18
0x16 = 1
16 + 6 = 22
0x01 = 0*16 + 1 = 1

Dies versuche ich ja!

Ich habe, wie gesagt, die softi2c nennt sich i2cMaster.
Das Beispiel Programm habe ich offen.

Und dort ist folgendes interessant:
wenn ich die Zeit stellen will wird dies aufgerufen:

uint8_t bcdRead(uint8_t min, uint8_t max, uint8_t &n) {
  uint16_t v;
  if (!hexRead(v)) return false;
  uint8_t d = 10 * (v >> 4) + (v & 0XF);
  if ((v >> 4) > 9 || (v & 0XF) > 9 || d < min || d > max) {
    PgmPrintln("Invalid");
    return false;
  }
  n = v;
  return true;
}

Was ich hier noch verstehe ist das hexRead aufgerufen wird.
dann kommt etwas was ich nicht verstehe. (uint8_t d = 10 * (v >> 4) + (v & 0XF):wink:
Und dann wird geschaut ob die Werte gültig sind.

hexRead:

uint8_t hexRead(uint16_t &v) {
  uint16_t n = 0;
  while (!Serial.available());
  while (Serial.available()) {
    uint8_t c = Serial.read();
    n <<= 4;
    if ('a' <= c && c <= 'f') {
      n += c - ('a' - 10);
    }
    else if ('A' <= c && c <= 'F') {
      n += c - ('A' - 10);
    }
    else if ('0' <= c && c <= '9') {
      n +=  c - '0';
    }
    else {
      PgmPrintln("Invalid entry");
      return false;
    }
    delay(10);
  }
  v = n;
  return true;
}

es wird gewartet bis was über Seriell rein kommt.
Dann werden die kommenden Daten in c gelesen
dann wird geschaut ob die Werte Zahlen sind (so denke ich)
und der rest ist wieder Bahnhof.

Hier wird die RTC beschrieben:

uint8_t writeDS1307(uint8_t address, uint8_t *buf, uint8_t count) {
  // issue a start condition, send device address and write direction bit
  if (!rtc.start(DS1307ADDR | I2C_WRITE)) return false;

  // send the DS1307 address
  if (!rtc.write(address)) return false;

  // send data to the DS1307
  for (uint8_t i = 0; i < count; i++) {
    if (!rtc.write(buf[i])) return false;
  }

  // issue a stop condition
  rtc.stop();
  return true;
}

Und wenn ich mir das anschaue würde ich sagen uint8_t *buf sollte mein Wert sein.
Also ein INT würde ich vermuten. Aber meine sekund() usw sind doch INTs

Und weil ich das nicht verstehe komme ich nicht weiter.

MueThoS:
Und weil ich das nicht verstehe komme ich nicht weiter.

Ich glaube, Du verhedderst Dich da in den Untiefen von Umrechnungen mit Zahlensystemen, von denen Du weder etwas verstehst noch dass Du sie benötigst.

BCD Zahlen sind Binary Coded Dezimals, binärcodierte Dezimalzahlen:

Damit kann man jede dezimale Ziffer von 0 bis 9 mit vier Bits darstellen.

Das wirst Du mit Sicherheit alles gar nicht benötigen.

Was Du immer benötigst, wenn es um Zeiten geht, das ist die Unix-Zeit.

Das ist ein long integer (32-Bit) Ganzzahlenwert mit der Anzahl der Sekunden seit dem 01.01.1970.

DAS ist es, womit Programmierer ihre Uhrzeiten handeln. Und wenn Du irgendeine Zeit-Library hast, dann gibt es einerseits bequeme Funktionen, um Tag, Monat, Jahr, Stunde, Minute, Sekunde in Unixzeit umzurechnen. Und umgekehrt genauso.

Und für Deine RTC-Library gibt es mit ziemlicher Sicherheit sowohl eine Schreibfunktion, der Du die Unixzeit übergeben kannst und auch eine Lesefunktion, von der Du die Unixzeit aus der Uhr geliefert bekommst.

Du hast es also im Endeffekt nur mit vier Funktionen zu tun, und die fressen allesamt Dezimalzahlen:

  1. Eine Umrechenfunktion von Tag, Monat, Jahr, Stunde, Minute, Sekunde in Unixzeit
  2. Eine Umrechenfunktion von Unixzeit in Tag, Monat, Jahr, Stunde, Minute, Sekunde
  3. Eine Uhr-Stellen Funktion, die eine Unixzeit zum Stellen der RTC übergeben bekommt
  4. Eine Uhr-Abfragen Funktion, die eine Unixzeit von der RTC geliefert bekommt

Wenn Du diese vier Funktionen bei Dir nicht findest, schreib mal genau, welche Time- und Realtime-Libraries Du installiert hast, dann schau ich mal in die Library rein!

Und Zahlensysteme wie Binärsystem, Hexadezimalsystem, und BCD-Zahlen kannst Du sicher getrost auf Lücke setzen, wenn Du nur eine Uhr stellen oder abfragen oder mit Zeiten rechnen möchtest, das sollte alles mit Dezimalzahlen zu erschlagen sein.

Unter "i2cmaster" finde ich nur eine Library, die was mit LCD-Displays zu tun hat, nicht mit RTC Uhren.

Also,
ich habe folgende Libraries die ich nutze:
softi2c von folgender Seite: (erster Beitrag)
http://forums.adafruit.com/viewtopic.php?f=25&t=13722
die Heißt dann I2cMaster

Time.h (Standard)

Hier aus diesem Fred:
DCF77.h
MsTimer2.h

Ich habe auch schon versucht die Libraries zu analysieren aber ich komme eben nicht weiter, deshalb frag ich.