Raspberry PI3 - DCF77

[__Klemens__]

Hallo Leute,

ich bin gerade dabei mich mit dem Raspberry zu beschäftigen.
Neben einiger kleiner Projekte, möcht ich nun mal - des lernens halber - eine DCF77 Uhr bauen bzw. nen darauf basierenden NTP.

Ich hab hier wie gesagt einen Raspberry Pi 3 und einen DCF77 empfänger.
Der Empfänger ist identisch zu dem hier: DCF77
https://www.reichelt.de/dcf77-empfaenge ... D_BwE&&r=1

Nun hab ich mich an dem Tutorial entlang gehangelt:
https://weberblog.net/ntp-server-via-dc ... pberry-pi/

Dabei bin ich auch schon selbst auf einige Dinge gestoßen die man ändern muss, wie z.B. die ttyS0 statt der ttyAMA0 Schnittstelle.
Ich kann über "sudo screen /dev/ttyS0 9600" einen Input vom DCF Modul sehen.
Nur leider keinen Eintrag über NTPQ-P...
Da sollte der als "GENERIC(0)" erscheinen...tut er aber nicht.

Jetzt hab ich schon alles mögliche versucht...mode des Treibers geändert...und vieles weitere...keine Ahnung...es will nicht klappen.
Meint ihr jemand könnt da mal kurz drauf schauen...

Das wäre grandios!
VG
Klemens

[Chefbastler]

DCF77 eigentlich eine schöne Sache.

Ein normaler DCF77 Empfänger bringt auch nur das DCF77 Protokoll raus und noch keinen UART mit 9600 baud.

Die üblichen billigst DCF Empfänger sind meist von Haus aus nicht sonderlich Empfindlich aber ziehmlich Empfindlich auf ansaubere Spannungsversorgung aus der Digitalwelt.

Wenn du ein Oszi hast kannst du das mit dran hängen und dir die Daten-Signalqualität aus dem Empfänger anschauen und ggf. die Antenne richtig ausrichten und Störquellen(CRTs, billigst SNTs...) in der Umgebung ausweichen. Zum Dekodieren müssen zwei bis drei Minuten komplett störungsfrei drüber kommen.

https://de.wikipedia.org/wiki/DCF77

[sirell]

Ich habe noch die scripte für meinen pi2.
Du klemmst im Prinzip den invertierten Ausgang mit pull-up an den uart Rx. Ich schau dann nach wenn ich daheim bin.

[__Klemens__]

Das wäre natürlich super spitze!

Dann könt ich die Scripte mal abgleichen.
Irgendwo ist der Wurm drin.

Auch wenn die LED minutenlang im Sekundentakt blinkt (synchronisiert)...kein Mux im Raspberry ...

Gerade nochmal im Datenblatt des DCF77 gelesen ob nun ein Pullup benötigt wird oder nicht.
Es steht explizit drin dass kein Pullup benötigt wird - das Modul positive Pulse mit 3,3V liefert (https://www.led-genial.de/DCF77-Empfaen ... omponenten).

Mir erscheint es als ob der PI das Gerät irgendwie nicht "erkennt".
Weil es auch nicht gelistet wird bei Abfrage...

[sirell]

Ich bin nach http://blog.debuglevel.de/raspberry-pi ... on-conrad/ vorgegangen. Der aktualisierte Nachfolger ist https://forum-raspberrypi.de/forum/thr ... -veraltet/

Meine Scripte sind nur für ein i2c Display.

Versuch es mal mit der aktualisierten Anleitung.
Im Zweifel Versuch ich es nochmal hier nachzustellen, aber ich habe nur die Conrad Empfänger...

Edit: was läuft eigentlich auf dem pi ? Welche Version?

[zauberkopf]

Ich habe das ganze mal interessehalber mir mal durchgelesen :
Also der DCF-77 empfänger scheint ein "dummes" device zu sein, das wirklich nur die Rohdaten liefert.
Also muss der NTP mit der option –enable-RAWDCF compiliert sein.
... und ... das passiert mir auch ganz gerne : auch gestartet sein .
Ich schreib das nur deshalb... weil ich mal ein programm veränderte, es kompilierte, und mich wunderte, warum sich nix tat.
Was ich nämlich gestartet habe, war die vorherige installierte Version... Kopf->Tisch.

[__Klemens__]

...ich werds nochmal probieren...
NTP hatte ich mit RAWDCF kompiliert...
Ich versuchs nochmal! danke für den Tip!

Der PI ist ein:
Raspberry Pi 3 Model B Plus Rev. 1.3
Das OS:
Raspbian Version 10 (Buster)

[Jannyboy]

Die Uart von RPI3 ist für die Tonne.
Die ist nur ein Stück Software und hängt am GPU Takt.
Das heißt die jittert wie sau. Wenn die GPU ihre Taktfrequenz regelt.

https://github.com/RPi-Distro/repo/issues/22
https://github.com/raspberrypi/firmware/issues/553

Das beste ist ein USB-auf-Serial-Chip dran machen und diesen benutzen.

Grüße Jan

[WoodSTokk]

Etwas spät aber trotzdem.
Hab vor Jahren ein Programm für die DCF77-Module geschrieben.
Das Problem mit der seriellen kenne ich allzu gut.
Der Treiber liest die Serielle und es muß die volle Minute fehlerfrei übertragen werden, ansonsten gibt es keine Zeit.
Umso weiter man vom Sender weg ist und eventuell noch in einer Stadt mit vielen Störungen lebt, wird es extrem schwierig auch nur eine Minute vollständig zu empfangen.
Deshalb hab ich ein Programm geschrieben das auch nur Teile versucht zu dekodieren und nach mehreren Minuten hat er die richtige Zeit, auch wenn keine einzige Minute vollständig war.
Das Programm läuft normal als Daemon und kann die Zeit an NTP über einen SHM weiterreichen.
Es benutzt die GPIOs flankengesteuert und verwendet die inkludierten Pullup/Pulldown-Widerstände vom Raspi.
Hatte eine zeitlang 3 Module (unterschiedliche Hersteller und Alter) gleichzeitig an einem Raspi laufen und es funktionierte problemlos trotz Störungen.
Der Code ist OpenSource und unter der GPL Lizenz.

Sourcecode: http://lepanto.at/download/dcf77_clock.c
Compile:

Code: Alles auswählen

gcc -Wall -pedantic -std=c99 -lrt -lwiringPi -o dcf77_clock dcf77_clock.c

Eine genauere Beschreibung hab ich auf blog.debuglevel.de schon vor Jahren gepostet.

[phettsack]

Statt DCF77 wäre natürlich heutzutage auch einfach NTP übers Netz möglich, aber das ist unsportlich
Selber empfangen geht auch noch mit einem GPS-Stick. Habe hier immer noch einen liegen den ich für 10€ geschossen habe. Ok, man braucht freie Sicht nach oben, aber wenn man einen Raspberry für ADSB-Empfang unterm Dach hat wäre das eine interessante Erweiterung.

[Profipruckel]

Umso weiter man vom Sender weg ist und eventuell noch in einer Stadt mit vielen Störungen lebt, wird es extrem schwierig auch nur eine Minute vollständig zu empfangen.

Wenn man mit DCF bastelt, gehört da eine akustische Anzeige dran. Selbst kleine Störungen wie z.B. ein Gewitter in der Nähe werden hörbar, besser als jedes Scope oder LED.

Ich male das mal, müsste so funktionieren:

Deshalb hab ich ein Programm geschrieben das auch nur Teile versucht zu dekodieren und nach mehreren Minuten hat er die richtige Zeit

Meine DCF-Uhr habe ich vor zweistelligen Jahren gebaut, 6502-CPU in Assembler. Da polle ich das Signal und zähle. Damit habe ich ein Toleranzfenster, selbst wenn Impulseinbrüche passieren.

Genaue Werte habe ich nicht im Kopf, aber das Prinzip: Abtastung alle 5ms, gäbe das für eine log. Null 20 und für ein High 40. Einen Wert zwischen 10..20 erkläre ich zu Null, einen größeren Wert zu High. Da kann man eine ganze Weile dran herumoptimieren, aber es lohnt sich.

War das kleiner 10, ist es eine Störung gewesen, größer 40 liegt wohl ein Ausfall vor.

Habe ich einen sinnvollen Wert, wird die Abtastung für die nächsten 700ms gesperrt.

Wenn schon eine CPU im Spiel ist, natürlich eine mathematische Prüfung auf Minute +1. Die Parity Bits im DCF bringen nichts, wenn Doppelfehler auftreten, kommt oft vor - dennoch nimmt man die natürlich auch mit.

Statt DCF77 wäre natürlich heutzutage auch einfach NTP übers Netz möglich, aber das ist unsportlich

Das ist genauso schlau wie Radio über Internet. Mein UKW-Radio oder die DCF-Uhr stelle ich irgendwo hin, Strom dran und funktioniert.

[sirell]

Als Authorität in Firmennetzen nimmt man oft DCF und GPS. DCF als Zeitquelle für den Timestamp und GPS für die genaue Sekunde.
Alles driftet. Ratet mal warum es das driftfile gibt. Das enthält die Abweichung zur Standardsekunde je quelle in PPM (oder usec, bin mir nimmer so sicher)
Und eine Quelle ist nutzlos wenn man WIRKLICH genaue Zeiten braucht.
Dafür gibts dann zb. https://www.meinbergglobal.com/ in Modulbauweise

[phettsack]

In einem Firmennetz ist es oft gar nicht so wichtig das die Uhren 100% genau sind aber am besten alle 100% gleich gehen.
Wenn einer am Tor X einstempelt und am Tor Y rausstempelt ist es schon gut wenn beide Stempelkästen GLEICH gehen. Ob die dann 10 Minuten vor- oder nachgehen wäre für die reine Anwesenheitszeit erstmal egal.

[MSG]

Wenn einer am Tor X einstempelt und am Tor Y rausstempelt ist es schon gut wenn beide Stempelkästen GLEICH gehen. Ob die dann 10 Minuten vor- oder nachgehen wäre für die reine Anwesenheitszeit erstmal egal.

Für manche Mitarbeiter aber nicht. Wir hatten einen, der hat tatsächlich festgestellt, dass unsere Terminals eine Zeitdifferenz von ca 2 Sekunden hatten zwischen morgens und abends. Die Rechner Uhr ist den Tag über etwas weggedriftet und wurde nur damals täglich gestellt.

Fun Fact: Die Terminals zeigen (und erfassen) nur Stunden und Minuten... also muss er jedes Mal davor gestanden sein, bis die Minute umgesprungen ist...