DCF77 Zeit öffters updaten und auf plausibilität prüfen

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • DCF77 Zeit öffters updaten und auf plausibilität prüfen

      Hallo,

      ich habe in letzter Zeit ein paar Probleme mit meiner Funkuhr.
      Ich müsste überprüfen ob der Wert der neuen _sec _min _hour ungleich 0 ist.
      Bevor er übernommen wird.
      Wie könnt ich das anstellen?

      Zur Zeit wird einfach der Wert übernommen und so hab ich öffters mal um 6 Uhr früh
      2 Uhr.

      Außerdem würde ich gerne dei Updaterate erhöhen.

      Grüße
      Alex
    • Hallo,

      ich glaub ich habs selber gelöst mit "Check = 2, Update = 0"

      Source Code

      1. Config Portb.0 = Input
      2. Config Dcf77 = Pinb.0 , Timer = 1 , Timer1sec = 1 , Debug = 1 , Check = 2 , Update = 0,
      3. Enable Interrupts
      4. Config Date = Dmy , Separator = .
      Mich würde noch intressieren ob man den Update irgendwie so konfigurieren kann das er nur alle 5 min neue Daten holt?

      Grüße
      Alex
    • In der Bascomhilfe steht dazu

      Mcs wrote:

      UPDATETIME

      This value depends on the used UPDATE parameter.
      When UPDATE is 1, the value must be in the range from 0-59. Start every hour at this minute with the new update.
      When UPDATE is 2, the value must be in the range from 0-23. Start every day at this hour with the new update.
      The default is 0.
      Ansonsten bleibt nur, alles zu Fuß zu programmieren.
      Eine Lösung habe ich nicht, aber mir gefällt Ihr Problem.
    • Hallo!

      Dieses Thema zeigt sehr schön das manche das Thema DCF77 noch nicht wirklich begriffen haben.
      DCF77 ist ein sehr langsames und vor allen auch massiv störanfälliges System der Zeitübertragung.

      Hätte man einen idealen Empfänger in ungestörter Umgebung (mitten in der Pampa, xxKm entfernt von Städten und Industrie) und bombastischen Empfang, und ebenso das Glück das kein Gewitter am Horizont vorbei zieht, dauert der Empfang eines kompletten Zeitprotokolls mindestens 58 Sekunden.

      Im Realfall hat so einen idealen Empfänger niemand, sondern nur ein DCF1 oder DCF2 von Pollin oder ELV irgendwo in der Wohnung.
      Dort ist es schon als Glücksfall zu betrachten wenn innerhalb einer Stunde wenigstens 20 Zeitstempel korrekt erkannt werden, von insgesamt 60.

      Daher gilt als Grundsatz für DCF-Uhren: Die Ganggenauigkeit der eigenen Uhr sollte genau gennug sein, um nur alle paar Stunden (regelfall alle 24 Stunden) einmal gestellt zu werden.

      Im Regelfall wird bei Funkuhren immer eine 32kHz-RTC gelegeltich mittels DCF77 korrigiert. Die Ganggenauigkeit zwischen den DCF-Korrekturen ist dann Sache der eigenen RTC.

      Die Bascom Lib geht leider einen anderen Weg:
      Config DCF ist nicht mit einer asynchronen RTC an Timer2 kombinierbar, sondern emuliert eine RTC mit der Main-CLK.
      Heißt genau genommen:

      Der interne RC-OSC der ATmegas taugt NICHT für sowas.
      Und ein externes Quarz taugt auch nur eingeschränkt:
      Will man die DCF-RTC von der Bascom-Lib auf 1-2 Sekunden Abweichung in 24h trimmen, muss man statt der 16-20pF Kondensatoren am Quarz ein Kapazitätstrimmer bestücken mit dem man die Ganggenauigkeit justiert.

      Genau sowas steht seit gut 6~7 Jahren in meinem Arbeitszimmer. Bascom-Lib mit manuell via Trimmer abgeglichener 8MHz-Quarz an einem ATmega16 freilaufend und jeden morgen um 03:00Uhr springt die DCF-Synchronisierung an.
      Gangabweichung in dem Augenblick der RTC-Stellung im Bereich 0,5-1s

      Eine andere Alternative ohne Trimmer am Quarz die Bascom DCF-Routine halbwegs genau zu bekommen wäre eine externe RTC.
      Die kann man dann auch jede Minute via I²C fragen wie spät es ist.
      Genau das geht mit DFC77 aber eben nicht.

      Grüße

      Jürgen
    • Also ich bin mit meinen Funkuhren zufrieden. Dabei verwende ich meist 16Mhz Quarz und einen Pollinempfänger. Ich stelle in den Dcf-Optionen allerdings check=2 und update=0 ein, größter Überprüfungsaufwand und update immer wenn was gültige kam. Rtc verwende ich dann, wenn sofort nach dem Einschalten eine gültige Zeit gebraucht wird, oder wenn die Peripherie soviel stört, dass ein dcf nicht möglich ist. Dann wird die halt um 3Uhr früh mal kurz abgeschaltet und auf einen gültigen Empfang gewartet. So gibt's nur minimale Abweichungen und Sommer/Winterzeit passt auch.
      Raum für Notizen

      -----------------------------------------------------------------------------------------------------

      -----------------------------------------------------------------------------------------------------
    • Hallo tschoeatsch!

      tschoeatsch wrote:

      Also ich bin mit meinen Funkuhren zufrieden. Dabei verwende ich meist 16Mhz Quarz und einen Pollinempfänger. Ich stelle in den Dcf-Optionen allerdings check=2 und update=0 ein, größter Überprüfungsaufwand und update immer wenn was gültige kam.

      Check = 2 ist das einzige was Sinn macht. Alles unter 2 ist sogar fahrlässig.
      Mit Check 2 dauert ein kompletter Empfang zwar 3 Minuten (bei optimalem Empfang), aber das Ergebniss ist weitgehend verlässlich.

      Eine Synchronisierung der Softclock häufiger als stündlich ist aber m.E. fragwürdig.


      tschoeatsch wrote:

      Dann wird die halt um 3Uhr früh mal kurz abgeschaltet und auf einen gültigen Empfang gewartet. So gibt's nur minimale Abweichungen und Sommer/Winterzeit passt auch.

      Genau da sprichst du hingegen einen Punkt an der mich letztens erst verwundert hat.
      Trotz eigentlich erträglichem Empfang mit Check = 2 sprang der Inhalt von DCF77TimeZone() munter umher zwischen 0, 1 und 2.
      Wie kann das sein?

      Und siehe da: Die Zeitzonen-Bits liegen bei DCF77 in einem Sekundenbereich der keinerlei Datensicherung hat, während der Zeitstempel hingegen je Byte zumindestens ein Parity hat.
      Wo das DCF-Protokoll kein Prüfbit hat, kann die Bascom-Lib auch nichts testen.

      Sicherlich könnte man mit den Zeitzonen-Bits einen Vergleich mit den Vorwerten machen, wie Check = 2 es ja auch mit dem Zeitstempel macht. Macht sie aber mit DCF77TimeZone() nicht.
      Ebenso könnte man eine Sicherung nach Kalender und Ankündigungsbits realisieren, macht die Lib also auch nicht.

      Daher ist und bleibt die Zeitzone (MEZ/MESZ) ein Glückspiel:

      BASCOM Source Code

      1. Sectic: 'Sub Sectic, wird sekündlich von RTC aufgerufen
      2. SyncSec = SyncSec + 1
      3. If dcf_status.7 = 1 then 'Wenn DCF-Synchronisierung aktuell...
      4. Timezone = DCF77TimeZone()'...kopiere Zeitzone
      5. Weekday = DayOfWeek() '...kopiere Wochentag
      6. SyncSec = 0 'Rücksetzung SyncSec
      7. SyncMin = 0 'Rücksetzung SyncMin
      8. SyncHour = 0 'Rücksetzung SyncHour
      9. RESET dcf_status.7
      10. end if
      11. Return
      Display All
      Das war mein Versuch DCF77TimeZone() blitzschnell nur dann zu übernehmen in eine eigene Variable, wenn alle anderen (prüfbaren) Felder als korrekt erkannt wurden.

      Dennoch springt der Wert Timezone gelegentlich umher, wenn auch deutlich seltener als vorher.

      Grüße

      Jürgen