mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik DCF77 Auswertung (ein bisschen anders)


Autor: Ozvald K (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Peter D. (peda)
Datum:

Bewertung
5 lesenswert
nicht lesenswert
Ozvald K schrieb:
> Nach einer positiven Flanke an INT0

Meine Erfahrung ist, daß ein externer Interrupt zu störempfindlich ist. 
Ich polle daher im Timerinterrupt:
Beitrag "DCF77 Uhr in C mit ATtiny26"

Autor: Ozvald K (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Alex D. (allu)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Alex D. (allu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Karl B. (gustav)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

: Bearbeitet durch User
Autor: Ozvald K (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Ozvald K (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 :-)

Autor: oszi40 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Peter D. (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ozvald K schrieb:
> Übrigens,bei mir läuft das ganze mit einem TINY13.

Beitrag "DCF77-Uhr mit ATTINY12"

Autor: Alex D. (allu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Ozvald K (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Manfred (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Ozvald K (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jacko (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Alex D. (allu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: wolle g. (wolleg)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Karl B. (gustav)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

: Bearbeitet durch User
Autor: Stefanus F. (stefanus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Karl B. (gustav)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

: Bearbeitet durch User
Autor: Jacko (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Manfred (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Ozvald K (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Rolf N. (rolfn)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielleicht auch von Interesse: 
https://blog.blinkenlight.net/experiments/dcf77/

...Rolf

Autor: Karl B. (gustav)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Alex D. (allu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Karl B. (gustav)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

: Bearbeitet durch User
Autor: Alex D. (allu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: wolle g. (wolleg)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Alex D. (allu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: wolle g. (wolleg)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: allu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Ozvald K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Manfred (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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."

Autor: Jacko (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Ozvald K (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Karl B. (gustav)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

: Bearbeitet durch User
Autor: HyperMario (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Ozvald K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Ozvald K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Ozvald K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
HyperMario schrieb:
> Z.B.:
> DCF ist ein 60 Hz Signal.

Das passt schon nicht, 60 Zustände pro Minute höchstens, aber 1 Bit pro 
Sekunde

Autor: Thomas W. (Firma: privat) (diddl)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Thomas W. (Firma: privat) (diddl)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Naja, okay, du hast recht, es wird nur ein Bit übertragen pro Sekunde 
...

Autor: Karl B. (gustav)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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 (!)

: Bearbeitet durch User
Autor: Jacko (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Ozvald K (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Ozvald K (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ah ja, alle grammatischen Fehler bitte ignorieren. Deutsche Sprache 
schwere Sprache :-)

Autor: Ozvald K (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: HyperMario (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: HyperMario (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Tim (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Wilhelm M. (wimalopaan)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Ozvald K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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"...

Autor: Lurchi (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: HyperMario (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: wolle g. (wolleg)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Bauform B. (bauformb)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Karl B. (gustav)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

: Bearbeitet durch User
Autor: Karl B. (gustav)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

: Bearbeitet durch User
Autor: Alex D. (allu)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Dirk W. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Ozvald K (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Stefanus F. (stefanus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stelle den Empfänger mal neben einen WLAN Router.

Autor: 900ss D. (900ss)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ;)

: Bearbeitet durch User
Autor: Ozvald K (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 :-)

Autor: Alex D. (allu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jacko (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Karl B. (gustav)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: John (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Karl B. (gustav)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

: Bearbeitet durch User
Autor: Bauform B. (bauformb)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Manfred (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Alex D. (allu)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: G. H. (schufti)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Wolfgang (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: 900ss D. (900ss)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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':
$GPRMC,081836,A,3751.65,S,14507.36,E,000.0,360.0,130998,011.3,E*62
$GPRMC,225446,A,4916.45,N,12311.12,W,000.5,054.7,191194,020.3,E*68

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.

: Bearbeitet durch User
Autor: Ozvald K (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Bauform B. (bauformb)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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)?

Autor: Ozvald K (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Ozvald K (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
..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.

Autor: John (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Karl B. schrieb:
> Hi, bin mir ziemlich sicher, dass die anderen Module die klimatischen
> Einflüsse nicht lange mitgemacht hätten.

Das Reichelt-Modul ist für -10°C…+70°C spezifiziert:
https://www.reichelt.de/dcf-77-empfaengermodul-dcf77-modul-p57772.html?

Bei Reichelt gibt es auch dieses Modul (–20°…+50°C):
https://www.reichelt.de/dcf-77-funkempfaenger-hm-fu20-00-p174059.html?
Zwei-Draht und polaritätsunabhängig zum halben Prei (Vergleich zu Bürk).

Wie ist der Temperaturbereich von deinem Bürk-Modul. Hast du ein 
Datenblatt. Ich kann online nichts finden.

Autor: John (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Ozvald K (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Karl B. (gustav)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

: Bearbeitet durch User
Autor: John (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Wolfgang (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Bernd D. (bernd_d56) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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....

Autor: Bauform B. (bauformb)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wolfgang schrieb:
> Das kann nicht sein. Woher soll der Empfänger die genaue Zeit kennen,
> wenn er nicht weiss, wo er ist?

Ich wäre dafür, dass wir mit den GPS-Feinheiten umziehen:
Beitrag "GPS- statt DCF77-Auswertung (ein bisschen anders)"

Autor: Bauform B. (bauformb)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Stefanus F. (stefanus)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Dass soll heissen, dass der Ausgang mindestens mit 5µA belastbar ist. 
Wenn du Glück hast, funktioniert er auch mit mehr Strom.

Autor: Ozvald K (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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)

Autor: 900ss D. (900ss)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
John schrieb:
> Direkt dahinter die Uhr mit LED-Multiplexanzeige

Die schönste Uhr mit LED-Matrix im Universum ;)
Super gemacht.

Autor: Crazy H. (crazy_h)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 :-)

Autor: Alex D. (allu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Manfred (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Manfred (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Stefanus F. (stefanus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Meiner Uhr hat gerade Empfang (Düsseldorf).

: Bearbeitet durch User
Autor: 900ss D. (900ss)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
Autor: John (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: John (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Die Beiden Signal habe ich letzte Nacht aufgenommen:

DCF77_Ausfall.mp3      -> 22:50 Uhr
DCF77_Auido-Signal.mp3 -> 23:05 Uhr

Gruß
John

Autor: Karl B. (gustav)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: gerd (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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

Autor: Ozvald K (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Dieter F. (jim_quakenbush)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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).

Autor: gerd (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Karl B. (gustav)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Lurchi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: wolle g. (wolleg)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.