Hallo, guten Morgen oder Mahlzeit! Angesichts der "DCF77 Empfangsprobleme" müsste man mal eine DCF-Uhr ohne Altlasten bauen. Ungefähr das Gegenteil von "alles muss in einen ATtiny passen", also ganz normal, ohne exotische Bauteile und mit primitivem Programm. Als DCF-Uhr wird sie nicht besonders genau, sagen wir ±42 Millisekunden. Aber auch nicht mehr, eine um Minuten oder Stunden falsche Anzeige ist absolut lächerlich und unnötig. Eine 1-Chip Lösung ist nicht praktikabel, man braucht mindestens einen Analogteil mit AGC. Ein typischer Empfänger arbeitet z.B. mit 1 µV bis 20 mV. Das geht natürlich auch diskret und/oder mit uC, wird mir aber viel zu aufwendig. Also muss man mit dem digitalen 1-Sekunden Impuls klar kommen. Bei manchen Empfänger-Chips könnte man noch die AGC-Regelspannung auswerten. Außerdem braucht man Spannungsregler, Treiber für die serielle Schnittstelle und vor allem einen RTC-Chip. Soviel zur 1-Chip Lösung. Ein Display kann per I2C, SPI, UART oder parallel angebunden werden, egal. Wegen der Verbindung zum PC braucht man eigentlich keine Tasten o.ä.; evt. für Display-Beleuchtung oder Wecker. Ein Wecker braucht relativ viel Akku oder Batterie, der ganze Rest muss bei Netzausfall nicht funktionieren. Die RTC bekommt sowieso eine eigene CR2032. Mit uC und Verbindung zum PC ist Batteriebetrieb mit einer AAA nicht interessant. Der Empfänger wird nie abgeschaltet, der braucht weniger Strom als der Rest. Der entscheidende Unterschied zu vielen DCF-Uhren: die Zeit kommt immer aus dem RTC-Chip. Das Programm vertraut im Zweifel der RTC-Zeit, nicht der DCF-Zeit. Man geht davon aus, dass die RTC nie mehr als z.B. 30 Sekunden abweichen kann. Deshalb müssen nur die Minuten-Bits korrekt empfangen werden. Wahrscheinlich darf man sogar in jeder halbwegs brauchbaren Minute einfach die Differenz DCF-RTC zum Feinabgleich nutzen. Die RTC nutzt natürlich UTC oder noch besser TAI und die DCF-Stunde ignoriert man einfach. Die RTC wird auch nur ein einziges Mal bei der Inbetriebnahme gestellt und dann nur per Trim-Register nachgezogen.
Ich habe mal ein paar Experimente mit einem GNSS-Empfänger von Aliexpress für 2€ gemacht. Auch indoor bekommt der relativ schnell 1..2 Satelliten (ca. 30sec cold start), was für die Uhrzeit bereits ausreicht, man braucht ja keinen 3D-fix. Dadurch, dass die neben GPS auch weitere Systeme empfangen können, ist die Anzahl an Satelliten enorm. Vlt. ist das die modernere DCF Variante. Ansonsten finde ich Deine Überlegungen richtig, nur Abgleich/Korrektur der RTC. Wenn man bei DCF bleibt kann man den korrekten Empfang absichern, indem man mehrere Protokolle nacheinander vergleicht und nur bei z.B. 3-maliger "Übereinstimmung" verwendet.
:
Bearbeitet durch User
Moin, Bauform B. schrieb: > Hallo, guten Morgen oder Mahlzeit! >...<viele gute Ideen>... Naja, mach hinne! Was haelt dich zurueck? Mach' Schaltplan/Layout/Software, stell vor, lass' dich bemeckern, bau' auf, poste Foddo vong der Geraet und freu' dich. :-) Gruss WK
Ich hatte vor Jahren mal in Netz eine Webseite mit einer "high end" DCF77 Uhr gesehen, die genau diese Philosophie hatte: Es mal ordentlich machen. Aber ob ich das wiederfinde?
Falls man die Zeit aus einem GPS-Empfänger nimmt, darf man nicht vergessen, dass man dort die GMT-Zeit (Grenwich Meant Time) bekommt. Für die Ortszeit muss man hier im Winter eine Stunde addieren und im Sommer 2 Stunden - solange die Zeitumstellung wie bisher weiter besteht. Das nimmt uns der DCF-Sender ab.
Bauform B. schrieb: > Der entscheidende Unterschied zu vielen DCF-Uhren: die Zeit kommt > immer aus dem RTC-Chip. Alle mir bekannten DCF-Uhren machen das so. Empfangen wird i.d.R. nur einmal am Tag, zumindest bei den mit Batterie betriebenen.
Bauform B. schrieb: > Der entscheidende Unterschied zu vielen DCF-Uhren: die Zeit kommt immer > aus dem RTC-Chip. So machen das praktisch alle DCF Uhren, das ist nicht neu. Und single chip ist genau der Weg um bulletproof zu werden, weil Fehlererkennung und Fehlerkorrektur nicht weggelassen werden um den Hardwareaufwand im Zaum zu halten. Dein Ansatz ist also unsinnig. Am besten ein single chip uC mit RF Frontend, RTC mit 32kHz Quartz und inkludiertem Displaytreiber (für welches Display auch immer du dich entscheidest, LCD, LED, OLED oder Zeiger). Besser wäre GNSS, das weiss nicht nur die Zeit, sondern auch die Zeitzone in der man ist und funktioniert weltweit, nicht nur in Frankfurt und um Frankfurt herum.
:
Bearbeitet durch User
Günter N. schrieb: > Falls man die Zeit aus einem GPS-Empfänger nimmt, darf man nicht > vergessen, dass man dort die GMT-Zeit (Grenwich Meant Time) bekommt. Nicht ganz: GPS gibt Dir UTC (Coordinated Universal Time, fuer die Blechmuetzen Zulu-time), GMT ist eine Zeitzone (Greenwich Mean Time). So modernes Zeug wie Zeitumstellung gibt es ja nicht. > Für > die Ortszeit muss man hier im Winter eine Stunde addieren und im Sommer > 2 Stunden - solange die Zeitumstellung wie bisher weiter besteht. Das > nimmt uns der DCF-Sender ab. Das waere die universelle Uhr: Die Uhr holt sich die UTC-Zeit und die Position und bestimmt die lokale Zeit. Wenn noch Platz ist, schreibe WOZ (wahre Ortszeit, Sonnenzeit) auf Display (in Spanien oder China(*) lustig) (*) China hat eine Laengengrad-Differenz von ca. 60° (75° Ost bis 135° Ost), d.h. fuenf Stunden! Um das leben etwas einfacher zu machen hat China nur eine Zeit (Bejing-Time).
:
Bearbeitet durch User
Thomas W. schrieb: > China hat eine Laengengrad-Differenz von ca. 60° (75° Ost bis 135° > Ost), d.h. fuenf Stunden! 60° sind bei mir aber 4 Stunden.
Harald A. schrieb: > Auch indoor bekommt der relativ schnell 1..2 > Satelliten (ca. 30sec cold start), was für die Uhrzeit bereits > ausreicht, man braucht ja keinen 3D-fix. Unsinn. Die genaue Zeit von einem GNSS-Empfänger ist genauso ein Ergebnis der Lösung des Gleichungssystems, wie die drei räumlichen Koordinaten. Damit ist alles, was der Empfänger vor dem 3D-Fix (bzw. 2D-fix mit festgenagelter Höhe) ausgibt, eine mehr oder weniger gute Schätzung auf Basis der zu Grunde gelegten Pseudoentfernung, wobei ich einmal zu behaupten wage, dass "GNSS-Empfänger von Aliexpress für 2€" keine Atomuhr enthalten.
Dann müsste man sich eigentlich auch mal die Ferritantenne anschauen, ob man die nicht effektiver gestalten kann. ...die kurzen Stummel die da oft drin sind...?
Rainer W. schrieb: > wobei ich einmal zu > behaupten wage, dass "GNSS-Empfänger von Aliexpress für 2€" keine > Atomuhr enthalten. ???...; die Atomuhr ist in dem Satelliten der die Daten sendet...!
Uwe B. schrieb: > ???...; die Atomuhr ist in dem Satelliten der die Daten sendet...! Eben. Damit ein Empfänger die Laufzeit des Signals von einem Satelliten bei unbekannter Position herausrechnen kann, bräuchte der Empfänger auch eine. Sonst ist er auf die angenommene Pseudoentfernung angewiesen. p.s. Deine Tastatur prellt.
:
Bearbeitet durch User
Thomas W. schrieb: > Das waere die universelle Uhr: Die Uhr holt sich die UTC-Zeit und die > Position und bestimmt die lokale Zeit. Wenn noch Platz ist, schreibe WOZ > (wahre Ortszeit, Sonnenzeit) auf Display (in Spanien oder China(*) > lustig) Du verwechselst gesetzliche Zeit mit mittlerer Ortszeit. Ohne die Kenntnis der aus politischen Gründen mehr oder wenig willkürlich festgelegten Grenzen der Zeitzonen wird das sowieso nichts. Für die Berechnung der WOZ aus UTC benötigst du auch noch die Bahndaten der Erde, genauer die daraus resultierende Zeitgleichung und musst noch die Differenz zwischen UTC und UT1 berücksichtigen.
Rainer W. schrieb: > Damit ein Empfänger die Laufzeit des Signals von einem Satelliten bei > unbekannter Position herausrechnen kann, bräuchte der Empfänger auch > eine. hmmm, wenn man eine Atomuhr hat, braucht man keine GPS-Satelliten ;-) Aber im Ernst: * wenn man seine Position kennt, braucht man nur das Signal eines Satelliten * wenn nicht, dann mindestens von vier Satelliten, um die Position bestimmen zu können Wobei sich dann aber immer noch die Frage stellt, wie genau muss die Position sein, um eine ausreichend genaue Uhrzeit ermitteln zu können. Welche Genauigkeiten lassen sich mit dem DCF-77-Signal erreichen? Rainer W. schrieb: > p.s. > Deine Tastatur prellt. nö, war Absicht...;-)
Uwe B. schrieb: > Welche Genauigkeiten lassen sich mit dem DCF-77-Signal erreichen? Besser als 1s, ein paar Millisekunden, aber wozu wenn die Anzeige sowieso nur Sekunden anzeigt.
Michael B. schrieb: > Besser als 1s, ein paar Millisekunden, aber wozu wenn die Anzeige > sowieso nur Sekunden anzeigt. ok, bei GPS --> 1m Position daneben, entspricht ca. 3,3ns Zeitungenauigkeit.
Rainer W. schrieb: > Thomas W. schrieb: >> Das waere die universelle Uhr: Die Uhr holt sich die UTC-Zeit und die >> Position und bestimmt die lokale Zeit. Wenn noch Platz ist, schreibe WOZ >> (wahre Ortszeit, Sonnenzeit) auf Display (in Spanien oder China(*) >> lustig) > > Du verwechselst gesetzliche Zeit mit mittlerer Ortszeit. Ohne die > Kenntnis der aus politischen Gründen mehr oder wenig willkürlich > festgelegten Grenzen der Zeitzonen wird das sowieso nichts. Eben, deswegen waere das schon eine "universelle Uhr": Z.B. im Grenzgebiet Spanien <-> Portugal waere das schon sehr spannend. Da die Regeln der Sonnenzeit-Umstellung auch manchmal kurzfristig geaendert werden, koennte man ein Zeitaenderungs-Abo einfuehren. Aber ich nehme an, ein kleines Menue auf dem Display (Waehle Zeitzone) ist viel einfacher. Aber noch einmal zu dem DCF77: Ich hatte mal eine DCF77-Uhr als Geschenk nach Rom mitgenommen. Synchronisierung dauert manchmal eine Nacht, aber ich haette nie gedacht dass die Langwelle so weit reicht.
Uwe B. schrieb: > Welche Genauigkeiten lassen sich mit dem DCF-77-Signal erreichen? Erstmal würde ich sagen, das man vorher festzulegen sollte wie genau die Uhr werden soll. Das scheint es sehr unterschiedliche Ansprüche zu geben. Das wird auch den Aufwand beeinflussen. Und wie genau kann man mit DCF77 überhaupt werden? Dann gibt es die Frage, ob das Teil mit Batterie laufen soll oder von Netz versorgt. Und im Threadtitel steht DCF-Uhr. Da verstehe ich eine Uhr die die Zeit aus dem DCF77 Signal ermitteln und nicht aus GPS oder NTP. Der Vorschlag, ein Controller mit RF Frontend oben war schon gut denke ich. Dann kann man den Träger direkt abtasten und per Software filtern und dekodieren. Funktioniert sehr gut. Und dann Filteraufwand sind da auch kaum Grenzen gesetzt. Es geht natürlich auch ein Controller mit ADC und man liefert ihm das verstärkte Antennensignal.
Uwe B. schrieb: > hmmm, wenn man eine Atomuhr hat, braucht man keine GPS-Satelliten ;-) Nun gut, das ist ein anderes Thema. Aber Harald sprach von Zeitbestimmung mit nur einem Satelliten und das geht eben nicht ohne Fix. Uwe B. schrieb: > Aber im Ernst: > * wenn man seine Position kennt, braucht man nur das Signal eines > Satelliten Nach einem Kaltstart kennt ein GNSS-Empfänger seine Position nicht. > Wobei sich dann aber immer noch die Frage stellt, wie genau muss die > Position sein, um eine ausreichend genaue Uhrzeit ermitteln zu können. Das kommt drauf an, was "ausreichend genau" in Zahlen bedeutet. Ansonsten lässt sich der Worst-Case für den Fehler aus Geometrie und Lichtgeschwindigkeit abschätzen, wenn man z.B. von Unsicherheiten durch die Elektronendichte in der Ionosphäre absieht. > nö, war Absicht...;-)mm Ich, an deiner Stelle, würde inhaltliche Defizite nicht so sehr an die große Glocke hängen ;-) 900ss schrieb: > Und wie genau kann man mit DCF77 überhaupt werden? IMHO schreibt die PTB das auf ihrer Website, über richtig lange Zeiträume so genau wie die Atomuhr dahinter ;-)
:
Bearbeitet durch User
Mhm, .. DCF from scratch .. hört sich gut an! Aber ich würde das kompakter angehen: * Statt einer RTC kann das auch eine µC übernehmen. Das ist mehr als hinreichend genau, wenn regelmäßig durch DCF Empfang synchronisiert wird. Oder man nimmt gleich einen µC mit eingebauter RTC. * Die Ungenauigkeit der SW-RTC kann man durch einen automatischen Abgleich mit dem DCF-Empfang so gut ausregeln, dass sie nicht auffällt. https://www.mikrocontroller.net/articles/AVR_-_Die_genaue_Sekunde_/_RTC * Es gab hier vor einiger Zeit einen DCF-Empfänger, der als SDR ausgeführt war. Dafür gibt es mWn. einen Port nach C auf ARM µC. Beitrag "ATTINY85 als DCF77-Empfänger" oder (den anderen Beitrag finde ich gerade nicht) * Der zu Demozwecken äußerst primitiv gehaltene Empfänger bzw. die Verstärkerstufe könnte man durch eine regelbare Verstärkerstufe ersetzen. * Nach einem Stromausfall kann sich eine DCF-Uhr wieder die Zeit holen. Das muss man nicht puffern. Für einen Wecker müssen natürlich die Schalt-/Weckzeiten nichtflüchtig abgelegt werden. Just my 2 ct.
Thomas W. schrieb: > Aber noch einmal zu dem DCF77: Ich hatte mal eine DCF77-Uhr als Geschenk > nach Rom mitgenommen. Synchronisierung dauert manchmal eine Nacht, aber > ich haette nie gedacht dass die Langwelle so weit reicht. Die Entfernung entspricht etwa 260 Wellenlängen, umgerechnet auf 868MHz also 90 m. Ausbreitung über Ozean (gut leitende Spiegelfläche) sollte also noch deutlich weiter gehen (oder nachts über Raumwelle).
:
Bearbeitet durch User
900ss schrieb: > Und wie genau kann man mit DCF77 > überhaupt werden? Wenn du nur das amplitudenmodulierte Signal auswertest: nicht so besonders. Alleine der übliche Low-Pass-Filter am Empfänger-Ausgang versaut dir die Genauigkeit. Kannst du auf der https://dcf77logs.de/live -Seite schön beobachten, wo die Puls/Pause Zeiten wackeln wie ein Kuhschwanz. Wenn du die Phasenmodulation mit auswertest, die sein 1983 mit ausgesendet wird, kriegst du das deutlich besser hin. https://de.wikipedia.org/wiki/DCF77#Phasenmodulation Es gibt ein paar Implementierungen für gnuradio, https://github.com/henningM1r/gr_DCF77_Receiver http://jmfriedt.free.fr/agu_dcf77.pdf ist im Endeffekt aber kein Hexenwerk. Statt dem Dekoderchip an der Antenne den Schwingkreis hochohmig mit JFET abgreifen, etwas verstärken, direkt, ohne Mischer/Demodulation, an den ADC. 77,5 kHz ist jetzt keine Hochfrequenz, aber etwas schneller als der AVR-Arduino-ADC sollte der schon sein. (STM32, RP2040, ...) Rest ist Software.
Εrnst B. schrieb: > Statt dem Dekoderchip an der Antenne den Schwingkreis hochohmig mit JFET > abgreifen, etwas verstärken, direkt, ohne Mischer/Demodulation, an den > ADC. Würde ich auch so machen. Heutzutage kann man sogar die Bilder auf der Schallplatte der Voyager Weltraumsonden in Echtzeit decodieren: https://youtu.be/ibByF9XPAPg
Thomas F. schrieb: > Bauform B. schrieb: >> Der entscheidende Unterschied zu vielen DCF-Uhren: die Zeit kommt >> immer aus dem RTC-Chip. > > Alle mir bekannten DCF-Uhren machen das so. Empfangen wird i.d.R. > nur einmal am Tag, zumindest bei den mit Batterie betriebenen. Ja, ok. Aber dann schreiben die die frisch empfangene Zeit in die RTC -- das ist der entscheidende Fehler. Warum macht man das? Man sollte der eigenen RTC etwas mehr vertrauen. Marek N. schrieb: > War das die hier? http://www.gjlay.de/software/dcf77/konzept.html Nö, völlig unabhängig und auch ein wenig anders: ich finde Fehlererkennung viel wichtiger als Fehlerkorrektur. Eigentlich brauche ich nur den Anfang der Sekundenmarken, Datum und Zeit habe ich ja. Selbst nach längerer Zeit ohne Empfang oder Strom kann man den maximalen Fehler abschätzen und braucht entsprechend weniger gute Bits. Harald A. schrieb: > Wenn man bei DCF bleibt kann man den korrekten Empfang > absichern, indem man mehrere Protokolle nacheinander vergleicht und nur > bei z.B. 3-maliger "Übereinstimmung" verwendet. Bei schlechtem Empfang kann man lange warten... 900ss schrieb: > Erstmal würde ich sagen, das man vorher festzulegen sollte wie genau die > Uhr werden soll. Das scheint es sehr unterschiedliche Ansprüche zu > geben. > Das wird auch den Aufwand beeinflussen. Ich würde den maximal erlaubten Aufwand festlegen und dann sehen wir schon, wie genau es wird. Das heißt, es kommt nur ein Empfänger-Chip wie z.B. MAS6180 in Frage. > Und wie genau kann man mit DCF77 überhaupt werden? In ca. 500 km Umkreis zum Sender könnte man die 0 bis 2 ms für die Ausbreitung raus rechnen, als Fehler bleibt noch die schwankende Luftfeuchtigkeit (oder noch was?). Weiter weg wird es schnell viel schlechter, weil die Raumwelle ins Spiel kommt. Der größte Fehler dürfte die Laufzeit im Empfänger sein und die ist wahrscheinlich von der Feldstärke abhängig. Dazu kommt der Jitter durch Störungen. Mal angenommen, man kann den Beginn der Trägerabsenkung auf ±86.4 ms bestimmen. Dann hätte man nach einem Tag mit gutem Empfang die Frequenz auf ±1 ppm genau, oder? Die RTC-Frequenz sollte bei Zimmertemperatur weniger als 1 ppm schwanken. Abgleichen lässt sie sich mit 0.12 ppm Auflösung. So genau geht die Uhr ohne Empfang. Mit Empfang kann es nur besser werden. Man muss nur länger als ein paar Minuten warten. Thomas W. schrieb: > Günter N. schrieb: >> Falls man die Zeit aus einem GPS-Empfänger nimmt, darf man nicht >> vergessen, dass man dort die GMT-Zeit (Grenwich Meant Time) bekommt. > > Nicht ganz: GPS gibt Dir UTC (Coordinated Universal Time, fuer die > Blechmuetzen Zulu-time), GMT ist eine Zeitzone (Greenwich Mean Time). So > modernes Zeug wie Zeitumstellung gibt es ja nicht. Es kommt noch schlimmer: du bekommst die GPS-Zeit plus Schaltsekunden -- falls der Empfänger weiß, wie viele Schaltsekunden es aktuell sind. Einfacher und sicherer, ist es, nur die GPS-Zeit zu lesen. Wenn man dann noch TAI für die RTC benutzt, müssen die beiden immer direkt übereinstimmen. Schaltsekunden, Zeitzone und Sommerzeit werden gemeinsam nur für die Anzeige addiert. Und vor allem muss die RTC nie mehr gestellt werden. Obwohl es hier um DCF geht, gilt hier das gleiche. Die Empfänger liefern freiwillig keine besonders praktische Zeit. Carsten W. schrieb: > Statt einer RTC kann das auch eine µC übernehmen. Kommt auf die eigenen Ansprüche an. Ein RTC-Chip mit eigener Batterie ist temperaturkompensiert und überbrückt Netzausfälle und Firmware Updates. > Nach einem Stromausfall kann sich eine DCF-Uhr wieder die Zeit holen. Wirklich nicht. Das dauert (mir jedenfalls) viel zu lange. Auch NTP und GPS sind nicht schneller oder zuverlässiger. Ich wollte schon mal so eine Uhr bauen. Die sollte eigentlich 3 (drei) RTC-Chips bekommen, damit man gefahrlos die CR2032 tauschen kann. Aus Platzgründen wären nur 2 auch ok, aber keine geht garnicht. > Für einen Wecker müssen natürlich die > Schalt-/Weckzeiten nichtflüchtig abgelegt werden. Also bitte, ein Wecker muss auch bei Stromausfall wecken. Spätestens dann ist das Preis/Leistungsverhältnis von einem RTC-Chip sehr gut.
Bauform B. schrieb: > Ja, ok. Aber dann schreiben die die frisch empfangene Zeit in die RTC -- > das ist der entscheidende Fehler. Warum macht man das? Man sollte der > eigenen RTC etwas mehr vertrauen. Nein, du kannst eine Software-PLL nachregeln und damit in Zukunft eine genauere interne RTC haben, macht ja jeder GPSDO auch so, musst nur beachten dass die RTC wohl nicht nur langsamem drift wegen sinkender Batteriespannung und Bauteilalterung unterliegt, sondern viel mehr Temperaturschwankungen. Bauform B. schrieb: > ein Wecker muss auch bei Stromausfall wecken. Spätestens > dann ist das Preis/Leistungsverhältnis von einem RTC-Chip sehr gut. Das kann ein uC auch alleine. Bauform B. schrieb: > Ein RTC-Chip mit eigener Batterie > ist temperaturkompensiert Eher nicht.
:
Bearbeitet durch User
Michael B. schrieb: > Bauform B. schrieb: >> Ein RTC-Chip mit eigener Batterie >> ist temperaturkompensiert > > Eher nicht. Selbst Schuld. Solche ohne TCXO kauft man nicht. Da kann eine Software-RTC natürlich leicht mithalten.
Kinders! Wir reden hier über einen digitalen Zeiger, der irgendwo herumsteht bzw. -hängt und von einem Menschen abgelesen wird. Da kommt es auf +/- eine Sekunde am Tag nicht drauf an. Das schaffen nicht einmal die Smartphones! Ich bleibe dabei: Eine externe RTC braucht man nicht. So selten, wie der Strom ausfällt, macht es wirklich nichts, wenn die Uhr ein paar Minuten ohne Zeitanzeige läuft. Wenn doch, dann kann man den µC mit einer AAA-Zelle puffern. So selten, wie die gebraucht wird, wird die ewig reichen. Dafür kann man den µC bei entsprechender Programmierung in den Stromsparmodus schicken. In meiner selbst entworfenen, -gebauten und -programmierten DCF-Uhr auf dem Schreibtisch werkelt in der Dekodierung eine Statemachine)*, die die DCF-Bits auf Plausibilität abklopft. Die hat bisher noch allen Unfug erkannt und verworfen. Ich habe jedenfalls noch nie Phantasiezeiten auf der Anzeige gesehen. Die Uhr wird vor jeder vollen Stunde synchronisiert. Das reicht völlig. )* Die Statemachine ist allerdings nicht von mir.
Hab mir in den 80ern eine Digitaluhr mit DCF beim Kaufhof für ca. 10 DM gekauft. Da waren sie noch nicht pleite. Die läuft und läuft und läuft. DCF wird gesynct, wenn Empfang ist. Batterie vor über 20 Jahren gewechselt. An diesem Boomer-Standard (technisch, preislich) musst Du Dich messen lassen.
Ralf S. schrieb: > An diesem Boomer-Standard (technisch, preislich) musst Du Dich messen > lassen. Weshalb?
Bauform B. schrieb: > Ungefähr das Gegenteil von "alles muss in einen ATtiny > passen", also ganz normal, ohne exotische Bauteile und mit primitivem > Programm. Nennt sich ACS-77: https://www.klaviatur.de/acs77.php Sind Dir das genügend Bauteile?
Rick schrieb: > Nennt sich ACS-77: https://www.klaviatur.de/acs77.php > Sind Dir das genügend Bauteile? Ja das ist ein sehr schönes Teil, so eine habe ich auch hier die bekommt gerade neue Kondensatoren. Die Auerswald® ACS-77 aus den 80er Jahren hat als funkgesteuerte Uhr mittlerweile Kultstatus erreicht.Ihr Herz ist ein Klassiker unter den Mikroprozessoren, der Z80. Gruß bastler2022
Angehängte Dateien:
-
GPS_Neo_6M.jpg
100 KB
Bauform B. schrieb: > Es kommt noch schlimmer: du bekommst die GPS-Zeit plus Schaltsekunden -- > falls der Empfänger weiß, wie viele Schaltsekunden es aktuell sind. > [...] > Obwohl es hier um DCF geht, gilt hier das gleiche. Die Empfänger liefern > freiwillig keine besonders praktische Zeit. Die Arduino GPS-Uhr zeigt im OLED nur "Suche Satelliten" an. Da blinken LEDs, aber auch nach ca. 5 Minuten tut sich nichts weiter. Im Innenraum und auch auf der Fensterbank keine Chance auf Empfang. (Bei DCF77 null problemo.) Der Witz bei der DCF77-Uhr ist ja, dass sie sich selbst stellt. Brauche nicht an den "Zeigern zu drehen". Ob die Zeit nun Miliisekunden synchron genau ist, hat für meinen Anwendungszweck keine praktische Bedeutung. Beim DAB+ Synchronfrequenznetzwerk sieht das schon anders aus. Da wird auf GPS zugegriffen. Für Otto-Normalverbraucher reichte ein RDS-fähiges UKW/FM Radio oder ein DAB+-Empfangsgerät aus, das sich die Zeitinformatiom vom Sendersignal und den aufmodulierten Zusatzsignalen (CT-Signal) holt. Letztens noch getestet: Nach Einschalten des Radios zeigte das LCD 01.01.2002 an. Nach etwa 10 Minuten Spielzeit: RDS Empfang ok und aktuelles Datum und aktuelle* Uhrzeit. *Bei den digitalen Programmen kommt noch eine Laufzeitverzögerung hinzu. Der Tagesschau-Gong hinkt etwa 10 Sekunden nach. ciao gustav
:
Bearbeitet durch User
Oh, der Thread hat sich gemäß dem Reizthema DCF mal wieder mit allerlei "Fachwissen" angehäuft. Schön. Den Leugnern der Möglichkeit mit dem GNSS-Modul würde ich mal ans Herz legen, einfach mal 3€ beim nächsten Ali-Einkauf zu spendieren. Es lohnt sich.
Harald A. schrieb: > Den Leugnern der Möglichkeit mit dem > GNSS-Modul würde ich mal ans Herz legen, einfach mal 3€ beim nächsten > Ali-Einkauf zu spendieren. Es lohnt sich. Deine Uhr steht unter freiem Himmel? Oder hat sie eine Fensterantenne? DCF funktioniert auch noch im Keller...
Rahul D. schrieb: > Deine Uhr steht unter freiem Himmel? Oder hat sie eine Fensterantenne? Dazu schrieb ich oben > DCF funktioniert auch noch im Keller... Ja.
Harald A. schrieb: > Dazu schrieb ich oben Ja, eigentlich wollte ich meinen Post noch löschen; ging aber nicht (mehr).
Bauform B. schrieb: > Angesichts der "DCF77 Empfangsprobleme" müsste man mal eine DCF-Uhr ohne > Altlasten bauen. Mit deinen etwas aus der Zeit gefallenen Konzept bist du meiner Meinung nach Jahrzehnte zu spät dran. Aber es gab hier schon richtig gute Konzeptideen „von scratch“. Erinnere mich an ein beeindruckendes Paper von Daniel vor über 10 Jahren: Beitrag "Paper zu DCF77" Weiß nicht ob es bei der theoretischen Arbeit blieb oder ob das real aufgebaut wurde, ich würde jedenfalls da ansetzten.
Rahul D. schrieb: > Harald A. schrieb: >> Dazu schrieb ich oben > > Ja, eigentlich wollte ich meinen Post noch löschen; ging aber nicht > (mehr). Danke für die ehrliche Rückmeldung!
Harald A. schrieb: > Den Leugnern der Möglichkeit mit dem GNSS-Modul würde ich mal ans > Herz legen, einfach mal 3€ beim nächsten Ali-Einkauf zu spendieren. > Es lohnt sich. Wie soll ich "Leugner" verstehen? Wenn ich eine DCF-Uhr bauen will, brauche ich einen DCF-Empfänger, ohne den geht's ja per Definition nicht. Ein zusätzlicher GNSS-Empfänger und NTP sind natürlich nett zwecks Redundanz, das leugnet doch niemand?
Nur eine allgemeine Warnung, falls jemand nach Auffinden dieses Threads die Uhrzeit aus RDS/UKW holen möchte: Ich habe das mal aufgebaut mit einem RDA5807, da er sehr günstig ist. Der Ansatz war: Per Suchlauf starken lokalen Sender finden, RDS auswerten, Uhrzeit holen, abschalten. Allerdings ist die RDS-Implementierung im RDA5807 buggy, das verhagelt einem leider die Verwertbarkeit der Uhrzeit. Dann lieber das Original SI47xx nehmen, der wird das hoffentlich besser können.
Wulf D. schrieb: > Bauform B. schrieb: >> Angesichts der "DCF77 Empfangsprobleme" müsste man mal eine DCF-Uhr ohne >> Altlasten bauen. > > Mit deinen etwas aus der Zeit gefallenen Konzept bist du meiner Meinung > nach Jahrzehnte zu spät dran. Naja, Anlass war ja der Thread DCF-Empfangsprobleme. Den dürfte es ja nicht geben, wenn alles schon seit Jahrzehnten klar wäre. > Aber es gab hier schon richtig gute Konzeptideen „von scratch“. > Erinnere mich an ein beeindruckendes Paper von Daniel vor über 10 > Jahren: > Beitrag "Paper zu DCF77" Das Paper ist zweifellos äußerst interessant, das habe ich damals "verschlungen" ;) Auch die verlinkten Forumsbeiträge sind überdurchschnittlich, vielen Dank. Offensichtlich gibt es sehr unterschiedliche Vorstellungen davon, was bei so einer Uhr wichtig ist und die meisten Forderungen schließen sich aus. Für mich ist ein handelsübliches Empfänger-Modul Grundvoraussetzung. Damit brauche ich an Phasenmodulation oder µs garnicht zu denken. "Genauigkeit" ist sowieso Ansichtssache. Manch große Firma ignoriert z.B. Schaltsekunden einfach. Die Uhr geht eben für einige Stunden um bis zu 1 Sekunde falsch. Wer sich bei der Sommerzeit-Umschaltung auf DCF verlässt, akzeptiert sogar einen Fehler von einer Stunde. Das muss doch wirklich nicht sein. Vor allem, wenn man mit einem einfacheren Programm ein zuverlässigeres Ergebnis bekommt. Inzwischen hatte ich versucht, ein gestörtes Signal aus dem guten alten Conrad-Empfänger auf dem PC zu verarbeiten. Da ist natürlich schon die Abtastrate nicht stabil, deshalb vertage ich das, bis die uC-Platine fertig ist.
RDS-Zeit ist nicht synchron zu DCF77 Zeit. Zeitzeichen im Radio oder im Fernsehen kann durch "digitales" Delay auf dem Übertragungsweg bis zu mehreren Sekunden versetzt sein. Schon gleichzeitiges Hören von UKW/FM und DAB+ desselben Programms zeigt den Versatz ganz deutlich. Für die Genauigkeitsdiskussion fällt der RDS/DAB+ Zusatzdienste Ansatz also raus. Bleiben wir bei DCF77 oder MSF60, den "klassischen" Langwellen-Zeitsignal-Sendern. (Und GPS unter freiem Himmel auf hoher See mit gestörtem Langwellenempfang.) ciao gustav
Bauform B. schrieb: > Für mich ist ein handelsübliches Empfänger-Modul > Grundvoraussetzung. Damit brauche ich an Phasenmodulation oder µs > garnicht zu denken. Im Grunde braucht man jemanden wie den "metallfunk", nur eben als DCF-Uhren-Erfinder. Ein guter Empfänger, der Nachbausicher designt ist und einem 5€-Modul in Störfestigkeit und "Reichweite" überlegen ist, darf auch ruhig ein paar € kosten. Aber eben nicht "kaufste halt eins von HKW" oder "Canaduino", sondern schon selber löten nach Stückliste. Schön mit Abgleichen (möglichst ohne allzu komplexe Werkstatt, nicht jeder ist ein FuA) und Spule wickeln. Die Auswertung des Sekundensignals reicht, es soll ja nur eine Uhr werden (also primär Zeitanzeige, evtl. plus Wecker/Schaltuhr), d.h. Phasengenauigkeit und selbst Langwellenausbreitungsprobleme dürften kein Problem sein, aber der Empfang soll "immer" und "überall" funktionieren.
Bauform B. schrieb: > Inzwischen hatte ich versucht, ein gestörtes Signal aus dem guten alten > Conrad-Empfänger auf dem PC zu verarbeiten. Das funktioniert mit dem Raspberry Pi recht gut mit entsprechenden Libs die eine stabile Abtastrate gewährleisten. Ich habe das vor ein paar Jahren mal probiert weil man eben kompilieren und direkt testen kann ohne erst einen uC zu flashen. Das hier hatte ich verwendet und hat ausreichend gut funktioniert. https://abyz.me.uk/rpi/pigpio/ Ein Feature: hardware timed sampling and time-stamping of GPIO 0-31 every 5 us Damit kann man ohne große Hürden seinen Algorithmus testen. Ich habe damit die DCF Bibliothek von Blinkenlight getestet. Die ist schon sehr gut um aus einem gestörtes Signal von solch einem Empfangsmodul noch die Uhrzeit zu holen. Ich behaupte mal, das ist nur äußerst schwer zu toppen.
:
Bearbeitet durch User
Karl B. schrieb: > RDS-Zeit ist nicht synchron zu DCF77 Zeit. > Zeitzeichen im Radio oder im Fernsehen kann durch "digitales" Delay auf > dem Übertragungsweg bis zu mehreren Sekunden versetzt sein. Für wen wären diese Sekunden Differenz relevant?
:
Bearbeitet durch User
900ss schrieb: > Ich habe damit die DCF Bibliothek von Blinkenlight getestet. Das ist Arduino auf einem RPi? Das kostet doch "geringfügige" Anpassungen? Was ich gefunden hatte, benutzt auch digitalWrite(), also noch externe Hardware? Ich verstehe nur Bahnhof :(
.● Des|ntegrator ●. schrieb: > Karl B. schrieb: >> RDS-Zeit ist nicht synchron zu DCF77 Zeit. >> Zeitzeichen im Radio oder im Fernsehen kann durch "digitales" Delay auf >> dem Übertragungsweg bis zu mehreren Sekunden versetzt sein. > > Für wen wären diese Sekunden Differenz relevant? Für jemand, der seine PC-Uhr damit stellen will, damit die gleich vom Start weg halbwegs richtig geht. Normalerweise geht der ntpd davon aus, dass die Uhr um max. 128 ms falsch geht, sonst ist die wohl defekt.
Bauform B. schrieb: > Das ist Arduino auf einem RPi? Das kostet doch "geringfügige" > Anpassungen? Was ich gefunden hatte, benutzt auch digitalWrite(), also > noch externe Hardware? Original läuft Blinkenlights auf einem AtMega168 oder 328 mit 16MHz. Arduino (also das Softwaresystem) ist aber schlau genug, das auch auf anderen Controllern zum Laufen zu bringen, allerdings sind da einige Hardwarespezialitäten (also: nicht portierbare Annahmen aber portierbarer Code) drin, die auf anderen Controllern evtl. anders gelöst werden müssen. Ein RPi hat aber wohl genug Feuer unterm Arsch das er den 328 emulieren kann... Das ist der Vorteil dieser aufgeblasenen Pseudo-Funktionen: digitalWrite() bleibt, aber je nach Core macht der was völlig anderes. Bauform B. schrieb: > Für jemand, der seine PC-Uhr damit stellen will, damit die gleich vom > Start weg halbwegs richtig geht. Das wäre ein interessantes Projekt: eine DIY-DCF-77-Uhr, die via LAN als Stratum-1-NTP-Server funktioniert. Eben für die Fälle wo man keinen Internetzugang nutzen kann/will, aber doch eine "gute" Zeit möchte. Bauform B. schrieb: > Normalerweise geht der ntpd davon aus, > dass die Uhr um max. 128 ms falsch geht, sonst ist die wohl defekt. Du meinst damit aber "128ms zu schnell in 24h" oder so? Auf 0,1s genau die Bios-Uhr zu stellen mit Zahlen ablesen, eintippen und OK klicken halte ich für sehr sportlich, daher missverstehe ich dich sicher. Bei meinen selten benutzten PCs fällt mir auf, das die RTC durchaus wesentlich mehr daneben liegt, und dann wenn ich mitstoppe sehe ich das die eine Minute in 57 Sekunden machen, und so langsam wieder an die richtige Zeit herankriechen. Wenn's hüpft kommen da wohl einige Programme nicht mit klar, also wird etwas Gas gegeben (oder gebremst), da dauert die Korrektur dann eben eine Stunde oder so.
Bauform B. schrieb: > 900ss schrieb: >> Ich habe damit die DCF Bibliothek von Blinkenlight getestet. > > Das ist Arduino auf einem RPi? Das kostet doch "geringfügige" > Anpassungen? Was ich gefunden hatte, benutzt auch digitalWrite(), also > noch externe Hardware? Ich verstehe nur Bahnhof :( Ich hatte die Aufrufe für Arduino nachgebildet bzw ersetzt. Ob das nun auch DigitalWrite() bei war weiß ich nicht. Frage mich auch weshalb ein write da drin sein sollte. Ich hatte nur das Signal des DCF Moduls an ein GPIO gelegt. Also viel Arbeit war es nicht dieses Arduino da raus zuholen. Es quasi zu entwanzen ;) Ich habe ganz sicher keine Arduino Umgebung da laufen gehabt. Ich mag es nicht.
Jens M. schrieb: > Das wäre ein interessantes Projekt: eine DIY-DCF-77-Uhr, die via LAN als > Stratum-1-NTP-Server funktioniert. Bitte nicht, oder wenn, dann privat. Diese Bastel-NTP-Server verseuchen die ganzen NTP-Server-Pools. Protzen mit Stratum 1, sind schlechter als fast alle Stratum 2…3 -Server. Schön mit "ntpq -p" zu sehen, wenn du z.B. "0.ubuntu.pool.ntp.org" oder einen anderen Server-Pool verwendest. refid "DCFa" oder "DCFp", wobei die PSK-Variante DCFp selten ist. Server mit refid "GPS" tauchen auch gelegentlich auf, sind mir aber noch nie negativ aufgefallen.
Εrnst B. schrieb: > Bitte nicht, oder wenn, dann privat. Genau darum geht's ja: nur im LAN. Für ein LAN ohne Internetzugang z.B. Als billiges Kästchen (ein ESP32-Modul z.B.), LAN, Netzteil, fertig. So das offline-Computer mit z.B. XP dennoch eine schöne Zeit bekommen. In Form einer "Hinstelluhr", die in der Nähe des PCs steht. Εrnst B. schrieb: > wenn du z.B. "0.ubuntu.pool.ntp.org" oder > einen anderen Server-Pool verwendest. Ich nutze nur ptbtime1.ptb.de und seine Kumpels ..2.. bis ..4.. Und das auch nur auf einem Router, seine LANs haben alle eine Sperre drin und werden via NAT auf eben diesen Router verbogen, selbst wenn sie woanders NTPen wollen.
:
Bearbeitet durch User
Jens M. schrieb: > Bauform B. schrieb: >> Für jemand, der seine PC-Uhr damit stellen will, damit die gleich vom >> Start weg halbwegs richtig geht. > > Das wäre ein interessantes Projekt: eine DIY-DCF-77-Uhr, die via LAN als > Stratum-1-NTP-Server funktioniert. Genau darum geht's hier; naja, nicht ganz: der NTP-Server von Debian ist gut genug, den muss man nicht selber bauen ;) >> Normalerweise geht der ntpd davon aus, >> dass die Uhr um max. 128 ms falsch geht, sonst ist die wohl defekt. > > Du meinst damit aber "128ms zu schnell in 24h" oder so? Auf 0,1s genau > die Bios-Uhr zu stellen mit Zahlen ablesen, eintippen und OK klicken > halte ich für sehr sportlich Mit der Bios-Uhr wird das nichts, es geht nur um die System-Uhr. "date --set=2026-05-19T15:42:00" und im richtigen Moment Enter sollte zu schaffen sein. Ab dann ist die 128 ms Grenze sogar großzügig, dank ntpd. "richtige Rechner" werden nie ausgeschaltet und einen Reboot kann die Bios-Uhr überbrücken. So ähnlich muss eine DCF-Uhr funktionieren. Die wird beim allerersten Einschalten irgendwie gestellt und geht dann einfach immer richtig. Die RTC-Frequenz sollte auf 1 ppm genau stimmen, macht 0.1 Sekunde pro Tag. Wenn man wenigstens jede Nacht guten Empfang hat, schafft man sogar die 128 ms. Auch wenn man 400 ms Fehler erlaubt, findet man den DCF-PPS noch wieder. Eigentlich braucht man nur diesen Impuls, keine Minuten-Marke, keinen Dekoder, nicht davon. Der ganze Aufwand wird erst gebraucht, wenn es wochenlang keinen Empfang gibt. Und dann dürften Datum und Stunde immer noch stimmen, also hat der Dekoder schon eine sehr gute Grundlage.
Bauform B. schrieb: > Genau darum geht's hier; naja, nicht ganz: der NTP-Server von Debian ist > gut genug, den muss man nicht selber bauen ;) Nä. Eben genau nicht "debian". Kein RPi, kein Linux. Nichts was man updaten muss. Controller mit LAN, Display dran, DCF dran, fertig. Steckt man an einen PC, der sonst kein LAN hat/haben kann/darf und der kann dann trotzdem via NTP seine Uhr stellen. Als Nebenfunktion einer "Hinstelluhr", die sich eh schon um DCF und Display kümmert. "Nur mal eben" LAN mit NTP-Server mit einbauen. Kann genau das, mehr nicht. Bauform B. schrieb: > Mit der Bios-Uhr wird das nichts, es geht nur um die System-Uhr. Das ist für 99% der Computernutzer das selbe. Es gibt eine Welt außerhalb von Linux-Servern... ;) Bauform B. schrieb: > im richtigen Moment Enter sollte zu > schaffen sein Auf der Funkarmbanduhr auf ":00" zu warten und dann Enter zu drücken, innerhalb einer zehntel Sekunde... Sportlich. Bauform B. schrieb: > Die > RTC-Frequenz sollte auf 1 ppm genau stimmen, macht 0.1 Sekunde pro Tag. Spooortlich. Aber Blinkenlights schafft das, sogar ohne eine RTC, rein in Software auf einem Arduino für wenige Euro, wenn er denn einen Quarz hat und keinen Reso. Ein TCXO ist toll, aber unötig: da die Software nichts davon weiß, altert der RTC-Status ebenso schnell wie mit Quarz, auch wenn der TCXO wesentlich länger genau bleibt. Aber es braucht Dauersignal vom DCF, um den Quarz bzw. die Soft-RTC immer wieder nachzustellen, auch wenn's mal Stunden oder gar Tage ohne geht. Du bist dann zwar immer um den Mittelwert des Jitters des Impulsbeginns verzögert, aber relativ immer sehr genau. Viel geiler geht für 10€ nicht.
Meine Bahnhofsuhr Beitrag "Re: Bahnhofsuhr als LCD-Anzeige" kann sich die Zeit via NTP und DCF77 holen und kann mit einer RTC die Zeit auch speichern. Ist die RTC angeschlossen wird ein NTP Server gestartet und soll zukünftig u.a. einen RasPi ohne Internet mit der Zeit versorgen. Holger
Bauform B. schrieb: > Mit der Bios-Uhr wird das nichts, es geht nur um die System-Uhr. "date > --set=2026-05-19T15:42:00" und im richtigen Moment Enter sollte zu > schaffen sein. Ab dann ist die 128 ms Grenze sogar großzügig, dank ntpd. > "richtige Rechner" werden nie ausgeschaltet und einen Reboot kann die > Bios-Uhr überbrücken. Beziehst du dich dabei auf die slew/skip Grenze? Dia kann man (ist aber unnötig) auch größer setzen. Aber muss man nicht, da bei mehr als 128ms Abweichung automatisch ein skip auf die richtige Uhrzeit gemacht wird. Da braucht's keine Tastaturakrobatik.
Jens M. schrieb: > Bauform B. schrieb: >> Die >> RTC-Frequenz sollte auf 1 ppm genau stimmen, macht 0.1 Sekunde pro Tag. > > Spooortlich. Nö, RV-3032-C7, 3.20 € bei Digikey > Aber Blinkenlights schafft das, sogar ohne eine RTC, rein > in Software auf einem Arduino für wenige Euro Ja, aber mit Arduino ;) So wird das nichts:
1 | dcf77.cpp:1498:20: error: 'F' was not declared in this scope |
2 | 1498 | sprint(F(" CET ")); |
3 | dcf77.h:592:31: error: 'Serial' was not declared in this scope |
4 | 592 | #define sprintln(...) Serial.println(__VA_ARGS__) |
usw.
Bis ich das in eine verständliche Sprache übersetzt habe...
> Aber es braucht Dauersignal vom DCF
Und ich brauche RTC und CR2032 sowieso gegen Stromausfall. Das hilft
gratis gegen DCF-Ausfall.
Bauform B. schrieb: > Ja, aber mit Arduino ;) So wird das nichts: Komisch. Bei mir klappt das einfach so. Vermutlich, weil ich es mit der richtigen IDE auf der vorgesehenen Hardware nutze. :D Ja, F ist eine Krücke, weil der AVR (oder der Programmierer des Compilers, des Cores oder der Libraries) zu doof ist und literale Strings beim Start aus dem Flash ins knappe RAM kopiert, damit man die dann da dauerhaft speichert und unverändert ausgeben kann. Aber Serial und F braucht die Library nicht, das ist ja schon die Uhrenfunktion. Aber du solltest dich evtl. dransetzen und nicht die Library umcoden, sondern den Algo sauber auf deiner Architektur bauen. Und das hat weniger damit zu tun das es Arduino ist (und du das nicht verstehst)... Je weiter du vom AVR weggehst, desto mehr Krücken musst du nutzen um das Verhalten nachzuahmen. Bauform B. schrieb: > Und ich brauche RTC und CR2032 sowieso gegen Stromausfall. Batterie ist ein Verschleißteil. RTC ist unnötig, wenn man mit 20 Minuten bis zum Sync leben kann. Aber ja, man könnte natürlich eine RTC mit einbauen und die ausschließlich dazu nutzen, das die Kiste sofort eine Zeit liefert, und dann auf die DCF-RTC umstellen wenn sie gültig wird.
Jens M. schrieb: > Aber ja, man könnte natürlich eine RTC mit einbauen und die > ausschließlich dazu nutzen, das die Kiste sofort eine Zeit liefert, und > dann auf die DCF-RTC umstellen wenn sie gültig wird. Man könnte auch eine RTC für beides benutzen?? Gerade die Idee "auf DCF umschalten" finde ich völlig verkehrt. Ich brauche keine gültige DCF-Zeit.
Bauform B. schrieb: > Ich brauche keine gültige > DCF-Zeit. Das macht ja in einer Funkuhr gar keinen Sinn?!?! Wir sind hier ja in einem "DCF-77-Uhr"-Thread. Da sollte der Empfang der offiziellen gesetzlichen Zeit der BRD schon eine der Kernfunktionen des Geräts sein, oder? Alles andere, wie NTP oder RTC, ist da schon Nebensache. Und schließlich willst du ja eine genaue Zeit. Die bekommst du per Funk. Irgendwie muss die RTC ja auch gestellt und getrimmt werden. Genau das macht Blinkenlights, und witzigerweise vollständig in Software, völlig ohne Batterie, RTC-Chip oder gar TCXO. Ein Controller mit Quarz reicht, und natürlich ein DCF-Empfänger-Modul, handelsüblich und billig.
Jens M. schrieb: > Ein Controller mit Quarz reicht, und natürlich ein DCF-Empfänger-Modul, > handelsüblich und billig. Aber: Strom weg, ggfs. sehr lange warten warten bis die Uhrzeit wieder da ist nachdem der Strom wieder da ist. Also ich hab schon 10 Minuten gesehen bei meinen Tests damals so wenn das Signal sehr schlecht war. Und dann ist eine RTC in HW schon ganz gut. Ob die nun so genau sein muss wenn sie eh mit DCF synchronisiert wird?
900ss schrieb: > Also ich hab schon 10 Minuten > gesehen bei meinen Tests damals so wenn das Signal sehr schlecht war. Joa. Normale DCF-Uhren brauchen 3 Minuten bei sehr gutem Empfang, evtl. auch gar nicht. Meine Blinkenlights schaffen es in unter 20 Minuten aus für mich zufälligem Blinken am DCF-Empfänger. Beste Zeit liegt auch so bei 5 Minuten. 900ss schrieb: > Und dann ist eine RTC in HW schon ganz gut. Kommt ganz auf den Anwendungsfall an. Wenn du einen PC o.ä. synchronisieren willst, ist sie unnötig, der hat eine RTC. Und für einen "Radiowecker" im Wohnzimmer ist es auch egal, denn der läuft immer, und wenn dann mal doch nicht, macht es nix wenn er 10 Minuten nichts zeigt. Du machst so eine Uhr ja nicht regelmäßig an und aus... Und wenn's um's Strom- oder Betriebsstundensparen geht, weil das Display in der Hinsicht doof ist: du kannst ja den Dekoder laufen lassen (ist auch besser weil die Filter erst wieder hochlaufen müssen, das dauert ein paar Tage) und nur die Anzeige deaktivieren. Stromverbrauch des AVR plus DCF-Modul sind wenige mA, das macht den Kohl nicht fett.
Jens M. schrieb: > Normale DCF-Uhren brauchen 3 Minuten bei sehr gutem Empfang, Bei normalen Empfang hat meine ACS-77 nach einer vollen Minute die Zeit.
Peter N. schrieb: > Normale DCF-Uhren brauchen 3 Minuten bei sehr gutem Empfang, Das ist die Plausibilitätskontrolle. Dreimal hintereinander zunehmende Skalenwerte der Minuten. Dann erst ok. Einige Uhren sparen sich das. ciao gustav
Norbert schrieb: > Beziehst du dich dabei auf die slew/skip Grenze? Ja, skip will man ja vermeiden. Wenn das Netzwerk nicht sofort da ist (DSL z.B) passiert das ja beliebig spät.
https://github.com/villamvadasz/DCF77_CH341_decoder Also falls jemand Lust hätte mein Projekt auszuprobieren und Rückmeldung geben wie es sich geschlagen hat, würde ich mich sehr freuen.
Bauform B. schrieb: > Ja, skip will man ja vermeiden. Na ja, Eingabe der Zeit über Tastatur ist auch nicht der wahre Sack der Zwerge. Also dann doch einfach den slew Bereich erweitern (und sich auf eine mehr oder weniger saftige Zeitstrafe einstellen ;-). Synchronisiert wird nämlich mit 500ppm, also ½ms/s. (pro 1 Sekunde Abweichung braucht es grob ½ Stunde bei slew )
Bauform B. schrieb: > Wer sich bei der Sommerzeit-Umschaltung auf DCF > verlässt, akzeptiert sogar einen Fehler von einer Stunde. Behaupte nicht solchen Quatsch, DCF sendet die aktuelle Zeit. Die Umschaltung wird eine Stunde zuvor angekündigt, sodass auch der scheinbare Plausibilitätsfehler verworfen wird. Jens M. schrieb: >> Für jemand, der seine PC-Uhr damit stellen will, damit die gleich vom >> Start weg halbwegs richtig geht. > Das wäre ein interessantes Projekt: eine DIY-DCF-77-Uhr, die via LAN als > Stratum-1-NTP-Server funktioniert. Interessant wird da die Laufzeit der Schnittstelle, die ja Zeitversatz verursacht. Eine korrekte NTP-Implementierung im Client spricht mit dem Server und rechnet die gemessene Laufzeit heraus, aber wie bringt der Server die Zeit versatzfrei ins LAN? Jens M. schrieb: > Bauform B. schrieb: >> Ich brauche keine gültige DCF-Zeit. > Das macht ja in einer Funkuhr gar keinen Sinn?!?! Vollkommen wirr, Herr Bauform macht einen DCF-Thread auf und schreibt dann, dass er keine gültige DCF-Zeit bräuchte. > Wir sind hier ja in einem "DCF-77-Uhr"-Thread. Genau das! Von einem Eigenbau erwarte ich eine Abweichung unter einer Sekunde und eine Anzeige, falls sie mal frei läuft. Ich habe vor etlichen Wochen eine DCF-Decodierung auf einem Chinuino-Uno angefangen, aber nicht ernsthaft weiterbetrieben. Die Displayanzeige der fehlenden Sekunde 59 bereitet mir Kopfzerbrechen. Peter N. schrieb: > Bei normalen Empfang hat meine ACS-77 nach einer vollen Minute die Zeit. Nach einer vollen , da man kaum genau in Sekunde 58 beginnt, sind es in der Realität eher zwei Minuten. Karl B. schrieb: >> Normale DCF-Uhren brauchen 3 Minuten bei sehr gutem Empfang, > Das ist die Plausibilitätskontrolle. Dreimal hintereinander zunehmende > Skalenwerte der Minuten. Dann erst ok. > Einige Uhren sparen sich das. In drei Minuten ab Start bekommt man maximal zwei Telegramme. Hier geht's um Eigenbau, wobei man das Verhalten selbst bestimmen kann. Mein altes Schätzchen übernimmt das erste Telegramm und zeigt das im Display an.
Manfred P. schrieb: > Eine korrekte NTP-Implementierung im Client spricht mit dem > Server und rechnet die gemessene Laufzeit heraus, aber wie bringt der > Server die Zeit versatzfrei ins LAN? Naja, solche Dinger gibt's ja. Ist also machbar, wenn vielleicht auch nicht leicht. Aber für einen Versatz den man noch in ms messen kann sollte das was man so selber schreiben kann reichen, und wesentlich mehr brauchts ja auch nicht. Denk dran, hier geht's nicht um Ultragenau, sondern "für Menschen ablesbar richtig", und einfach DCF-Module sind wg. der Langwellengeschichte eh schon etliche ms später. Manfred P. schrieb: > sind es > in der Realität eher zwei Minuten. Technisch gesehen im Durchschnitt 1:30 ;) Manfred P. schrieb: > Die Displayanzeige der > fehlenden Sekunde 59 bereitet mir Kopfzerbrechen. Nuja, 1000ms nach dem Beginn der 58. kommt die 59. DCF ist zum Stellen einer Uhr, nicht zum laufen... Manfred P. schrieb: > Mein altes Schätzchen übernimmt das erste Telegramm und zeigt das im > Display an. Finde ich gefährlich, weil die Parität manchmal daneben geht. Bei 2 oder 3 Telegrammen kann man solche Bitfehler vermeiden. Ich hab eine Uhr, die wenn dann immer 4, 8 oder gar 16 Minuten oder Stunden daneben geht. Daher lag die wohl im Müll, aber sie hat eine Kalenderwoche mit Kalender, daher hab ich sie behalten.
Manfred P. schrieb: > Nach einer vollen , da man kaum genau in Sekunde 58 beginnt, sind es > in der Realität eher zwei Minuten. Es ist erlaubt die letzten ~60 Bits zwischenzuspeichern. Irgendwo dazwischen ist die Minuten "Austastlücke". Jeder Entwickler der sich beim Frühstücken nicht ständig auf die Finger beißt, kann daraus durchaus ein gültiges Telegramm ableiten. Und anhand der Signalqualität, der drei Prüfsummen und einiger sanity checks auch eine Gültigkeit bewerten.
Jens M. schrieb: > Denk dran, hier geht's nicht um Ultragenau, sondern "für Menschen > ablesbar richtig", und einfach DCF-Module sind wg. der > Langwellengeschichte eh schon etliche ms später. Nein, in Braunschweig (PTB) kommt die Zeit aus Mainhausen ziemlich genau 1ms zu spät an, da kann die Langwelle nichts für. Was die Langwelle verschuldet, ist ein Jitter der Sekunden, aber eher im Bereich von µs. Für den einfachen Geradeausempfänger der PTB 70er-Jahre kommen etwa 15ms Laufzeit dazu. Wie Du sagst, "für Menschen ablesbar" interessieren zweistellige ms nicht. Jens M. schrieb: > Manfred P. schrieb: >> sind es in der Realität eher zwei Minuten. > Technisch gesehen im Durchschnitt 1:30 ;) Einigen wir und auf "statistisch gesehen". > Manfred P. schrieb: >> Mein altes Schätzchen übernimmt das erste Telegramm und zeigt das im >> Display an. > Finde ich gefährlich, weil die Parität manchmal daneben geht. Bei 2 oder > 3 Telegrammen kann man solche Bitfehler vermeiden. Ich hab eine Uhr, die > wenn dann immer 4, 8 oder gar 16 Minuten oder Stunden daneben geht. Ja, die drei Parity-Bits taugen wenig, weil sie bei Doppelfehlern stimmen. Groben Unfug kenne ich von meinem ersten TTL-Grab mit Monoflop und D-Registern. Per µC kann man viel holen, wenn man schnell zyklisch abtastet und den Wert mit zwei Fenstern vergleicht. Unabhängig davon beachte meinen Text "zeigt das im Display an". Die Uhr ist über 30 Jahre alt und schon damals habe ich mitgedacht.
Das erste, an was ich bei "from scratch" dachte, war mein Wunsch seit meiner Jugend, sehr schnell eine DCF-Zeit zu haben, z.B. wenn ich bei Sekunde 10 einschalte, ich bereits bei Sekunde 40 alle Daten angezeigt bekomme. Guter Empfang vorausgesetzt. Die Idee ist ein Bit-Schieberegister, das Schritt für Schritt auf Plausibilität durchgeprüft wird, also ohne die Minutenmarke. Das sollte doch zu machen sein.
Torsten B. schrieb: > z.B. wenn ich bei > Sekunde 10 einschalte, ich bereits bei Sekunde 40 alle Daten angezeigt > bekomme. > ... > Das sollte doch zu machen sein. Dann zeige doch mal Deine Idee dazu, ich habe keine. Die Uhrzeit liegt zwischen 21 und 34, aber wie soll der Anfang detektiert werden?
Manfred P. schrieb: > aber wie soll der Anfang > detektiert werden? Das Ende des Telegramms wird erkannt. Dann zurück gerechnet und all das dekodiert was man zuvor gespeichert hat..
Torsten B. schrieb: > Guter Empfang vorausgesetzt. Die Idee ist ein Bit-Schieberegister, das > Schritt für Schritt auf Plausibilität durchgeprüft wird, also ohne die > Minutenmarke. Das sollte doch zu machen sein. Sag' der Uhr das Datum, dann sind die meisten Bits bekannt. Das müsste doch sogar sicherer sein, als eine einzelne Minutenmarke. Selbst wenn man nur den Tag vorgibt, sind es 12 Bit, 36 bis 41 sicher, und 15 bis 20 mit ziemlich hoher Wahrscheinlichkeit. Man könnte noch einen Vertrauensfaktor anzeigen, abgeleitet aus der Streuung der Impulsbreiten.
Zum Thema Plausibilität: Die Bits 15 bis 20 sind doch 99,99% LLHLLH (Sommer) oder LLLHLH (Winter) Die Bits 21 bis 35 (2^15=32768 Möglichkeiten): hiervon sind nur 24*60=1440 gültig. Das heißt, gesamt gesehen: von den 2^21=2097152 Möglichkeiten sind nur 2*1440=2880 gültig, d.h. Trefferquote ist 727:1 (99,86%)
:
Bearbeitet durch User
Jens M. schrieb: > Ein guter Empfänger, der Nachbausicher designt ist und einem 5€-Modul in > Störfestigkeit und "Reichweite" überlegen ist, darf auch ruhig ein paar > € kosten. Das wird aber echt schwierig. Die Physik ist nicht mit Geld allein erschlagbar. Sonst hätten wir längst Fusionsmeiler in jedem Haus. Ja klar, bezüglich der Empfangseigenschaften ein WENIG besser als die 5€-Module ginge es sicher. Aber Preis und Energieverbrauch könnten dann nicht annähernd mit diesen Modulen mithalten. > sondern schon selber löten nach Stückliste. Schön mit Abgleichen > (möglichst ohne allzu komplexe Werkstatt, nicht jeder ist ein FuA) und > Spule wickeln. Das ist doch Rumgewichse. Viel Arbeit, viel Geld, um am Ende etwas zu erhalten, was nur in einem Aspekt und auch dort nur unwesentlich besser ist als das, was es für einen schmalen Taler an jeder Ecke zu kaufen gibt. Aber klar, wer Spaß an sowas hat, darf das gerne machen.
Ob S. schrieb: > Das ist doch Rumgewichse. Wie jede Bastelei :) > wer Spaß an sowas hat, darf das gerne machen. Eben. Erstaunlich, dass es hier noch so viele Radio-Bastler gibt ;) Den meisten geht es vor allem um das "Empfangserlebnis", den ersten Teil von DCF-Uhr. Mir geht es mehr um den zweiten Teil, um das beste "Benutzererlebnis" mit einer Uhr. Dafür braucht man nun mal etwas mehr Hardware. So eine Uhr * muss sofort¹ nach dem Einschalten Zeit und Datum liefern * darf niemals² gestellt werden * muss Strom- und DCF-Ausfall und Firmware-Updates überbrücken³ * muss anschließend den aufgelaufenen Fehler abschätzen können * kann NMEA-Sätze und ein PPS-Signal liefern * darf als (Licht)Wecker o.ä. dienen 1) wenige ms; max. 1 Sekunde, wenn es synchron sein soll 2) außer bei der Inbetriebnahme, aber nicht wegen Sommerzeit 3) mehrere Wochen. Die Hardware sollte 20 Jahre schaffen, aber in der Zwischenzeit könnten die Sommerzeit-Regeln geändert werden. Oder zu viele Schaltsekunden dazwischen kommen.
Bauform B. schrieb: > * darf niemals² gestellt werden > * muss Strom- und DCF-Ausfall und Firmware-Updates überbrücken³ >... > 2) außer bei der Inbetriebnahme, aber nicht wegen Sommerzeit > 3) mehrere Wochen. Die Hardware sollte 20 Jahre schaffen, aber in der > Zwischenzeit könnten die Sommerzeit-Regeln geändert werden. Beide Forderungen lassen sich nicht gleichzeitig erfüllen. für die Umstellung auf Sommerzeit brauchst du entweder DCF-Empfang oder musst dich auf die geltenden Regeln verlassen.
Sehr aufmerksam beobachtet, danke! Ich hoffe doch, dass so eine Änderung ein paar Wochen vorher bekannt gegeben wird und man dann auch ein Update macht. Deshalb mehrere Wochen und nicht noch mehr. Aber klar, irgendwas geht immer schief.
Zeit/Datum bekommt man auch über die Funkrundsteuerung (drei Sender im Bereich 129,1 kHz bis 139 kHz). Die Dekodierung ist problemlos, die Zeit wird normalerweise alle 10 Sekunden übertragen. https://de.wikipedia.org/wiki/Funkrundsteuertechnik Für eine hochgenaue Referenz nicht unbedingt geeignet, aber als Backup durchaus brauchbar.
Bauform B. schrieb: > 3) mehrere Wochen. Die Hardware sollte 20 Jahre schaffen, aber in der > Zwischenzeit könnten die Sommerzeit-Regeln geändert werden. Oder zu > viele Schaltsekunden dazwischen kommen. 2009 habe ich mir eine DCF-Uhr mit einem Atmega8 mit eigenem Code, der auch wichtige Geburtstage fest drinn hat und einem Puls-Empfänger (vermutlich von Conrad) gebaut. Zwischendurch ist mal das Gehäuse auseinandergefallen, weil ich es mit Heißkleber zusammen geklebt hatte, der wohl nicht so lange hält. Ich habe dann Schrauben rein gedreht. Die Uhr steht auf meiner Fensterbank und läuft immer noch. In 3 Jahren sind die 20 Jahr schon rum.
Bauform B. schrieb: > Ich hoffe doch, dass so eine Änderung > ein paar Wochen vorher bekannt gegeben wird und man dann auch ein Update > macht. Ich gehe davon aus, dass die Regeln so bleiben wie sie sind oder die Umstellung ganz abgeschafft wird. Bei meiner Uhr gibt es einen Jumper, mit dem man die Zeitumstellung abschalten kann. Ich denke, dass das genügt.
Ob S. schrieb: > Aber klar, wer Spaß an sowas hat, darf das gerne machen. Ich für meinen Teil bin mit den üblichen Empfängermodulen zufrieden. Da sitzt der Trick für eine gute Uhr im Decoder im Mikrocontroller. Wenn man eine einfachere Uhr (also ohne oder mit sehr wenig Software) bauen will muss man m.E. an die "Antenne", also die Ferritspule und den AM-Empfänger. Ja, für 5€ geht das nicht im Einzelstück, und das kann auch nicht jeder. Aber das wäre der einzige Punkt an dem man anfassen kann. Längerer Ferrit, abgestimmte Spule, getrimmter Empfänger, bessere AGC, wissenschon. So das der Signaleingang zur Uhr eben auch bei Störteppich von Schaltnetzteilen ruhiger ist und auch in Afrika noch Signale bekommt. Bauform B. schrieb: > * muss sofort¹ nach dem Einschalten Zeit und Datum liefern > * darf niemals² gestellt werden > * muss Strom- und DCF-Ausfall und Firmware-Updates überbrücken³ > * muss anschließend den aufgelaufenen Fehler abschätzen können > * kann NMEA-Sätze und ein PPS-Signal liefern > * darf als (Licht)Wecker o.ä. dienen Punkt 1 erledigt sich mit einer RTC. Ich persönlich kann darauf verzichten wenn die Uhr dann keine Batterie braucht, weil das ja wieder ein Verschleißteil ist. Punkt 2 erledigt sich via DCF, wenn der Empfänger und der Decoder gut sind. Oder via GPS, NTP, RDS. Punkt 3 kann jede Uhr. Auch Funkuhren laufen ohne Funk, und Stromausfall oder Reset gilt wie Kaltstart: Sofortzeit mit RTC, rein DCF mit Wartezeit. Punkt 4 versteh ich nicht. Wozu? Vertraust du deiner RTC nicht? Punkt 5 bedingt ja schon fast GPS. Ich wette das ein Blinkenlights-DCF-Arduino problemlos NMEA und PPS liefert, aber dann kommst du mit weiteren Forderungen um die Ecke, wie z.B. eine Position oder SoWi-Info, oder "PPS muss +-10µs an GMT liegen". PPS zu liefern, das relativ genau ist (also "1s dauert 999,9-1000,1ms" oder so) halte ich noch für machbar, aber absolut genau kann DCF nicht. Auch hier: wozu brauchst du das? Punkt 6 ist trivial, das kann man als DIYer ja ganz nach Gusto... Die Sowi-Regeln muss man nicht anpassen, wenn man DCF nutzt, denn der ergibt die gesetzliche Zeit. Wird das Gesetz geändert, überträgt DCF die SoWi-Änderung eben zu einer anderen Zeit oder evtl. auch gar nicht mehr. Wenn du selber, ohne Funk, nach "deinen" Regeln aus der RTC die gültige Zeit ermitteln willst und das auch noch in Jahren, dann bedingt das ja schon wieder eine Updatemöglichkeit. Da bist du dann schnell bei "das Teil hat WLAN und eine Webseite, wo man Regeln eintippen kann", und dann brauchts kein DCF mehr weil man NTP hat. Und dann kann deine Uhr keine Schaltsekunden.... Also so richtig selbstkasteiend: -Die RTC wird Temperaturstabilisiert und nur bei der Inbetriebnahme gestellt, danach kann man die nicht wieder (ver-)stellen via Lockbit. -Es gibt ein Trimregister, in dem man die Korrektur eintragen kann, damit man auch langfristig genaue Zeit hat -Die RTC läuft in UTC, ohne Schaltsekunden und SoWi -Der Controller hat konfigurierbare Tabellen, ab wann Schaltsekunden eingefügt werden und welche SoWi-Regeln gelten -Vor Anzeige/NMEA wird aus der RTC die lokale Zeit errechnet -Das alles mit möglichst wenig Software, möglichst Systemagnostisch und auch in 20 Jahren noch wart- und korrigierbar -Akkubetrieb, damit die RTC auch bei Ahrtalkatastrophen 72 Stunden temperiert weiterläuft, nicht das die Uhr 4 Millisekunden verliert... Kann man machen. Muss man nicht. Wie sagt man so schön: "das Beste" muss nicht sein, "gut genug" reicht.
:
Bearbeitet durch User
Mich würde ja beim Selberbauen eher interessieren, Empfang&Präzision besser zu machen als die 5€-Module, auch wenn dabei der Stromverbrauch und Preis deutlich steigt. Grob Überschlagen müsste so ein STM32F411 Blackpill-Board locker reichen um die 77kHz PSK Demodulation komplett als SDR in Software zu machen. ADC wäre auch schnell genug, und wenn das Abtasten mit exakt 310kHz geht, wäre das Baseband-Mixing so gut wie kein Rechenzeitaufand. Mit der CMSIS-DSP - Bibliothek gibt's einige der nötigen Funktionen auch schon für STM32 voroptimiert. Als Empfänger-Frontend tuts hoffentlich so ein 5€-Modul, dem man den Chip klaut, nur den Schwingkreis behält, und das Signal verstärkt.
Εrnst B. schrieb: > Grob Überschlagen müsste so ein STM32F411 Blackpill-Board locker reichen > um die 77kHz PSK Demodulation komplett als SDR in Software zu machen. > ADC wäre auch schnell genug, und wenn das Abtasten mit exakt 310kHz > geht, wäre das Baseband-Mixing so gut wie kein Rechenzeitaufand. Hier musste ich gerade schmunzeln, das geht sogar ganz hervorragend um nicht zu sagen heraus baumelnd. Mit 'nem RP2xxx. ADC Divider (bei 48MHz Clock) INT:153,FRAC:215 (für 77499,432Hz) Jeweils das Vierfache natürlich. INT:153,FRAC:214 (für 77501,388Hz) Der FRAC Teil passt sich immer automatisch an wenn die (gemittelten und gefilterten) Nullstellen größer werden. Nebenbei kann man über die Wochen auch noch die Abweichung des genutzten Quarzes bestimmen und sich ein verdammt gutes PPS Signal für sein System generieren.
:
Bearbeitet durch User
Norbert schrieb: > Mit 'nem RP2xxx. Hatte ich auch überlegt, aber wegen fehlendem Single-Cycle Multiply-and-Add und FPU lieber den F411 angeschaut. Aber der fraktionale Teiler für den ADC-Takt schaut schon nett aus.
Εrnst B. schrieb: > lieber den F411 angeschaut Hab hier noch ein F407. Selbst bei dem spielen die ADCs in einer völlig anderen Liga als bei den RPs. Triple-ADC-Interleaved mit bis zu 7.2MSps hatte ich mal laufen, WIMRE.
Dieter S. schrieb: > Zeit/Datum bekommt man auch über die Funkrundsteuerung (drei Sender im > Bereich 129,1 kHz bis 139 kHz) Christoph M. schrieb: > 2009 habe ich mir eine DCF-Uhr mit einem Atmega8 mit eigenem Code, der > auch wichtige Geburtstage fest drinn hat Sehr schön, jetzt kommen die guten Ideen! Verkauft noch irgendwer einzelne DCF49-Empfänger? HKW wohl nicht :( Jens M. schrieb: > Ich für meinen Teil bin mit den üblichen Empfängermodulen zufrieden. > Da sitzt der Trick für eine gute Uhr im Decoder im Mikrocontroller. Mein Reden seit 1328. > ... Batterie ... Verschleißteil Jein. Die kleinste Li-SOCI2 Batterie hat ca. 1 Ah, die RTC braucht weniger als 1 µA bzw. die meiste Zeit nur Leckstrom. Also 50 Jahre oder wenigstens 20 sollte die schon halten. Wie oft muss man in der Zeit wohl das Steckernetzteil tauschen? > Punkt 4 versteh ich nicht. Wozu? Vertraust du deiner RTC nicht? Doch, sicher mehr als dem gestörten DCF-Signal. Deswegen sind auch nur 2 Chips jeweils mit eigener Batterie und eigenem I2C-Bus vorgesehen. Wie viel sicherer wären eigentlich 3 statt 2? Die meisten Flugzeuge haben auch nur 2 Triebwerke. > Punkt 5 bedingt ja schon fast GPS. Ich wette das ein Blinkenlights-DCF-Arduino > problemlos NMEA und PPS liefert, aber dann kommst du mit weiteren > Forderungen um die Ecke, wie z.B. eine Position oder SoWi-Info GPS liefert keine SoWi-Info, andererseits habe ich die Info ja sowieso. Position wäre natürlich witzig: umgekehrte Funkpeilung mit 3 bis 5 Zeitzeichensendern und 2 bis 3 Ferritantennen. Oder eine drehbare Ferritantenne mit Motor. Die braucht man auch, wenn die Uhr genau am falschen Platz stehen soll ;) > PPS zu liefern, das relativ genau ist (also "1s dauert 999,9-1000,1ms" > oder so) halte ich noch für machbar, aber absolut genau kann DCF nicht. Das kann GPS auch nicht, besser als ±100 ns sind schon gut. Aber wenn man lange genug guten Empfang hat... Die RTC-Frequenz kann mit 0.1 ppm Auflösung getrimmt werden und zwischen 10 und 40°C bleibt weniger als 1 ppm Temperaturdrift. Der uC produziert Jitter, das ist der spannende Faktor. Trotzdem kann man wohl mit NTP per DSL mithalten. > Auch hier: wozu brauchst du das? Die NMEA refclock vom ntpd funktioniert überraschend gut, die DCF refclock überraschend schlecht. Und natürlich: Kein GPS-Empfang im Keller? GPS stärker gestört als DCF? Redundanz? Vergleich mit NTP per Glasfaser? RTC-Vergleichstest? Das ist halt so ein Feature, das nur einen Pin und einen Timer kostet, also nimmt man das mit. > Wenn du selber, ohne Funk, nach "deinen" Regeln aus der RTC die > gültige Zeit ermitteln willst und das auch noch in Jahren, > dann bedingt das ja schon wieder eine Updatemöglichkeit. Sommerzeit, Schaltsekunden und Zeitzone kosten im Wesentlichen nur eine Addition und eine Tabelle für alles. Dafür braucht man kein komplettes Update. Das brauche ich aber auf jeden Fall, weil meine Programme selten beim ersten Versuch funktionieren ;) > Also so richtig selbstkasteiend: Exakt. Genau so soll das aussehen. Bis auf die Li-SOCI2 Batterie statt Akkubetrieb. Die Wartbarkeit nach 20 Jahren ist natürlich ein ganz eigenes trauriges Kapitel. Das übelste Beispiel: Lieber RS-232 mit Sub-D als USB. Es muss ja nicht nur innen drin kompatibel bleiben, man muss ja auch noch Kabel kaufen können. Momentan ist USB-C der angesagte Stecker. Vor weniger als 20 Jahren war Mikro-USB die endgültige Lösung. Ja, die EU muss auch den armen Netzteil-Herstellern helfen :(
Εrnst B. schrieb: > Grob Überschlagen müsste so ein STM32F411 Blackpill-Board locker reichen > um die 77kHz PSK Demodulation komplett als SDR in Software zu machen. > ADC wäre auch schnell genug, und wenn das Abtasten mit exakt 310kHz > geht, wäre das Baseband-Mixing so gut wie kein Rechenzeitaufand. So weit so gut. Aber ein 5€-Modul mit AGC funktioniert mit 1 µV bis 20 mV, eher mehr. Wie schafft ihr die Dynamik? Da wären zwar nur 14 bis 15 Bit, aber es sollen ja noch mehr als 2 zum Rechnen übrig bleiben. > Als Empfänger-Frontend tuts hoffentlich so ein 5€-Modul, dem man den > Chip klaut, nur den Schwingkreis behält, und das Signal verstärkt. Da bleibt ja nichts übrig, eigentlich klaut man dem Modul die Antenne. Und gerade die will man ja verbessern, vor allem mit längerem Ferritstab.
Bauform B. schrieb: > Das kann GPS auch nicht Etwas OT: GPS sagt mir gerade, dass das Arduino-Bastelmodul mit einer Geschwindigkeit von 2,2 km/h bewegt wurde. Hat 5 Minuten am Fenster gestanden. Dann habe ich es auf den Tisch gestellt. Jetzt gerade 0,5 km/Stunde. Es liegt ja unbewegt auf dem Tisch. Wie errechnet das Modul das? Oder - wage ich zu spekulieren - das sind die prinzipiellen Unsicherheiten des GPS-Empfangs (Wolken/Regen etc.) P.S.: Die Zeit-Datums-Funktion muss ich noch einbinden. Händisch +2 wegen Sommerzeit Korrekturfaktor eingeben. Long/Lat und Speed sind im Programm drin. (Und 5 Sats!) /OT ciao gustav
Karl B. schrieb: > P.S.: Die Zeit-Datums-Funktion muss ich noch einbinden. Händisch +2 > wegen Sommerzeit Korrekturfaktor eingeben. Long/Lat und Speed sind im > Programm drin. (Und 5 Sats!) > /OT Man kann theoretisch auch die Zeitzone aus dem Lat Long ermitteln und lokale Zeit anzeigen. Wollte ich mal machen, nur habe ich nirgendwo einen map in digitalen format gefunden. Falls jemand soetwas hätte....
Andras H. schrieb: > Man kann theoretisch auch die Zeitzone aus dem Lat Long ermitteln und > lokale Zeit anzeigen. Wollte ich mal machen, nur habe ich nirgendwo > einen map in digitalen format gefunden. Falls jemand soetwas hätte.... vielleicht hilft das: https://github.com/evansiroky/timezone-boundary-builder hab's nicht genau angeschaut
Bauform B. schrieb: > Sehr schön, jetzt kommen die guten Ideen! Geburtstage Feiertage Mülltonnen Sonstige Termine Sollte man alles aus einem "öffentlichen" Kalender auslesen können, mittels CalDAV. Wochentag, Tag im Jahr, Kalenderwoche sowieso, zusätzlich Sonnen- und Mondauf- und -untergang. Arbeitstag x von y dieses Jahr. HDMI-Ausgang für ein großes Display, damit man die ganze Tabelle auch gut sehen kann. Bauform B. schrieb: > Deswegen sind auch nur 2 > Chips jeweils mit eigener Batterie und eigenem I2C-Bus vorgesehen. Jetzt wird's wild. Ich hoffe, 2 verschiedene Chips, von 2 verschiedenen Herstellern, mit 2 verschiedenen Protokollen. 2 unterschiedliche Batterien, nicht das Varta in der einen Charge einen Fehler hatte, dann tut hoffentlich die Duracell noch. Bauform B. schrieb: > GPS liefert keine SoWi-Info, andererseits habe ich die Info ja sowieso. Woher? Bauform B. schrieb: > Die braucht man auch, wenn die Uhr genau am > falschen Platz stehen soll ;) Ein abgesetzter Empfänger (evtl. mit Phantomspeisung wenn 3-adrige Leitung zu teuer ist) tut's auch. Bauform B. schrieb: > eine Tabelle für alles. Tabellen sind irgendwann zuende. Ja, du schreibst Daten für 50 Jahre da rein. Und deine Erben ärgern sich dann, das Opis Uhr nicht mehr tut weil der Depp damals nicht an die Galaktime gedacht hat. Schade, schönes Retroding, leider Müll. Update per RS232? Kabel sind so letztes Jahrtausend. Eine (natürlich SSL-gesicherte!) Webseite ist das was du willst. Karl B. schrieb: > Wie errechnet das Modul das? Entweder ist der Empfang schlecht und das wirkt sich auf die Doppler-Berechnung aus, oder weil die Position immer etwas wackelt und der Unterschied nun mal eben ein paar Schritte pro Sekunde sind.
Jens M. schrieb: > HDMI-Ausgang für ein großes Display Also wirklich nicht; wenn, dann Display Port ;) > Und deine Erben ärgern sich dann, das Opis Uhr nicht mehr tut weil der > Depp damals nicht an die Galaktime gedacht hat. Dagegen hilft nur eins: zurück zur Natur. Die Uhr benutzt nicht nur intern TAI, sondern zeigt auch nur TAI an. Alles andere passiert ja sowieso immer auf dem PC. Wer ist eigenlich auf die seltsame Idee gekommen, dass eine DCF-Uhr Lokalzeit anzeigen muss? Leute, die die Umstellung hassen, nutzen das sowieso nicht. Und die paar Sekunden Versatz zu UTC merkt keiner. NMEA-Sätze für den ntpd kann man dann nicht mehr erzeugen; das wäre UTC, und NTP-Zeit ist praktisch auch UTC. Man müsste auf dem PC eine shm refclock benutzen, die /usr/share/zoneinfo/leap-seconds.list auswertet. Allerdings benutzt der ntpd die Liste auch selber, was macht der damit? Aber die Uhr wird sooo viel einfacher, das sollte es uns wert sein. > Eine (natürlich SSL-gesicherte!) Webseite ist das was du willst. Das würde auch Updates brauchen und, viel schlimmer, irgendwann akzeptiert ein Browser solche Zertifikate aus politischen Gründen nicht mehr. Also: nix gibt's. Jens M. schrieb: > Bauform B. schrieb: >> Deswegen sind auch nur 2 >> Chips jeweils mit eigener Batterie und eigenem I2C-Bus vorgesehen. > > Jetzt wird's wild. Ich hoffe, 2 verschiedene Chips, von 2 verschiedenen > Herstellern, mit 2 verschiedenen Protokollen. 2 unterschiedliche > Batterien, nicht das Varta in der einen Charge einen Fehler hatte, dann > tut hoffentlich die Duracell noch. Wie so oft war der erste Entwurf wohl doch besser. Da wollte ich als 2. RTC den uC benutzen. Ein TCXO mit 10 MHz ist garnicht verkehrt, braucht aber über 1 mA, auch im Batteriebetrieb. Das geht, wenn ein Wecker drin ist, weil man für den Akkus braucht.
SCNR. Habe heute morgen einmal DCF77-Empfang und GPS-Empfang verglichen. (OK. Die Minute 59 macht auch beim DCF77-ASM-Programm gewisse Unsauberkeiten. Da muss ich nochmal ran.) Der Direktmischer (Tonwiedergabe) arbeitet mit S042P und ist ca. 2,5 kHz höher als 77,5 kHz eingestellt. Viel Spaß! ciao gustav P.S.: Hier noch der "Sketch".
:
Bearbeitet durch User
Karl B. schrieb: > Die Arduino GPS-Uhr zeigt im OLED nur "Suche Satelliten" an. Da blinken > LEDs, aber auch nach ca. 5 Minuten tut sich nichts weiter. Als Fehlerdiagnose ist das etwas dünn. Eine Antenne ist angeschlossen? Ansonsten verrät dir evtl. ein Blick in die NMEA-Daten mehr. Oder ist das NEO-6M-Modul so alte, dass es mit dem Überlauf vom Zähler für die GPS Woche nicht zurecht kommt?
:
Bearbeitet durch User
R. L. schrieb: > vielleicht hilft das: > > https://github.com/evansiroky/timezone-boundary-builder > > hab's nicht genau angeschaut Sieht gut aus. Danke!
Rainer W. schrieb: > Als Fehlerdiagnose ist das etwas dünn. Typischer Fehler: RXD und TXD nicht an Nano-Pins mit derselben Bezeichnung. Im Sketch steht aber bei näherem Hinsehen an Deutlichkeit kaum zu überbieten im Kommentar "3" und "4". Und das heißt im Klartext: D3 und D4. Und der zweite GND-Anschluss sollte auch beschaltet werden. Dann gehts. (BTW: Und beim Flashen für den "neuen" Bootloader den 10µF Kondensator an der richtigen Stelle nicht vergessen. "...Ein 10µF-Kondensator wird benötigt, wenn ein Arduino als sogenannter "ArduinoISP" (Programmierer) dient, um den automatischen Reset des Programmierer-Boards zu verhindern. Dadurch bleibt der Mikrocontroller im Programmiermodus, während er den neuen Bootloader auf das Zielboard (z. B. einen Nano oder Uno) flasht)...") ciao gustav P.S.: Beim "einfachen" Uhrenprogramm oben wird nur TXD gebraucht. Ist dann schon richtig verlötet.
:
Bearbeitet durch User
@ Karl B.: Das interessiert hier in diesem Thread KEIN Schwein! Es geht hier um ein ganz anderes Thema. Hör endlich mit der Kaperei auf!
Karl B. schrieb: > Time_21May2026.mp4 (4,3 MB) Frechheit und off topic. Rainer W. schrieb: > verrät dir evtl. ein Blick in die NMEA-Daten mehr. DCF77 liefert keine NMEA-Daten. Karl B. schrieb: > Typischer Fehler: RXD und TXD nicht an Nano-Pins mit derselben > Bezeichnung. DCF77 benötigt für den Empfang kein Rx. Carsten W. schrieb: > @ Karl B.: Das interessiert hier in diesem Thread KEIN Schwein! Es > geht hier um ein ganz anderes Thema. Hör endlich mit der Kaperei auf! Nicht nur hier, dieser 'komische Gustav' (alte Redewendung) kaspert überall.
Bauform B. schrieb: > aber über 1 mA, auch im Batteriebetrieb. Das geht, wenn ein Wecker drin > ist, weil man für den Akkus braucht. Also mein 10€-Funk-Wecker läuft mit einer R3-Primärzelle gut ein Jahr. Und er nervt wirklich. Ich wüßte nicht, wozu der noch einen Akku brauchen sollte...
Ob S. schrieb: > Bauform B. schrieb: >> aber über 1 mA, auch im Batteriebetrieb. Das geht, wenn ein Wecker drin >> ist, weil man für den Akkus braucht. > Also mein 10€-Funk-Wecker läuft mit einer R3-Primärzelle gut ein Jahr. > Und er nervt wirklich. Es gibt Unterschiede, ich habe einen, den ich kaum höre. > Ich wüßte nicht, wozu der noch einen Akku > brauchen sollte... Ich weiß nicht mehr, was Herr Bauform B. eigentlich will. Er hat den Thread gestartet, aber mutiert inzwischen mehr zum Troll und führt diesen zur Sinnlosigkeit.
Manfred P. schrieb: > Es gibt Unterschiede, ich habe einen, den ich kaum höre. Sender- oder Empfängerproblem?
Manfred P. schrieb: > Ob S. schrieb: >> Also mein 10€-Funk-Wecker läuft mit einer R3-Primärzelle gut ein Jahr. >> Und er nervt wirklich. > > Es gibt Unterschiede, ich habe einen, den ich kaum höre. Laß mich raten: er ist mindestens 20 Jahre alt? Dann erstze ihm durch einen neueren. Auch da hat sich etwas getan in Sachen Effizienz. Eine Piezo-Scheibe mit passender Resonanzkammer macht einen Höllenlärm bei marginalem Energiebedarf. Ach so: die Kenntnis eines Beispiels (deines Weckers) reicht ohnehin nicht für eine gültige Generalaussage (alle Wecker fressen Batterien und sollten deshalb mit Akkus betrieben werden).
Beitrag #8052682 wurde vom Autor gelöscht.
Angehängte Dateien:
-
trolluhr.jpeg
210 KB -
trolluhr-brd.png
53 KB -
trolluhr-sch.png
19 KB
Manfred P. schrieb: > Ich weiß nicht mehr, was Herr Bauform B. eigentlich will. Er hat den > Thread gestartet, aber mutiert inzwischen mehr zum Troll Es tut mir leid, dass ich dich so irritiert habe. Die gute Seite davon: die Uhr hat jetzt einen passenden Namen: "trolluhr", ausgesprochen so wie "Tellur", dieses seltene Halbmetall. Zum Trost gibt es auch Bilder vom aktuellen halbfertigen Stand. Das war nur ein Muster um zu sehen, ob die Platinen mechanisch passen und ob man lieber die niedrigen oder die hohen Taster nehmen sollte. Unter der blauen Haube steckt ein SAM-M10Q, unter dem fetten Kühlkörper ein RPi-3B und ganz unten erkennt man vielleicht die 6 Batteriehalter. Hinter das große Loch gehört ein DOG-LCD 102x64.
Was fragst Du hier im Forum noch herum, wenn das Design schon fertig ist? Kannst Du den Schaltplan auch in einer lesbaren Form (PDF) hier einstellen? So als PNG ist das unbrauchbar, weil viel zu klein.
Moin! Ich bin da voll bei @ernst, und ich habe da mal etwas recherchiert. Am Ende komnmt da ein Cortex-M4 oder ein Cortex-M7 bei heraus, da diese FPU und DSP Funktionen mitbringen und den SDR Filter Part in Hardware nebenbei erledigen ohne die CPU zu stören. Also echte parallel Verarbeitung. Ich habe dann mal nach diesen Daten die STM32 gefiltert und dabei dann STM32H723 oder den STM32H743 gefunden. Beide sind auf Nucleo Boards für 30 bis 50€ erhältlich. Echte 16-bit ADC mit DMA, SMID und DSP, 16-bit DAC um einen OCXO zu führen. Ethernet und USB sind auch drin. Theoretisch kann man damit die ganze Strecke vom SDR Receiver bis zum PTP Server oder NEMA backup für seinen Symmetricom bauen oder den 16-Bit DAC zum nachführen eines OCXO nutzen.
Manfred P. schrieb: > Karl B. schrieb: >> Time_21May2026.mp4 (4,3 MB) > Frechheit und off topic. > > Rainer W. schrieb: >> verrät dir evtl. ein Blick in die NMEA-Daten mehr. > > DCF77 liefert keine NMEA-Daten. > > Karl B. schrieb: >> Typischer Fehler: RXD und TXD nicht an Nano-Pins mit derselben >> Bezeichnung. > > DCF77 benötigt für den Empfang kein Rx. > > Carsten W. schrieb: >> @ Karl B.: Das interessiert hier in diesem Thread KEIN Schwein! Es >> geht hier um ein ganz anderes Thema. Hör endlich mit der Kaperei auf! > > Nicht nur hier, dieser 'komische Gustav' (alte Redewendung) kaspert > überall. Sehe mich leider genötigt, einiges klarzustellen: GPS wurde hier erwähnt, habe bloß vergessen zu zitieren. Und wer lesen kann ist eindeutig im Vorteil. Hier bringt jemand ganz bewusst wieder die Postingsfolge durcheinander, nur um mir wieder unschöne Worte an den Kopf werfen zu können. Dabei wäre es wirklich einen Versuch wert, die allenthalben zur Verfügung stehenden Systeme (DCF77/MSF60/GPS) miteinander zu vergleichen. Nichts anderes habe ich im Video gemacht. Sowas mit Frechheit und offtopic zu bezeichnen, sagt viel über denjenigen aus, der sowas postet. Die Antwort mit dem Begriff RX bezieht sich auf die Bemerkung von: Rainer W. schrieb: > Als Fehlerdiagnose ist das etwas dünn. Eine Antenne ist angeschlossen? > Ansonsten verrät dir evtl. ein Blick in die NMEA-Daten mehr. Oder ist > das NEO-6M-Modul so alte, dass es mit dem Überlauf vom Zähler für die > GPS Woche nicht zurecht kommt? Und meine Antwort bezieht sich auf die Arduino-GPS-Uhr. Mit der Angabe der typischen Fehler, die man machen kann. Wird die Verdrahtung richtig gewählt, funktioniert es wunschgemäß. Da brauche ich nicht soweit in die GPS-Technologie einzusteigen und mir die NEMEA-Suite auswendig zu lernen. So what? > Carsten W. schrieb: hier um ein ganz anderes Thema. Hör endlich mit der Kaperei auf! > > Nicht nur hier, dieser 'komische Gustav' (alte Redewendung) kaspert > überall. Ich fordere Dich hiermit auf, diese Beleidigung zurückzunehmn. Sonst drücke ich den Meldeknopf. Dienmal mache ich Ernst. Ich weiß, ich bin zwar klein und mickrig, aber anspucken lasse ich mich nicht. ciao gustav
Carsten W. schrieb: > Was fragst Du hier im Forum noch herum, wenn das Design schon > fertig ist? Fertig ist maximal die Mechanik und Auswahl von LCD, GPS, RPi u.ä. Die Schaltung hat noch 2 bis 3 grobe Fehler, vor allem die Stromversorgung. In diesem Thread hat man mir z.B. erklärt, dass 2 gleiche RTC Chips ziemlich sinnlos sind, besonders, wenn sie sich eine Batterie teilen. Wer solche "Kleinigkeiten" übersieht, darf hier fragen, oder? Eigentlich ist das Programm doch viel wichtiger und spannender. Die Hardware muss "nur" genug Möglichkeiten bieten. Zum Beispiel geht das Signal vom DCF-Empfänger auf einen Pin mit ADC, UART oder Timer. Das sollte für 5€-Module oder Empfänger mit µC und auch für Antenne+Verstärker passen, weil Ulrich schrieb: > Ich bin da voll bei @ernst, und ich habe da mal etwas recherchiert. > Am Ende komnmt da ein Cortex-M4 oder ein Cortex-M7 bei heraus [...] > Echte 16-bit ADC mit DMA, SMID und DSP, 16-bit DAC um einen > OCXO zu führen. Na gut, eine Nummer kleiner, STM32L496. Der DAC hat nur 12 Bit und der Oszillator ist nur ein TCXO, aber immerhin mit eigenem Spannungsregler ;) Der ADC hat auch nur 12 Bit, aber ich glaube, das muss reichen. Der Verstärker braucht sowieso AGC, um mit der Dynamik vom 5€-Modul mithalten zu können. Mit 1 µV * 100 dB wird der ADC gerade mal zu 10% ausgesteuert. An der Stelle bin ich völlig ratlos, wie das funktionieren soll. Hier kam auch der Einwand, dass PSK nicht gegen Störungen hilft, weil es mehr Bandbreite braucht. Sollte man vielleicht Filter und AM Demodulator in Software machen? Außerdem, wenn ich einen 100 dB Verstärker baue, haben wir einen Sender, keinen Empfänger ;) > Kannst Du den Schaltplan auch in einer lesbaren Form (PDF) hier > einstellen? So als PNG ist das unbrauchbar, weil viel zu klein. Lohnt sich das jetzt schon? Gibt das nicht noch mehr Verwirrung?
Karl B. schrieb: >> Carsten W. schrieb: >> hier um ein ganz anderes Thema. Hör endlich mit der Kaperei auf! >> >> Nicht nur hier, dieser 'komische Gustav' (alte Redewendung) kaspert >> überall. > > Ich fordere Dich hiermit auf, diese Beleidigung zurückzunehmn. Ich sehe da keine Beleidigung. Zum Streiten und Beleidigen braucht man immer zwei. > Ich weiß, ich bin zwar klein und mickrig Vor allem bist du ungewöhnlich zart besaitet. Gönn' dir Kaffee und Kuchen oder ne Maß Bier, dann wird das schon wieder. Und dann vertragt euch wieder, in DCF-Threads wird nicht gestritten.
Bauform B. schrieb: > Mit 1 µV * 100 dB wird der ADC Brauchst du denn diese Empfindlichkeit? Oder möchtest du die einfach gerne erreichen?
Keine Ahnung. Bis jetzt, mit den 5€-Modulen kann ich "zu wenig Signal" nicht von "zu viele Störungen" unterscheiden. Und es sollte ja besser werden ;) Aber egal, 20 dB hin oder her, auch echte 16 Bit reichen doch nie?
Manfred P. schrieb: .... >> Carsten W. schrieb: >> @ Karl B.: Das interessiert hier in diesem Thread KEIN Schwein! Es >> geht hier um ein ganz anderes Thema. Hör endlich mit der Kaperei auf! > > Nicht nur hier, dieser 'komische Gustav' (alte Redewendung) kaspert > überall. Wenn man schon rumpöbeln muss, dann sollte man auch wenigstens richtig zitieren! Von mir war der Spruch nämlich nicht!
Bauform B. schrieb: > Unter der blauen Haube steckt ein SAM-M10Q, .. womit das nicht hierher passt, dieses GNSS-Modul kann keinen DCF-Empfang. > unter dem fetten Kühlkörper ein RPi-3B Geht's noch, soviel (Verlust-)Leistung für eine Uhr? Fette Kühlkörper hatte man vor xx-Jahren, als DCF-Uhren mit TTL und Längsregler-Netzteil gebaut wurden. Die Decodierung des DCF erledigt jeder Mikrocontroller mit weniger als 100 Milliwatt, der größte Stromverbraucher wird das Display.
Manfred P. schrieb: > Geht's noch, soviel (Verlust-)Leistung für eine Uhr? Ja geht's noch? Muss ich jetzt meine Nixieuhr die auch DCF77 dekodiert, stilllegen? Die braucht immerhin 3-4 W ähnlich dem RPi. Meine Scopeuhr braucht sogar 10W, da sind die Ablenkverstärker aus zwei Doppeltrioden. Ach her je...... ;-)
:
Bearbeitet durch User
Bauform B. schrieb: > Keine Ahnung. Bis jetzt, mit den 5€-Modulen kann ich "zu wenig Signal" > nicht von "zu viele Störungen" unterscheiden. Und das ist mit viel teurerer und aufwendigerer Hardware auch nicht viel anders, sofern sie nur einmal existiert. Genau das ist das physikalische Problem, was da dahinter steckt. Sprich: du brauchst diese teure und aufwendige Hardware MEHRFACH und räumlich verteilt, erst das versetzt dich in die Lage, die heftigen Störungen im Nahfeld vom Fernfeld-Signal "abziehen" zu können. Stichwort: phase array. Da wird das bis zum Exzess durchgezogen. Mit Dutzenden bis Hunderten von einzelnen "Empfängern".
Da gabs mal eine thread zur Nutzung des seit 1983 per Phasenmodulation hinzugekommenen PRN Anteils im DCF-Signal. Ist aber eher ein FPGA und kein AVR-Thema. Der thread von 2012: * Beitrag "Paper zu DCF77"
:
Bearbeitet durch User
Bradward B. schrieb: > Da gabs mal eine thread zur Nutzung des seit 1983 per Phasenmodulation > hinzugekommenen PRN Anteils im DCF-Signal. > > Ist aber eher ein FPGA und kein AVR-Thema. Nein, Quatsch. 1) Erfolgreicher Empfang der Phasenmodulation mit AVR wurde bereits umgesetzt. Da gab es eine entsprechende Lösung in "Projekte und Code". 2) Die funktioniert allerdings bei Nahfeld-Störungen durch irgendwelche geswitchte Scheiße genau so wenig wie der AM-Empfang der üblichen DCF77-Module. Ist doch logisch: wenn dir ein Preßlufthammer direkt neben dem Kopf die Gehörgänge zunagelt, wirst du nie den menschlichen Sprecher aus dem nächsten Zimmer verstehen. Und unser Gehör ist schon SEHR clever bei der Trennung von Nutzsignal und Müll. Technische Lösungen erreichen hier gerade erst seit wenigen Jahren wenigstens in etwa dasselbe Niveau.
900ss schrieb: > Manfred P. schrieb: >> Geht's noch, soviel (Verlust-)Leistung für eine Uhr? > Ja geht's noch? Muss ich jetzt meine Nixieuhr die auch DCF77 dekodiert, > stilllegen? Die braucht immerhin 3-4 W ähnlich dem RPi. Erkenne den Unterschied und meine Anmerkung "der größte Stromverbraucher wird das Display". Auf seinem Bild sieht mir der Kühlkörper nach mehr als 3 Watt aus. > Meine Scopeuhr braucht sogar 10W, da sind die Ablenkverstärker aus zwei > Doppeltrioden. Darfst Du gerne betreiben, wenn es Spaß macht. Es muß Dir nicht gefallen, ich bleibe bei meiner Kritik des überdimensionierten Controllers. Selbst, wenn ein AT328 wegen zusätzlicher Spielereien nicht ausreichen sollte, wäre ein ESP32 noch weit weg von einem Kühlkörper. Ob S. schrieb: >> Keine Ahnung. Bis jetzt, mit den 5€-Modulen kann ich "zu wenig Signal" >> nicht von "zu viele Störungen" unterscheiden. > Und das ist mit viel teurerer und aufwendigerer Hardware auch nicht viel > anders, sofern sie nur einmal existiert. Genau das ist das physikalische > Problem, was da dahinter steckt. NJein, mit einer schmalbandigen und sorgfältig abgestimmten Antenne lässt sich schon etwas gewinnen. Wenn natürlich das Schaltnetzteil 50cm daneben mit mehreren Volt bläst, verloren. > Sprich: du brauchst diese teure und aufwendige Hardware MEHRFACH und > räumlich verteilt, erst das versetzt dich in die Lage, die heftigen > Störungen im Nahfeld vom Fernfeld-Signal "abziehen" zu können. Nah- und Fernfeld bei 77,5 kHz = 3,9 km Wellenlänge? > Stichwort: phase array. Da wird das bis zum Exzess durchgezogen. Mit > Dutzenden bis Hunderten von einzelnen "Empfängern". "phase array" für Langwelle, reicht dafür die Fläche von Berlin aus? Ob S. schrieb: > Bradward B. schrieb: >> Da gabs mal eine thread zur Nutzung des seit 1983 per Phasenmodulation >> hinzugekommenen PRN Anteils im DCF-Signal. >> >> Ist aber eher ein FPGA und kein AVR-Thema. > > Nein, Quatsch. > > 2) Die funktioniert allerdings bei Nahfeld-Störungen durch irgendwelche > geswitchte Scheiße genau so wenig wie der AM-Empfang der üblichen > DCF77-Module. Sehe ich ebenso, ohne sauberen Empfang des Grundsignals nützt die Phasenmodulation nichts und ist für eine Uhr sowieso sinnlos. > Ist doch logisch: wenn dir ein Preßlufthammer direkt neben dem Kopf die > Gehörgänge zunagelt, wirst du nie den menschlichen Sprecher aus dem > nächsten Zimmer verstehen. Und das, obwohl der in einem anderen Frequenzbereich Hämmert - das Zustopfen des Eingangs nennen die HF-Leute "Weitabselektion".
> 2) Die funktioniert allerdings bei Nahfeld-Störungen durch irgendwelche > geswitchte Scheiße genau so wenig wie der AM-Empfang der üblichen > DCF77-Module. (Aktive) Ferritantenne mit Richtcharakteristik durch die PRN ist das SNR besser. und swiktsche switschen eben nicht zufällig.
:
Bearbeitet durch User
Manfred P. schrieb: > Geht's noch, soviel (Verlust-)Leistung für eine Uhr? Fette Kühlkörper > hatte man vor xx-Jahren, als DCF-Uhren mit TTL und Längsregler-Netzteil > gebaut wurden. Zur Zeit geht der Trend eindeutig zu "der Strom kommt ja aus der Steckdose". Der RPi 3B war insofern der letzte brauchbare, der 5er ist ja wohl ein schlechter Scherz. Schon der 3B+ ist Mist mit dem halben Gigabit Netzwerk und der Stromfresser-CPU. Der 3B läuft natürlich auch ohne den Kühlkörper, aber das ist ein stabiler und formschöner Deckel. > Die Decodierung des DCF erledigt jeder Mikrocontroller mit weniger als > 100 Milliwatt, der größte Stromverbraucher wird das Display. Der RPi ist nur für NTP zuständig und irgendwer wollte HDMI haben ;)
1 | Display DOGS102: 0.25 mA typisch |
2 | CPU STM32L496: < 4 mA |
3 | TCXO KT2016K10000: < 1.5 mA |
4 | GPS SAM-M10Q: 7 mA typisch; tracking |
5 | DCF ???: t.b.d. |
6 | diverse Pull-Down: 1.2 mA |
7 | ALS SFH5711: ca. 0.5 mA |
8 | RS-232 MAX3223E: < 1.3 mA ohne Last |
9 | RS-485 MAX3079E: < 1.5 mA unterminiert |
10 | 4x LDO MIC5236: < 0.12 mA |
11 | 3x Referenz REF3433: < 0.3 mA |
12 | OP INA186A1Q: ca. 0.2 mA |
13 | was-ich-noch-vergaß: ? |
So ein krasser Fall von Kleinvieh macht Mist :( Das meiste ist zwar einzeln abschaltbar und zwecks Tiefentladeschutz kann alles abgeschaltet werden. Der RPi wird bei Batteriebetrieb wohl kaum gebraucht. Aber das Kleinvieh baut man ja nicht zum Spaß ein.
(Aktive) Ferritantenne mit Richtcharakteristik Durch die PRN ist das SNR besser. Und "Switche" switchen eher nicht "zufällig", das "filtert" die Korrelation gut raus.
Hatte beim Eröffnungspost gleich den Eindruck, dass um zweierlei Kategorien von "Störungen" geht. Oben wurde verlinkt zu: http://www.gjlay.de/software/dcf77/konzept.html Einmal der Empfang selbst, dann die En- bzw. Decodierung. Bei Betrachtung letzerer gibt es bei DCF77 historisch nicht viel zu berichten, außer, das die ersten 14 Bits nun "vermietet" wurden. Bei MSF60 war das etwas anders: Es wurde der Fastcode abgestellt, d.h. zu Beginn der Minute 0 wurde früher die gesamte Info MM:DD:YYYY etc. in ein FSK-Telegramm (200 Bd?) gesteckt. Es wird seit einiger Zeit nur noch im Slow-Code", vergleichbar mit dem vom DCF77 gesendet. Also hat sich der FSK-Code hier als weniger praktikabel erwiesen. Unterschiede gibt es aber darüber hinaus in der Zuordnung einmal des BCD-Codes aber auch Bits, die zur Synchronisation des Minutenbeginns dienen sollen. Beim DCF77 ist das einzige Kriterium zur Erkennung des Minutenbeginns die ausgelassene 59. Minute. Dass das schon Schwierigkeiten bereiten kann, und damit der Start der Decodierung ab Bit 20 wurde ja oben schon angedeutet: Bauform B. schrieb: > ...ich finde > Fehlererkennung viel wichtiger als Fehlerkorrektur. Eigentlich brauche > ich nur den Anfang der Sekundenmarken, Datum und Zeit habe ich ja. > Selbst nach längerer Zeit ohne Empfang oder Strom kann man den maximalen > Fehler abschätzen und braucht entsprechend weniger gute Bits. Bei MSF 60 hat die Minute "Null" sage und schreibe 500 ms Austastung. Aber auch eine festgemauerte Anzahl von Nullen und Einsen soll dazu dienen, den Minutenanfang und damit die Synchronisation der Decodierung besser zu erkennen. 52 53 54 55 56 57 58 59 0 1 1 1 1 1 1 0 Auch werden die Parity-Bits alle aufs "Ende" verschoben, nicht mittendrin gesendet. Dass irgendetwas an der Encodierung von DCF77 geändert werden würde, ist reine Spekulation und auch nicht praktikabel wegen der dann folgenden Unbrauchbarkeit üblicher auf dem Markt befindlicher keineswegs updatefähiger "Funk-"Uhren. Trotzdem darf man wohl einmal darüber nachdenken, was theoretisch möglich wäre Nur wie oben bei der Betrachtung in http://www.gjlay.de/software/dcf77/konzept.html ausgeführt: Welche Encodierung hätte welche Verbesserung zur Folge? Klar ist, dass das Erwartungsschema eindeutiger nicht sein kann. Zur Plausibilitätskontrolle wird üblicherweise nach dem Prinzip der zunehmenden Skalenwerte bei Minuten vorgegangen. Welche noch intelligentere mathematisch-statistische Methode könnte hier angewendet werden? An vorgeschlagener Prozessorleistung sollte das nicht scheitern. Εrnst B. schrieb: > Grob Überschlagen müsste so ein STM32F411 Blackpill-Board locker reichen > um die 77kHz PSK Demodulation komplett als SDR in Software zu machen. > ADC wäre auch schnell genug, und wenn das Abtasten mit exakt 310kHz > geht, wäre das Baseband-Mixing so gut wie kein Rechenzeitaufand. > > Mit der CMSIS-DSP - Bibliothek gibt's einige der nötigen Funktionen auch > schon für STM32 voroptimiert. ciao gustav
Karl B. schrieb: > Welche noch intelligentere mathematisch-statistische Methode könnte hier > angewendet werden? (Für AM) Schon eine Ebene tiefer beginnen: Abtastung mit z.B. 100Hz und dann Korrelationsanalyse gegen einen synthetischen DCF-Signalframe, vorbelegt mit allen konstanten Bits und der Minutenlücke, die variablen Bits hingegen werden darin alle nur durch 0-Bits dargestellt. Aus den Ergebnissen dieser Analyse kann man viele Informationen entnehmen, insbesondere aus dem Verlauf der Ergebniswerte in der Nähe des "Einrastpunktes". Mit Hilfe dieser Informationen kann man dann auch ein relativ stark gestörtes Signal noch recht gut rekonstruieren. Selbst wenn es dann doch nicht für einen vollständig korrekten Inhalt reicht, reicht es doch mit recht hoher Wahrscheinlichkeit wenigstens für einen Sekundentakt und eine recht zuverlässige Erkennung von Sekunde 0. Wenn man eine eigene Zeitbasis hat, kann man kann das natürlich noch richtig schick machen: statt des synthetischen Frames als Vergleichwert nimmt man einfach ein vorberechnetes Frame mit dem aktuell erwarteten Inhalt (und das der beiden Nachbarminuten) und prüft dagegen. > An vorgeschlagener Prozessorleistung sollte das nicht > scheitern. Wenn man's richtig macht, braucht das nicht mal sehr viel Prozessorleistung. Allerdings leider relativ viel Speicher.
Das ist soweit ich das verstehe genau das, was Udo Klein in der Blinenlights-Library macht.
Meine erste MC51 basierte DCF Uhr hat so gearbeitet, dass sie kurz vor zu erwartenden Events auf die Events gewartet hat. Es gab einen Zähler, der wurde durch die Sekundenmarke zurückgesetzt, aber nur, wenn die Marke plausibel war. Der musste natürlich am Anfang ein paar Runden drehen, um die zyklischen Pulse von den Störungen zu trennen, aber dann war er eingerastet und hat immer nur kurz vor der Sekundenmarke bis kurz danach auf eine Flanke gewartet. Zuerst wurde dann nach ca 120ms 8x in wenigen ms Abstand der Pegel eingelesen und wenn das Byte mehrheitlich 0 war, war es eine 0, sonst eine 1. Später hatte ich das auch noch mal für den high Pegel der ersten 100ms nachgezogen, um besser Fehler im Empfang feststellen zu können. So konnte dann nicht nur durch den reinen Überlauf des Sekunden-Zählers die Sekunde der Minutenwechsel erkannt werden, sondern, im Fall eines Falles, konnte auch das Einrasten der Sekunden-Schleife neu gestartet werden. Da die Sekunden-Schleife nachgeführt wurde, also die erkannte Flanke den Zähler korrigierte, konnte man die Sekunden unabhängig und pünktlich weiterschalten, auch dann, wenn in der 59ten kein Puls kam. So gab es diese kleine Verzögerung nicht, weil man einen Teil der 59ten gewartet hat, bis klar war, dass keine Flanke kommen würde. Das war mal meine selbst gebaute DCF77 auf Basis MCS51. Ist aber sehr lange her und ich hatte von Filtern und Mathe kaum Ahnung. Ich frage mich gerade, wo das Ding eigentlich abgeblieben ist, oder ob es "In der Zeit verloren gegangen ist".
Ulrich schrieb: > Es gab einen Zähler, > der wurde durch die Sekundenmarke zurückgesetzt, aber nur, wenn die > Marke plausibel war. Der musste natürlich am Anfang ein paar Runden > drehen, um die zyklischen Pulse von den Störungen zu trennen, aber dann > war er eingerastet und hat immer nur kurz vor der Sekundenmarke bis kurz > danach auf eine Flanke gewartet. So muss das sein, einfach und gut — wenn es erstmal eingerastet ist; nur, wie schafft man das mit starken Störungen?
Ulrich schrieb: > Zuerst wurde dann nach ca 120ms 8x in wenigen ms Abstand der Pegel > eingelesen und wenn das Byte mehrheitlich 0 war, war es eine 0, sonst > eine 1. Später hatte ich das auch noch mal für den high Pegel der ersten > 100ms nachgezogen, um besser Fehler im Empfang feststellen zu können. Wenn man keinen Speicher, dann kann man das so machen. Ansonsten mit einem Histogramm. Das Signal kann dann nicht so kaputt sein, dass die Sekundenmarke (genauer die Phase der Marke) nicht mehr sicher erkannt werden kann.
900ss schrieb: > Bauform B. schrieb: >> wie schafft man das mit starken Störungen? > > Blinkenlight ;) Du hast die Aufgabenstellung immer noch nicht verstanden? Es ging nicht darum eine DCF77 decoder zu kopieren, klauen, kaufen sondern ihn für sich selbst zu entwickeln. Also Verständnis mit den Zeilen an Code wachsen zu lassen. Ich hätte für die SDR Idee auch "Biquadfilter" schreiben können und den TO damit dumm stehen lassen können. Bauform B. schrieb: > So muss das sein, einfach und gut — wenn es erstmal eingerastet ist; > nur, wie schafft man das mit starken Störungen? Dafür müssen wir zuerst wissen, was für eine Empfängerplatine Du da hast. Schon mit einem integrierten DCF AM Decoder oder rein mit einem FET und etwas Filter? Wenn der AM Decoder da schon drauf ist, brauchen wir keinen ADC mehr. In dem Fall ist das Board auch falsch angeschlossen, es braucht einen Pull-Up, denn die AM Decoder ICs haben einen open Collector Output. Die internen STM32 PullUp sind aber nur dann zu gebrauchen, wenn Du kurze Signalwege hast. Bei einem längeren Kabel zwischen Empfänger und Decoder braucht es einen echten Widerstand mit ein paar wenigen kR und dann das lange Kabel. Wenn das Kabel noch länger wird, braucht es einen echten Treiber. Hast Du wirklich ein rein analoges Frontend, also Antenne mit vielleicht einem FET zur Verstärkung und Entkopplung des Schwingkreises, dann sollte da noch mal ein Filter und ein weiteres FET hin, dass möglichst nur 77.5 kHz verstärkt werden. Mit 12 Bit ist der Dynamikbereich halt wirklich eng für Signale kurz über dem Rauschen.
Ulrich schrieb: > Bauform B. schrieb: >> So muss das sein, einfach und gut — wenn es erstmal eingerastet ist; >> nur, wie schafft man das mit starken Störungen? > > Dafür müssen wir zuerst wissen, was für eine Empfängerplatine Du da > hast. Schon mit einem integrierten DCF AM Decoder oder rein mit einem > FET und etwas Filter? Falls die Platine mal fertig wird, habe ich beide Möglichkeiten und vielleicht auch gleichzeitig. Aber es wird wohl beim 5€ Modul bleiben, weil: > Mit 12 Bit ist der Dynamikbereich halt > wirklich eng für Signale kurz über dem Rauschen. Zum Vergleich: der AM Chip MAS6180C funktioniert laut Datenblatt von 1 µVrms bis 20 mVrms. Man müsste mindestens ein "Standort-Poti" für die Verstärkung spendieren. Und das hilft nicht gegen den Unterschied zwischen Tag und Nacht. Es hilft auch nichts, wenn das Nutzsignal verschwindet, weil der Verstärker übersteuert. Mit guter AGC würden die Störungen auf 3 Vss verstärkt und man hätte 12 Bit um die 77.5 kHz da raus zu fischen. Wenn das tatsächlich funktionieren würde, könnte man wahlweise AM oder PSK demodulieren -- theoretisch. Daniel V. schrieb: > Histogramm. Das Signal kann dann nicht so kaputt sein, dass die > Sekundenmarke (genauer die Phase der Marke) nicht mehr sicher erkannt > werden kann. Das hatte ich mal probiert. Mit einem guten alten Conrad-Modul konnte ich durch Drehen der Antenne das Signal von perfekt bis totalgestört einstellen. Im Histogramm auf dem PC-Bildschirm sieht man nach ein paar Minuten die Sekundenmarke problemlos. Mangels stabiler Referenzfrequenz wandert die natürlich, und an der Stelle hatte ich aufgegeben. Mit besserer Hardware scheint das sehr aussichtsreich. Man bekommt auch gratis die Empfangsqualität. Ulrich schrieb: > Es ging nicht darum eine DCF77 decoder zu kopieren, klauen, > kaufen sondern ihn für sich selbst zu entwickeln. Danke!
Beitrag #8054969 wurde vom Autor gelöscht.
Bauform B. schrieb: > Mangels stabiler Referenzfrequenz > wandert die natürlich... Korrekt - hatte ich vergessen. Beispielsweise wandert die Phase bei einer Quartzabweichung von 100 ppm bereits nach 1000 Sekunden um 100 ms. Wenn man allerdings jeden Histogrammwert mit einem Hochpass von Tau=100s abklingen lässt, dann kann man das Histogramm dauerhaft verwenden. Außerdem ist es nicht optimal direkt das Minimum im Histogramm zu verwenden. Besser ist die Summenwerte über 100ms zu bilden ("Faltung") und dann das Minimum der Summenwerte zu suchen. Auf dem ersten Blick ist eine Abklingzeit von nur 100s unbefriedigend. Die erreichte Genauigkeit ist trozdem praktisch perfekt. Auch mit dem exakten Phasenwert würde man den Bitwert einer Sekunde kaum sicherer bestimmen können. Mit analogen Amplitudenwerten habe viel Erfahrung. Alle normalen Empfänger haben allerdings "High-/Low-Empfangsdaten". Ob das damit ähnlich gut funktioniert?
:
Bearbeitet durch User
Bauform B. schrieb: > theoretisch funzt die Datenübertragung auf ganz anderen Frequenzen auch ganz gut. -schön' Freidach.
Daniel V. schrieb: > Außerdem ist es nicht optimal direkt das Minimum im Histogramm zu > verwenden. Besser ist die Summenwerte über 100ms zu bilden ("Faltung") > und dann das Minimum der Summenwerte zu suchen. Ich verstehe schon wieder Bahnhof, oder sollte das Maximum heißen? > Auf dem ersten Blick ist eine Abklingzeit von nur 100s unbefriedigend. > Die erreichte Genauigkeit ist trozdem praktisch perfekt. Auch mit dem > exakten Phasenwert würde man den Bitwert einer Sekunde kaum sicherer > bestimmen können. OK, aber mit dem exakten Phasenwert könnte man dem GPS-PPS Konkurrenz machen ;) > Mit analogen Amplitudenwerten habe viel Erfahrung. Alle normalen > Empfänger haben allerdings "High-/Low-Empfangsdaten". Ob das damit > ähnlich gut funktioniert? Ich glaube, daran scheitert es nicht. Ich habe mal "ein paar" Screenshots vom Histogramm auf dem PC gemacht: https://bauformb.uber.space/
Bauform B. schrieb: > Ich verstehe schon wieder Bahnhof, oder sollte das Maximum heißen? Dort wo die Senderamplitude minimal ist. Wenn das Empfangsmodul zu diesen Zeiten ein High liefert, dann hast du recht. Hmm, nach den Histogrammen auf deiner Seite ist das aber nicht der Fall. Jetzt verstehe ich Bahnhof. Bauform B. schrieb: > OK, aber mit dem exakten Phasenwert könnte man dem GPS-PPS Konkurrenz > machen ;) Auf 0.1 µs (entspricht 30 Meter) kann man die 77kHz-Phase bereits nach wenigen Sekunden synchron halten. Der zeitlich schwankende Anteil der Raumwelle kann die Phase allerdings um viele Mikrosekunden verziehen. Die Zeit- und Ortsabweichung ist also viel höher. Mit fertigen DCF77-Modulen geht das natürlich nicht. Dort sollte man bei gutem Signal trotzdem deutlich unter 1ms kommen können. Mit etwas Software kann man die Quartzabweichung bestimmen und rausrechnen, wodurch man ein Vielfaches von 100s wählen könnte. Wieviel hängt hauptsächlich von der Stabilität des Oszillators (z.B. durch schwankende Temperaturen) ab. Bauform B. schrieb: > Ich glaube, daran scheitert es nicht. Ich habe mal "ein paar" > Screenshots vom Histogramm auf dem PC gemacht: > https://bauformb.uber.space/ In meiner Erinnerung sahen meine Histogramme (vom Analogempfängerausgang) viel besser aus. Deine Grafik ist zwar grob, aber daran wird es nicht liegen. Leider habe ich nur eine normale DCF77-Uhr die man nur schwierig zerstörungsfrei öffnen kann. Wenn ich am Wochenende Zeit (und Lust) finde, dann werde mal ein paar Stunden Daten sampeln...
Mein selbstgebauter DCF-Empfänger (mit EEblocks und also mit Picee board) wurde im Dezember 2007 in Elektor veröffentlicht; er funktioniert noch immer einwandfrei und wurde 2009 um eine DCF-Funktion für Stationsuhren erweitert. Die Schaltung wurde auch im Elektor-Buch „311 Circuits“ abgedruckt. Im Jahr 2025 behob ich einige Fehler in der Firmware, die ein anderer Programmierer in meinem korrekten Quellcode hinterlassen hatte. Meine version arbeitet inklusive eines ewigen Kalenders, Schaltjahren und Schaltsekunden. Die aktualisierte Firmware-Version stellte ich den Herausgebern von Elektor im Juli 2025 zur Verfügung. https://www.elektormagazine.nl/magazine/elektor-200907/15859
:
Bearbeitet durch User
PIC-Assemblercode, der aus einem Compiler rausgepurzelt ist. Ohne Kommentare, ohne aussagekräftige Label! Wer will sich heute im Zeitalter von Hochsprachen durch so einen Spaghetti-Code quälen?
Angehängte Dateien:
-
RV-3032-TCXO.png
55 KB
Daniel V. schrieb: > Bauform B. schrieb: >> Ich verstehe schon wieder Bahnhof, oder sollte das Maximum heißen? > Dort wo die Senderamplitude minimal ist. Wenn das Empfangsmodul zu > diesen Zeiten ein High liefert, dann hast du recht. Der "Conrad" liefert Low, aber mein Histogramm zählt, wie oft zu dem bestimmten Zeitpunkt eine Flanke gefunden wurde. Dass es nach unten wächst, ist nur meine Bequemlichkeit mit der ASCII-Grafik. So macht man maximale Verwirrung ;) Jetzt habe ich mal versucht, aus dem Digitalsignal sowas wie dein Analog-Histogramm zu machen. Ganz simpel mit plus oder minus 1, je nach High oder Low. Davon gibt's neue Bilder mit etwas zu schlechtem Empfang, der zum Schluss gut wird. > Bauform B. schrieb: >> OK, aber mit dem exakten Phasenwert könnte man dem GPS-PPS Konkurrenz >> machen ;) > Mit fertigen DCF77-Modulen geht das natürlich nicht. Dort sollte man > bei gutem Signal trotzdem deutlich unter 1ms kommen können. Vergleichen mit GPS über USB und NTP über DSL reicht das leicht ;)
1 | $ ntpq -pn |
2 | remote refid st t when poll reach delay offset jitter |
3 | =============================================================================== |
4 | +51.75.67.47 242.233.146.16 3 u 31 256 377 13.4627 -0.2261 3.0859 |
5 | *NMEA(0) .GPS. 1 l 6 16 377 0.0000 1.2928 1.7068 |
> Mit etwas Software kann man die Quartzabweichung bestimmen und > rausrechnen, wodurch man ein Vielfaches von 100s wählen könnte. > Wieviel hängt hauptsächlich von der Stabilität des Oszillators > (z.B. durch schwankende Temperaturen) ab. Weil ich nur billige Bauteile von Reichelt oder Digikey mag, ist für den 10 MHz CPU-Takt der KT2016 für 1.39€ geplant. Der und der DAC zum Trimmen bekommen 3.3 V aus einer eigenen Referenz. Kyocera verspricht, dass der besser ist als die RTC RV-3032-C7 für 3.20€ von Micro Crystal. Was kann man von den beiden erwarten? Wenigstens wird so eine Uhr nicht im Freien betrieben. > Leider habe ich nur eine normale DCF77-Uhr die man nur schwierig > zerstörungsfrei öffnen kann. Mach' bitte nichts kaputt!
Angehängte Dateien:
Der TO hat im Titel des Threads das englische Wort "scratch" verwendet. Das führte zumindest bei mir und anderen Postern zu massiven Missverständnissen. Also: Auf gut Deutsch: Titel sollte wohl besser lauten: "DCF Decodierung nach völlig anderem Prinzip." Alle anderen Ideen interessieren den TO nicht die Bohne. Aber ich nehme mir jetzt die Unverschämtheit heraus, trotzdem meine Idee vorzustellen: Gerade gestern Abend waren die Gewitter-Störungen extrem. So dass die Funkuhren (60 kHz / 77,5 kHz) nicht mehr synchronisieren konnten. Trotzdem konnte ich mit dem akustischen Direktempfänger die Träger-Signale neben Krachern mehr oder weniger deutlich als Pfeifton vernehmen. Das führte mich zu folgender Überlegung: Trennung des Empfanges nach reinem Empfang des Telegramminhalts (Uhrzeit-Datum etc.), was nicht unbedingt tausendstelsekundengenau sein muss. Und, zweitens, möglichst exakte Erkennung der Sekundenflanke (für Referenzzwecke) in einem separaten, simultan mitlaufenden Programm. Für ersteres hatte ich damals schon mit DSP-Filter für Verbesserung des MSF60-Superhet-BFO-Empfanges herumexperimentiert. Tatsächlich scheint die Erkennung von einer Sinuswelle besser als lediglich Erkennung einer fallenden DC-Flanke. Die Software kann zusätzlich noch kreuzkorrelieren und Fehler "herausrechnen." Ein Delay der Uhrzeitanzeige müsste dann im Toleranzbereich zu liegen kommen. Der TO hat sich, soweit ich das hier verfolgen konnte, auf die möglichst exakte Flankenerkennung kapriziert. Diese Baustelle überlasse ich ihm gerne. Aber vielleicht findet er die Idee mit der "Sinustonerkennung" auch ein wenig überlegenswert. ciao gustav P.S.: GPS war gestern abend auch ungenauer als sonst (Bewölkung).
:
Bearbeitet durch User
Karl B. schrieb: > Titel sollte wohl besser lauten: > "DCF Decodierung nach völlig anderem Prinzip." Vielleicht, es wird sich hinterher zeigen, wie verschieden das Prinzip dann geworden ist. Hier im Forum liest man überwiegend "kopiert von..." oder "billig gekauft". Mit "from scratch" meine ich, dass ich nichts kopieren will und keine "lib" benutzen will. > Alle anderen Ideen interessieren den TO nicht die Bohne. Ja, per Definition soll das so sein. Andererseits bin ich viel zu neugierig und lese viel zu viel, was andere machen. Ich hab sogar versucht, das Programm von villamvadasz-DCF77_CH341_decoder zum Laufen zu bringen, aber das ist zu arduinisch für mich. > Trennung des Empfanges nach reinem Empfang des Telegramminhalts > (Uhrzeit-Datum etc.), was nicht unbedingt tausendstelsekundengenau sein > muss. > Und, zweitens, möglichst exakte Erkennung der Sekundenflanke (für > Referenzzwecke) in einem separaten, simultan mitlaufenden Programm. > Der TO hat sich, soweit ich das hier verfolgen konnte, auf die möglichst > exakte Flankenerkennung kapriziert. Im Programm passiert das als erster Schritt. Erst, wenn der fertig ist, beginnt die Dekodierung. Weil man dann schon die Flanke genau kennt, wird es viel einfacher, die Datenbits zu finden. > Aber vielleicht findet er die Idee mit der "Sinustonerkennung" auch ein > wenig überlegenswert. Ist sie natürlich, aber dafür brauche ich Hardware, die nicht beim ersten Versuch läuft. Das mag ich garnicht, besonders, wenn das vorher schon klar ist. > P.S.: GPS war gestern abend auch ungenauer als sonst (Bewölkung). Ja, man braucht beides bevor man pool.ntp.org trauen kann ;)
Angehängte Dateien:
-
1__Histogramm_schlecht.png
3,3 KB -
2__Ausschnitt_schlecht.png
1,7 KB -
3__Histogramm_gut.png
2,2 KB
Ich habe bei meiner Wetterstation das Ausgangssignal vom DCF77-Modul abgegriffen. Das Signal habe ich direkt verwendet, d.h. ich habe kein Tiefpass oder Hochpass angewendet. Die Quartzabweichung ist allerdings heraus gerechnet. Daraus habe ich ein Histogramm über eine Sekunde gebildet - siehe Anhang. Es zeigt sich, dass das Low-High-Signal verglichen mit einem Analogsignal doch sehr wenig Information liefert. Selbst nach einer halben Stunde Messzeit liegt man bei der Genauigkeit der Sekundenmarke nur in der Größenordnung von 10ms.
Daniel V. schrieb: > Selbst nach einer > halben Stunde Messzeit liegt man bei der Genauigkeit der Sekundenmarke > nur in der Größenordnung von 10ms. Das ist der AGC des Empfänger-ICs geschuldet, ebenso, dass die Impulslängen 100/200ms deutlich abweichen und erkennbar jittern. Für die manuell abzulesende Uhr ist das gut genug, für Meßtechnik eher nicht. Baue einen Empfänger diskret auf, mache die Amplitudenregelung sehr langsam (Minuten) und decodiere mit einem Schmitt-Trigger mit fester Schwelle. Damit sieht das Signal deutlich besser aus und hat kaum Jitter. Bei den verbreiteten Modulen mit ICs von Micro Analog Systems könntest Du probieren, die Kondensatoren an AGC und DEC zu verändern.
Manfred P. schrieb: > Baue einen Empfänger diskret auf Dann kann er auch gleich das PSK-Signal dekodieren... Wikipedia meint: Mit selbstgebastelten, optimierten AM-Empfänger geht's auf 1ms, mit Kreuzkorrelation der Phaseninfos auf 0,0065ms bis 0,025ms genau. https://de.wikipedia.org/wiki/DCF77#Zeitliche_Aufl%C3%B6sung
> Wikipedia meint: Mit selbstgebastelten, optimierten AM-Empfänger geht's > auf 1ms, mit Kreuzkorrelation der Phaseninfos auf 0,0065ms bis 0,025ms > genau. > > https://de.wikipedia.org/wiki/DCF77#Zeitliche_Aufl%C3%B6sung Die Begründung zur Genauigkeit von Haushaltsgeräten in der WP klingt nicht stichhaltig. Auch werden unterschiedliche Laufzeiten durch unterschiedliche Ausbreitungsbedingungen nicht berücksichtigt. OK, signallaufstrecke ist bei DFN77 nicht so lang wie bei GPS mit 20 Mm, dazu muss man dabei auch das Verhalten der Ionossphäre mit berücksichtigen https://de.wikipedia.org/wiki/European_Geostationary_Navigation_Overlay_Service#Hintergrund * https://apps.dtic.mil/sti/tr/pdf/ADA171147.pdf (Kap. 3)
Bradward B. schrieb: > Auch werden unterschiedliche Laufzeiten durch unterschiedliche > Ausbreitungsbedingungen nicht berücksichtigt. Die Quellen (Direkt vom PTB) sind im Artikel verlinkt. 2004_Piester_-_PTB-Mitteilungen_114.pdf Bradward B. schrieb: > Die Begründung zur Genauigkeit von Haushaltsgeräten in der WP klingt > nicht stichhaltig. ja, die 100ms kamen mir auch hoch vor, vermutlich Offset, nicht Jitter. 25 bis 50ms Offset sind Plausibel für ein 10Hz-Bandpass, noch ganz auf der Analogen Seite.
Manfred P. schrieb: > Das ist der AGC des Empfänger-ICs geschuldet, ebenso, dass die > Impulslängen 100/200ms deutlich abweichen und erkennbar jittern. Das suggeriert, dass AGC einen wesentlichen Anteil hat, was nicht Fall ist. Ursache ist die Quartzgüte (<50Hz Bandbreite), wodurch die Anstiegszeit (>20ms) hoch ist. Ohne Rauschen ist diese durch die Digitalisierung verborgen. Ein AGC braucht die Schwelle nicht zu ändern, bei konstanter Schwelle hat Rauschen den gleichen Effekt. Eine Rampe (durch Güte, Hochpass, Tiefpass, ...) zusammen mit Rauschen erzeugt auch bei konstanter Schwelle Jitter. Manfred P. schrieb: > Baue einen Empfänger diskret auf, mache die Amplitudenregelung sehr > langsam (Minuten) und decodiere mit einem Schmitt-Trigger mit fester > Schwelle. Damit sieht das Signal deutlich besser aus und hat kaum > Jitter. Waren Güte und Rauschen gleich? Sicher nicht. Die Aussage beweist leider nichts. Fertige Standardmodule als Basis für "DCF-Uhr from Scratch" zu verwenden ist wirklich nicht sinnvoll. Ein digitaler Ausgang liefert zu wenig Information. Man braucht unnötig viel Zeit um die Streuung klein zu bekommen. Das größere Problem ist, dass der Resonator unbekannt ist. Ohne den Wert kann man die Zeitverschiebung (sehr viele Millisekunden) nicht korrigieren. Der Wert ließe sich durch Messung bestimmen, es bleibt aber das Hauptproblem: Die Zeitverschiebung hängt von der Digitalisierungsschwelle ab. Nur die Breite der Impulse liefert darüber eine Information, welche aber erst gewonnen werden muss. Εrnst B. schrieb: > ja, die 100ms kamen mir auch hoch vor, vermutlich Offset, nicht Jitter. Es ist wohl der Offset der durch den Resonator enststeht und zu sehr aufgerundet wurde.
:
Bearbeitet durch User
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.