Hallo an alle,
hiermit möchte ich meine Erfahrungen in Thematik DFC77-Auswertung
teilen. Mein längerfristiges Ziel ist eine Nixi-Funkuhr zu bauen,
deswegen war ich in letzter Zeit mit Auswertung vom DCF77-Signal
beschäftigt. Bei Recherche habe ich verschiedene Methoden gefunden:
integrieren, falten, Auswertung über analogen Eingang, Signal
Breitenmessung, usw. Schließlich habe ich als Grundlage die Beschreibung
von Autor: Volker (Gast), Datum: 27.06.2011 15:43,
Beitrag "DCF77-Modul von Pollin" genommen. Ende Oktober habe
ich ein Modul bei Pollin gekauft, als Plattform nahm ich AVR µC. Mein
Vorgehen: Nach einer positiven Flanke an INT0 nehme ich 20 Samples in
10ms Abständen. Dann nehme ich Samples 1 bis 9 und 12 bis 20, zähle die
„1“-er und bilde ein Byte, das bei gutem Empfang idealerweise den Wert
90 für „0“ und 99 für „1“ hat. Dabei sah ich, dass bei einem
auswertbarem Signal dieses Byte nur begrenzte Anzahl an Werten liefert:
60, 70, 80, 90, 91-99. Als nächstes habe ich direkt die Samples
visualisiert und festgestellt, dass beim (noch) guten Empfang es keinen
(99), oder einen Übergang (<99) von 1 auf 0 gibt. Solange das Signal
nicht fragmentiert ist, sieht ein „70“ so aus: 11111110000000000000, ein
„92“ kommt von Samples 11111111111110000000. Ist klar, die fallende
Flanke vom Signal variiert, bei 100ms mehr, bei 200ms weniger, und das
ist wiederum vom Empfangsqualität des DCF77 Signals abhängig. 60 – 95
werte ich als „0“ aus, ab 96 werte ich als „1“ aus, wobei 60 und 95
schon sehr grenz-wertig sind, die Störungen sind dann stärker, nächste
Phase die LED blinkt nur mehr wild herum oder gar nicht mehr, das
Signal wird fragmentiert, das nächste oder übernächste Bit fällt
komplett aus, die Software dadurch einen (falschen) BIT-0 Bedingung
registriert und fängt von vorne an, und in diesem Fall kann man nichts
vernünftiges mehr bekommen. Bei diesem Herumexperimentieren habe ich
auch gesehen, dass solange das Signal nicht defragmentiert ist, man kann
selbst bei zeitlich stark variierender fallender Flanke eine Stelle im
Signal finden die eine gute Aussage über den empfangenen Bit liefert,
und das ist der 17. Sample, oder 170ms nach dem Signal Anfang. Anders
gesagt, der Sample 17 liefert direkt das empfangene Bit. Meine letzte
Softwareversion wertet nur Sample 17 aus mit ganz brauchbarem Ergebnis.
Ich weiß nicht, vielleicht habe ich das Rad nur neu erfunden, aber würde
mich an dieser Stelle interessieren ob diese Methode auch für andere
Module anwendbar ist, oder es nur mit dem Pollin Modul funktioniert?
Noch zur Info: ich lebe in Wien, mein ~3.5m² Hobby Werkstatt ist am 2.
Stock eines Altbau und dort kann ich genau eine Stelle finden wo ~90%
der Zeit ein guter (auswertbarer) Empfang vorhanden ist.
Hallo Peter,
den Beitrag habe ich auch gefunden und es funktioniert zweifellos. Gegen
Störempfindlichkeit mache ich folgendes: Ich verbiete die externen
Interrupts in der Behandlungsroutine selbst, und gebe ich wieder frei im
Timer Interrupt in definierten Zeitfenstern. Aber jetzt unabhängig davon
möchte wissen ob alle andere Module so auswertbar sind bei 170ms wo es
(höchstwahrscheinlich) keine Überlappung von gesendeten Bits existieren
kann? Weil dann würde es die Auswertbarkeit ziemlich vereinfachen.
Peter D. schrieb:> Meine Erfahrung ist, daß ein externer Interrupt zu störempfindlich ist.> Ich polle daher im Timerinterrupt:
Sehe ich auch so :Beitrag "[Bascom/AVR] Uhr und DCF"
In meinem Progamm werden nur die Pausen in 20msec-Schritten ausgezählt,
also 800msec=1, 900msec=0 und über 1,x sec=59. und fehlende sec.
Auswertung des Zählerstands:
Zuerst wird auf eine fehlende 59.sec geprüft. Wenn ja auswerten, wenn
nein überprüfen ob eine 1 oder 0 empfangen wurde. Es genügen dadurch 2
Schwellwerte zur Dekodierung des DCF-Signals.
Ozvald K schrieb:> Meine letzte> Softwareversion wertet nur Sample 17 aus mit ganz brauchbarem Ergebnis.
Nach meinen Messungen an einem Pollin- und einem Conrad-DCF-Empfänger
verlängern diese (an meinem Empfangsort nahe Frankfurt) die Samples um
ca. 20msec. Legt die Vermutung nahe, dass das 17. Sample die bessere
Mitte zwischen einer 0 und einer 1 ist.
Ob man nun auszählt oder die Mitte zwischen 0- und 1-Samples abtastet
ist meiner Meinung nach egal, bzw. liefert gleich gute Ergebnisse. Bei
Impulsbreiten modulierten Bitfolgen ist dieses Verfahren gebräuchlich.
Die Besonderheit des DCF-Signals ist die sehr langsame Übertragung.
Ansonsten wäre ein Ausmessen der Bit-Breite mit einem im Softwarezähler
gar nicht möglich, d.h. das Zählverfahren gerät bei höheren
Übertragungsgeschwindigkeiten schnell an seine Grenzen.
Ozvald K schrieb:> Vorgehen: Nach einer positiven Flanke an INT0 nehme ich 20 Samples in> 10ms Abständen.
Vorab, für diesen Lösungsansatz wären 25 Samples wahrscheinlich besser
geeignet um die Impulsverlängerungen durch den DCF-Empfängers abzufangen
Der Interrupt könnte aber auch durch einen Störimpuls verursacht worden
sein. Eine Möglichkeit wäre zuerst zu prüfen, ob es sich um eine Störung
handelt. Dazu zuerst prüfen, ob zum Beispiel in den ersten 5 Samples
eine Pegeländerung am Eingang auftritt. Wenn ja, beim ersten erkennen
sofort das IRQ-Programm verlassen.
Der Vorteil des Abtastens per Timerinterrupt ist auch noch der sehr
geringe Zeitbedarf der DCF-Empfangsroutine.
Hi,
das Programm ist auch praktikabel.
https://s-huehn.de/elektronik/wohnuhr/wohnuhr.htm
Das hierbei verwendete "Polling" bringt zwar mehr Unsicherheit bezüglich
Genauigkeit, ein Programm mit den INTO etc.- Interrupts ist dagegen
ziemlich störanfällig, wie @Peda oben schon richtig bemerkte.
Habe ich selbst ausprobiert und bin zum ersten Programm zurückgekehrt.
Mit der Genauigkeit der fallenden Flanke, ob die nun 10 Millisekunden
früher oder später kommt, ist für mich ohne Belang.
Abgesehen davon käme man, wenn man alle gesendeten Features vom DCF77-
Signal auswerten wollte, nicht herum, die "Kreuzrelation" mit
einzubeziehen. Also das komische Rauschen in den Pausen ist so eine
Bitfolge. Dient in erster Linie dazu, die fallende Flanke - laienhaft
ausgedrückt - noch "genauer" zu machen.
ciao
gustav
Alex D. schrieb:> für diesen Lösungsansatz wären 25 Samples wahrscheinlich besser> geeignet um die Impulsverlängerungen durch den DCF-Empfängers abzufangen
Das habe ich mir auch schon überlegt, nur fange ich mit der Information
Impulsverlängerung später nichts an. Es sei denn aus
"qualitätsrelevanten" Gründen, falls man die Samples analysiert bis
250ms um sicher zu stellen, dass nur ein Übergang von 1 auf 0 vorhanden
ist. Das würde auf ein stabiles Signal deuten. Wegen INT0
Störanfälligkeit: ja, es ist störanfälliger, gebe zu. Habe ein paar mal
gehabt, dass der Bitzähler ein immaginäres 59. Bit gezählt und damit
einen Überlauf verursacht hat. Das habe ich dazwischen gefixt. Ich
verwende den INT0 interrupt in Kombination mit Timer0. In der INT0
verbiete ich die weitere INT0 interrupts, synchronisiere den Timer0
Lauf, (RELOAD value -> TCNT0) und in der Timer Routine selbst erlaube
ich wieder den INT0 in einem definierten Zeitfenster. So wirke ich den
Störimpulsen entgegen. Wenn der INT0 wegen einer Störung ausgelöst
wurde, dann sind die Störungen ohne dies schon derartig massiv, dass man
kaum Vernünftiges mehr auswerten kann, und das Ergebnis wird
weggeworfen.
Kann aber auch folgendes machen: werde eine Lösung mit nur Polling
Verfahren parallel laufen lassen um einen direkten Vergleich zu
bekommen.
Karl B. schrieb:> Abgesehen davon käme man, wenn man alle gesendeten Features vom DCF77-> Signal auswerten wollte, nicht herum, die "Kreuzrelation" mit> einzubeziehen. Also das komische Rauschen in den Pausen ist so eine> Bitfolge. Dient in erster Linie dazu, die fallende Flanke - laienhaft> ausgedrückt - noch "genauer" zu machen.
Sorry Gustav, das verstehe ich nicht ganz, besonders das mit dem
komischen Rauschen.
Sonst auch ein nettes Projekt, man sieht, viele Wege führen nach Rom.
:-)
Übrigens,bei mir läuft das ganze mit einem TINY13. Nicht, weil ich ein
masochist bin, aber es hat sich so ergeben. In der Vergangenheit habe
ich ein 10+ Protopack Platine für irgendein TINY13 Projekt bestellt,
und habe noch ein paar Platinen übrig. Am Anfang wollte ich nur das
Signal dekodieren um Erfahrung zu sammeln, aber dann ist immer mehr
geworden. So ist eine minimalistische Funkuhr entstanden :-)
Eure Impulsdiagnose finde ich schon ganz gut, aber zu Verbesserung der
Zuverlässigkeit sollte man schon zusätzlich einige Werte auf
nacheinander vergleichen nach 17:52 darf nicht 17:51 kommen usw...
Meinem System haben falsche Zeiten wie 17:$A sehr geschadet.
Ozvald K schrieb:> Kann aber auch folgendes machen: werde eine Lösung mit nur Polling> Verfahren parallel laufen lassen um einen direkten Vergleich zu> bekommen.
Bitte schreibe mal deine Ergebnisse. Ich habe nur Versuche mit dem
CTC-Timerinterrupt unternommen. Ein Vergleich der Verfahren finde ich
spannend.
Nach vielen Versuchen habe ich folgende Empfangsroutine entwickelt und
verwendet. Eine Möglichkeit von vielen:
- Aufruf durch CTC-Timmer1 alle 20msec -
Dcf_auswerten:
- Der Pegel am DCf-Port-Pin wird in ein 3-Bit langes Schieberegister -
geschoben (D2,D1,D0).
'*** Port einlesen, DCF-Empfängerpegel einrollen
Shift Dcf_input , Right
Dcf_input.2 = Dcf_empfaenger
- Erst wenn 3 gleiche Pegel nacheinander anliegen wird ein
- Software-RS-Flip-Flop (Dcf_filter_out) entsprechend geschaltet.
'*** DCF-Signal filtern, Mindestbreite 60msec
If Dcf_input = &B0000_0111 Then Dcf_filter_out = 1
If Dcf_input = &B0000_0000 Then Dcf_filter_out = 0
- Schieberegister zur Flankenerkennung
'*** Gefiltertes DCF-Signal einrollen zur Flankenerkennung
Shift Dcf_gefiltert , Left
Dcf_gefiltert.0 = Dcf_filter_out
- Zeitdauer des Samples messen
'*** DCF-Impulsbreite ausmessen, wenn Pegel +Us anliegt
If Dcf_filter_out = 1 Then Incr Dcf_impulsdauer
'*** DCF-Signal demodulieren, Breite mindestens 7*20msec = 140msec
' ... Impulsbreite bewerten (Pause 59.sec/0/1 ),
' ... und Bit ins dcf_Empfangsregister einrollen
- Prüfen ob die Bit-Zeitdauer um ist.
'negative Flanke erkannt
If Dcf_gefiltert = &B1111_1110 Then Incr Dcf_bitzaehler
- Ins Empfangsregister schieben, DCF-D0 auf Schieberegister-D0
Die Dcf-Stunde, Minute usw. werden im nachfolgenden Programm zum
richtigen Zeitpunkt zur weiteren Verarbeitung aus dem Empfangsregister
kopiert.
Shift Dcf_empfangsregister , Right ' DCF-Bit 0/1 einrollen
If Dcf_impulsdauer < Dcf_bit_schwelle Then Set
Dcf_empfangsregister.7
- einige Programmzeilen weiter:
'*** Wenn alle Dcf-Daten eingesammelt sind und die 59. Sekunde
ausgeblieben
' ... ist, wird ausgewertet.
If Dcf_impulsdauer => Dcf_pause59 Then
If Dcf_bitzaehler = 59 Then
-usw.
Peter D. schrieb:> Beitrag "DCF77-Uhr mit ATTINY12"
Diesen Beitrag kannte ich nicht, es sind immerhin 16! Jahre seit der
Erstellung vergangen. Respekt :-)
Habe mich kurz hinein gelesen (INDEX.HTM)
und dabei viele Parallelen zu meinem Projekt gesehen, aber auch
Unterschiede.
@ Alex D: Nichts gegen Deine Lösung, aber werde ich höchstwahrscheinlich
das von Peter nehmen zu testen weil Hardware schon vorhanden, eine
Portierung auf tiny13 dürfte auch kein Problem sein.
Alex D. schrieb:> Ob man nun auszählt oder die Mitte zwischen 0- und 1-Samples abtastet> ist meiner Meinung nach egal, bzw. liefert gleich gute Ergebnisse.
Zu TTL-Zeiten hat man ein Monoflop mit etwa 150ms Laufzeit auf die
fallende Flanke getriggert und bei Ablauf geguckt, ob ein H oder L
anliegt. Ein entferntes Gewitter, und vorbei war's mit der Decodierung.
In dem Gebilde hatte ich etwa 50 TTL-Bausteine.
Mit einem µC kann man das Signal zyklisch abtasten (pollen) und zwei
Toleranzfenster für L und H bilden. Damit bringt nicht mehr jeder Blitz
oder pfurzende Lichtschalter den Decoder aus dem Tritt. Wenn man
synchron ist, bildet man ein Zeitfenster, in dem das Polling gesperrt
wird.
Klar, dass man eine mathematische Plausibilitätskontrolle drüber legen
sollte. Leider hab eich die Schaltsekunde ignoriert, da gerät meine 2
Minuten lang aus dem Tritt, das Sommerzeit-Ankündigungsbit werte ich
aus.
Die drei Paritybits im DCF-Signal taugen zu nichts, da keine
Doppelfehler auffallen.
Ich schreibe das aus der Erinnerung heraus, meine letzte DCF-Decodierung
habe ich 1992 auf einem 6502 in Assembler geschrieben. Inzwischen juckt
es in den Fingern, das wieder mal zu tun, auf einem Aurduino.
Mit den käuflichen Empfängern wird man niemals ganz genau, bei den
Superhet-Bausteinen habe ich ein gehöriges Jittern gesehen, welches mein
Geradeausempfänger nicht hat.
Manfred schrieb:> Mit einem µC kann man das Signal zyklisch abtasten (pollen) und zwei> Toleranzfenster für L und H bilden.
Genau, und jetzt sind wir wider bei meiner anfänglichen Analyse. Nehmen
wir an, es sind 20 Samples vorhanden, die so aussehen:
11111111111111100000 (15x1, 5x0) Ist das jetzt eine lang geratene 0 oder
ein kurz geratener 1 ? Samples wie diese z.B. 11100111101100100000 kommt
bei "normalen" Empfang gar nicht vor, und wenn es vorkommt, dann ist das
Signal schon so schlecht, dass das nächste Bit komplett ausfällt und
dadurch ein falscher Bit0 Zustand detektiert wird.
Ursprünglich habe ich Das Vorhanden von 1-er gezählt, aber es war
dadurch nicht besser, zumindest nicht mit solchen gekauften Modulen.
Ja, man kann beliebig viele Pegelabfragen über die Sekunde
machen, solange es dem µC nicht zuviel wird...
Von der Erfahrung her kann ich nur sagen:
Bei Empfang innerhalb Deutschlands ist das viel zu viel Aufwand.
Bei schlechten Empfangsbedingungen im Stahlbetonbau hilft
aber auch dein Ansatz nicht. VIELLEICHT (?) hilft ein Ansatz, der
aus Empfangsbruchstücken versucht, noch was mit Wahrscheinlichkeits-
rechnung zusammenzufügen. - WENN Bruchstücke ankommen...
Polling, oder external Interrupt ist komischerweise für manche
eine Glaubensfrage! - Lass dich nicht darauf ein!
Das übliche Polling funktioniert ganz gut.
Wenn man Modul-unabhängig programmieren will, könnte man zu
Beginn das Polling schon mal zum Herausfinden der Polarität
der sekündlichen Zeitsignale nutzen: Der seltenere Signalpegel
ist der Sekundentakt.
External Interrupt funktioniert auch gut, wenn man danach ein
Zeitfenster (z.B. +/- 50 ms) für den nächsten Interrupt setzt:
Entweder es passt ab dem ersten Takt, oder es "ruckelt sich ein",
wie bei RS232-Empfang.
Der Interrupt setzt einen Timer auf Null, der nach 150 ms dazu
auffordert den Pegel abzufragen. Derselbe Timer erlaubt erst nach
950 ms den nächsten external DCF-Interrupt.
Klappt bei mittelmäßigem Empfang hervorragend!
Danach ist die Auswertung der Telegramme wichtig. Parity und
Plausibilität: Ist das vorige Zeittelegramm + 1 Minute = dem neuen
Zeittelegramm?
Vorteil beim external Interrupt: Wenn man die mittlere Verzögerung
seines Empfängers kennt, kann man die Uhr mit einigen 10 ms
Vorlauf noch etwas exakter auf den "echten" Sekundenwechsel
synchronisieren.
Manfred schrieb:> 6502 in Assembler
Hat jetzt zwar nichts mit dem Thema zu tun, aber mit guten Erinnerungen:
Nostalgie ein - eine super CPU, damals ihrer Zeit weit voraus -
Nostalgie aus
Jacko schrieb:> Danach ist die Auswertung der Telegramme wichtig. Parity und> Plausibilität: Ist das vorige Zeittelegramm + 1 Minute = dem neuen> Zeittelegramm?
So ist es.
Meine Uhr läuft schon über 30 Jahre nach dieser Methode.
Geradeausempfänger + Schieberegister + sonstigen Kram + Quarzuhr.
Die Quarzuhr übernimmt den Wert der Funkuhr nur dann, wenn das
Funkzeittelegramm plausibel ist.
Jacko schrieb:> Das übliche Polling funktioniert ganz gut.
OK,
man kann eine erhöhte Störsicherheit dadurch erreichen, indem der
Eingangsport für die Zeit bis zum Eintreffen des nächsten Impulses
gesperrt wird.
Bin drauf gekommen, weil beim MSF60 "Doppelimpulse" pro Sekunde kommen.
Die müssen ausgeblendet werden. Das kann man beim DCF77-Programm als
zusätzliche Störaustastung ansehen.
Ein DCF77-Decoderprogramm wurde auf MSF60-Empfang umgemodelt.
Programm findet man hier:
Beitrag "MSF60 Dekoder AVR Teil_2"
Der relevante ASM Schnipsel ist angehängt.
Ozvald K schrieb:> Sorry Gustav, das verstehe ich nicht ganz, besonders das mit dem> komischen Rauschen.
Zitat:
"...Zusätzlich zur amplitudenmodulierten Zeitübertragung wird seit Juni
1983 diese Information über eine Phasenmodulation des Trägers mit einer
Pseudozufallsfolge (PZF) in einer Länge von 512 Bit übertragen. Mittels
Kreuzkorrelation kann mit dem auf Empfangsseite reproduzierten Signal
der exakte Beginn der Sekundenmarken wesentlich besser ermittelt werden.
Die PTB Braunschweig gibt die immer noch hinzunehmenden Ungenauigkeiten
mit 6,5–25 μs an, abhängig von Tages- und Jahreszeit...."
/Zitat
Quelle: https://de.wikipedia.org/wiki/DCF77
Wie so ein Empfänger aussieht, der die Kreuzkorrelation ausführt, weiß
ich leider nicht. Wäre vielleicht noch eine interessante Sache, das
herauszufinden.
ciao
gustav
Ich habe mir die Impulse meines DCF77 Empfängers angeschaut und dann in
fünf Kategorien unterteilt:
a) Ungültig (zu kurz)
b) Low-Bit
c) Ungültig (weder High noch Low)
d) High-Bit
e) Ungültig (zu lang)
Gleiches mache ich mit den Pausen zwischen den Bits. Wobei die
Schwellwerte großzügig gesetzt sind. Die konkreten Millisekunden habe
ich gerade nicht verfügbar.
Hi,
noch ein Filmchen zum Vergleich von DCF77 und MSF60.
Der erste Durchlauf liefert natürlich bis zur Minutensynchronisation
"Mist".
Dann sieht man, wie der Null-Minuten-Impuls bei MSF60 (500 ms)
verlängert ist.
Und der 9. und 10. Impuls ist A Code low und B Code high. Ergo zwei
fallende Flanken, was beim hier verwendeten DCF77-Decoderprogramm die
Sekundenanzeige jeweils weiterzählen würde. Dies muss mit der Software
eliminiert werden und gelingt mit dem Sperren bzw. Verodern des Ports
ganz leicht. Vorher hatte ich noch mit einer Hardwarelösung mit Monoflop
und Odergatter experimentiert, das läuft nicht lange stabil.
Und diese Portsperre konnte ich hinterher genau so in das DCF77-Programm
einbauen. Das bewirkt eine zusätzliche Sicherheit gegen Impulse, die
hinter den 100 bzw. 200 ms Impulsen, also für den Rest der Sekunde
eventuell auftreten können.
ciao
gustav
Du zeigst hier Empfangsbeispiele:
11111110000000000000 ein "70" ???
11111111111110000000 ein "92“ ???
11111111111111100000 (15x1, 5x0) ???
Diese Beispiele, egal ob 300 km, 600 km (Wien), oder auch 1000 km von
Mainflingen entfernt, zeigen nur: Schlechter Antennenstandpunkt,
schlechte
Antennenausrichtung, oder Störfeld. Sonst käme was Brauchbares aus dem
Modul.
Da hilft keine Erbsenzählerei, sondern nur das Vermeiden der genannten
Empfangsbehinderungen.
Ideal wäre bei 20 Abtastungen pro Sekunde:
100111111111111111 (0), oder 100001111111111111 (1)
oder bei umgedrehter Polarität:
011000000000000000 (0), oder 011110000000000000 (1)
Wegen des beliebigen Abtastzeitpunkts und Signalverschleifungen
kann es auch mal eine 0, (oder 1) mehr, oder weniger sein.
Daher mein schon beschriebener Vorschlag:
Antenne (Modul) gut aufstellen und ausrichten,
Sekundenflanke erkennen (und darauf einrasten), dann nach 150 ms den
Logikpegel erfassen.
Abgesehen von sehr aufwändiger Software mit Kongruenzverfahren ist es
die erfolgversprechendste Methode.
Jacko schrieb:> Du zeigst hier Empfangsbeispiele:> 11111110000000000000 ein "70" ???> 11111111111110000000 ein "92“ ???> 11111111111111100000 (15x1, 5x0) ???>> Diese Beispiele, egal ob 300 km, 600 km (Wien), oder auch 1000 km von> Mainflingen entfernt, zeigen nur: Schlechter Antennenstandpunkt,> schlechte Antennenausrichtung, oder Störfeld.
Dein Kommentar zeigt eher "DCF schlecht verstanden".
Egal wo, genau so sieht das reale Leben aus! Man kann mit geschickten
Algorithmen ein Großteil der Störungen ausblenden.
Jacko schrieb:> Du zeigst hier Empfangsbeispiele:> 11111110000000000000 ein "70" ???> 11111111111110000000 ein "92“ ???> 11111111111111100000 (15x1, 5x0) ???
Ja, in einem Zeitfenster von 0,2 Sekunden, -> 100 Abtastungen/sec
Rolf N. schrieb:> Vielleicht auch von Interesse:> https://blog.blinkenlight.net/experiments/dcf77/
Hi,
stimmt nicht ganz, was im Blog steht. Schon seit mehreren Jahren wird
statt mit 25% auf 15% abgesenkt, was einer Sendeleistungserhöhung und
damit verbesserter Dekodierschwelle gleich käme. (MSF60 tastet afaik
dagegen schon immer mit 100% aus.)
Zitat:
"... wird die Amplitude für die Dauer von 0,1 s oder 0,2 s
phasensynchron mit der Trägerschwingung auf etwa 15 % abgesenkt. Die
Restamplitude ermöglicht die Gewinnung einer kontinuierlichen
Trägerschwingung und soll die Nutzung des DCF77-Trägers als
Normalfrequenzsignal erleichtern..."
/Zitat
Quelle:
https://www.ptb.de/cms/ptb/fachabteilungen/abt4/fb-44/ag-442/verbreitung-der-gesetzlichen-zeit/dcf77/amplitudenmodulation.html
ciao
gustav
Ozvald K schrieb:> Ende Oktober habe> ich ein Modul bei Pollin gekauft, als Plattform nahm ich AVR µC.
Meine Erfahrung mit dem Pollin-Modul:
Mein Modul reagierte sehr empfindlich auf eine R-Last am Ausgang. Das
Ausgangssignal änderte sich bis zur Unbrauchbarkeit.
Bitte nur als Hinweis sehen, vielleicht ist Dein Modul schon optimal
angeschlossen. Das Schaltbild meiner Anschaltung ist Beitrag
Beitrag "[Bascom/AVR] Uhr und DCF" dargestellt.
Alex D. schrieb:> Meine Erfahrung mit dem Pollin-Modul:> Mein Modul reagierte sehr empfindlich auf eine R-Last am Ausgang. Das> Ausgangssignal änderte sich bis zur Unbrauchbarkeit.Ozvald K schrieb:> Ende Oktober habe> ich ein Modul bei Pollin gekauft, als Plattform nahm ich AVR µC.
Hi,
könnt Ihr noch mal genau die Bestellnummer sagen. Bei Pollin finde ich
mehrere Module.
So wie ich das auf den ersten Blick sehe, fehlen hier wieder die
Pullup-Widerstände. Die Empfängerplatinen, die man jetzt bei Pollin
findet, sind nicht separat zu betrachten, sondern zusammen mit den
anderen Modulen zu verwenden. Da sind dann wohl die Pullup-Widerstände
dran.
Dasselbe gilt für das Conrad Modul im Plan, welches ist's genau?
Brauche mehr Infos, falls Tipps gewünscht werden.
ciao
gustav
Karl B. schrieb:> könnt Ihr noch mal genau die Bestellnummer sagen. Bei Pollin finde ich> mehrere Module.
Die Bestellnummer habe ich nicht mehr, mein Pollin-Modul sieht so aus
wie das aktuelle "DCF-Empfangsmodul DCF1" von Pollin. Meins ist aber
schon viele Jahre alt.
Noch älter sind meine Module von Conrad. Diese waren ursprünglich in
einem fertigen DCF-Wecker eingebaut und sind mit einem TFK U2775B
Empfangs-IC bestückt.
Karl B. schrieb:> Dasselbe gilt für das Conrad Modul im Plan, welches ist's genau?> Brauche mehr Infos, falls Tipps gewünscht werden.
Die Anschaltung der Module, wie in meinem Schaltplan gezeigt,
funktioniert schon seit mehreren Jahren problemlos.
Verbesserungvorschläge sind mir immer willkommen.
Gruß Alex
Hier werden ja richtige Kopfstände gemacht, um Fehlsignale
auszusortieren.
Ich bin der Meinung; dass man mit einer Plausibilitätsprüfung + Quarzuhr
eine Uhr hat, die "immer" die richtige DCF77-Uhrzeit anzeigt.
Im Anhang mal einige Diagramme zur tatsächlichen Empfangsqualität.
Besonders nachts sind Störungen zu erkennen.
Wie die Diagramme entstanden sind, wird unter
Beitrag "Erklärung DCF 77-Empfang nachts häufiger gestört als am Tag" erklärt.
wolle g. schrieb:> Ich bin der Meinung; dass man mit einer Plausibilitätsprüfung + Quarzuhr> eine Uhr hat, die "immer" die richtige DCF77-Uhrzeit anzeigt.
Wieso bist Du der Meinung, dass in allen vorhergehenden Vorschlägen
keine Quarzuhr enthalten ist ?
Meine Uhr z.B. läuft mit einem 12,8Mhz TCXO und wird nur nach dem
Einschalten einmalig eingestellt.
Alex D. schrieb:> Meine Uhr z.B. läuft mit einem 12,8Mhz TCXO und wird nur nach dem> Einschalten einmalig eingestellt.
verstehe ich nicht so richtig.
Geht es hier nicht um eine DCF77-Funkuhr?
wolle g. schrieb:> Geht es hier nicht um eine DCF77-Funkuhr?
Da war ich ungenau, lässt sich für einen "normalen" Quarz auch auf
"ständig nachstellen" konfigurieren und wird dann zur DCF77-Funkuhr.
Meiner Meinung nach ging es ursprünglich nur darum ein möglichst
optimales Empfangs- und Demodulationsverfahren zu finden und nicht um
die Möglichkeiten zur Weiterverarbeitung. Was ich dazu beitragen konnte,
habe ich gesagt und gehe jetzt wieder in den Lesemodus.
Gruß Alex
Alex D. schrieb:> Mein Modul reagierte sehr empfindlich auf eine R-Last am Ausgang. Das> Ausgangssignal änderte sich bis zur Unbrauchbarkeit.
Deswegen ist bei mir vorläufig direkt an Pin von µC ohne Pull Up
Aktivierung angeschlossen. Zusätzlich lasse ich eine LED über einen
2N7000 Mosfet blinken. Das ist nicht die endgültige Lösung, zu
Testzwecken ist es so schnell entstanden. Gespeist wird von 5V über
einen Widerstand (weiß nicht den Wert auswendig) und eine Zenerdiode
(habe 3Volt drauf), dazu parallel 0.1µ C + 22µ Elko.
Karl B. schrieb:> könnt Ihr noch mal genau die Bestellnummer sagen.
Bitte schön:
DCF-Empfangsmodul DCF1 ArtNr: 94-810054
Alex D. schrieb:> Wieso bist Du der Meinung, dass in allen vorhergehenden Vorschlägen> keine Quarzuhr enthalten ist ?
Es muss nicht immer Quarz sein, wie ich es schon geschrieben habe bei
mir läuft die Dekodierung auf einem tiny13 (vorläufig) ohne Quarz. Ich
wollte mich ursprünglich nur in das Thema DCF77-Decodierung hinein
arbeiten, aber dann ist es immer mehr gewachsen. Aber das jetzt nur als
Nebensache...
Alex D. schrieb:> Mein Modul reagierte sehr empfindlich auf eine R-Last am Ausgang. Das> Ausgangssignal änderte sich bis zur Unbrauchbarkeit.
Wer lesen kann, ist klar im Vorteil!
Diese Module sind allesamt auf einen geringen Leistungsverbrauch
gezüchtet, man kann spekulieren, dass dort Empfänger-ICs von
Consumer-Uhren im Einsatz sind. Das gilt nicht nur für Pollin.
"DATA ist current source/sink mit Iout > 5 µA."
Ozvald K schrieb:
> Ja, in einem Zeitfenster von 0,2 Sekunden, -> 100 Abtastungen/sec
Oha, da hab ich die 20 Abtastungen falsch interpretiert. Dachte 20/s.
Aber: Was hilft es, herauszufinden, dass manchmal das Signal aus dem
Empfangsmodul keine eindeutige "0", oder "1" (100/200 ms) ergibt?
Bestenfalls hilft es bei der Suche nach einer besseren Antennenposition.
Korrigieren kann man damit nix.
Macht man einfach eine Pegelabtastung 150 ms nach der aktiven
DCF-Flanke,
kommt dann auch ein fehlerhaftes Bit heraus.
Parity-Test + Plausibilitätskontrolle zeigen das aber bei der
Auswertung.
Hat man aber 2..3 gültige Minutentelegramme hintereinander dekodiert und
auf Plausibilität (zeitliche Abfolge) geprüft, kann man damit eine sonst
autonom auf dem µC laufende Quarzuhr (nach-)stellen.
Wer es genau braucht, kann noch überwachen, ob in den letzten x Stunden
solche gültigen Zeitsignale gekommen sind und bei Fristüberschreitung
ein Warnsignal auf dem Uhren-Display setzen...
Mehr geht ohne aufwändige Korrelationsrechnung nicht!
Jacko schrieb:> Was hilft es, herauszufinden, dass manchmal das Signal aus dem> Empfangsmodul keine eindeutige "0", oder "1" (100/200 ms) ergibt?
Es ging einfach darum eine günstige Position zu finden wo man mit der
größten Wahrscheinlichkeit annehmen kann ob der Sample den richtigen
Wert liefert. Beim Pollin Modul diese Position ist eher bei 170ms statt
150.
Jacko schrieb:> Mehr geht ohne aufwändige Korrelationsrechnung nicht!
Sehe ich auch so.
Zu Test- und Beobachtungszwecken lasse ich mehrere Variablen
visualisieren. Eine davon ist die Anzahl der 1-er Samples die nach der,
schon erklärten Methode zusammengestellt wird. Eine andere ist der
Abstand zwischen zwei "Sekundenflanken". Bei gutem Empfang sind die
Werte stabil und ändern sich kaum. 90 oder 99 für Samples und 100 für
den Abstand (100*10ms). Abends fangen an die Werte zu "wackeln", auch
der Abstand zwischen 97 und 104, und hier ist die Dekodierung schon
schwierig.
Jacko schrieb:> Hat man aber 2..3 gültige Minutentelegramme hintereinander dekodiert und> auf Plausibilität (zeitliche Abfolge) geprüft, kann man damit eine sonst> autonom auf dem µC laufende Quarzuhr (nach-)stellen.
Hi,
eine Gangreserve, so möchte ich den fortzählenden Uhrenbetrieb ohne
DCF77-Signal nennen, halte ich für notwendig. Ein Quarz bringt da mehr
Genauigkeit, da die Netzfrequenz als Frequenznormal ja seit dem Debakel
Anfang vergangenen Jahres unter Umständen Probleme bereiten kann.
Auf den Plausibilitätstest mit extra dafür reservierten SRAM-Puffern und
Inhaltsvergleich nach Prinzip der Zunahme der Skalenwerte (Minuten immer
n+1) habe ich verzichtet, um am Anfang nicht so lange auf eine Anzeige
warten zu müssen.
In einem Video wird gezeigt, wie das so in der Praxis bei gestörtem und
wiedereintreffendem guten Empfang so aussehen kann.
Übrigens synchronisiert sich das andere ausprobierte Programm, das mit
den Interrupts arbeitet nicht mehr bei Wiedereintreffen guten Empfangs.
Programm zeigt 00:00:00 und bleibt dort hängen.
Mit dem Polling-Programm von S. Huehn habe ich da keine Probleme, das
ist im Video zu sehen.
Gleichzeitig noch akustisch mit Direktmischer die Marken als ca. 1,5 kHz
Töne zu hören. Bei Störung rauscht es nur.
Viel Spass!
ciao
gustav
Ozvald K schrieb:> Es ging einfach darum eine günstige Position zu finden wo man mit der> größten Wahrscheinlichkeit annehmen kann ob der Sample den richtigen> Wert liefert. Beim Pollin Modul diese Position ist eher bei 170ms statt> 150.
Wäre oversampling eine Option?
Den optimalen Abtastpunkt zu finden ist schwierig. Wenn man Signale
überabtastet kann man die Ergebnisse bewerten. Bei binären Signalen ist
das auch relativ einfach.
Z.B.:
DCF ist ein 60 Hz Signal. 20 fach oversampling wäre dann 1200 Hz
Abtastrate.
15x > 70% = high, 15 x < 30% = low.
Karl B. schrieb:> Übrigens synchronisiert sich das andere ausprobierte Programm, das mit> den Interrupts arbeitet nicht mehr bei Wiedereintreffen guten Empfangs.> Programm zeigt 00:00:00 und bleibt dort hängen.
Möchte dazu nur sagen, dass das Problem hier m.M.n bei der Software
liegt, und nicht beim Verfahren. Bin völlig bei Dir wie sich eine Uhr
verhalten muss. Meine Lösung verwendet den "schrecklichen :-)"
Interrupt, aber hat keine Probleme beim Wiedereintreffen vom Signal nach
einem Ausfall. Habe 3 Zustände definiert: 0 - nach dem Einschalten, 1 -
hat Bit0 Marke entdeckt und versucht das weitere Signal zu verarbeiten,
und 2 - die Uhr ist synchronisiert. Bleibt jetzt das Signal mehr als 2,5
Sekunden aus, dann wechselt die Software in Zustand 0, und wartet wieder
auf eine Bit0 Marke. Funktioniert gut.
HyperMario schrieb:> Wäre oversampling eine Option?
Ehrlich gesagt, weiß ich nicht, habe mich mit diesem Thema
(Oversampling) noch nie in Detail beschäftigt. Aber danke für den Tipp,
werde mir anschauen und wenn das Aufwand/Nutzen Verhältnis entsprechend
gut ausfällt, why not?
Wenn das Signal gut ist, es ist egal mit welchem Verfahren man die Bits
extrahiert. Mit Störungen fangen die Probleme an. Wie würde ein
Oversampling beim gestörten Signal aussehen? Keine Ahnung...
Ozvald K. schrieb:> Das passt schon nicht, 60 Zustände pro Minute höchstens, aber 1 Bit pro> Sekunde
Nee, das passt schon!
Es werden zwischen 5 und 10 Zeichen übertragen pro Sekunde.
100 ms Absenkung stehen für den Wert „0“, 200 ms für „1“.
Es wird nur jede Minute EIN Telegramm gesendet.
Und dazwischen ist halt Pause.
Ozvald K. schrieb:> Möchte dazu nur sagen, dass das Problem hier m.M.n bei der Software> liegt, und nicht beim Verfahren.
Hi,
es war diese sophisticatete Variante:
Benutzt INT für fallende und steigende Flanke, UART mit Interrupt und
zwei Timer Interrupts. etc. Wake up mit UART. Ist mit Abstand wohl so
das Grenzwertigste, was man in den ATtiny2313 nicht alles so reinpacken
kann. Die Escape Sequenzen für die Farben am Monitor etc. Die
Decodierung des Signals wird noch angepasst an die Signalqualität.
http://www.avr-asm-tutorial.net/avr_de/dcf77uhr.html
Irgendwo kommen die Interrupts sich in die Quere, und das Programm gibt
nur noch 00:00:00 aus. Nur power cyclen hilft afaik da.
LCD-Ausgabe nur über Zusatzprog. von mir und zweiten AVR ohne MAX232
UART direkt . Die Routinen passten nicht mehr rein. Und natürlich 10 MHz
Takt.
ciao
gustav
P.S.: OK, die LCD Ausgaben überschreiben sich. Ist unschön. Weiß ich.
Das erste Zeichen ist auch jedesmal beim Start ein Zufallscharakter.
SRAM (!)
Ozvald K schrieb:
> Es ging einfach darum eine günstige Position zu finden ...> ... Beim Pollin Modul ... eher bei 170ms ...
Ist vielleicht eine gute Idee, um die Empfangssicherheit zu verbessern!
Man kann das bei guten Empfangsbedingungen auch schön testen, wenn man
die Antenne langsam (immer abwarten, bis die träge Empfängerregelung
fertig ist) aus der optimalen Empfangsrichtung rausdreht:
Bevor der Empfang aussetzt, verschieben sich die Bit-Zeiten (100/200 ms)
langsam und werden schließlich immer ungenauer. Die Module von
Pollin/Reichelt/Conrad sind sich da nach meiner Beobachtung ähnlich,
es könnte aber sein, (habe nicht danach gesucht), dass die Zeitwerte in
unterschiedliche Richtungen auswandern.
Wenn der µC "nur DCF macht", hat er ja genug Reserven um sowas im
Hintergrund zu erfassen.
Da würde ich vorschlagen, mit einem Startwert für den Abtastzeitpunkt
nach der Sekundenflanke anzufangen und ihn nur gaaaanz langsam nach den
beobachteten Zeitwerten nachzuführen.
Überreaktion ist eher schädlich!
Habe schon mal probiert, aus dem AM-DCF-Signal ein Zeitnormal zu
basteln,
daher kann ich bestätigen, dass die empfangene Sekundendauer um einige
ms abweichen kann. (Mit GPS-Sekundenpuls kommt man da weiter.)
Bei mir (450 km von Mainflingen) habe ich aber bei allen oben
genannten Modulen nur SEEEHR selten Probleme mit der DCF-Dekodierung,
wenn ich die Bits 150 ms nach der Sekundenflanke erfasse.
Jacko schrieb:> Da würde ich vorschlagen, mit einem Startwert für den Abtastzeitpunkt> nach der Sekundenflanke anzufangen und ihn nur gaaaanz langsam nach den> beobachteten Zeitwerten nachzuführen.
Wenn ich es richtig verstanden habe du schlägst vor die Zeitabweichungen
zu erfassen und daraus eine Regelgröße zu bilden was den Zeitpunkt vom
Sampling beeinflusst. Ja, die Signale werden zeitweise ungenauer, das
habe ich gesehen. Ich visualisiere jetzt schon eine Variable die in 10ms
Takt vom Flanke bis Flanke (1s) hochgezählt wird. der Wert ist im
idealen Fall 100. (100 * 10ms = 1s). Wenn die Störungen stärker werden,
dieser Wert fängt an zu "wackeln" zwischen 97 und 104. Nur, der
Mittelwert bleibt trotzdem 100,weil wenn ein Wert 97 ist, wird der
nächste 103. z.B. 100, 98,102,101,99,100,97,103,99,100,usw. D.h. selbst
wenn ein Impluls länger wird, der nächste ist kürzer und damit der
Mittelwert bleibt bei 100. Aber was ich machen könnte, 2 Funkuhren neben
einander laufen zu lassen, einen mit 150ms Samplingzeit, den anderen mit
160ms z.B. und beobachten welche wird öfter synchronisiert.
An Peter Dannegger: habe die Software aus Deinem Projekt Funkuhr mit
TINY12 auf TINY13 portiert und an die Hardware angepasst. Meine LCD
Steuerung ist anders, und habe noch geringfügige Änderungen gemacht,
aber möchte dass Du sie auch noch einmal kontrollierst ob die Änderungen
nicht irgendwas unabsichtlich beeinflussen. Projekt als Anhang hier.
Danke!
Hier habe ich das Ergebnis vom Vergleich. Folgendes habe ich gemacht:
die Antenne habe ich in verschiedene Positionen gebracht, so habe ich
alles vom guten Signal bis zu "nur mehr Mist" gehabt. Habe von beiden
Uhren ~1 Stunde lang den Status in Minutentakt notiert. (1 - nicht
synchronisiert, 2 - synchronisiert). Auf den Bildern links läuft das
Programm von Peter, rechts läuft meines. So habe ich auch auf den Zettel
die Werte notiert. (links <--> rechts) Wie man sieht, es gibt
Positionen wo beide gut laufen, es gibt Positionen wo gar nicht mehr
geht, und dann findet man auch Position wo sich die linke Uhr noch
synchronisieren kann, die rechte aber nicht mehr. M.M.n. es ist nicht
nur die Frage ob Polling oder Interrupt, es ist eher das Gesamtkonzept
was hier zieht. Peter seine Software misst die Impuls- und Pausenlängen.
Hier reicht es wenn eine Größe außer Toleranz gerät, das Resultat wird
schlecht. Meine Lösung dagegen geht nicht so streng mit dem Signal um,
und das erwies sich in diesem Fall als leichtes Vorteil. Muss noch dazu
sagen, dass ich die Grenze des Übergangs in der Software von Peter von
150 auf 170ms erhöht habe, weil davor ein paar mal das Datum falsch
angezeigt hat. Die Software hat 2 lang geratene Nullen schon als 1
interpretiert, Parität stimmte aber. Damit sieht man dass die
Impulslängen Modulabhängig sein können und es unter Umständen in der
Auswertung berücksichtigt werden muss. Vor dieser Korrektur war die
Auswertung noch schlimmer. Was Peter aber besser gelöst hat ist die
Feinjustierung des Timers. Bei meiner Lösung driften die Sekunden
stärker weg in nicht synchronisiertem Zustand. Eine Uhr sollte aber so
wieso mit Quarz laufen.
Ozvald K. schrieb:> Wenn das Signal gut ist, es ist egal mit welchem Verfahren man die Bits> extrahiert. Mit Störungen fangen die Probleme an. Wie würde ein> Oversampling beim gestörten Signal aussehen? Keine Ahnung...
Oversampling ist von Prinzip nichts anderes wie eine Entprellung bei
Tastern.
Du addierst mehrere Werte innerhalb des Zeitfensters und bewertest dann
das Ergebnis.
Beispiel positives Signal als Quiz (für jedes richtige Ergebnis bekommt
der Kandidat* einen Punkt):
Wenn statt 1 mal 20x abgetastet wird hätte der Kandidat im Idealfall 20
Punkte. Bei mehr als 10 Punkten kriegt er aber Kandidat immer noch den
Hauptpreis. Alles andere wären Nieten**. Störungen fallen von selber
raus so lange Sie kürzer sind als die hälfte des Signals.
Das kann man jetzt bis ins 100 1000 fache ausdehnen, ob das Sinn macht
hängt von der Art der Störung ab. DCF Telegramm sind nah an der
Netzfrequenz, es macht deshalb Sinn die Messpunkte immer etwas zu
verschieben.
_________
*Der Kandidat ist hier die Messung eines positiven (high) bits, für die
negativen gilt es natürlich genau so.
**Nieten entwerten nur den Teil der Botschaft in dem Sie vorkommen.
Ein Fehler im der Sekunde z.B. lässt alle anderen Daten valide.
HyperMario schrieb:> Beispiel positives Signal als Quiz (für jedes richtige Ergebnis bekommt> der Kandidat* einen Punkt):> Wenn statt 1 mal 20x abgetastet wird hätte der Kandidat im Idealfall 20> Punkte. Bei mehr als 10 Punkten kriegt er aber Kandidat immer noch den> Hauptpreis. Alles andere wären Nieten**. Störungen fallen von selber> raus so lange Sie kürzer sind als die hälfte des Signals.
Das kann man noch etwas besser Ausrücken:
Beispiel: Während einer Bitlänge wird 20 x gemessen. Die Ergebnisse
werden addiert.
Am Ende wird mit einem Schwellwert verglichen. Der ist erstmal
willkürlich. Be einem Schwellwert von 9 wären ein Zählerstand von mehr
als 11 ein high bit weniger als 9 ein Lowbit. Fehler bei Werten von 9
bis 11.
Den Schwellwert kann man dann leicht ändern, auch die Samplerate. Das
hängt von der Art der Störungen ab.
Der Trick daran: Störungen fallen von selbst raus. Wenn Sie länger als
der Schwellwert sind ist das Signal wohl so oder so unbrauchbar.
HyperMario schrieb:> DCF Telegramm sind nah an der> Netzfrequenz, es macht deshalb Sinn die Messpunkte immer etwas zu> verschieben.
Das verstehe ich nicht.
Die Netzfrequenz ist bei uns 50 Hz.
Beim DCF wird ein Bit pro Sekunde übertragen, als 1 Hz.
Der Unterschied ist Faktor 50.
Was wiederum sinnvoll wäre, wenn das Abtastverfahren zum Einsatzkommt:
eine Abtastrate von 10, 25 oder 50 Hz zu wählen. Damit werden
Einstreuungen durch das Stromnetz wirksam unterdrückt.
Das DCF77- Modul von Pollin kostet 5,45€ und der Empfang ist in manchen
baulichen Situation einfach unmöglich (s.a. Schaltnetzteile). Ich
benutze dafür nur noch die GPS-Module mit der kleinen Antenne (5x15mm).
Das reicht eigentlich immer und man bekommt die Uhrzeit per UART.
HyperMario schrieb:> Während einer Bitlänge wird 20 x gemessen. Die Ergebnisse> werden addiert.>> Am Ende wird mit einem Schwellwert verglichen.
Ah, ok, das habe ich ohne dies schon gemacht, nur das Signal aus dem
Empfängermodul ist ein bisschen anders als von einem Taster. Es wird im
Modul selbst schon vorbereitet. Könnte mir gut vorstellen dass es bei
einem Empfänger mit analogen Ausgang so funktioniert, aber bei
Billigmodulen ist das Signal entweder da (auch mit Jittern), oder kommt
fragmentiert heraus aber dann schon mit Aussetzten. (nächstes Bit fehlt
z.B.)
Aber kürzlich ist mir die Idee gekommen wie ich den Jittern entgegen
wirken könnte. Wie man auf dem Bild "falsches_Datum" sehen kann, wurden
2 Bits im Datum als 1 interpretiert. Die Software hat die Schwelle von 0
auf 1 bei 150ms gehabt. Ich habe am 28.12. kurzfristig auf LCD das Datum
08.10. gehabt. Hier wurden mit 170ms Schwelle die "kurze 1-er" als 0
interpretiert. Deswegen meine Idee: ich werde mehrere Ergebnisse bilden,
ein mit Sample 15 und ein mit Sample 17 z.B, und der plausiblere Wert
wird übernommen. Das lässt sich in meiner Software mit relativ geringem
Mehraufwand implementieren. Nennen wir es multisample-Verfahren. Und bin
jetzt am Ende meiner "Diplomarbeit"...
Ein Punkt den ich hier bisher vermisse ist auszunutzen, dass die
Sekunden-pulse im festen Abstand (bis auf den fehlenden) kommen. D.h.
die Zeit für den Start der Pulse müsste man nicht jedes mal messen,
sondern könnte einen Mittelwert über längere Zeit nutzen. Das sollte die
Fehler bei der Pulslänge reduzieren, weil man so den Start einheitlich
und besser hat.
Für den Start der Pulse hätte man eine Art PLL, der einen Sekundentakt
erzeugt und sich am Start der Pulse anhängt. Wenn der erst einmal
eingerastet ist braucht der nur sehr langsam, und wenig nachregeln.
Falsche Pulse in den Pausen werden so weitgehend unterdrückt, sofern der
PLL nicht darauf einrastet, was eher unwahrscheinlich ist.
Bei den Pulsen wird dann nur noch das Ende (und ob überhaupt da)
individuell gemessen, etwa per Abtastung alle 20 ms.
Auch wenn die einfache Parität nur Fehler erkennen kann ist das schon
sehr Hilfreich. Eine Minute länger messen ist deutlich besser als eine
falsche Zeit.
Tim schrieb:> Das verstehe ich nicht.> Die Netzfrequenz ist bei uns 50 Hz.> Beim DCF wird ein Bit pro Sekunde übertragen, als 1 Hz.> Der Unterschied ist Faktor 50.
Stimmt.
Ozvald K. schrieb:> Ah, ok, das habe ich ohne dies schon gemacht, nur das Signal aus dem> Empfängermodul ist ein bisschen anders als von einem Taster. Es wird im> Modul selbst schon vorbereitet.
Dann kann man oversampling wohl vergessen.
Lurchi schrieb:> Eine Minute länger messen ist deutlich besser als eine> falsche Zeit.
und deshalb macht man, wie oben schon mehrfach angeführt, jede Minute
eine Plausibilitätskontrolle
Lurchi schrieb:> Ein Punkt den ich hier bisher vermisse ist auszunutzen, dass die> Sekunden-pulse im festen Abstand (bis auf den fehlenden) kommen. D.h.> die Zeit für den Start der Pulse müsste man nicht jedes mal messen,> sondern könnte einen Mittelwert über längere Zeit nutzen.
Jetzt wird's interessant! Wenn man das Signal per Timer-Interrupt
abtastet kann man den Teilerfaktor des Timers in kleinen Schritten
verstellen. Damit ist die Abtastung synchron zu DCF, auch wenn der
uC-Takt (fast) beliebig ungenau ist. Ein primitiver PI-Regler kann das
recht gut.
Übrigens kommen die Minuten-Marken auch im festen Abstand ;)
Richtig interessant wird es aber erst, wenn man eine RTC mit Batterie
hat. Dann kann man nämlich die DCF-Daten für die nächste Minute
vorhersagen, jedenfalls das Datum. Damit hat man 8+1+1 aufeinander
folgende Bits als Minuten-Marke. Normal kann man noch Wochentag und
Stunde dazu nehmen, dann kennt man die Hälfte der 60 Bits im Voraus und
muss nur noch die Minuten-Bits auswerten.
Der entscheidende Punkt dabei: man vertraut nur der eigenen RTC und
zieht sie nur ganz langsam nach. Dafür braucht man nur die Minuten-Bits.
So verliert auch die Sommerzeitumstellung ihren Schrecken, weil man
nichts davon merkt.
Bauform B. schrieb:> So verliert auch die Sommerzeitumstellung ihren Schrecken, weil man> nichts davon merkt.
Hi,
kann man leich zusätzlich decodieren.
Man muss nur den Time-Code kennen und die Bits ins SRAM schieben und
auswerten.
Für logs gibt es schon eine Seite im Netz.
Manchmal ist der Empfang auch gestört.
Oder seltener das Rufbit gesetzt.
Irgendwie muss der Decoder das ja auch decodieren und das wird IMHO am
einfachsten mit dem Schieben der gewünschten Bitfolge ins SRAM gemacht.
(Die Meteotime Daten interessieren hier zunächst nicht. Brauchen u.U. 24
Stunden störungsfreien Empfang, um überhaupt erst einmal etwas aufs
Display zu bekommen.)
https://dcf77logs.de/logs
(Hatte bei "meinem" Programm den Bug, dass immer bei Datumswechsel 24:60
angezeigt wurde. Erst dann direkt 00:01 ohne 00:00. Aber das ist mit der
Auswertungssoftware leicht in den Griff zu bekommen.)
ciao
gustav
Hi,
noch ein Bildchen zu den beiden Codes ( A und B)bei MSF60.
Bei dem vorgestellten Programm wird (leider) nur der A Code decodiert.
Das reicht zur Zeit- und Datumserfassung, hat unter anderem allerdings
dann keine Paritätskontrolle, die liegt im sogenannten B-code.
Aber MSF60 hat noch eine Finesse, die DCF77 nicht aufweist:
Die Bitfolge in den Sekunden 52 bis 59 am Ende ist mit 01111110
festgelegt, ändert sich nicht, kann somit zur Synchronisation zusätzlich
verwendet werden.
Will man Paritykontrolle und noch den DUT Code, dann braucht man wohl
noch einen Co-Prozessor oder ein völlig anderes Decoderprogramm, das
nicht wie beim einfachen DCF77-Programm mit dem Trick des Carrybits
arbeitet.
ciao
gustav
Ozvald K schrieb:> Wenn der INT0 wegen einer Störung ausgelöst> wurde, dann sind die Störungen ohne dies schon derartig massiv, dass man> kaum Vernünftiges mehr auswerten kann ...
Hallo Ozvald,
um Störungen zu minimieren habe ich versuchsweise mal eine Art
Tiefpassfilter in einen ATTiny13 programmiert. Das DCF-Signal wird 333
mal pro Sekunde in ein 30Bit-Schieberegister geschoben. Nach jeder
Abtastung wird ausgewertet wie viel Einsen im Schieberegister stehen.
Anhand dieses Wertes wird, unter Berücksichtigung einer kleinen
Hysterese entschieden, ob eine 1 oder eine 0 ausgegeben wird. Der Tiny
läuft mit 1,2MHz, die IRQ-Routine dauert unter 100usec. Das Programm ist
in Bascom geschrieben
Falls Du mal probieren möchtest:
Der DCF-Filter wird zwischen DCF-Empfänger und die Auswerteschaltung
eingefügt.
PB3 ist der Filtereingang,
PB4 ist der Fiterausgang,
PB0 ist ein Testausgang zur Messung der IRQ-Dauer
Ob es mit Filter besser oder schlechter funktioniert, kann ich nicht
sagen, dazu wohne ich zu nahe an DCF-Sender.
Alex D. schrieb:> um Störungen zu minimieren habe ich versuchsweise mal eine Art> Tiefpassfilter in einen ATTiny13 programmiert.
Das klingt interessant, Alex - magst Du den Quelltext dazu
veröffentlichen?
Viele Grüße,
Dirk
Hallo Alex,
danke für die Mühe, nur das Problem ist, dass ich nie ein Dauersignal
aus dem Empfängermodul so herausbekomme. Ich glaube das Modul selbst
macht schon eine Art Filtrierung. Bei gutem Empfang ist das Signal
stabil. Bei schlechterem Empfang fangt das Signal an zu "jittern", d.h.
die Sekundenflanken wackeln ~ +/- 30ms, aber keine Spikes. Bei noch
schlechterem Empfang entstehen solche Spikes aber dann zusammen mit
Aussetzungen. Um es zu testen bräuchte ich ein Spike verschmutztes
Dauersignal von mehreren Minuten, was aber nie der Fall ist. Wo hast Du
das Signal her?
Stefanus F. schrieb:> Stelle den Empfänger mal neben einen WLAN Router.
Oder neben ein Steckernetzteil was getaktet ist.
Beides sollte natürlich eingeschaltet sein ;)
900ss D. schrieb:> Stefanus F. schrieb:>> Stelle den Empfänger mal neben einen WLAN Router.>> Oder neben ein Steckernetzteil was getaktet ist.> Beides sollte natürlich eingeschaltet sein ;)
Gut, das werde ich machen :-)
Dirk W. schrieb:> Das klingt interessant, Alex - magst Du den Quelltext dazu> veröffentlichen?
Ja, aber ich muss das Prg. vorher noch etws aufräumen.
Ozvald K schrieb:> Wo hast Du> das Signal her?
Die Antenne stand zufällig in einem ungüstigen Winkel zum DCF-Sender.
War nicht wiederholbar. Interessant sind aber nur Störungen wie sie in
der Realität vorkommen.
Gruß Alex
Find ich gut, dass du mit deiner Vorgehensweise auf die
spezifischen "Macken" der Empfangsmodule eingehen kannst.
Auch für die Module anderer Hersteller/Lieferanten kann damit
ein optimaler Abtastzeitpunkt gefunden werden, der deren
typische Pulsverformungen bei normalen und schwachem Pegel
berücksichtigt.
- Speichert man den gefundenen Abtastzeitpunkt ist die Uhr beim
nächsten Einschalten gegenüber der Standardabtastung im Vorteil.
Bei echt gestörtem Empfang hilft es natürlich nicht.
Bei gutem Empfang stört es sowieso nicht, wenn 130, oder 170 ms nach
der aktiven Flanke abgetastet wird, aber bei schwachem Empfangspegel
kann es (je nach Modultyp) helfen.
Nach sorgfältig auf Plausibilität geprüften Zeittelegrammen stellt,
(oder "diszipliniert") man damit eine freilaufende Quarzuhr.
Ich hatte mir sogar mal die Mühe gemacht, per Software die Gang-
Abweichungen so einer DCF-Quarzuhr gegenüber den DCF-Korrekturen zu
erfassen, um den Quarz (oder einfacher den Vorteiler von Quarztakt
auf Sekundentakt) zu korrigieren.
Das ist aber erst nach tagelanger Beobachtung und Mittelwertbildung
sinnvoll, da der Sekundentakt aus dem DCF-Modul einige 10 ms jittert.
Beispiel:
DCF-Takt mit gültigen (!) Telegrammen jittert um +/-30 ms.
Maximaler Fehler: 60 ms.
Erst nach 16,7 Stunden kann man mit so einem (nur langfristig
hochgenauen) DCF-Signal Zeitfehler von > 1 ppm erfassen.
Hi,
da ich im Hause praktisch keinen durchgehend sauberen DCF77-Empfang
hatte, habe ich mir den AD450 am Balkongitter montiert.
Nur bei Gewitter und starken statischen atmosphärischen Störungen
"spinnt" der daran angeschlossene Decoder.
https://www.buerk-mobatime.de/pages/shop/shopAction/showProductDetails/id/465/produkt/Zeitfunkempf%C3%A4nger
Kostenpunkt ca. 170 Euro
Der Witz ist, dass eine einfache unabgeschirmte Liyy
Zweidraht-(Telefon)leitung ausreicht.
Die Spannungsversorgung braucht keinen Extradraht, wie bei den meisten
anderen Empfangsmodulen, die im I-Net angeboten werden.
Polung der Drähte spielt auch keine Rolle.
Schaltungsprinzip Stromschnittstelle.
ciao
gustav
Karl B. schrieb:> Kostenpunkt ca. 170 Euro>> Der Witz ist, dass eine einfache unabgeschirmte Liyy> Zweidraht-(Telefon)leitung ausreicht.> Die Spannungsversorgung braucht keinen Extradraht, wie bei den meisten> anderen Empfangsmodulen, die im I-Net angeboten werden.>> Polung der Drähte spielt auch keine Rolle.> Schaltungsprinzip Stromschnittstelle.
Mit einem dreiadrigem Kabel und einem DCF-Modul von Conrad oder Reichelt
hättest du dir 140€ Sparen können.
Und so kompliziert ist es auch nicht, drei Adern korrekt anzuschließen.
John schrieb:> Mit einem dreiadrigem Kabel und einem DCF-Modul von Conrad oder Reichelt> hättest du dir 140€ Sparen können.
Hi, bin mir ziemlich sicher, dass die anderen Module die klimatischen
Einflüsse nicht lange mitgemacht hätten. Habe übrigens auch die
genannten Module ausprobiert, auch mit Aussenmontage nach Einbau in ein
passendes Gehäuse. Sie lieferten mir kein verwertbares Signal. Und wenn,
dann driftete der Empfänger weg, lief vielleicht ein paar Minuten, dann
kamen wieder massenhaft Spikes. War also notgedrungen gezwungen, etwas
besseres auszuprobieren, bevor ich der BNetzA Bescheid gebe.
Leider gibt es Gegenden, da ist der Störnebel doch so groß, dass auf dem
benutzten Längstwellenbereich kein Gras mehr wächst. Da muss man eben
die besseren Empfänger verwenden.
ciao
gustav
Karl B. schrieb:> Leider gibt es Gegenden, da ist der Störnebel doch so groß, dass auf dem> benutzten Längstwellenbereich kein Gras mehr wächst. Da muss man eben> die besseren Empfänger verwenden.
In solchen Fällen fällt einem natürlich GPS als Alternative ein. Aber
DCF funktioniert auch noch mit Schneehaube wie im Foto (danke dafür!).
Was würde ein GPS-Empfänger an der Stelle noch liefern?
Bauform B. schrieb:> Was würde ein GPS-Empfänger an der Stelle noch liefern?
(M)ein GPS-Empfänger möchte schon bei gutem Wetter auf der Fensterbank
innen sein Bit "Stabile Zeit" nicht setzen. Im Gegensatz zu DCF muss ich
mit der Antennne raus aus dem Haus, das ist lästig.
Die Frage ist natürlich, wie genau es denn sein soll, eine
Wohnzimmeruhr oder ein Zeitserver in Konkurrenz zum ptb per Internet.
Dirk W. schrieb:> Das klingt interessant, Alex - magst Du den Quelltext dazu> veröffentlichen?
Mit Bascom 2.0.8.1 für ATTiny13a compiliert. Im Quelltext kann man
mehrere Einstellungen vornehmen:
Abtastrate = CTC-Timer. Zur Änderung der Abtastrate einfach in
"_irq_abstand" den gewünschten Zeitwert in nsec eintragen. Der Compiler
errechnet dann aus $crystal und _irq_abstand die Einstellwerte.
Das Schieberegister ist 30Bit lang. Bei einer Abtastrate von 3,333 msec
passen genau 100msec in das Schieberegister.
Die Hysterese lässt sich ändern, voreingestellt sind 13 und 15.
Zur Anzeige des Eingangssignals kann an PB2 über einen 2,2K-Widerstand
eine Leuchtdiode angeschlossen werden
Analog dazu an PB4 für des Ausgangssignal.
PB3 ist der Filtereingang
PB4 ist der Filterausgang und LED-Anschluss
PB2 ist zum Anschluss einer LED zur Anzeige des Filtereingangs
PB0 ist ein Testausgang zur Messung der IRQ-Dauer
Ob der Tiefpassfilter in der Praxis eine Verbesserung bringt, kann ich
leider nicht sagen.
Gruß Alex
wie "stabil" z.B. die (Sekunden)Flanke eines DCF RX ist könnte man ja
per Vergleich mit einem GPS pps Signal ermitteln, welches ja auch bei
den günstigsten GPS RX mit max. ~40ns Jitter angegeben ist.
Manfred schrieb:> (M)ein GPS-Empfänger möchte schon bei gutem Wetter auf der Fensterbank> innen sein Bit "Stabile Zeit" nicht setzen.
Kannst du das mal in NMEA0183 ausdrücken oder wo liest du so ein Bit bei
einem GPS-Empfänger ab?
Wolfgang schrieb:> wo liest du so ein Bit bei einem GPS-Empfänger ab?
Ich habe dafür den RMC-Datensatz genommen.
Das zweite Feld ist ein Statusbyte.
Steht dort ein 'A', ist die Zeit gültig, steht dort ein 'V', ist sie
nicht gültig.
Die Zeit selber steht in Feld 1 in UTC, in Feld 7 steht das Datum.
Fehler sind mit ',' getrennt.
Der RMC- Datensatz wird auch von allen Empfängern geliefert, dass trifft
nicht auf alle Datensätze zu.
Zwei Beispiele mit Status 'A':
Der Status hier hat aber noch nichts mit dem Positionfix zu tun. Die
Position kann noch ungültig sein obwohl der Status auf 'A' steht. Die
Zeit in dem RMC-Datensatz ist dann aber gültig.
Alex D. schrieb:> Ob der Tiefpassfilter in der Praxis eine Verbesserung bringt, kann ich> leider nicht sagen.
Hallo Alex,
habe deinen Tiefpassfilter (noch) nicht getestet, aber was anderes: habe
bei gutem Empfang den Empfänger mit einem Schaltnetzteil beeinflusst.
Bei zunehmender Störung wird erst gejittert, dann kommen Spikes dazu.
Habe eine Position gefunden wo es nur gejittert hat ohne Spikes, aber
das stark (+/- 30ms). In diesem Zustand habe ich ~ halbe Stunde
getestet. Die Software von Peda ist damit überhaupt nicht mehr zu Recht
gekommen, bis meine nur 2x mit Parity Error aus dem gelockten Zustand
ausgefallen ist. Gehe sogar weiter, die ab und zu Spikes können auch
nichts anhaben, solange in Bereich fallen wo der Interrupt verboten ist.
Bei starken Störungen wie am Bild hilft das dann auch nicht mehr.
Meine Prognose für Filter:
Wenn der Tiefpassfilter die Jitters auch weiter reicht (und ich vermute,
ja), dann würde das für die Software mit Impuls-Längenmessung auch
nichts bringen, es sei denn man definiert die Grenzen "locker". Es
interessiert mich aber ohne dies was bei solchen starken Störungen wie
am Bild herauskommt.
Noch Etwas:
Ich möchte die PeDa-Software nicht schlecht machen, aber fehlen mir die
Kenntnisse um sie zu finetunen, und mein Fokus liegt jetzt so wieso
anderswo.
Mal eine Zwischenfrage: was meint ihr mit "Jitter"? Jittert die
Vorderflanke (also die Sekunde fängt 30ms früher oder später an) oder
die Impulsbreite (also 70 bis 130ms statt 100ms)?
Bauform B. schrieb:> Jittert die> Vorderflanke (also die Sekunde fängt 30ms früher oder später an) oder> die Impulsbreite (also 70 bis 130ms statt 100ms)?
Beides. Wenn du die (weiter oben) angehängten Fotos mit Uhren ansiehst,
siehst du vier Variablen die ausgegeben werden. "Q"ality zeigt die
Anzahl der 1-er in den Samples, die mit schon beschrieben Verfahren
ermittelt werden, "W"idth zeigt den Abstand (in Hexadecimal) zwischen 2
Sekundenflanken, "S"tatus zeigt den Zustand (synchronisiert/nicht
synchronisiert) und "C"heck zeigt ob und wo die Konvertierungsroutine
Fehler gefunden hat.
Bei gutem Empfang habe ich (großteils) W64 und Q90 oder Q99 angezeigt.
Wenn es jittert, dann dann habe ich W61-67 und Q60,70,80, 90-99 alles
dabei.
..da ich nicht editieren kann, Nachtrag: ich habe in meinem Beitrag mit
Jittern in diesem Fall die variierende Flanke gemeint, aber die
Impulsbreiten variieren auch, von 60 bis über 200 ms ist alles dabei.
So ähnliche Störungen hatte ich auch mal, bei einer selbst gebauten Uhr
mit TIL311 LED-Anzeige.
Für einigermaßen störungsfreien Empfang musste der Empfänger mindestens
30…40cm von der Anzeige entfernt sein und sehr genau ausgerichtet
werden.
Mit einem Filter in der Versorgungsspannung (C1, R2) gab es keine
Störungen mehr. Auch nicht wenn der Empfänger nur wenige cm von der
Anzeige entfernt platziert wird und nur ungefähr in Richtung Mainflingen
ausgerichtet ist.
Empfänger siehe hier:
Beitrag "Re: Reichelt DCF77-Empfänger"
Gruß
John
John schrieb:> Mit einem Filter in der Versorgungsspannung (C1, R2) gab es keine> Störungen mehr.
Ok, dann platziere einen (Laptop) Schaltnetzteil in die Nähe vom
Empfängermodul :-)
Ich habe es auch so, zusätzlich parallel zu C noch eine Zenerdiode und
Elko.
John schrieb:> Wie ist der Temperaturbereich von deinem Bürk-Modul. Hast du ein> Datenblatt. Ich kann online nichts finden.
Hi,
habe nur das an Info noch gefunden. (Das Modul hat Bauteile nach
MIL-Norm eingebaut.)
Beitrag "Re: Trennstufe für DCF Modul gegen Schwingen ?"
Man sieht, der Empfänger ist ursprünglich für die Bahnuhren konzipiert.
Die Detailinformationen und Preisanfragen sollten ausschließlich über
die Kundendienstadresse laufen.
https://www.buerk-mobatime.de/pages/Kontaktform/
ciao
gustav
Ozvald K schrieb:> Ok, dann platziere einen (Laptop) Schaltnetzteil in die Nähe vom> Empfängermodul :-)
Ist das genug "in der Nähe"?
Vorne in der Mitte ist der DCF-Empfänger. Direkt dahinter die Uhr mit
LED-Multiplexanzeige.
Es hat etwas über 10 Minuten gedauert, aber die Uhr hat synchronisiert.
Gruß
John
900ss D. schrieb:> Der Status hier hat aber noch nichts mit dem Positionfix zu tun. Die> Position kann noch ungültig sein obwohl der Status auf 'A' steht. Die> Zeit in dem RMC-Datensatz ist dann aber gültig.
Das kann nicht sein. Woher soll der Empfänger die genaue Zeit kennen,
wenn er nicht weiss, wo er ist?
Eine Aussage über die Genauigkeit liefert erst der TDOP- bzw. GDOP-Wert.
Insofern ist für die Bewertung der Genauigkeit eher der GSA-Sentence
geeignet.
Manfred schrieb:> "DATA ist current source/sink mit Iout > 5 µA."
Da haben die sich doch im DB vertan und < mit > verwechseln, oder muss
der Strom wirklich größer sein als 5µ, aber dann müßte ja auch der max.
angegeben sein....
Bernd D. schrieb:> Manfred schrieb:>>> "DATA ist current source/sink mit Iout > 5 µA.">> Da haben die sich doch im DB vertan und < mit > verwechseln, oder muss> der Strom wirklich größer sein als 5µ, aber dann müßte ja auch der max.> angegeben sein....
Das passiert oft, denk' dir nichts...
John schrieb:> Ist das genug "in der Nähe"?
ok, aber da spielen mehrere Faktoren mit. Der Filter in der Versorgung
filtert den Mist aus der Versorgung aus, aber nicht die em-Strahlungen
von einem Schaltnetzteil was die Ferritantenne aufnimmt.
Bernd D. schrieb:> Da haben die sich doch im DB vertan und < mit > verwechseln, oder muss> der Strom wirklich größer sein als 5µ, aber dann müßte ja auch der max.> angegeben sein....
Der Ausgang ist hochohmig und verträgt keine Belastung. Es reicht aber
eine Minimalbeschaltung um Modul herum, siehe Beitrag von John.
Habe kurzfristig versucht mit einem OpAmp als Impedanz- und Pegelwandler
+ LED Treiber, aber der LM358 ist dafür nicht geeignet, weil: 1.kann
kein Rail to Rail und bei 5V Versorgung gibt keinen höheren Pegel aus
was das Signal eh schon hat (3v), und 2. intern ist frequenzkompensiert,
dadurch war die Anstiegszeit der Flanke am Ausgang viel schlechter.
(~10µS)
Wilhelm M. schrieb:)
> Ich benutze dafür nur noch die GPS-Module mit der kleinen Antenne (5x15mm).> Das reicht eigentlich immer und man bekommt die Uhrzeit per UART.
Hast du da einen Typ, Hersteller, Lieferanten? Danke :-)
Ozvald K schrieb:> Wenn der Tiefpassfilter die Jitters auch weiter reicht (und ich vermute,> ja)
Hallo Ozvald,
dass der Tiefpassfilter den Jitter verbessert, glaube ich auch nicht.
Der Jitter wird eher noch größer werden, da das Signal im 3,3 msec
Raster abgetastet wird. Mit dem von Dir dargestellten Signal wird der
Filter sicher nicht fertig, dazu liegen die Störimpulse zu dicht am
100msec Nutzsignal. Kurze Spikes werden schon entfernt.
Auch ich habe meine eigene DCF-Uhr gebaut, einfach weil es mir Spaß
gemacht hat. Obwohl es genug fertige und sicher auch bessere Vorschläge
gibt. Eine Rückmeldung zu meinen DCF-Programm habe ich lustigerweise mal
aus .at erhalten. Dort hat es in 700km Entfernung gut funktioniert.
Mein DCF-Prg. zählt einfach nur die Dauer der Pausen aus. Also 800msec,
900msec und die 1800msec bis 1900mse aus. Ist einfacher auszuwerten.
Vorgeschaltet ist ein 3.stufiges Schieberegister. Erst wenn 3 gleiche
Samples im Register sind, wird auf 0 oder 1 erkannt. Also Mindestbreite
= 60msec. da das Signal in 20msec Abstand abgetastet wird.
Interessant sind die verschiedenen Lösungsansätze, dabei kann man noch
einiges lernen.
Gruß Alex
Wolfgang schrieb:>> (M)ein GPS-Empfänger möchte schon bei gutem Wetter auf der Fensterbank>> innen sein Bit "Stabile Zeit" nicht setzen.> Kannst du das mal in NMEA0183 ausdrücken oder wo liest du so ein Bit bei einem
GPS-Empfänger ab?
Lange ist's her ... ich suche jetzt nach und finde es im Datenblatt des
CXD2951 auf Seite 41 "Data valid / Data invalid"
oder in AN07NMEA183-010 auf Seite 23.
Spielobjekt war eine GPS-Maus Navilock NL-208P mit serieller
Schnittstelle.
Was ist beim DCF77 faul?
Seit gut zwei Wochen sehe ich des öfteren, dass meine Uhr keinen Empfang
hat.
Ich gucke dann auf https://dcf77logs.de/live und sehe, dass auch dort
keine Decodierung möglich ist. Der Kerl sitzt etwa 200km nördlich von
mir, damit kann ich eine lokale Störung bei mir sicher ausschließen.
Meine auch, ca. 500km nördlich von Frankfurt.
Ich habe abends auch oft Empfangsstörungen bei der Uhr. Ist wohl normal
durch atmosphärische Störungen. Ist schon seit 12 Jahren so :) Im Sommer
weniger.
Letzte Nacht war der Sender für einige Zeit komplett aus. Ich konnte
beobachten, dass er wenige Sekunden vor 23 Uhr wieder gesendet hat. In
den ersten paar Minuten gab es noch einige Aussetzer.
Laut PTB ist eine Ursache für längere Unterbrechungen Sturm, Eisregen
und Schnee.
https://www.ptb.de/cms/ptb/fachabteilungen/abt4/fb-44/ag-442/verbreitung-der-gesetzlichen-zeit/dcf77/verfuegbarkeit-und-empfangsberechtigung.html
„Die häufigste Ursache für diese länger andauernden Unterbrechungen war
die elektrische Verstimmung des Antennenresonanzkreises durch Auslenkung
der Antenne in starkem Sturm, bei Eisregen und Schnee. Bei zu großer
Fehlanpassung wird die Aussendung unterbrochen.“
Gruß
John
Hi,
kann noch ein paar ältere Direktmischer-Audioaufnahmen beisteuern.
Da arbeitete noch der HBG in der Schweiz, daher zwei Differenztöne im
Trägerabstand zu DCF77.
Das gute Signal bringt auch noch einen Überschwinger. Das ist
offensichtlich ein "Filterartefakt". Man hört auch die Extra-Zufallsbits
als Rauschen.
Das als schlecht bezeichnete Signal enthält die HF-Überlagerung eines
Schaltnetzteils mit Lastausregelung. Hier ist keine Decodierung mehr
möglich, wenngleich die Sekundenmarken als diskreter Pfeifton akustisch
neben den "jitternden" Pfeif-Störungen noch wahrnehmbar bleiben.
ciao
gustav
Ich fasse das alles mal zusammen:
- Gegen Breitbandstörer wie chinesische Schaltnetzteile ist kein Kraut
gewachsen, nur gehöriger Abstand.
- Wer außer dem Antennenkreis keine weitere Selektion hat, nimmt den
vierfachen Abstand zum Störer.
- Gegen schlechten Empfang und Rauschen ist schon ein Kraut gewachsen:
ordentlich HF-Verstärkung. Wer mit einem FET im Antennenkreis (ohne
Verstärkung) und einem Transistor (mit Verstärkung) was Anständiges
empfangen will, kriegt halt in 500 km Entfernung nicht so arg viel
HF-Signal. Was heutzutage sich so alles AM-Empfänger nennt, ist oft
nicht viel mehr als ein besserer Germanium-Detektor.
- In allen Diagrammen, die hier gepostet wurden, waren ganz saubere
Rechtecke zu sehen. Wer da statt eines simplen INT noch (Over-)Sampling
macht, hat es nicht anders verdient. Lässt man einen 16-Bit-Timer mit
z.B. 1 ms Takt laufen, liest den bei jedem INT ab und setzt ihn dann
wieder auf Null, der hat schon alles, was er braucht. Wenn man im INT
noch alles ignoriert, was kürzer als z.B. 10 ms ist, braucht sich auch
um Rauschen und spurious signals nicht mehr zu scheren.
- Ist die gemessene Signaldauer irgendwo um 100 ms, ist es eine Null,
ist es irgendwo bei 200 ms eine Eins, ist es zwischen 800 und 900 ms ist
es ein Sekundenzwischenraum und ist es zwischen 1800 und 1900 ms lang
ist es ein Minutensignal. Alles was in dieses Schema (mit etwas Toleranz
nach oben und nach unten) nicht reinpasst, ist HF-Schrott. Ob das Signal
high- oder low-aktiv ist, ist dann auch egal, wenn man bei jeder Flanke
einen INT auslöst.
- Überstehen alle eingegangenen Signale diese Prüfung ihrer Dauer, sind
zum Minutenwechsel genau 59 Signale eingegangen und prüft man alle Einer
ob sie nicht mehr als Neun sind, alle Zahlen ob sie nicht mehr als im
zulässigen Bereich sind (beim Tag und beim Monat auch die Null) und alle
Paritätsbits auf Nullsumme hat man das Signal schon hinreichend
überprüft. Auf das dreimalige Abchecken, ob die Minuten genau um Eins
gewachsen sind (was sie zur vollen Stunde eh nicht tun) kann man dann
vollkommen verzichten? Einschalten, maximal zwei Minuten warten, und
alles ist perfekt.
Ich habe mir also mit einem ollen TCA440 einen Superhet mit 455 kHz ZF
gestrickt (siehe
http://www.avr-asm-tutorial.net/avr_de/apps/dcf77_m16/dcf77_superhet/dcf77_superhet.html),
der in 50 km Entfernung zu Mainflingen selbst noch innerhalb einer
Wellblechkeksdose noch genug Signal produziert und das Auswerteprinzip
in einem ATmega16 umgesetzt (siehe
http://www.avr-asm-tutorial.net/avr_de/apps/dcf77_m16/dcf77_uhr_m16.html)
und dort auch das Auswerteverfahren detaillierter beschrieben. Seither
habe ich schon in 50 cm Distanz zu meinem wild strahlenden
Lenovo-Netzteil keine Aussetzer mehr. Und die Fehlermeldungen zu
Signal-/Einer-/Paritäts-Fehler habe ich nur gesehen, wenn Lenovo daneben
lag.
Empfangsstörungen habe ich seither nur noch dann, wenn der Lautsprecher
eine Weckmelodie abspielt. Gut, der ist auch nur zwei Zentimeter weit
weg von der Empfangsantenne. Auf Entstörmaßnahmen der abgespielten
Rechtecke habe ich wegen der Seltenheit solcher Störungen verzichten
können.
mfg
gerd
Manfred schrieb:> Mit den käuflichen Empfängern wird man niemals ganz genau, bei den> Superhet-Bausteinen habe ich ein gehöriges Jittern gesehen, welches mein> Geradeausempfänger nicht hat.gerd schrieb:> Ich habe mir also mit einem ollen TCA440 einen Superhet mit 455 kHz ZF> gestrickt
Hallo Gerd,
dass du mit einer TCA440 IC besser unterwegs bist, das glaube ich gerne.
Aber was sagst zu der Aussage von Manfred? Er bevorzugt den
Geradeausempfänger. Hast du schon einen direkten Vergleich machen
können?
Alex D. schrieb:> Das DCF-Signal wird 333> mal pro Sekunde in ein 30Bit-Schieberegister geschoben. Nach jeder> Abtastung wird ausgewertet wie viel Einsen im Schieberegister stehen.> Anhand dieses Wertes wird, unter Berücksichtigung einer kleinen> Hysterese entschieden, ob eine 1 oder eine 0 ausgegeben wird.
Funktioniert PeDa's Routine nicht ähnlich? Meine ich zumindest im
Hinterkopf zu haben. Sieht wirklich gut aus :-)
Ich habe hier ein Modul von - keine Ahnung, schon recht alt aus einer
Uhr - was bei guter Ausrichtung auch gute Ergebnisse liefert. Bei sehr
schlechter Ausrichtung "stottert" das Signal.
Ich hebe den Pegel (etwas ungewöhnlich, habe ich irgendwo nachgemacht)
mit einem TCDT 1121 und glätte mit 22 pF etwas. Ergebnis anbei (bei
schlechter Ausrichtung).
Ozvald K schrieb:> dass du mit einer TCA440 IC besser unterwegs bist, das glaube ich gerne.> Aber was sagst zu der Aussage von Manfred? Er bevorzugt den> Geradeausempfänger. Hast du schon einen direkten Vergleich machen> können?
Geradeausempfänger habe ich auch schon einige gebaut. Funktionieren bei
der niedrigen Frequenz auch ganz brauchbar. Aber so etwa bei Verstärkung
von einigen 100 ist dann definitiv Schluss. Bei mir in der Nähe von
Mainflingen kann ich das DCF-Signal schon mit einigen mV im
Antennenkreis sehen, da reichen 1.000 an Verstärkung schon recht gut
aus. Das dürfte aber in 500 km Entfernung etwas anders aussehen.
Entscheidender beim Superhet ist aber die Selektion. Wenn man keine
Quarzfarm mit 77,5 kHz bauen will, hat so ein Keramikteil mit 455 kHz so
seine Vorteile. Und man ist den ganzen Schrott unter 70 kHz und über 90
kHz los, den Schaltnetzteile so produzieren.
mfg
gsc
Hi,
der "Gude" hatte im Frankfurter Raum im Display stehen "Resonanzfall".
https://www.gude.info/fileadmin/user_upload/pdf/sb/steckbrief-emc3001-3011.pdf
(Innen jede Menge Siferrit-Schalenkerne.)
Das deutet darauf hin, dass eine Pegelanpassung je nach Standort nötig
ist. Entweder erfolgt die automatisch, oder die Antenne wird
"rausgedreht".
Man ist ja bei Geradeausempfängern je höher die Verstärkung wird, der
Gefahr der Rückkopplung ausgesetzt. Daher wurde ja auch das
Superhetprinzip favorisiert. Hat aber auch Nachteile. Die Mischprodukte
zum Beispiel.
Das geht mit entsprechenden Filtern dann ganz gut, eine
Spiegelfrequenzselektion hinzubekommen. Jedenfalls besser als
gerd schrieb:> Wenn man keine> Quarzfarm mit 77,5 kHz bauen will.
Gerade diese Quarze haben auch Einschwingvorgänge. Bei "normalem"
Rundfunk würde das wohl nicht so viel ausmachen, hier will man möglichst
saubere Schaltflanken.
Bei Superhets: Nur die Frequenz des Mischer-Oszillators müsste möglichst
driftfrei sein. (Quarzofen)
ciao
gustav
Karl B. schrieb:> Gerade diese Quarze haben auch Einschwingvorgänge. Bei "normalem"> Rundfunk würde das wohl nicht so viel ausmachen, hier will man möglichst> saubere Schaltflanken.> Bei Superhets: Nur die Frequenz des Mischer-Oszillators müsste möglichst> driftfrei sein. (Quarzofen)
Für normalen Rundfunk ist ein so schmalbandiges Filter nicht zu
gebrauchen. Auch der normale CW Morsecode ist eher schneller als das DCF
Signal.
Mit dem LO muss man es nicht übertreiben, wenn man das Signal nicht
phasenstar auswertet. Wenn man das macht dann wohl um die 77,5 kHz
Trägerfrequenz zu gewinnen, und dann hat den stabilen Takt für den LO,
in der Regel dann wohl als VCXO.
Ein normaler Quarz für den LO-Takt ist vollkommen ausreichend. Das ist
immer noch stabiler als die 455 kHz ZF Filter.
Um den Takt der Quarzuhr zu korrigieren würde ich nicht das
Sekundensignal selber nutzen, sondern eher die Zeitkorrektur von Tag zu
Tag.
Karl B. schrieb:> Man ist ja bei Geradeausempfängern je höher die Verstärkung wird, der> Gefahr der Rückkopplung ausgesetzt.
Um Rückkopplungen zu vermeiden, habe ich die Feriitantenne mit dem
1.Transistor ca. 1m vom Empfänger aufgestellt und richte die Antenne
mittels Oszi auf maximale Amplitude. Entfernung zum Sender: ca. 350km
DCF.jpg
(480 KB)
