| Re: dcf Zeit falsch Kategorie: Programmierung (von Norbert - 12.01.2009 21:29) | ||
| Als Antwort auf Re: dcf Zeit falsch von André H. - 11.01.2009 16:47 | ||
| ||
|
> Hallo Norbert, > > > Was macht eigentlich das CC2 OS genau mit dem dcf frame? > > > > Laut dcf Beschreibung werden sowohl time als auch date mit jeweils einem > > eigenen parity bit übertragen. Nun ist es natürlich denkbar, dass durch einen > > gro�en Zufall eine �bertragungsstörung trotzdem zu einem richtigen parity > > geführt hat. > > Dieses Problem ist bekannt und führt dazu, dass es für Programmierer empfehlenswert ist, > > zwei aufeinander folgende dcf frames nach Plausibilität zu prüfen: > > ... > > ... > > Ich werde nun meine Nachtroutine ändern, aber > > Was macht eigentlich unser CC2 Betriebssystem? > > Das OS prüft nicht die Parity-Bits, liest aber immer zwei DCF-Frames ein, und vergleicht, > ob beide "gleich" sind. "Gleich" bedeutet hier, da� alle Angaben au�er der Minute > identisch sein müssen. Bei der Minute mu� die Differenz aus neuem Frame und > zuvor eingelesenem Frame 1 betragen. > Ist dies nicht der Fall, wurd solange eingelesen, bis zwei aufeinanderfolgende Frames > nach dieser Prüfmethode korrekt sind. > Da das OS im laufenden Betrieb die Uhr nur zur vollen Stunde syncronisiert, d.h. frühestens > zwei Minuten nach Stundenwechsel werden die neuen Zeitdaten in die entsürechenden > Systemvariablen der CC2 geschrieben, reicht dies normalerweise aus. > Erfolgt ein Neustart der CC2 kurz vor Stundenwechsel, z.B. um x:58, dauert der Sync > mindestens 4 Minuten, da beim Frame um (x+1):00 die Stunden und evtl. sogar > die Datumswerte abweichen. > Da� bei zwei aufeinanderfolgende Frames vereinzelt derselbe Fehler auftaucht und somit > auf eine falsche Zeit syncronisiert wird, konnte ich leider schon feststellen. > Nicht nur bei µControllern, sondern auch bei normalen Funkuhren. > So unwahrscheinlich ist das leider nicht, wenn der Empfang an der Grenze ist, oder > etwas störendes in der Gegend ist, das in einem Minutenrythmus stören kann, so da� > dergleiche Fehler öfters hintereinander auftauchen kann. > Die Wahrscheinlichkeit, da� dies passiert, wäre wahrscheinlich geringer, wenn das OS > auch die Parity-Bits auswerten würde. > Jetzt wird meine ToDo-Liste schonwieder länger. :-) > > Ich habe vor längerem eine kleine Testroutine geschrieben, um DCF-Frames > "per Hand" ohne OS an einem normalen I/O einzulesen, da ich Empfangsprobleme hatte. > Das Parity prüfe ich aber hier auch nicht. :-) > Anbei das Programm. > > MfG André H. > > > const bcd[]=1,2,4,8,10,20,40,80; > const DOW_NAMES[] = "So", "Mo", "Di", "Mi", "Do", "Fr", "Sa"; > > thread main > {long timer;int bit,nr; > byte minute, stunde, tag, dow, monat, jahr; > string s1,s2; > hwcom.setspeed(8); > hwcom.clr(); > loop > { > wait ports.get(15); > timer=system.timer(); > wait not ports.get(15); > timer=system.timer()-timer; > if timer>1950 bit='F'; > else > if timer>1780 {bit='S';nr=-1;} > else > if timer>930 bit='F'; > else > if timer>880 bit='0'; > else > if timer>830 bit='F'; > else > if timer>780 bit='1'; > else bit='F'; > > hwcom.num(nr+1); > hwcom.tab(); > hwcom.num(timer); > hwcom.tab(); > hwcom.put(bit); > if bit=='F' > { > hwcom.tab(); > hwcom.print("Bitfehler"); > } > else > if nr==-1 > { > hwcom.tab(); > hwcom.print(DOW_NAMES[dow%7]); > s1= ' ' + (tag/10+0x30) + (tag%10+0x30) + '.' > + (monat/10+0x30)+ (monat%10+0x30) + '.' > + (jahr/10+0x30) + (jahr%10+0x30); > hwcom.print2(s1); > s2= 9 + (stunde/10+0x30) + (stunde%10+0x30) + ':' > + (minute/10+0x30) + (minute%10+0x30) + ":00"; > hwcom.print2(s2); > } > else > if nr==15 > { > hwcom.tab(); > if bit=='0' hwcom.print("Betriebsantenne"); > else if bit=='1' hwcom.print("Reserveantenne"); > } > else if nr==16 > { > hwcom.tab(); > if bit=='1' hwcom.print("Ankündigung Zeitumstellung"); > } > else if nr==17 > { > hwcom.tab(); > if bit=='0' hwcom.print("Normalzeit"); > else if bit=='1' hwcom.print("Sommerzeit"); > } > else if nr==18 > { > hwcom.tab(); > if bit=='0' hwcom.print("Sommerzeit"); > else if bit=='1' hwcom.print("Normalzeit"); > } > else if nr==19 > { > hwcom.tab(); > if bit=='1' hwcom.print("Ankündigung Schaltsekunde"); > } > else if nr==20 > { > hwcom.tab(); > if bit=='1' hwcom.print("Startbit Zeit OK"); > else hwcom.print("Startbit Zeit Fehler"); > } > else if nr>20 and nr<28 > { > if nr==21 minute=bit and 1; > else if bit=='1' minute=minute+bcd[nr-21]; > } > else if nr>28 and nr<35 > { > if nr==29 stunde=bit and 1; > else if bit=='1' stunde=stunde+bcd[nr-29]; > } > else if nr>35 and nr<42 > { > if nr==36 tag=bit and 1; > else if bit=='1' tag=tag+bcd[nr-36]; > } > else if nr>41 and nr<45 > { > if nr==42 dow=bit and 1; > else if bit=='1' dow=dow+bcd[nr-42]; > } > else if nr>44 and nr<50 > { > if nr==45 monat=bit and 1; > else if bit=='1' monat=monat+bcd[nr-45]; > } > else if nr>49 and nr<58 > { > if nr==50 jahr=bit and 1; > else if bit=='1' jahr=jahr+bcd[nr-50]; > } > > hwcom.ret(); > nr=nr+1; > } > } > > > > Hallo André, vielen Dank für die Testroutine dcf, aber: wenn ich lese, dass nach dem 1. dcf Sync nur zu vollen Stunden die dcf Zeit vom CC2 übernommen werden kann, mach ich mir jetzt Sorgen, dass das Problem tiefer sitzt. Die Störungen haben namlich deutlich nach der 2.Minute einer neuen Stunde stattgefunden. Genauer: 22.12.2008, 16:07:00 wurde im Logbuch protokolliert mit system.date; system.time; event ; FCS 02.12.2008 ; 16:07:00 ; "neuer Tag" ; ok ... bla bla bla ... und wurde erst um 16:10 richtig gestellt, traurigerweise wieder mit der Funktion "neuer Tag", die von mir stammt. Die zweite und ältere Beobachtung stammt vom 07.Juli 2008: 07.07.2008 05.07.2008; 19:28:00; "neuer Tag"; ok und wurde 4 Minuten später wieder korrigiert. Ich schreibe das deswegen so ausführlich, weil ich zeigen möchte, dass nur ein Bit gekippt ist, um z.B. aus einem 07.Tag einen 05. Tag zu lesen. Nun zu meinen Sorgen: das hei�t doch, dass eine system Variable falsch ausgelesen werden kann! Muss ich das Lesen von system.day() thread ... int day; ... if day != system.day() ... //neuer Tag mit capture verriegeln? Grü�e aus dem sonnigen Norden, Norbert P.S. mein Logbuch schreibt die Solarproduktion mit :) In einem weiteren sehr interessanten Beitrag schreibst du, dass Daten über den I2C-Bus natürlich ohne Checksumme übertragen werden. Da meine Logbuch events wegen schlechter Erfahrungen nur mit CRC Prüfung in das CC2Net RAM Device geschrieben werden, bin ich mir wenigstens hier sicher. Meine Beobachtungen sind die, dass etwa nach 300 bis 1000 solcher Logbuch Zeilen (30 Byte + 2 Byte FCS) eine Zeile genau 2. mal geschrieben werden musste.Tatsächlich ist es bisher noch nie vorgekommen, dass dieser Schreibvorgang 3. mal stattfand. | ||
Antwort schreiben Antworten: | ||