Seite 4 von 4 ErsteErste ... 234
Ergebnis 31 bis 39 von 39

Thema: DCF77 mit Pollin DCF1 Modul

  1. #31
    Neuer Benutzer
    Registriert seit
    02.11.2016
    Beiträge
    54
    Hallo DG7GJ

    Deine theoretischen Abhandlungen sind schon toll nur nicht Praxistauglich. Noch mal meine Frage, warum diese Stolperumwege, wenn es nachweislich besser geht.

    Bin nur ein Praktiker mit bescheidenen Theorie- Level. Ha, Ha also zu Blöd.

    Na gut klinke ich mich aus, schreibt man wohl so.

    Gruß

  2. #32
    Kabelträger
    Registriert seit
    08.12.2016
    Beiträge
    26
    Hallo fredfred,

    Zitat Zitat von fredred Beitrag anzeigen
    verfolge mit Interesse diese Thema.
    Habe aber noch nicht verstanden warum du zusätzlich Config Clock = Soft und ein 32KHz Quarz verwendest.
    Komme ohne diese Soft- Hardware bestens zurecht.
    Macht doch alles die Bascom dcf77 lib von Josef Vögel und ist auch sehr gut beschrieben, finde ich.
    Kennst ja diese, wie ich lese, aber warum nicht nutzen und eventuell auf eigenem Projekt anpassen?
    Weil es mir aktuell um kein konkretes Projekt geht, sondern um ein Versuchsprojekt um grundlegende RTC-Probleme zu evaluieren.
    Da geht es bei mir um einen ganzen haufen von Projekten die genau an der Stelle scheitern.

    DCF77 ist eine feine Sache für Projekte wo:
    - Der Timer1 frei ist für solche Spielchen
    - Wo im bereich um 30-100kHz keine Schaltregler oder PWM-Krams umsaut
    - Wo perfekter Empfang von DCF77 vorrausgesetzt werden kann
    - Wo mechanisch Platz für ein DCF-Modul nebst Antenne ist.

    Es gibt aber eine Reihe von Projekten wo diese Punkte nicht gegeben sind, aber eine annähernd sekundengenaue Zeiterfassung trotzdem gebraucht wird.
    Und die logischste Erschlagung solcher Probleme ist die Nutzung eines 32,768kHz Quarzes an einem asynchronen RTC-Timer.

    Der Versuchsaufbau um den es hier geht nutzt DCF77 ausschließlich zum regelmässigen synchronisieren der RTC nach einem Quarzwechsel, um viele unterschiedliche Uhrenquarze testen zu können und eine Tabelle zu füllen welche die Abweichungen zu den getesteten Typen festhält.

    In erster Linie um daraus für meine Projekte den Quarz oder zumindest die Quarzspezifikationen zu finden, welche an den üblichen 8bit-ATmegas am genausten läuft.
    Gerne wäre ich aber auch bereit diese Erkentnisse zu veröffentlichen.
    Weiß ja nicht ob hier im neuen Forum auch wieder ein Wiki geplant ist, wie es im alten Forum existierte.
    Wenn ja, würde die Tabelle nebst Randinformationen da gut rein passen..:-)


    Zitat Zitat von fredred Beitrag anzeigen
    Hatte es ja schon erwähnt, wurde die DCF77 Zeit einmal mit interner Zeit synchronisiert ist diese Zeit sehr genau(µC extTakt 16 MHz )
    Nicht wirklich, es sei denn du hast extern einen OCXO als Taktquelle, welcher entsprechend feinfühlig abgeglichen ist.
    Mit nem normalen Quarz und zwei Festkondensatoren nach GND kannst du von einer Tolleranz von gut +-3kHz ausgehen.
    Egal ob Quarze bei 4,8, 16 oder 20MHz...verlassen kann man sich höchstens auf zwei Nachkommastellen, ab der 3. Nachkommastelle schlägt der Zufall zu.

    Wolle man das ein 16MHz Quarz tatsächlich auf 16,0000xxMHz und nicht irgendwo bei 16,003875MHz oder so taktet, müsste man mindestens einen der Bürdekapazitäten durch einen Kapazitätstrimmer versehen wo man die Taktfrequenz dann feinfühlig genau anhand entsprechender Meßmittel abgleichen kann.

    Frequenzzähler taugt dafür nicht: Die Gesamtleistung an solch einem Taktquarz ist nicht so stark, das sie berührungslos abgefangen für einen Frequenzzähler reicht. Und soband man mit einem Tastkopf an den Quarz geht, verfälscht die Kapazität des Tastkopfes die Resonanzfrequenz.
    Besser ist ein empfindlicher Spektrumanalyzer dem eine HF-Sonde oder Antenne neben der Platine reicht um die Quarzfrequenz messen zu können.

    Und davon ab: Ist der Timer nicht asynchron, sondern nutzt die Mainclock, dann wird die Uhr langsamer werden bei höherer Auslastung des µC.

    Zitat Zitat von fredred Beitrag anzeigen
    Nochmals das A&O ist ein gutes DCF77 Modul für zuverlässigen Zeitsynchronisierung wenn mal nötig wie SZ/WZ.
    MEZ / MESZ ist etwas, was man schlicht auch manuell im Code berücksichtigen kann. Immerhin ist der Wechsel dazwischen immer an den gleichen Kalendertagen um 2 bzw 3Uhr. Wenn man es in einem Projekt braucht, ist es also kein Problem das zu Berücksichtigen.
    Und die Schaltsekunde die alle paar Jahre eingefügt wird, kann man, sollte man es brauchen, auch im Code schrauben.

    Wie bereits oben beschrieben: DCF77 macht Sinn, wenn eine handvoll grundlegender Vorraussetzungen gegeben sind, die ein DCF77-Modul ermöglichen.
    Für alles andere braucht es eine RTC.
    Freilich kann man, wenn man Platz hat und die Mehrkosten nicht scheut, eine externe RTC via I²C dran hängen. Im Extremfall sogar eine DS3231.

    Nur, darum geht es ja nicht immer zwangsweise bei jedem Projekt wo eine RTC gebraucht wird.
    Die Zeit inklusive Datum, Wochentag usw. wird unwichtig, wenn es z.B. in einem Projekt darum geht Funktion A alle 3600 Sekunden und Funktion B alle 86000 Sekunden ausführen, jeweils auf Zeitsekunde xx.
    Da braucht's kein kalender, sondern nur grundlegende Zeitvariablen für Stunden, Minuten und Sekunden, sowie einen exakten Sekundenzähler.

    Grüße

    Jürgen

  3. #33
    Kabelträger Avatar von dino03
    Registriert seit
    02.11.2016
    Beiträge
    21
    Hi Jürgen,

    Ein paar Auszüge aus dem Mega16-Datenblatt (den du ja verwendest) als Zusammenfassung ...

    Note:
    The Timer/Counter Oscillator uses the same type of crystal oscillator as Low-Frequency Oscillator
    and the internal capacitors have the same nominal value of 36 pF.
    The Oscillator is optimized for use with a 32.768 kHz watch crystal. Applying an external
    clock to the TOSC1 pin may result in incorrect Timer/Counter2 operation. The CPU main
    clock frequency must be more than four times the Oscillator frequency.
    leider hab ich im Datenblatt (354 Seiten) auf die Schnelle nicht viel weiteres gefunden was elektrische Werte angeht.
    Ich tippe mal das du das Ding schon durchgewälzt hast.

    Gruß
    Dino

  4. #34
    Spaghetti-Coder Avatar von Basti
    Registriert seit
    10.11.2016
    Beiträge
    106
    Hallo Jürgen,
    dein Programm nutzt doch gar keinen Quarz für die Zeitberechnung.
    Wenn du den Timer zusammen mit der DCF Routine verwendest, dann ignoriert der Compiler den sauber laufenden Timer2 und verwendet stattdessen, was in den Fuses als Takt eingestellt ist. Und das ist bei dir wahrscheinlich der interne RC-Oscillator. Dessen Genauigkeit ist wohl das, was du da bemerkst, nämlich einige % Abweichung.
    Wenn du das anders haben möchtest, dann musst du die ISR vom Timer2 verwenden, der ja nun jede Sekunde einmal überläuft. Dort solltest du dann auch die Zeitvariablen verwenden können, die der Compiler schon definiert hat. DSie kommen sich dann aber evtl. mit dem Update durch die DCF in die Quere, denn die DCF Routine wird bei geglücktem Empfang auch die Variablen setzen.

    Edit: Ich habe jetzt mal dein Programm genommen und nur die LCD Befehle rausgeschmissen, dass sollte ja grundsätzlich nichts ausmachen.
    Dann den Controller auf intern RC 8MHz gefused und dein Programm aufgespielt.
    Solange die DCF läuft, ist die Print-Ausgabe absolut synchron zur Funkuhr. Sobald ich aber DCF abklemme, läuft die Ausgabe grob geschätzt 1 Sekunde pro Minute zu langsam. Wenn ich DCF wieder anklemme, geht die Ausgabe nach 2 Minuten für korrekten Empfang wieder synchron.
    Geändert von Basti (11.01.2017 um 21:00 Uhr)

  5. #35
    Spaghetti-Coder Avatar von Basti
    Registriert seit
    10.11.2016
    Beiträge
    106
    Hallo Jürgen,
    dein Programm nutzt doch gar keinen Quarz für die Zeitberechnung.
    Wenn du den Timer zusammen mit der DCF Routine verwendest, dann ignoriert der Compiler den sauber laufenden Timer2 und verwendet stattdessen, was in den Fuses als Takt eingestellt ist. Und das ist bei dir wahrscheinlich der interne RC-Oscillator. Dessen Genauigkeit ist wohl das, was du da bemerkst, nämlich einige % Abweichung.
    Wenn du das anders haben möchtest, dann musst du die ISR vom Timer2 verwenden, der ja nun jede Sekunde einmal überläuft. Dort solltest du dann auch die Zeitvariablen verwenden können, die der Compiler schon definiert hat. DSie kommen sich dann aber evtl. mit dem Update durch die DCF in die Quere, denn die DCF Routine wird bei geglücktem Empfang auch die Variablen setzen.

    Edit2: Du wirst es nicht glauben, aber die Uhr läuft doch nicht synchron. Die Ausgabe ist immer noch zu langsam, aber wenn nach einer Minute ein gültige Zeit empfangen wurde, dann überschreibt die einfach die aktuelle Zeit. Führt dann dazu, dass meistens die Sekunde 59 fehlt. Krass.

    Code:
    21:11:57 11.01.17 21:12:57 11.01.17 10000000 00000001 00010001 Timezone : 1 4 35
    21:11:58 11.01.17 21:12:58 11.01.17 10000100 00000000 00010001 Timezone : 1 8 36
    21:12:00 11.01.17 21:12:00 11.01.17 10000001 00000000 00010001 Timezone : 1 8 70
    21:12:01 11.01.17 21:12:01 11.01.17 10000000 00000000 00001000 Timezone : 1 4 36
    Geändert von Basti (11.01.2017 um 23:48 Uhr)

  6. #36
    Spaghetti-Coder Avatar von Basti
    Registriert seit
    10.11.2016
    Beiträge
    106
    Das ganze wird immer besser. Ich habe dann gedacht, ok lasse ich den Timer2 einmal richtig laufen, und zwar so:

    Timer2 = Timer , Prescale = 128
    On Ovf2 Sectic
    Enable Ovf2

    Die beiden Befehle zum Setzen von TCCR2 und OCR2 habe ich weggelassen.
    Dann habe ich der Bascom Routine das Gosub=sectic auskommentiert.
    Config Dcf77 = Pinb.3 , Timer = 1 , Inverted = 0 , Debug = 1 , Check = 2 ', Gosub = SecticConfig
    Jetzt kommt der Print exakt genau nach einer Sekunde, also gesteuert vom Timer2 mit Uhrenquarz.
    Solange DCF Signal anliegt, ist alles ok. Wenn ich es aber wegnehme, sieht das Ergebnis so aus:
    Code:
    23:34:36 11.01.17 23:34:19 11.01.17 10000000 00000000 01000100 Timezone : 1 4 31
    23:34:37 11.01.17 23:34:19 11.01.17 10000000 00000000 01000100 Timezone : 1 4 31
    23:34:38 11.01.17 23:34:19 11.01.17 10000000 00000000 01000100 Timezone : 1 4 31
    23:34:38 11.01.17 23:34:19 11.01.17 10000000 00000000 01000100 Timezone : 1 4 31
    23:34:39 11.01.17 23:34:19 11.01.17 10000000 00000000 01000100 Timezone : 1 4 31
    23:34:40 11.01.17 23:34:19 11.01.17 10000000 00000000 01000100 Timezone : 1 4 31
    D.h. dass die Routine für die Neuberechnung der Zeit immer noch den RC Osc verwendet.

  7. #37
    Spaghetti-Coder Avatar von Basti
    Registriert seit
    10.11.2016
    Beiträge
    106
    Zitat Zitat von fredred Beitrag anzeigen
    Hallo DG7GJ

    Deine theoretischen Abhandlungen sind schon toll nur nicht Praxistauglich.
    Eigentlich arbeitet Jürgen doch gar nicht theoretisch sondern eher sehr praktisch.
    Er hat halt ein Problem mit seinem Aufbau, den wir lösen wollen. Dass dabei auch mal in mögliche Erweiterungen, Konzeptänderungen usw abgeglitten wird, ist doch ganz normal.

    Zitat Zitat von fredred Beitrag anzeigen
    Noch mal meine Frage, warum diese Stolperumwege, wenn es nachweislich besser geht.
    Ich habe mir nicht alles durchgelesen und den Rest auch nicht im Kopf, aber welchen nachweislich besseren Weg meinst du?
    Sein Problem ist ja, dass die Uhr nicht genau genug - besser gesagt unfassbar ungenau - läuft, wenn DCF nicht verfügbar ist.
    Und das, obwohl er einen Uhrenquarz angeschlossen hat.

    Zitat Zitat von fredred Beitrag anzeigen
    Bin nur ein Praktiker mit bescheidenen Theorie- Level. Ha, Ha also zu Blöd.
    Stell mal nicht dein Licht unter den Scheffel. Du hast doch hier immer gute Beiträge, auch wenn ich dir manchmal nicht folgen kann, wenn du zu schnell hin- und herspringst. In einem anderen Forum habe ich mal in der Signatur eines Mitstreiters dem Sinn nach gelesen, dass
    Theorie ist, wenn man weiß wie, es aber nicht funktioniert.
    Praxis ist, wenn es funktioniert aber man weiß nicht wieso.
    Und dass der Unterschied zwischen Theorie und Praxis in der Praxis immer größer ist als in der Theorie.

    Glaube ich alles nicht. Die beiden liegen viel näher beieinander als man denkt.

    Zitat Zitat von fredred Beitrag anzeigen
    Na gut klinke ich mich aus, schreibt man wohl so.
    Das würde ich und sicherlich viele andere sehr bedauern. Überlege es dir bitte noch einmal.

    Viele Grüße Basti

    PS: Das war jetzt mein 4. Beitrag hintereinander. Jetzt schweige ich erst einmal.

  8. #38
    Neuer Benutzer
    Registriert seit
    02.11.2016
    Beiträge
    54
    Hallo Basti,
    danke

    Zitat:
    auch wenn ich dir manchmal nicht folgen kann
    Zitat Ende

    Ja da bist du nicht der einzige. Viele sind sich nicht Eins „ ist seine Rhetorik das übelste oder die Rechtschreibung“ na klar beides.
    Male eine Antwort mal so schnell zwischen durch und schreibe so wie ich halt bin.
    Ein Baubudenrülps. Locker, spaßig und wenn es sein muss auch mal zynisch. Lege keinen großen Wert auf „Etikette“ will nur Erfahrungen vermitteln und nicht nur auf Datenblatt usw. hinzuweisen.

    Bin mit Sicherheit kein Akademiker aber nicht so schlecht als Handwerker.
    Ja die Handwerker sollen willens PoliXX aussterben. Prognosen, Hochrechnungen zeigen eindeutig (nicht nur am Gehalt) die Manager sind die, die wissen wo der Frosch die Locken hat.
    Alle andere sind nach deren Ansicht nicht wenig tolle dumm. Ich werde mich hüten zu fragen woher diese die vielen Goldklumpen in ihre Taschen her haben und wer diese ausgegraben musste.

    Zitat:
    PS: Das war jetzt mein 4. Beitrag hintereinander. Jetzt schweige ich erst einmal.
    Zitat Ende

    Ich auch.
    Gruß
    Geändert von fredred (12.01.2017 um 16:57 Uhr)

  9. #39
    Kabelträger
    Registriert seit
    08.12.2016
    Beiträge
    26
    Hallo in die Runde...!

    @ fredfred:

    Deine theoretischen Abhandlungen sind schon toll nur nicht Praxistauglich. Noch mal meine Frage, warum diese Stolperumwege, wenn es nachweislich besser geht.
    Theorie toll, aber nicht Praxistauglich?
    War es nicht dein Vorschlag einfach DCF77 zu nehmen wenn man die Zeit braucht?
    Was ist Praxistauglich daran jedes Projekt welches halbwegs gut eine Sekunde definieren soll ein DCF77-Modul zu verpassen wenn ein 32,768kHz-Quarz reichen soll?

    Das worum es mir geht, ist eine Technik die seit der Erfindung der Quarzuhr eigentlich Standard ist.
    Und was jede Armbanduhr schon seit >40 Jahren kann (32768Hz / 128 / 256 = 1 Sek.) sollte heute unmöglich und Praxisfremd sein?

    Mir währe nicht bewusst dich gekränkt zu haben.
    Vielmehr habe ich dir nochmal verdeutlicht was ich warum vor habe. Das ich dabei technisch teilweise theoretisch werde hat nichts damit zu tun das ich kein Praxismensch bin.
    Vielmehr ist es so das ich eher aus der Analog-/ Hochfrequenztechnik komme, wo man schnell lernt das Theorie und Praxis zusammen gehören.
    Theorie ohne Praxis geht nicht, Praxis ohne Theorie geht aber auch nicht.


    @ Basti:
    Ja, du hast mein Problem erkannt, womit der Fehler besser eingrenzbar ist.
    Doch zunächst eine kurze klarstellung zu deinen fanlschen Annahmen:

    Fusebits stehen bei mir auf 0F.
    Heißt Fusepits KLA987: 001111 (Ext. Crystal/Resonator High Freq.)
    Und das 8MHz Quarz was auf dem Board sitzt, habe ich damals mühevoll abgestimmt für ein Projekt.
    Gerade nochmal den Specki abgeschmissen...das Quarz liegt nach Jahren noch immer auf 8,00000xMHz, fehler also bei Raumtemperatur (aktuell ca. 21°C) kleiner 10Hz.

    Deine Erkentnisse haben mich eben mal veranlasst die Config Dcf77 komplett aus zu kommentieren und gegen Config Clock = Soft aus zu tauschen.
    Und siehe da...:
    Sieht endlich mal gut aus, auch die Register stimmen ohne vorherige Einstellung:
    TCCR2= 00000101 (= Prescaler auf 128)
    OCR2 = 00000000 (=Timer 2 Vergleichswert für IRP)
    ASSR = 00001000 (=Timer 2 asynchron an 32,768kHz Quarz)

    Meine damaligen Versuche scheiterten dann wohl an parasitären Blindanteilen zwischen den TOSC-Pins und dem Quarz.
    Auf dem Pollinboard habe ich dicht nebeneinanderligende Dukos genommen um den Uhrenquarz ein zu löten. Da sind aber leider reichlich lange Leiterbahnen dazwischen.
    Das aktuelle Testquarz direkt an die hochgebogenen TOSC-Pins gelötet hingegen läuft als asynchrone Softcklock nun erstmals vielversprechend.

    Fragt sich nur, warum Config Dcf77 nicht auch den asynchronen Timer2 nutzen kann/will.

    Denn ursprünglich dachte ich den Test nach jedem Quarzwechsel exakt mittels DCF77 synchronisieren zu können um eine exakte Startzeit zu haben.

    Nun bin ich da wo ich nicht hinwollte:
    Vor der Do-Loop Schleife eine Startzeit vorgeben, programmieren...und zur Startzeit = Realzeit sekundengenau Reset aus zu lösen.
    Das ganze auch noch mit nem prellendem Tact-switch...
    Wenn ich exakt auf Sekunde 0 Reset zu drücken, hinkt die RTC fast ne Sekunde nach.

    Aber gut, dann scheidet DCF77 mit der DCF77.lib für mein Experiemt eben aus.
    Warte ich eben noch ne Woche darauf, das meine ersten DS3231 Module ankommen.

    Grüße

    Jürgen

Lesezeichen

Lesezeichen

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •