Kommentar:
Einfügen von HTML im Kommentar:
Link einfügen: <a href="LINKURL" target="_blank">LINKTITEL</a>
Bild einfügen: <img src="BILDURL">
Text formatieren: <b>fetter Text</b>  <i>kursiver Text</i> <u>unterstrichener Text</u>
Kombinationen sind auch möglich z.B.: <b><i>fetter & kursiver Text</i></b>
C2 Quellcode formatieren: <code>Quellcode</code>
ASM Quellcode formatieren: <asm>Quellcode</asm>
(Innerhalb eines Quellcodeabschnitts ist kein html möglich.)
Wichtig: Bitte mache Zeilenumbrüche, bevor Du am rechten Rand des Eingabefeldes ankommst !  
> > 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. > > > > <code> > > 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; > > } > > } > > </code> > > > > > > > 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. >

Dateianhang: (.gif, .png., .jpg, .zip, .rar)

max. 256kB

max. 256kB