Im Internet findet man viele Schaltpläne für DCF77-Empfänger, bei denen
aber verglichen mit Fertigmodulen recht viel verbaut wurde. Bastler
fehlt halt der Zugang zum nötigen Spezialquarz mit der richtigen
Frequenz und Güte. Meine Idee war nun, ein dem Fertigmodul ähnliches
Funktionsprinzip durch Software auf einem ATTINY85 nachzubilden (SDR).
#### Hardware
Die Elektronik für einen Mischer, Demodulator u.s.w. entfällt, da der
ATTINY direkt das Antennensignal erhält. Etwas Elektronik ist aber
trotzdem nötig, da das Antennensignal für den ADC sonst zu schwach wäre.
#### Empfängercode
Die Frequenz vom Spezialquarz kann per Bresenham-(artigen)-Algorithmus
zeitsparend aus dem Controller-Takt hergeleitet und die Güte
(7750=77500Hz/10Hz) kann bei geeigneter ADC-Frequenz durch plumpes
Summieren von ADC-Werten erzielt werden. Eine geeignete ADC-Frequenz
(fADC=fDCF/(1.25+n/2)) wäre 62000Hz. Das Bild "03 Filter.png" zeigt die
Dämpfungsfunktion des "Software-Spezialquarzes". Zum Vergleich zeigt die
rote Linie die Dämpfung einer normalen DCF77-Ferritantenne (Güte 100).
Die Güte der Ferritantenne ist trotzdem wichtig, da der Verstärker durch
fremde Signale sonst völlig übersteuern würde.
#### Auswertung
Im Prinzip wäre der Empfänger nun fertig. Wie man am (internen)
Ausgangssignal in Bild "04 DCF77.png" sieht, ist der Verlauf aber
"andersartig", was an der höheren Güte des Softwarefilters liegt. Die
Qualität wird dadurch zwar optimal, die Auswertung muss aber anders
erfolgen: Dazu verwendet wurde ein Histogramm über eine Sekunde, welches
fließend aktualisiert wird. Nach einigen Sekunden "schiesst" sich der
ATTINY auch bei sehr schlechtem Signal zuverlässig auf den genauen
Zeitpunkt (blaue Linie) der Sekundenmarke ein.
Der DCF-Bitwert kann anschließend einfach bestimmt werden, indem genau
100ms (rote Linie) nach der Sekundenmarke die Amplitude mit einem
Schwellwert (grüne Linie) verglichen wird. Der Schwellwert beträgt dabei
58% (=(100%+15%)/2) der mittleren Trägeramplitude. Vom Bild her scheint
der Schwellwert falsch zu sein, das liegt aber nur an der
logarithmischen Darstellung.
#### ATTINY-Ausgangssignal
Zum einem werden wie beim Fertigmodul die DCF-Impulse ausgegeben.
Zusätzlich gibt es noch einen Ausgang für UART-Daten:
#00113 | dPPM: 0 | ADC: -43.6 db | Noise: 0.0 db | Bits: 00 | Date:
Do, 23.12.2021 19:46:03 MEZ - 1 ValidCount
#00114 | dPPM: 0 | ADC: -43.6 db | Noise: 0.0 db | Bits: 00 | Date:
Do, 23.12.2021 19:46:04 MEZ - 1 ValidCount
#00115 | dPPM: 0 | ADC: -43.6 db | Noise: 0.0 db | Bits: 00 | Date:
Do, 23.12.2021 19:46:05 MEZ - 1 ValidCount
#00116 | dPPM: 3 | ADC: -43.6 db | Noise: 0.0 db | Bits: 00 | Date:
Do, 23.12.2021 19:46:06 MEZ - 1 ValidCount
#00117 | dPPM: 3 | ADC: -43.6 db | Noise: 0.0 db | Bits: 00 | Date:
Do, 23.12.2021 19:46:07 MEZ - 1 ValidCount
#00118 | dPPM: 0 | ADC: -43.5 db | Noise: 0.0 db | Bits: 00 | Date:
Do, 23.12.2021 19:46:08 MEZ - 1 ValidCount
#00119 | dPPM: 0 | ADC: -43.5 db | Noise: 0.0 db | Bits: 00 | Date:
Do, 23.12.2021 19:46:09 MEZ - 1 ValidCount
#00120 | dPPM: 0 | ADC: -43.5 db | Noise: 0.0 db | Bits: 01 | Date:
Do, 23.12.2021 19:46:10 MEZ - 1 ValidCount
#00121 | dPPM: 0 | ADC: -43.5 db | Noise: 0.0 db | Bits: 01 | Date:
Do, 23.12.2021 19:46:11 MEZ - 1 ValidCount
#00122 | dPPM: 3 | ADC: -43.5 db | Noise: 0.0 db | Bits: 00 | Date:
Do, 23.12.2021 19:46:12 MEZ - 1 ValidCount
- dPPM-Wert
Der dPPM-Wert zeigt die Abweichung vom ATTINY-Quarz an. Bei 60 PPM ist
der Empfang nur 3 dB schlechter, bei 120 PPM bereits mehr als 20 db. Der
Empfänger sollte gegebenenfalls kalibriert werden (s. "fCrystal_PPM" in
"dcf.h").
- ADC-Wert
Der Wert gibt die Trägeramplitude am ADC-Eingang (nicht am
Schwingkreis!) an. Beim Wert von 0 db würde das Trägersignal den
ADC-Bereich (d.h. Uss=VCC) voll ausschöpfen.
- Noise
Bei 0.9 db ist Fehlerqoute für eine Dekodierung noch völlig problemlos.
Bei 1.1 dB wird es bereits sehr schwierig.
#### Praxistauglichkeit
Der Empfänger ist eindeutig störungsunempfindlicher als meine
Tchibo-DCF-Uhr. Der Unterschied ist aber eher marginal: Statt 33cm
Abstand dürfen es dann 28cm sein. Die maximale Senderreichweite hängt
vom Verstärker und der Antenne ab. Der ATTINY benötigt mindestens ein
Signal von -66 dB was einem Ueff von 0.6mV (=10^(-66/20)/2/sqr(2)*3.3V)
entspricht. Vor dem Verstärker (1000x) wäre dann ein Ueff von 0.6µV
nötig. Mit der Empfindlichkeit der blauen Speicherdrossel (Bild) von 2.5
mV/(V/m) ergibt sich eine Mindestfeldstärke von E=0.00024 V/m bzw. 48
db(µV/m). Nach dem PTB-Diagramm würde die blaue Drossel also bis 1000 km
Entfernung reichen. Würde man eine normale DCF77-Antenne verwenden, dann
wäre das Signal etwa 12 dB höher und man hätte eine Reserve für einen
stabilen Betrieb. Eigentlich wäre das Signal sogar nochmals 12 dB
größer, wenn da nicht der schlechte Verstärker (kleiner
Eingangswiderstand) wäre.
#### Entfernungstest
Der Empfang vom britischen Zeitzeichensender MSF 60 in 750km statt 270km
Entfernung war auch möglich. Der Empfang ist aber nicht so gut wie man
nach dem Bild "05 MSF60.png" meinen könnte. Es reicht die
Speicherdrossel um 60° zu drehen (also 6 dB Schwächung) um in die Nähe
der Empfangsgrenze zu kommen. Außerdem sind die natürlichen täglichen
Signalschwankung (10 dB) so hoch, dass man auch bei richtiger
Ausrichtung nicht immer ausreichend Empfang hat. Das wäre mit einer
normalen DCF77-Antenne vermutlich anders.
#### Fazit
Es geht, macht aber bei 5 Euro für ein Fertigmodul keinen Sinn.
Franz schrieb:> Der Empfänger ist eindeutig störungsunempfindlicher als meine> Tchibo-DCF-Uhr. Der Unterschied ist aber eher marginal: Statt 33cm> Abstand dürfen es dann 28cm sein
Abstand zu was? Zum Sender? ;-)
Franz schrieb:> Meine Idee war nun, ein dem Fertigmodul ähnliches> Funktionsprinzip durch Software auf einem ATTINY85 nachzubilden (SDR).
Schönes Projekt, gefällt mir.
Franz schrieb:> Es ist der Abstand der Antenne zur linken CCFL-Monitor-Kante.
Ah, ok :-)
> Viel Aussagekraft hat der Test natürlich nicht.
Nach meiner Erfahrung werden die CCFL-Röhren mit 50 kHz betrieben.
Wie hast Du die Anpassung an MSF60 gemacht?
Vielleicht kannst Du mal bei 50 kHz schauen, wie hoch der Pegel ist.
Ansonsten: Schöne Arbeit!
Franz schrieb:> #### Fazit> Es geht, macht aber bei 5 Euro für ein Fertigmodul keinen Sinn.
Man kann noch ein paar Bauteile weglassen: Quartz, C6, C7. Zur
Kalibrierung der Zeitbasis für die serielle Schnittstelle die fallende
Flanken des Sekundensignals nehmen. Statt ATTiny85 ATTiny13 nehmen und
schon bist DU bei 4,95 Euro.
Bernd schrieb:> Franz schrieb:> Nach meiner Erfahrung werden die CCFL-Röhren mit 50 kHz betrieben.
Ich weiß nicht ob die Störungen vom TFT-Schirm, vom CCFL-Netzteil oder
von den Röhren kommen. Ich meine auf dem Oszi sogar eine extrem
ungünstige Frequenz von etwa 77kHz gesehen zu haben.
> Wie hast Du die Anpassung an MSF60 gemacht?
Beim MSF60 wird der Sender bis zu 500ms (statt 200ms) je Sekunde in der
Leistung herabgesetzt. Das ist bei der Bestimmung der Trägeramplitude
unbedingt (wg. Schwellwert) zu berücksichtigen.
Ein weiterer Unterschied ist nur die andere ADC-Frequenz.
Glücklicherweise hat man auch bei 60kHz die benötigten gemeinsamen
Teiler 5 und 250. Der Code wäre sonst ein klein wenig aufwändiger aber
damit zu langsam für einen 10MHz Controller-Takt.
> Vielleicht kannst Du mal bei 50 kHz schauen, wie hoch der Pegel ist.
Wegen Corona habe ich viel Zeit. Ich versuche mir das mal anzusehen.
> Ansonsten: Schöne Arbeit!
Danke!
Saubere Arbeit. Anstelle des diskreten Antennenverstärkers würde ich
einen Dual-OP-Amp vorschlagen, z.B. TS922. Damit erreichst Du dann auch
einen hochohmigen Eingang.
Olaf schrieb:> Man kann noch ein paar Bauteile weglassen: Quartz, C6, C7.
Ohne C6, C7 habe ich es bereits probiert. Ich brauchte einen
Kalibrierwert von 505 PPM. Erst als plötzlich ein Wert von über 600 PPM
nötig war, habe ich den Fehler bemerkt. Ein Wackelkontakt - lag wohl am
alten Lötzinn. ;-)
> Statt ATTiny85 ATTiny13 nehmen
Wenn ich da Hoffnung gehabt hätte, wäre es ganz sicher ein ATTiny13
geworden. Aber mit einem ATTINY85 war es bereits sehr eng. Ich musste
sogar das Histogramm in grob und fein trennen um SRAM zu sparen. Wenn
man sonst nur mit STM32s arbeitet ist es mit einem ATTINY so, als ob man
einen Keller mit einer Schippe ausheben würde.
> 4,95 Euro
Man könnte auch einen China-STM32F030F4P6 für 50 Cent nehmen. Der hat
sogar genug Resourcen um die phasenkodierten DCF77-Daten auszuwerten:
Billiger,
empfindlicher und störungsunempfindlicher.
Franz schrieb:> Man könnte auch einen China-STM32F030F4P6 für 50 Cent nehmen. Der hat> sogar genug Resourcen um die phasenkodierten DCF77-Daten auszuwerten:> Billiger,> empfindlicher und störungsunempfindlicher.
Meiner Rechnung nach sollte auch ein etwas neuzeitlicherer Tiny (also
einer der XMega-Erben mit Hardware-Multiplikation) dafür ausreichen. OK,
es ist etwas knapp, aber machbar.
Der Vorteil wäre: Man gewinnt viele Freiheiten.
Batterie/Akku-Betrieb->kein Problem, 5V-Ausgang benötigt->auch kein
Problem. Und auch die Integration einer Quarz-"Gangreserve" ist damit
kein Problem.
chris_ schrieb:> Die Schaltung finde ich wirklich interessant.> Welche Werte haben den Lxx und Cxx? Bei der Spule sehe ich die größte> Schwierigkeit.
Bei C<10nF (bzw. L>1000µH) wird der Resonanzwiderstand relativ groß. Ein
beträchtlicher Teil der Spannung wird deshalb vom niederohmigen
Verstärker einfach vernichtet (wäre schade). Solche Schwingkreise
(übliche DCF77-Ferritspulen) sind aber optimal, wenn man die erste Stufe
durch eine hochohmige FET-Stufe (oder ähnliches) ersetzt.
Bei C>100nF (bzw. L<100µH -> kleine Speicherdrossel) reicht das Signal
nur bei sehr geringer Senderentfernung.
Welche Freiheiten man da hat, hängt von der Senderentfernung ab. Bei
großen Senderentfernungen oder bei kleinen Spulen ist der gute Abgleich
der Resonanzfrequenz sehr wichig.
Mark S. schrieb:> TS922
Man findet Transistoren überall und die primitive Schaltung hat auch
Vorteile. Fast unabhängig von den Umständen (Betriebsspannung,
Temperatur, ...) erhält zuverlässig das gleiche (schlechte) Ergebnis.
Also Qualität! :-)
Der TS922 steht nun auf meiner Bestellliste. Die Daten (Rail-to-rail,
2.7V, ...) klingen gut. Danke!
@c-hater
Ich kenne die Microchip-Typen der letzten Jahre nicht - bin also wieder
Neuling. Auch wenn ich sicherlich bei STM32 bleiben werde, welchen Typen
hast du da konkret im Sinn?
Franz schrieb:> Ich kenne die Microchip-Typen der letzten Jahre nicht - bin also wieder> Neuling.
Naja, wenn du auch noch die alten XMegas kennst, bist du nicht wirklich
Neuling. Deren Kern und deren Peripherie erben im Wesentlichen die
neueren Tinys, Megas und AVRxxxD...
Der Unterschied zu den ollen XMegas ist vor allem das, was sie auch
gegenüber den STM32 auszeichnet: der weite mögliche Bereich der
Versorgung (1.8..5.5V). Das macht sie viel flexibler einsetzbar.
Zusätzlich gibt es auch noch einige weitere Gimmicks geringerer
Bedeutung.
Der wesentliche Unterschied der neuen Tinys im Vergleich zu den
klassischen ist die Verfügbarkeit der Hardware-Multiplikation, was
natürlich inbesondere für alle Anwendungen im Bereich der
Signalverarbeitung einen extrem signifikanten Vorteil bringt.
> Auch wenn ich sicherlich bei STM32 bleiben werde, welchen Typen> hast du da konkret im Sinn?
Für deine konkrete Anwendung wäre ganz klar der ATtiny814 der "best
match". Es sei denn, man braucht mehr Space für Lookup-Tabellen, da käme
dann der 1614 in Frage, der doppelt so viel Flash und viermal so viel
SRAM bietet wie der 814.
MaWin schrieb:> Sehr schön! Gefällt mir sehr gut.> Top Arbeit.
Da kann ich nur zustimmen! Minimaler Hardwareaufwand und schlaue
Software.
Das Projekt eignet sich für mich super um mich in SDR reinzufuchsen. Den
Lötkolben für itsashame_2 würde ich aber gerne noch stecken lassen :-)
und lieber dort einsteigen, wo die Luft schon etwas dünner wird:
"(fADC=fDCF/(1.25+n/2))".
Hast du vielleicht aus Vorversuchen noch Abtastwerte (DCF77) bei höheren
Abtastfrequenzen (ca. 200kHz), die du netterweise als Datei zur
Verfügung stellen könntest? Dann könnte ich mich langsam an die
Unterabtastung und das Filter rantasten. Am meisten Spaß macht es immer,
wenn man sich Schritt für Schritt durchkämpft. Dann bleibt es bis zum
Schluss spannend ;-)
Eigentlich werden hier nur die beiden Fourier-Koeffizienten für die
Frequenz von 77500Hz und den ADC-Werten über 100ms berechnet.
Normalerweise würde man auf die ADC-Werte noch eine besondere
"Fensterfunktion" (Wikipedia) anwenden. Hier wurde aus mehreren Gründen
darauf verzichtet (bzw. das Rechteck-Fenster angewendet). Die Rechnung
bleibt deshalb einfach:
(Prinzip)
a = Summe aus ADC(tSample)*cos(2*pi*fDCF77*tSample)
b = Summe aus ADC(tSample)*sin(2*pi*fDCF77*tSample)
Die Amplitude hinter dem 10Hz-Filter beträgt dann:
Amp_Filter = sqrt(a*a+b*b)
Um nicht den ATTINY zu überfordern kann man die Sample-Zeitpunkte
sinnvoll wählen. Bei fADC=fDCF/(1.25+n/2) bleibt von den sin()- und
cos()-Werten nur eine +1, -1 oder eine 0 übrig.
Noname schrieb:> Das Projekt eignet sich für mich super um mich in SDR reinzufuchsen.
Es ist leider nur ein sehr spezieller Sonderfall (minimalst SDR?). Offen
gesagt habe ich keine Ahnung von SDR. Ob es beim Einstieg hilft, weiß
ich nicht.
> Hast du vielleicht aus Vorversuchen noch Abtastwerte
Die habe leider nicht, weil keine benötigt wurden.
Noname schrieb:> SDR reinzufuchsen
Ein RTL-USB-Stick (z.B. RTL2832U) könnte ein Must-have beim SDR-Einstieg
sein. Einfach nur die "rtl-sdr.h" inkludieren und man hat Zugriff auf
die Konfiguration und die ADC-Rohdaten.
Franz schrieb:> Der hat> sogar genug Resourcen um die phasenkodierten DCF77-Daten auszuwerten:
Die Implementierung eines Phasendekoders wäre auch sehr interessant!
Wenn du da mal was zeigen könntest oder andiskutieren könntest, das wäre
dann Weihnachten und Ostern zusammen.
In der SW sind einige interessante Ideen ... die ich jetzt tiefer
betrachten werde und bestimmt in andere Projekte übernehmen kann.
Endlich wieder ein interessantes Projekt und nicht der überliche Mist.
Danke!
Da muss ich etwas ausholen:
Mein mikrocontroller.net-Benutzername ist "DanielV2". Es ist der Name
eines früheren Arbeitskollegen der mir bei der Anmeldung - aus negativen
Gründen - spontan einfiel. Deshalb verwende ich den Account inzwischen
nur noch wenn nötig (z.B. Bearbeitungsmöglichkeit).
Apollo M. schrieb:> Weihnachten und OsternBeitrag "Ad-hoc-Frequenznormal und -Zeitzeichenempfänger"
Frohes Fest!
Franz schrieb:>> #### Fazit> Es geht, macht aber bei 5 Euro für ein Fertigmodul keinen Sinn.
Wieso?
Hast Du nichts gelernt dabei?
Hat es keinen Spass gemacht?
Hattest Du keinen Erfolg?
Warum hast Du es dann gemacht?
Fragen über Fragen zu einem Interessanten Projekt.
Apollo M. schrieb:> Endlich wieder ein interessantes Projekt und nicht der überliche Mist.
Ja ganz hübsch aber leider nicht viel mehr als eine technische
Machbarkeitsstudie solange DCF77 Module z.T. deutlich günstiger kommen.
Insofern FullAck fürs Fazit
Franz schrieb:> Eigentlich werden hier nur die beiden Fourier-Koeffizienten für die> Frequenz von 77500Hz und den ADC-Werten über 100ms berechnet.
Danke dir für die Erklärung des Filters. Jetzt wird alles klarer. Den
Stick habe ich bereits zur Dekodierung eines Funksensors verwendet. War
sehr interessant, da das Protokoll nicht bekannt war. Leider braucht man
für den Stick einen Up-Converter und die Ferritantenne für das
DCF77-Signal.
In deinem Programm ist die Abtastfrequenz 62000 Hz. Ist es richtig, dass
durch aliasing das DCF77-Signal auf 15500Hz verschoben wird und
eigentlich dann ein 15500Hz-Signal ausgewertet wird?
Apollo M. schrieb:> Die Implementierung eines Phasendekoders wäre auch sehr interessant!> Wenn du da mal was zeigen könntest oder andiskutieren könntest, das wäre> dann Weihnachten und Ostern zusammen.
Genau, das wäre mal wieder ein richtiges Highlight. Kann auch gerne ein
Nucleo-Board mit STM32L4 oder G4 für 10€ anstatt ein Attiny sein :-).
Ist ja Forschung.
@Noname
Nee, das scheint nur so. Zeichne notfalls einfach mal den Verlauf von
mind. sieben Perioden des DCF77-Signals auf und trage dann die
ADC-Abtastpunkte ein.
Der Controller "sieht" eher 15500 Hz als 77500 Hz. Funktioniert aber
trotzdem. Die 77500 Hz müssen ja nicht rekonstruiert werden. Ist nur
eine Frage der Betrachtungsweise.
Danke für den Verweis auf dein Vorgängerprojekt. Es liefert viele
zusätzliche Infos.
Noname schrieb
>Der Controller "sieht" eher 15500 Hz als 77500 Hz. Funktioniert aber>trotzdem. Die 77500 Hz müssen ja nicht rekonstruiert werden. Ist nur>eine Frage der Betrachtungsweise.
Die Sache mit der Unterabtastung ist mir auch schon aufgefallen (im Code
sehe ich fs=62kHz). Ich nehme an, dass der Empfangskreis die weiter
entfernten Störer so weit weg filtert, das der Ampltude beim
zurückfalten nicht mehr stört,
Franz schrieb
>(Prinzip)>a = Summe aus ADC(tSample)*cos(2*pi*fDCF77*tSample)>b = Summe aus ADC(tSample)*sin(2*pi*fDCF77*tSample)>Die Amplitude hinter dem 10Hz-Filter beträgt dann:>Amp_Filter = sqrt(a*a+b*b)>Um nicht den ATTINY zu überfordern kann man die Sample-Zeitpunkte>sinnvoll wählen. Bei fADC=fDCF/(1.25+n/2) bleibt von den sin()- und>cos()-Werten nur eine +1, -1 oder eine 0 übrig.
Vielleicht könnte der Goertzel Algortihums helfen, wenn der Attiny 2
Multiplikationen mit 62kHz schafft ...
https://de.wikipedia.org/wiki/Goertzel-Algorithmus
Ich finde das Projekt großartig!
Als absoluter HF-Laie frage ich mich aber, ob das nicht auch noch
einfacher ginge. Mit Sicherheit übersehe ich hier irgendwas und ich wäre
froh über einen Denkanstoß eurerseits.
Ich stelle mir das so vor: Der Träger von ca 77 kHz enthält doch keine
Information, da die Information vollständig in der Amplitude (= dem sehr
sehr langsamen amplitudenmodulierten (kann man das so sagen?) Signal)
kodiert ist.
Könnte man den Träger nicht einfach irgendwie mit einer beliebigen
Frequenz von zum Beispiel 10 kHz abtasten und dann die Samples mit einem
gleitenden Mittelwert mitteln? (Mit ist klar, dass man mit der
Abtastfrequenz deutlich über der Absenkfrequenz bleiben muss)
Dann verschleifen sich die modulierten Nutzsignalflanken natürlich etwas
und diese liegen nicht mehr exakt am gesendeten Zeitpunkt, sondern je
nach Abtastfrequenz vielleicht ein paar Millisekunden verschoben.
Aber wenn einem das egal ist, sollte das nicht genau so möglich sein?
Die Absenkzeit der Amplitude ist doch um viele Größenordnungen breiter
als die Trägerperiode. Sollte das nicht möglich sein da einen trivialen
mittelwertsbildenden Algorithmus zu nutzen, der den Träger mittelt, aber
das Nutzsignal nur unwesentlich beeinflusst?
Wo ist mein Denkfehler? :)
Danke!
Franz schrieb:> Das Bild "03 Filter.png" zeigt die> Dämpfungsfunktion des "Software-Spezialquarzes".
Wo kommen die Daten für die Dämpfung her und wie wurde die Abbildung
erzeugt?
Kannst du das mal aufzeigen ... Danke!
@Noname
@chris_
Ich stimme (als Nicht-Mathematiker) einfach mal zu, dass es sich hier um
eine Unterabtastung handelt. Trotzdem sollte man den Begriff meiner
Meinung nach in diesem Fall nicht verwenden. Es ist in dem Sinne falsch,
dass er einen falschen Eindruck vermittelt: Ob ich bei einem reinen
DCF77-Trägersignal eine vierfache Überabtastung (TADC=TDCF*0.25) oder
wie hier eine 0.8 fache Unterabtastung (TADC=TDCF*1.25) mache, die
ADC-Werte sind identisch! Wenn man es Unterabtastung nennt, wäre das
(pragmatisch gesehen) nur irreführende Haarspalterei. :-)
Beim Oszilloskop kann man sich für die ADC-Samples ein Frequenzspektrum
anzeigen lassen. Hier wird allerdings kein Spektrum berechnet, sondern
nur der Wert für eine einzelne Frequenz:
Ich wähle als Frequenz 77500Hz, als Abtastfrequenz 77500Hz/1.25 und als
Meßintervall 100ms. Das macht 6200 Abtastwerte (=77500Hz/1.25*0.1s). Für
die Fourier-Koeffizienten sind dann zwei Summen zu je 6200 Summanden zu
berechnen:
1
a = ADC0*cos(2*pi*fDCF*0/fADC) + ADC1*cos(2*pi*fDCF*1/fADC) + ...
2
b = ADC0*sin(2*pi*fDCF*1/TADC) + ADC1*sin(2*pi*fDCF*1/fADC) + ...
Setzt man fDCF und fADC ein,,,
1
a = ADC0*cos(2*pi*1.25*0) + ADC1*cos(2*pi*1.25*1) + ...
2
b = ADC0*sin(2*pi*1.25*0) + ADC1*sin(2*pi*1.25*1) + ...
( der Amplitudenwert wäre schließlich: A = sqrt(a*a + b*b) )
Wenn man übrigens hier (77500Hz, 62000Hz, 100ms) den
Goertzel-Algorithmus verwendet, erhält man nicht nur das gleiche
Ergebnis sondern man braucht - welch Wunder - die gleichen
Rechenoperationen.
DC-Frickler schrieb:> beliebigen Frequenz von zum Beispiel 10 kHz
Da die Messwerte extrem fehlerbehaftet sind, sind Mehrfachmessungen
äußerst wichtig. Optimal wäre deshalb eine maximale
ATTINY-Abtastfrequenz. Bei einer Abtastfrequenz von 10KHz statt 62kHz
wäre der Qualitätunterschied wahrscheinlich noch gering.
> gleitenden Mittelwert
Sehe ich auch so.
> verschleifen sich die modulierten Nutzsignalflanken
Genau - nicht so schön aber ok.
> trivialen mittelwertsbildenden Algorithmus
Nicht unbedingt: Die ADC-Werte geben nicht die AM-Amplitude, sondern den
Momentanwert vom Trägersignal wieder. Das heißt, es muss erst eine
Amplitude aus den Werten berechnet werden (bevor ein gleitender
Mittelwert gebildet werden kann). Bei der Amplitudenberechnung
("Demodulator") geht aber die Phaseninformation (Information!) verloren.
Man kann die Phaseninformation berücksichtigen, wenn der gleitende
Mittelwert über zwei Summen vor dem Demodulator geschieht. Für die
Summenbildung müssen die ADC-Werte aber "mittelwertbildbar" gemacht
werden (62000Hz) oder es muss "gleitend vergoertzelt" (doofe
ATTINY-Software-Multipliktionen) werden.
Apollo M. schrieb:> Wo kommen die Daten für die Dämpfung her
Man muss nur die ADC-Werte simulieren.
> wie wurde die Abbildung erzeugt?
Mit "SetPixel()". :-)
Mir geht immer noch die Idee mit der Phasenauswertung durch den Kopf.
Hierzu wird eine höhere Abtastfrequenz benötigt und damit auch ein
kleinerer Ausgangswiderstand des Verstärkers. Die Eingangsimpedanz des
Verstärkers belastet den Schwingkreis mit ca. 10k. Dieser ließe sich mit
einer zusätzlichen Stufe auf etwa 80k erhöhen.
Wären die folgenden Erweiterungen, abgesehen von dem höheren
Bauteileaufwand, sinnvoll? Es werden die gleichen Transistoren
eingesetzt und die Verstärkung ist etwas höher als 1000.
Die PTB schreibt unter
https://www.ptb.de/cms/en/ptb/fachabteilungen/abt4/fb-44/ag-442/dissemination-of-legal-time/dcf77/dcf77-phase-modulation.html
In addition to the amplitude modulation (AM), a pseudo-random phase
noise is modulated onto the carrier of DCF77. For this purpose, the
phase is shifted in accordance with a binary random sequence by ±15,6°,
the mean value of the carrier phase remaining unchanged. At the
reception side, the pseudo-random sequence used can be reproduced as a
search signal and cross-correlated with the phase noise contained in the
DCF77 signal received. This allows the arrival times of the time signals
received to be determined more precisely.
Wird dadurch auch der Empfang verbessert?
>Mir geht immer noch die Idee mit der Phasenauswertung durch den Kopf.
Die Frage ist: Was willst Du mit der Phase anfangen?
Das was Franz gebaut hat, ist ein Quadraturdemodulator, der die Frequenz
auf 15.5kHz herunter mischt
https://de.wikipedia.org/wiki/Quadraturamplitudenmodulation
und dann die aus den I und Q die Amplitude berechnet. Das Verfahren wäre
umso besser, je höher die Abtastfrequenz ist. Ideal wäre für die
Mischung ein Sinus- und Cosinussignal, weil die Rechteckmischung
Artifakte der Störungen mit in die Auswertung mischt.
Noname (Gast)
26.12.2021 20:13
>In addition to the amplitude modulation (AM), a pseudo-random phase>noise is modulated onto the carrier of DCF77. For this purpose, the>phase is shifted in accordance with a binary random sequence by ±15,6°,>the mean value of the carrier phase remaining unchanged. At the>reception side, the pseudo-random sequence used can be reproduced as a>search signal and cross-correlated with the phase noise contained in the>DCF77 signal received. This allows the arrival times of the time signals>received to be determined more precisely.>Wird dadurch auch der Empfang verbessert?
Tschuldigung, nicht gelesen ...
Wie dort steht, wird die Pseudo-Random-Noise überlagerte Phase
verwendet. Dadurch kann man die Laufzeit des Signals bestimmen. Ich
würde sagen, dass setzt aber gute AD-Wandler, die Kenntnis der Sequenz
und eine sehr lange Korrelation voraus. Naiverweise behaupte ich jetzt
erst einmal, dass damit der Attiny85 ziemlich überfordert ist.
chris_ schrieb:> der Attiny85 ziemlich überfordert ist.
... ziemlich sicher!
Zum lernen/analysieren im Anhang ein entspr. pic33 Phasendecoder ...
Ich blicke bis jetzt die ganze Methode nicht ...
Die pic33 Lösung habe ich eingesammelt von
http://www.marvellconsultants.com/DCF/
Wer hat die Jan 2012 Elektor magazine edition und macht eine Kopie von
dem Artikel dazu?
chris_ schrieb:> Ideal wäre für die> Mischung ein Sinus- und Cosinussignal, weil die Rechteckmischung> Artifakte der Störungen mit in die Auswertung mischt.
Kann ich allein durch Abtastung ein IQ-Signal aus dem reellen Signal
gewinnen? In der Literatur wird immer erst gemischt und dann werden
danach die beiden Ausgänge der Mischer zeitgleich abgetastet. Was die
Mischer machen müsste man doch auch berechnen können.
Oder kann man auch zwei ADCs nehmen. Einer tastet mit fa ab und der
andere um Ta/4 später?
>Kann ich allein durch Abtastung ein IQ-Signal aus dem reellen Signal>gewinnen?
Du hast nur eine Antenne, die ein Signal empfängt. Du willst aber zwei
Signale daraus machen:
I und Q.
Das passiert, in dem man das Antennensignal ( im Bild r(t) ) mit cos und
sin multipliziert.
Bei sehr hohen Frequenzen und den RDS Receivern passiert das
üblicherweise extern analog.
>Ja, nennt sich Direct Sampling Receiver.
So wird der Attiny hier verwendet.
chris_ schrieb:> Wie dort steht, wird die Pseudo-Random-Noise überlagerte Phase> verwendet.
Naja, der Träger wird halt phasenmoduliert.
> Dadurch kann man die Laufzeit des Signals bestimmen.
Das wäre (besonders in einem bestimmten Entfernungsbereich vom Sender,
in dem unterschiedliche Ausbreitungswege relevant sind) sicherlich ganz
toll, ist aber leider nichts so.
Nur die Ankunftszeit des Signals kann man dadurch viel exakter bestimmen
als mittels der Amplitudenmodulation. Steht übrigens auch so im
geposteteten Text.
> Ich> würde sagen, dass setzt aber gute AD-Wandler
So super gut brauchen die garnicht zu sein, der Phasenhub beträgt ja
immerhin +-15.6°. Verschiebe doch einfach mal gedanklich einen Sinus um
eben diesen Betrag und schaue dir die Elongation an den konstanten
Abtaststellen im Vergleich an, dann siehst du, dass die ADC nicht
besonders hochauflösend muss, um das zu checken.
Übrigens wird in dieser Anwendung die eher mäßige Güte der vom TO
vorgeschlagenen, sehr simplen, Empfangsschaltung positiv wirksam.
Höhere Güte bedeutet nämlich tendenziell, dass von der Phasenmodulation
immer weniger beim Empfänger ankommt.
> die Kenntnis der Sequenz
Ja klar, die muss man natürlich kennen.
> und eine sehr lange Korrelation voraus.
Nur, wenn man keine Ahnung von effizienter Programmierung hat,
insbesondere nicht von der Ausnutzung bekannter Nebenumstände zur
Verringerung der Rechenlast.
> Naiverweise behaupte ich jetzt> erst einmal, dass damit der Attiny85 ziemlich überfordert ist.
Ja, das stimmt. Allerdings kommen da mehrere Sachen zusammen, es ist
nicht die mangelnde Rechenleistung alleine. Sein ADC ist zu langsam und
das Taktsystem zu unflexibel. Erst diese drei Sachen zusammen machen es
praktisch nahezu unmöglich.
Bei einem Tiny814 sieht es aber unter jedem der drei Aspekte deutlich
besser aus. Deswegen geht's damit dann insgesamt auch und zwar sogar
relativ problemlos.
Das Spielen mit dem DCF77 Empfänger ist ziemlich lehrreich.
Mit den kleinen Drosselspulen hatte ich keinen Erfolg bzw das Signal ist
noch sichtbar aber ziemlich schwach. Ein alter Radio Ferritstab hat hier
eine wesentlich größeres Signal.
Zur Detektion habe ich einfach mal einen Lowpassfilter als
Basislevel-Tracker und eine 50% Schwelle nach unten für die
Pulserkennung verwendet.
Apropos: Es gibt hier ein paar nette Vorschläge für DCF77 Empfänger im
MC-Netz
Beitrag "DCF77 Empfänger Eigenbau selber bauen einfacher Rückkopplungsempfänger / Geradeausempfänger"
Ich bin hier irgendwie komplett raus, aber mega cooles Projekt, ein
ganzer Artikel (wie der Elektor-Artike) dazu mit einfachen Erklärungen
wäre cool.
Das generelle Prinzip (IQ-Demodulation) ist ungefähr klar, aber wie das
in der Software umgesetzt wurde ist echt abgefahren.
Könnte man sich einen Verstärker und den Quarz sparen indem man einen
ATiny1624 verwendet?
Den PGA ADC zur Verstärkung nutzen und den internen Oszillator auf das
DCF77-Signal abgleichen? Der hätte evtl. noch genug Pins und Speicher
für ein kleines I2C oder SPI Display...
Hat der Empfänger von chris_ etwas mit dem Original-Projekt hier zu tun?
Lässt sich der Tiny85-Code auf den Arduino übertragen? Ich vermute nicht
so ohne weiteres.
>Hat der Empfänger von chris_ etwas mit dem Original-Projekt hier zu tun?
Ja, ein sehr faszinierendes Projekt.
Mein Aufbau hat insofern etwas damit zu tun, dass er mit der
Verstärkerschaltung aus dem Eingangspost aufgenommen wurde.
Allerdings läuft der Nano hier mit 308kHz Samplingfrequenz um die
Unterabtastung zu vermeiden und 512 Wertebuffer. Dann wird das ganze
durch den IQ-Demodulator im Nano gejagt und das Ergebnis als Punkt
geplottet.
Lupin schrieb:> Könnte man sich .. den Quarz sparen
Ohne Quarz liegt die Frequenzgenauigkeit bei 1% (10000PPM!). Der
Controller kann deshalb nicht mehr zu einer höheren Empfangsqualität
beitragen, als es bereits die Antenne macht (700Hz Bandbreite -> also
auch 1%). Außerdem ist der Jitter so schnell und hoch, dass man die
Abweichung nicht per Software an den DCF77 angleichen kann.
Lupin schrieb:> Könnte man sich einen Verstärker ... sparen
Die 64 fache Verstärkung (16x Gain und zwei weitere ADC-Bits gegenüber
der 1000 fachen beim Verstärker ist auch bei guter Antenne etwas knapp.
Aber auf eine Stufe kann man sicherlich verzichten.
Franz schrieb:> Im Internet findet man viele Schaltpläne für DCF77-Empfänger, bei denen> aber verglichen mit Fertigmodulen recht viel verbaut wurde.
Nicht nur, das z.Bsp. wäre eine DCF77-Schaltungen mit kaum Bauteilen
http://afug-info.de/Schaltungen-Eigenbau/DCF77/
Nachdem der Empfang von amplitudenmodierten DCF77-Daten mit einem
ATTINY85 geht, geht das auch mit den phasenmodulierten DCF77-Daten? :-)
### Funktionsweise
Nur die Hardware und die Abtastfrequenz von 62000Hz sind gleich
geblieben. Die Sample-Verarbeitungseinheit wurde von 4ms auf 0.516ms
verkleinert, was 1/3 der Dauer eines phasenmodulierten Bits (120
DCF77-Perioden) entspricht. Aus der Summe der letzten drei Samples wurde
die Bit-Phase und aus dem gleitenden Mittelwert (exponentielle Glättung
mit Tau=260ms) aller Samples wurde die Referenzphase berechnet.
- "01 Minus_43db.png"
Das Bild zeigt die internen DCTBit- und DCTRef-Phasen bei gutem Empfang
und einem Uss-ADC-Signal von -43db. Dort sind die DCF77-Phasenänderungen
von +-13° sowie die Zykluslänge von rund 0.8s (512 Bits x 120
DCF77-Perioden) erkennbar. Die verbleibenden 0.2s werden für die
Amplitudenmodulation verwendet, wo die Phase entweder verrauscht
(Amplitudenabsenkung) oder konstant ist, wie man es im Bild ("59.
DCF-Sekunde") sehen kann.
Die ADC-Frequenz wird anhand der Änderung der Referenzphase der
DCF77-Frequenz angeglichen. Dies ist notwendig, da beispielsweise
bereits eine 2 PPM Abweichung zu einem Phasenfehler von 7°
(=2PPM*260ms*77500Hz*360°/2) bei der Referenzphase führt. Der Fehler und
die Regelung bei einer 20 PPM Abweichung sind in den ersten Sekunden
beim Bild gut erkennbar.
- "02 Zoomed.png"
Das Bild zeigt die Meßwerte nun unskaliert. Es wurden farbige Linien im
Abstand von 3 Pixel, also einer Bitlänge, darübergelegt. Die Farbe wurde
je nach Tabellenwert des PRN-Kode (Pseudo-Random Noise Kode) vom DCF77
gewählt und der Startpunkt wurde mit der PRNBitOfs_GetResult()
ermittelt. Es ist erkennbar, dass in den 512 PRN-Bits auf der rechten
Bildseite der DCF77-Bitwert "0" und auf der linken Seite - wegen der
invertierten Phasen - der Wert "1" kodiert ist.
- "03 Decoded.png"
Im Bild ist die dekodierte Variante der gleichen Daten zu sehen. Dort
wurden aber alle Pixel ausgeblendet, die nicht ein PRN-Bit
repräsentieren und, die Bit-Phase wurde an der Referenzphase in dem Fall
gespiegelt, wenn der jeweilige PRN-Tabellenkode "1" war. Nur etwa vier
von den 512 Pixel eines jeden Blocks liegen auf der "falschen" Seite der
Referenzphase. Der DCF77-Bitwert ist hier also extrem sicher bestimmbar,
da die Wahrscheinlichkeit, dass dies zufällig geschehen kann, bei eins
zu 10^140 (eine eins mit 140 Nullen) liegt!
- "04 Minus_75db_aber_Ok.png"
Das Bild zeigt die Phasenwerte bei einem guten aber mit -75db sehr
schwachen Uss-ADC-Signal, was etwa 1/5 der ADC-Auflösung entspricht. Die
fADC-Regelung braucht deshalb zum Ausgleich eine Minute, das Signal ist
aber dann gut dekodierbar.
### Vergleich mit dem vorherigen AM-ATTINY85-Empfänger: Der Abstand zum
TFT-Monitor darf nun von 28cm auf fast 20cm verkleinert werden. Die
Empfindlichkeit ist etwas (3db?) und die Übersteuerungsfestigkeit ist
deutlich (20db?) gestiegen. Eine Quarzabweichung bis 30PPM wird
selbständig ausgeglichen und eine Kalibrierung bis zu einer Abweichnung
von 500 PPM kann manuell per PB0-Pin und ohne Quelltextänderung
gestartet werden (Infos in "main.h). Die DCF77-Impulse werden nun nicht
mehr an PB0 ausgegeben, aber die UART-Ausgabe an PB1 gibt es weiterhin:
#00207 | dPPM: -3 | ADC: -46 db | DBG: 0 0 33 | AvrHitVal: 16
HitVal: 15 BitVal: 1 | Date: Fr, 07.01.2022 19:58:27 MEZ - 2
ValidCount
#00208 | dPPM: -3 | ADC: -48 db | DBG: 0 0 33 | AvrHitVal: 16
HitVal: 24 BitVal: 1 | Date: Fr, 07.01.2022 19:58:28 MEZ - 2
ValidCount
#00209 | dPPM: -2 | ADC: -48 db | DBG: 0 0 33 | AvrHitVal: 16
HitVal: -17 BitVal: 0 | Date: Fr, 07.01.2022 19:58:29 MEZ - 2
ValidCount
#00210 | dPPM: -1 | ADC: -48 db | DBG: 0 0 33 | AvrHitVal: 15
HitVal: -23 BitVal: 0 | Date: Fr, 07.01.2022 19:58:30 MEZ - 2
ValidCount
#00211 | dPPM: -4 | ADC: -46 db | DBG: 0 0 33 | AvrHitVal: 15
HitVal: 20 BitVal: 1 | Date: Fr, 07.01.2022 19:58:31 MEZ - 2
ValidCount
Neu ist der Wert "HitVal". Der gibt für das aktuelle DCF-Bit an,
wieviele PRN-Bits mit dem PRN-Kode übereinstimmten. Bei +256 entsprachen
alle Bits dem PRN-Kode und bei -256 waren alle Bits entgegengesetzt. Der
Wert spiegelt die Signalqualität wieder und ermöglicht eine Aussage über
die Fehlerwahrscheinlichkeit des DCF-Bits.
### Spezialdekoder "07 DCF77DecHit.zip"
Meist ist die Empfangssituation für alle Empfänger gut und manchmal für
alle unzureichend. Im folgenden geht um den normalerweise schmalen
Grenzbereich. Dort kann die Erkennungsqualität mit speziellen Dekodern
deutlich gesteigert werden. Im Anhang liegt ein Programm welches die
Empfangsdaten mehrerer Minuten verrechnet und zu der Zeitinformation
auch eine Fehlerwahrscheinlichkeit liefert. Das Programm verwendet dazu
die HitVal- statt der BitVal-Werte, da diese ein vielfaches an
statistischer Information enthalten. Das Programm (Achtung STM32-Code:
32Bit-int) benötigt dazu über 900 Byte RAM und einige Kilobyte Flash. Da
der ATTINY nur noch 33 Byte RAM und 500 Byte Flash frei hat, wurde der
Dekoder nur testweise unter Windows, aber mit den ATTINY-HitVal-Werten,
ausgeführt. Das Ergebnis liegt in der Datei "06
DCF77DecHit.zip/Vergleich.txt". Der normale Dekoder hat in 10 Minuten
nur einen einzigen Datensatz (ValidCount 1) gefunden. Bei solch
niedrigen Quoten besteht auch die Gefahr von Doppelfehlern (Prüfbit
wertlos), wodurch der gefundene Datensatz sogar fraglich wird. Im
Gegensatz dazu hat der Spezialdekoder nach 360 Sekunden (Zeile "#00297")
das Ergebnis mit einem "dbErr" von über 180 ermittelt. Das entspricht
einer Fehlerwahrscheinlichkeit von eins zu einer Milliarde
(=1:10^(180/20)).
### Fazit
Auch dieser PM-Empfänger macht gegenüber einem Fertigmodul wenig Sinn.
Der Grund ist unverändert: Ein Fertigmodul ist einfach nicht teuer oder
qualitativ schlecht genug, dass sich der Arbeitsaufwand für einen
ATTINY-Empfänger lohnt.
Franz schrieb:> ### Fazit> Auch dieser PM-Empfänger macht gegenüber einem Fertigmodul wenig Sinn.> Der Grund ist unverändert: Ein Fertigmodul ist einfach nicht teuer oder> qualitativ schlecht genug, dass sich der Arbeitsaufwand für einen> ATTINY-Empfänger lohnt.
So sehe ich das auch.
Wie sieht es damit aus von einem Fertigmodul den breitbandigen
Antennenteil zusatzlich zu verwenden und damit die Pseudomodulation für
eine noch genauere Zeitbasis zu verwenden?
Was meinst du mit Antennenteil? Man kann beim Fertigmodul die Antenne
abtrennen, mehr doch nicht?
Nach meiner Meinung kann der DCF77 nur in Sendernähe (300km) als genaue
Zeitbasis (Zeit- nicht Frequenzbasis) verwenden. In größeren
Entfernungen wirkt sich die Raumwelle immer mehr aus. Erst nur durch
eine Phasenverschiebung (d.h. einige µs) und später, wenn sie
dominierend wird, kann die Zeit um viele Perioden (z.B. 100µs) springen.
Selbst wenn man Erfahrung mit der örtlichen Situation hat, greift man
doch besser zum GPS-Empfänger. Wirklich praktikabel kann man den DCF77
eigentlich "nur" bis etwa 1ms verwenden.
Dcf77 hat den Vorteil dass es überall funktioniert, GPS braucht da schon
mehr. Klar, es geht am Fenster, ansonsten muss man die Mauer anbohren.
Differenz sind ca +47ms bei dcf77, +-2ms, die 0.15ms Differenz zwischen
70km und 90km Ionosphäre an der es reflektiert wird kommt da nicht zum
Tragen.
Jetzt ohne das Delay von agc und Quarzfilterung wäre das Timing weniger
als 4ms, mit der psnr Modulation dann effektiv ohne agc +-30uS und
Laufzeit von ca 3.6ms.
Interessant wäre die Verwendung eines Fertigmoduls und gleichzeitig das
Sampling des breitbandigen Antennensignals bevor es mittels Quarzfilters
schmalbandig wird.
Klarerweise fängt sich ein Breitbandiges Signal mehr Störsignale ein,
sollte es zu sehr gestört sein kann man ja mit dem 44ms späterem
schmalbandigerem Signal arbeiten.
Hallo Franz,
ich bin wirklich beeindruckt über Deine Entwicklung. Wie viel Zeit hast
Du in das Projekt gesteckt und mit welchen Tools arbeitest Du? Das
Format der Grafiken kann ich keinem Programm zuordnen.
Ich habe den Verstärker nach dem Schaltplan von Dir oben aufgebaut. Er
hat eine Verstärkung von ~68.5dB (V=2660) und wenn ich richtig messe,
liefert der Ausgang eine Amplitude von ~30mV also ~6LSB beim 10bit ADC
auf 4.6Vcc bezogen.
=======
Wenn ich es richtig sehe, sind wir jetzt schon 2 Chris im Thread. Ich
bin "chris_", nur damit es nicht zu Verwechslungen kommt.
Chris schrieb:> Differenz sind ca +47ms bei dcf77, +-2ms
Die Differenz kann man berücksichtigen. Es bleiben dann 2ms
Ungenauigkeit, was in Ordnung ist.
Chris schrieb:> Interessant wäre die Verwendung eines Fertigmoduls und gleichzeitig das> Sampling des breitbandigen Antennensignals bevor es mittels Quarzfilters> schmalbandig wird.
Ich verstehe es nicht. Was bleibt denn dann übrig? Falls nicht nur die
Antenne, dann die Antenne mit Vorverstärker. Aber das ist doch das, was
hier verwendet wird.
Beitrag "ATTINY85 als DCF77-Empfänger":
Beim amplitudenmodulierten ATTINY85-Empfänger beträgt das Delay 200ms
und der Fehler 4ms. Mit mehr SRAM könnte man den Fehler deutlich unter
1ms verkleinern. Spätestens unter 0.5ms sollte man die Verzögerung durch
die Spulengüte (Anschwingen-Ausschwingen) von etwa 0.2ms (bei Güte 100)
berücksichtigen oder die Güte verkleinern (Parallelwiderstand).
Beitrag "Re: ATTINY85 als DCF77-Empfänger":
Beim phasenmodulierten ATTINY85-Empfänger beträgt das Delay 993m
(=0.2s+512*120/77500Hz) und der Fehler etwa 0.8ms (ein halbes PRN-Bit:
=1/2*120/77500Hz). Eine zusätzliche Verzögerung durch die Spulengüte
gibt es auch hier.
chris_ schrieb:> ich bin wirklich beeindruckt über Deine Entwicklung.
Vielen Dank!
> Wie viel Zeit hast Du in das Projekt gesteckt
Schändlich viel. Punkt. :-)
> mit welchen Tools arbeitest Du?
Eigentlich ist es kein AVR-Projekt. Die Rohdaten werden von einem STM32
(EmBitz-Projekt) per STLink und GDB zum Windows-Programm (VS6-Projekt)
gestreamt und dort letztendlich verarbeitet. Nur für die obigen
Diagramme wurde ein spezielles ATTINY85-Streamer-Programm verwendet um
echte ATTINY-ADC-Werten verarbeiten zu können. Grafiken benötige ich
normalerweise nur bei der Entwicklung, dort aber viel.
Die Grafiken sind so speziell, dass sich für mich ordentliche Tools
wenig lohnen. Für mikrocontroller.net werden die Grafiken einfach mit
MSPaint ergänzt.
> Ich habe den Verstärker nach dem Schaltplan von Dir oben aufgebaut. Er> hat eine Verstärkung von ~68.5dB (V=2660) und wenn ich richtig messe,> liefert der Ausgang eine Amplitude von ~30mV also ~6LSB beim 10bit ADC> auf 4.6Vcc bezogen.
Kann ich teilweise bestätigen. Mit LTSpice erhalte ich einen Wert von
etwa 1500. Für andere Messungen brauchte ich die genaue tatsächliche
Verstärkung und habe sie über verschiedene Verfahren bestimmt. Die
betrug 1260+-20 mit zweifelsfrei originalen BC547B-Typen. Dein Wert mit
über 2660 scheint mir für einen BC547B etwas hoch. Für den ADC ist das
natürlich sehr gut.
chris_ schrieb:> Hier noch eine für mich sehr erstaunliche Sache: Die Funkmaus stört den> Empfänger und zwar auch bei ausgeschaltetem Zustand.
Selbst eine IR-Fernbedienung stört gewaltig, dort gibt es nicht mal HF.
Es reichen Stromänderungen und ab gewisser Leitungslänge oder Hub auch
Spannungsänderungen. Glücklicherweise nehmen die Störungen meist sehr
stark mit der Entfernung ab.
Hat die Spule wirklich keine 20 Windungen? Die grossen Cs deuten auch
darauf hin. Da verschenkt man ziemlich viel Signal. Bei einem V=2660
natürlich nicht so schlimm.
PS: Mit deinem Aufbau gewinnst du aber auch keinen Preis. :-)
Danke erst mal für die ausführlichen Kommentare.
>> Wie viel Zeit hast Du in das Projekt gesteckt>Schändlich viel. Punkt. :-)
Uh, jetzt bin ich beruhigt: Eigentlich wollte ich mich mal 2 Tage damit
beschäftigen, aber jetzt sind die Weihnachtsferien dafür drauf gegangen
...
>Selbst eine IR-Fernbedienung stört gewaltig, dort gibt es nicht mal HF.>Es reichen Stromänderungen und ab gewisser Leitungslänge oder Hub auch>Spannungsänderungen. Glücklicherweise nehmen die Störungen meist sehr>stark mit der Entfernung ab.
Das ist interessant. Ich frage mich, ob man bei dem riesigen
Empfangsradius von 500km nicht auch alle möglichen Störungen einfängt.
Was ist, wenn der Stromabnehmer einer Zuges auf die Oberleitung klatscht
oder ein Kraftwerk eine Sicherung ein oder ausschaltet? Das könnte
vielleicht als eine Art Dirac-Impuls auch die 77kHz anregen. Gibt es
Effekte aus dem Weltraum, die man eventuell sehen kann?
Bei der Maus finde ich vor allem eine Eigenschaft sehr bedenklich: Wieso
sendet sie, wenn der Schalter aus ist? Das kann ja wohl nicht sein, so
saugt sie im ausgeschalteten Zustand langsam die Batterie leer.
>Hat die Spule wirklich keine 20 Windungen? Die grossen Cs deuten auch>darauf hin. Da verschenkt man ziemlich viel Signal.
Wenn ich die letzte Windung mitzähle, die so halb schräg das Kabel weg
führt, sind es 21. Wäre 20 Windungen ein gebräuchliches Wickelmaß?
>Kann ich teilweise bestätigen. Mit LTSpice erhalte ich einen Wert von>etwa 1500. Für andere Messungen brauchte ich die genaue tatsächliche>Verstärkung und habe sie über verschiedene Verfahren bestimmt. Die>betrug 1260+-20 mit zweifelsfrei originalen BC547B-Typen. Dein Wert mit>über 2660 scheint mir für einen BC547B etwas hoch. Für den ADC ist das>natürlich sehr gut.
Bei mir sind es BC548C. Die haben wohl eine etwas höhere Verstärkung.
Ich habe die Schaltung auch mit LtSpice simuliert. Da es dort keine
BC558C gibt, habe ich BC547C genommen und die Simulation ergab V=1820.
>PS: Mit deinem Aufbau gewinnst du aber auch keinen Preis. :-)
Oh, jetzt habe ich mich so angestrengt und dachte, das muss beim
Retro-Style so sein :-)
Wenn ich die Spule und den Kondesator mit einem LCR-Meter messe und die
Resonanzfrequenz berechne, liege ich so ca. 2kHz im Vergleich zur
Bodeplot Messung mit dem Oszilloskop daneben.
L_uH = 37
C_nF = 120.1
fg_Hz = 75500
Falls es andere Bastler hier mit einfacherem Equipment probieren wollen:
Ich hatte ursprünglich den hier entwickelten Transistortester verwendet,
damit weiß man dann schon ungefähr, wo die Induktivität der Spule liegt.
chris_ schrieb:> Das ist interessant. Ich frage mich, ob man bei dem riesigen> Empfangsradius von 500km nicht auch alle möglichen Störungen einfängt.
Es gibt einen Hin- und einen Rückweg. Zumindest ein Teil der Störung
müsste sich je nach Leitungsabstand über "kurz oder lang" aufheben.
> Wieso sendet sie, wenn der Schalter aus ist?
Würde mich auch interessieren. Vielleicht weiß das einer?
> L_uH = 37> C_nF = 120.1> fg_Hz = 75500
Ich glaube 37µH sind bei einer DCF77-Antenne schon sehr unüblich. Als
Folge muss die Kapazität gross werden, wodurch man auch an
Kondensatorverluste denken sollte.
Nach dem Diagramm liegt die Bandbreite bei sehr schlechten 5 kHz. Mit
den niedrigen Verstärkereingangswiderstand lässt sich das nicht
erklären, da dieser erst ab etwa 200µH an Bedeutung gewinnt - seltsam.
Die Folgen einer zu hohen Bandbreite sind ein kleineres Signal und ein
höherer Rausch-/Störanteil.
>Nach dem Diagramm liegt die Bandbreite bei sehr schlechten 5 kHz.
Oh, ich habe keine Erfahrungen mit Antennenschwingkreisen. Ich dachte,
das wäre schon recht schmalbandig und würde die Störungen gut filtern.
Beeindruckendes Projekt, ich gratuliere!
Franz schrieb:> Es geht, macht aber bei 5 Euro für ein Fertigmodul keinen Sinn.
Einspruch: Das ist höchst sinnvoll.
Ich bin sicher, du hast viel dabei gelernt, was beim Kauf eines
Fertigmoduls nicht gelernt worden wäre ;) . Da meine ich das
theoretische Wissen, aber noch viel mehr das praktische Können in allen
Aspekten der Entwicklungsarbeit. Das ist unbezahlbar.
Sogar als Leser profitiere ich davon.
Geniales Projekt - Chapeau! Mit 20MHz Quarz läuft die ursprüngliche
Version 07_DCF77.zip auf dem Breadboard sehr stabil. Bei 10 und 16MHz
war es noch etwas "wackelig". Das Meiste wurde ja schon erklärt, aber
welche Bedeutung haben die beiden Bits bei der UART-Ausgabe?
Käptn schrieb:> Am Wochenende kannst du noch NAVTEX und die Wetterberichte aus> https://de.wikipedia.org/wiki/Sendeanlage_Pinneberg einbauen, dann> ergibt alles einen Sinn :-)
Kalter Kaffee - ist seit Monaten fertig (STM32-Bluepill-Board).
Die 50 Baud sind allerdings sehr gemächlich. Aber als Einschlafhilfe
ganz nett und Worte wie Azoren, Biskaya usw. sorgen dabei für schöne
Träume...
@Thomas
Sehr schön. Auch der nun moderne Aufbau gefällt mir. Ich bin froh, dass
dein Aufbau funktioniert hat, da vom Display, zweiten Controller und den
Strom- und Steuerleitungen erhebliche Störungen ausgehen könnten. Die
VCC- / GND-Leitungen zum ATTINY85 können unter Umständen sogar extreme
Störquellen sein. Besonders dann, wenn man es gut meint und dem ATTINY
einen großen und niederohmigen Pufferelko spendiert. In dem Fall
entstehen nämlich enorme Stromspitzen (bis in den Akku hinein!) die
ziemlich synchron zur Trägerfrequenz sind. Gegebenenfalls würde aber
z.B. ein Widerstand oder eine Spule in der VCC-Leitung helfen. Der
PM-Empfänger (s.u.) müsste hier übrigens toleranter sein.
Thomas N. schrieb:> Bei 10 und 16MHz war es noch etwas "wackelig".
Beim 10MHz Takt sind die Compiler-Einstellungen ziemlich kritisch. Mit
"AVRStudio4.18SP3" und der Optimierung "-Os" sollte das eigentlich
anständig funktionieren. Bei moderneren Compilern hat man mehr Luft.
Eine Optimierungseinstellung wie "-Os" bleibt aber wichtig.
Beim PM-Empfänger "05_DFC77p.zip" ist es zeitlich noch enger. Es wird
mind. ein Takt von 16MHz Takt benötigt. Mit dem alten
"AVRStudio4.18SP3"-Compiler sogar noch mehr. Auch der freie
SRAM-Speicher ist grenzwertig. Aus diesen Gründen gibt es in der
UART-Ausgabe die drei Werte hinter "Dbg:". Obwohl der PM-Empfänger von
den Resourcen her kritischer als der AM-Empfänger ist, hat er trotzdem
nur Vorteile:
- Resourcen-Probleme sind erkennbar (UART-"Dbg:"-Einträge)
- empfindlicher
- störungsunempfindlicher
- Sekundenzeitpunkt genauer (wenn man die Verzögerung richtig
berücksichtigt)
- automatische Kalibrierung bis 30PPM Quarzabweichung
- selbst Quarze mit extremen Abweichungen (500PPM) ohne
Quelltextänderung verwendbar (s. "main.c")
- genaue Information über die Empfangssituation ("AvrHitVal")
> welche Bedeutung haben die beiden Bits bei der UART-Ausgabe?
Das erste Bit gibt an, ob der Sender bei der Sekundenmarke eingeschaltet
war und das zweite Bit, ob er bei der DCF-Bit-Position eingeschaltet
war. Es ist also das negierte DCF-Bit.
Franz schrieb:> Beim 10MHz Takt sind die Compiler-Einstellungen ziemlich kritisch. Mit> "AVRStudio4.18SP3" und der Optimierung "-Os" sollte das eigentlich> anständig funktionieren. Bei moderneren Compilern hat man mehr Luft.
Mit Assemblern hat man noch sehr viel mehr Luft. Und, absolut endgeil:
Auch eine neuere Version des Assemblers ändert daran rein garnix, weder
zum Guten noch zum Bösen ;o)
>Mit Assemblern hat man noch sehr viel mehr Luft. Und, absolut endgeil:>Auch eine neuere Version des Assemblers ändert daran rein garnix, weder>zum Guten noch zum Bösen ;o)
Schon, aber auf einem Arduino Nano findet es mehr Zuspruch.
Franz schrieb:> Dieses Projekt auf einem ATTINY aus Spaß (!) zu machen - naja. In ASM> wärs SM.
Für mich ist das halt genau umgekehrt: In Asm macht's Spaß, in C ist's
blöde Arbeit/Routine.
Oder es nervt sogar: Bei Projekten, wo man dann feststellt: es geht in C
schlichtweg nicht mehr, in Asm aber schon noch.
Normalerweise treffe ich allerdings nicht auf diese Situation. Wenn ich
von vornherein schon weiss, das es eng werden könnte, entwickle ich auch
gleich von vorherein in Asm.
Bei mir war es umgekehrt. Eine kleine Geschichte dazu:
Anfang 2000 gab es das letzte Update meines
Windows-Grafikbildbetrachters, der ausschließlich (inkl. Oberfläche!) in
Assembler geschrieben war. Das waren 326269 Bytes reines Assembler. Das
neue Programm war ein richtiges cpp-Programm (inkl. Polymorphie). Intern
wurden monochrome Bilddaten damit nicht mehr pixelweise verarbeitet
(vergrößern/verkleinern), sondern in laufenlängenkodierter (also in
komprimierter) Form. Das war um ein vielfaches schneller als der alte
Assembler-Code. In Assembler wäre die Komplexität praktisch nicht
handhabbar gewesen. - Das war mein Schlüsselerlebnis.
Seitdem verwende ich Assembler selten, aber weiterhin gerne. Wenn ich
Erfahrung und Übung mit AVR-Assembler gehabt hätte, dann wäre die ISR
vom Empfänger eine Assemblerroutine (aber kein Inline-ASM) geworden.
Kleiner Offtopic-Einschub...
Käptn schrieb:> Franz schrieb:>> fertig>> Gleiches Prinzip? Bitte posten!
Gleiches Prinzip, aber anderer Controller. Im Anhang liegt der Empfänger
für den DDH47 Wettersender Pinneberg.
Der Empfangsteil kann vom ATTINY-Empfänger übernommen werden. Der
Schwingkreis muss natürlich von 77500Hz auf 147300Hz umgestimmt werden.
Der Sender "sendet" (ist es die aufgenommene oder abgestrahlte
Leistung?) mit nur 20kW. Ob dieser Empfänger auch für Süddeutschland
reicht?
Hier einige Infos (aus "main.c" raus kopiert):
1
//
2
// ### Empfänger für den Wettersender Pinneberg "DDH47" auf 147.3 MHz ###
// GPIO-PA9: UART-Ausgang: "9600 8N1" (9600 Baud, ein Startbit, acht Datenbits, kein Paritybit, ein Stoppbit)
10
//
11
// - Abgleich
12
// - Resonanzfrequenz von der Empfangsantenne gut abstimmen (+-1kHz)
13
// - Antenne senkrecht zu Pinneberg ausrichten
14
// - bei ausreichend Empfang ("SNR"-Wert über 5) den über UART angezeigten Wert für "ppm"
15
// für "Crystal_PPM" (in "main.c") eintragen
16
//
Das Programm ist zwar von der Funktion her relativ ausgereift, es ist
aber kaum getestet. Außerdem habe ich den Quelltext heute nach vielen
Monaten überarbeitet. - Hoffentlich läufts.
PS: Der Sender verwendet die "CR"- und "LF"-Codes zwar korrekt, aber
seltsam. Die Debug-Ausgaben machen es noch schlimmer. Eventuell ist die
UART-Ausgabe mit einem anderen Terminalprogramm als Putty chaotisch.
Franz schrieb:> Gleiches Prinzip, aber anderer Controller. Im Anhang liegt der Empfänger> für den DDH47 Wettersender Pinneberg.
Wenn du so weiter machst, dann "verliebe" ich mich noch in deine
Projekte.
Ich war gerade dabei mir dazu was zum spielen aufzubauen, kann jetzt
direkt in die Tonne.
Danke!
Franz schrieb:> Im Anhang liegt der Empfänger für den DDH47 Wettersender Pinneberg.
Danke dass du diese Projekte teilst. Ich bin begeistert :)
Ich war vor Jahren mal angefangen, dass 77.5kHz Signal direkt zu
samplen, so wie du es gemacht hast. Am Ende hab ich aber zu wenig Ahnung
über digitale Signalverarbeitung, sodass es im Sande verlaufen ist.
Und jetzt schmeißt hier einer sowas mit 'nem Tiny ins Forum. Unglaublich
eigentlich :)
Ich werde das auf jedenfall auch probieren.
Danke nochmal.
@Zeitloser
@Apollo M.
@900ss D.
Danke!!
Käptn schrieb:> In deiner main.c muss KHz, nicht MHz stehen (2x) ;-)
Oh ja. (Wäre schön wenn es der einige Fehler bliebe.)
> Sind auch 500 kHz +/- für NAVTEX zu schaffen? Habe von SDR noch keine> Ahnung. Konnte man die ADCs des STM32 nicht "interleaven" und über 1 MHz> ADC kommen?
Notfalls, wie man beim ATTINY sieht, würde ein fADC von 400kHz reichen
und der STM32F103 schafft interleaved sogar 2MHz. Die CPU läuft auch
noch bei 80MHz und RAM/FLASH sind auch reichlich vorhanden. Ich kenne
aber NAVTEX nicht und es ist vielleicht letztendlich doch zu
rechenintensiv oder zu kompliziert. Ich muss mir zuerst deine Links
ansehen. Auch wenn man qualitativ zu weit von deren Leistungen entfernt
bleiben wird, würde daraus kein richtiges Projekt (sondern nur ein Test)
werden. - Sehr schöner Tipp, danke erstmal.
Franz schrieb:> Ich kenne> aber NAVTEX nicht und es ist vielleicht letztendlich doch zu> rechenintensiv oder zu kompliziert.
RTTY zu SITOR ist kein großes Ding, das habe ich vor Jahren auch mit
einem kleinen AT89C2051 gemacht. Ein STM32 ist mehr als ausreichend
dimensioniert. Auf meinem miniSDR (auch STM32) werden die Meldungen
sämtlicher NAVTEX-Stationen im Klartext als HTML Dateien
zwischengespeichert und über einen kleinen HTTP Server verteilt.
c-hater schrieb:> Franz schrieb:>>> Dieses Projekt auf einem ATTINY aus Spaß (!) zu machen - naja. In ASM>> wärs SM.>> Für mich ist das halt genau umgekehrt: In Asm macht's Spaß, in C ist's> blöde Arbeit/Routine.>> Oder es nervt sogar: Bei Projekten, wo man dann feststellt: es geht in C> schlichtweg nicht mehr, in Asm aber schon noch.> Normalerweise treffe ich allerdings nicht auf diese Situation. Wenn ich> von vornherein schon weiss, das es eng werden könnte, entwickle ich auch> gleich von vorherein in Asm.
Oh Mann, Du kannst C hassen wie Du gerne möchtest, Du kannst Assembler
lieben wie Du gerne möchtest, aber welcher cerebrale Defekt suggeriert
Dir das Du diese Umstände hier über Jahre bei jeder Gelegenheit breit
treten solltest? Das ist ja wie diese bescheuerte Prostata-Untersuchungs
und Uterus-In-Ordnung Werbung aus dem Fernsehen..
Bist Du exhibitionistisch veranlagt?
Send Pics...
Gruß,
Pille
Hallo Franz,
ich bin echt begeistert ! Ich habe das 07_DCF77 auf einem SAMD21 laufen.
Antenne ist eine Mini-Whip ohne jede Filter mit ca -66dBV DCF-Signal.
Das Programm zeigt -55dB, 0.2dB Noise und dekodiert einwandfrei.
Vom ADC nutze ich auch nur 10bit wie der Tiny85.
Ludger
Ludger schrieb:> auf einem SAMD21 laufen.
Kannst du dein Projekt hier hochladen, weil samd21 ist interessant,
liegt bei mir rum und will auch was zu tun haben.
Ludger schrieb:> Ich habe das 07_DCF77 auf einem SAMD21 laufen.
Das schwierigste ist oft, erstmal etwas lauffähiges zusammenzubekommen.
Da dieser Schritt (ATTINY -> SAMD21) hinter dir liegt, wären nun
Spielereien mit der deutlich leistungsfähigeren Hardware möglich. Die
Nutzung der um zwei Bit besseren ADC-Auflösung wäre noch einfach. Um
eine 16 fach höhere Sample-Frequenz zu erreichen wird es schwieriger.
Die Samples könnten zwar per DMA blockweise CPU-schonend erfasst werden,
die bestimmte ADC-Frequenz müsste dabei aber auf wenige PPM genau
eingehalten werden. Mit Tricks geht das zwar (s.o. "02 DDH47.zip"), aber
einfacher wäre es (bei beliebiger ADC-Frequenz) den Goertzel-Algorithmus
zu verwenden. Das Ergebnis wäre das gleiche und auf der SAMD21-Hardware
ginge das vielleicht sogar schneller. Der Vorteil einer höheren
Sample-Frequenz wäre ein um etwa 12dB niedrigeres Rauschen bzw. eine
höhere Empfindlichkeit.
> ca -66dBV DCF-Signal
Das Programm liefert für ein ADC-Signal mit Uss=3.3V einen Wert von 0dB.
Rechnet man -55dB nach dBV um, passt das trotzdem nicht - seltsam.
> Antenne ist eine Mini-Whip
Ich selber mache zur Zeit erste Empfangsversuche für die NAVTEX-Sender.
Verglichen mit der Empfangsqualität bei "Twente SDR" (35 km entfernt)
ist das Ergebnis äußerst bescheiden. Da Hardware- und Software
zweifelsfrei in Ordnung sind, plane ich nun auch eine Whip-Antenne zu
bauen (und einen besseren Antennenstandort zu suchen).
Oh, oh, ich bin hellauf begeistert! Funktioniert in Chemnitz (= nicht
ganz so nah an Mainflingen) in störungsverseuchter Umgebung auf dem
Steckbrett auf Anhieb! Siehe Foto. Obwohl mit dem Oszi kein Signal zu
sehen ist, legt die Software einfach los und findet sprichwörtlich die
Nadel im Heuhaufen.
Erstaunlich, dass das ohne MOSFET (Spannungsfolger), ohne Superhet, ohne
Amplitudenregelung funktioniert. Die Stromaufnahme des Verstärkers ist
obendrein günstig, nur der ATtiny schwitzt mit ca. 10 mA etwas.
Etwas schade ist, dass der Software kein Makefile beiliegt und keine
Info, mit welcher Version von gcc die Hex-Datei zustande kommt. Mit gcc
4.33 aus dem Jahr 2008 bekomme ich zwar (immerhin) die gleiche Größe
aber unterschiedlichen Inhalt.
avr-gcc -Wall -std=gnu99 -Os -DF_CPU=16000000 -mmcu=attiny85 *.c
avr-objcopy -j .text -j .data -O ihex a.out DCF77a_16MHz.hex
Nicht zu vergessen die LFuse zu ändern und beim Firmwareupdate per ISP
einen laufenden Quarz angeschlossen zu haben.
Beim Überfliegen sehe ich es als heikel an, dass die ISR für die
serielle Schnittstelle die Flags nicht rettet.
Na denn, mit der Hoffnung auf den Tipp für Binärgleichheit — henni
Ein paar Wochen später: Nein, Irrtum, die ISR der seriellen
Schnittstelle war und ist okay.
Etwas störend an der Implementierung war mir:
* Der hohe Stromverbrauch bzw. die hohe Quarzfrequenz
* Der hohe RAM- und Flash-Verbrauch.
* Die lahme serielle Schnittstelle
Schritt für Schritt habe ich das Programm (hier: Nur AM-Demodulation,
nicht PM-Demodulation) überarbeitet und bin nun bei dem Ergebnis:
* 4-MHz-Quarz, ca. 4 mA Stromaufnahme
* 60 Byte RAM zzgl. Stack, 3 KByte Flash (mit I²C statt UART reicht dann
sicherlich ein ATtiny25)
* 38400 Baud (bei 8-MHz-Quarz sind 115200 Baud drin)
Geändert habe ich:
* ISR, 24-Bit-Arithmetik, uprintf() in Assembler
* ISR-Fortsetzung per Idle-Routine statt software-getriggerter ISR
* FIR-Filter in IIR-Filter (spart erheblich RAM)
* die Art der Start- und Datenbiterkennung sowie den
Schwellwert-Detektor
* die Art der DCF77-Bitzuweisung in 8 nichtkontinuierliche Bytes
* die Generierung der Logarithmentabelle zur Compilezeit in C++
* die Bitflankengenerierung der Software-UART durch Hardware, hier USI
* die Fuses
* den Wahrheitsgehalt der Dezibel-Angaben: Nun ohne Umrechnungen um die
Multiplikation zu sparen.
Belassen habe ich:
* Die sekündliche Debugausgabe
* Das Rechnen mit Binärlogarithmen im Format Q8.8
Hier isses:
http://www.tu-chemnitz.de/~heha/pc/FunkUsb/dcf77franz*.zip/
... ich habe das jetzt auch einmal ausprobiert und bin beeindruckt.
Allerdings ist meine Empfangsleistung eher als "schlecht" zu bewerten
und ich vermute dass das an meiner kleinen Drosselspule liegt.
Ich habe mit 2 Drosselspulen, 680µH und 330µH, experimentiert und - für
mich unerwartet - lieferte die 330µH Spule die besseren (stabileren)
Ergebnisse. Zur Spule sind 2 Kondensatoren parallel geschaltet, 10nF und
3.3nF.
Wie gesagt funktioniert, aber jetzt würde mich interessieren, wie gut
(oder schlecht) das mit einer Ferrit-Antenne funktioniert, die hier
schon auf manchen Bildern zu sehen war.
Man sollte niemals etwas wegwerfen (habe ich aber getan... mir tun meine
Nixie-Röhren und VFD-Displays leid, die ich vor gut 30 oder 40 Jahren in
den Müll getan habe, genauso wie jetzt die Ferrit-Antennen aus
Mittelwellenradios):
Wo habt ihr die schönen Antennen her. Ich finde immer nur "nackte"
Ferritstäbe auf die ich eine Spule noch wickeln müßte (und das bestimmt
nicht so sauber hinbekomme wie die, die ich hier gesehen habe)
Ralph S. schrieb:> Wie gesagt funktioniert, aber jetzt würde mich interessieren, wie gut> (oder schlecht) das mit einer Ferrit-Antenne funktioniert, die hier> schon auf manchen Bildern zu sehen war.
Nicht ganz was du suchst, aber vielleicht doch interessant:
Im Beitrag "Ad-hoc-Frequenznormal und -Zeitzeichenempfänger" ist ein Bild mit
verschiedenen Spulen und man findet dort unter "Wie gut sind
"Ad-hoc-Spulen"?" eine Tabelle mit den Empfangseigenschaften dieser
Spulen.
Ralph S. schrieb:> jetzt würde mich interessieren, wie gut> (oder schlecht) das mit einer Ferrit-Antenne funktioniert
Mit der im ersten Bild gezeigten Ferritantenne habe ich das im zweiten
Bild gezeigte Signal empfangen. Entfernung zum Sender war >400km.
Ralph S. schrieb:>> https://www.pollin.de/p/dcf-empfangsmodul-dcf1-810054>> SCNR :-)> Smile Frank... :-) sehr super. Da kann ich mir super eine Antenne> herausschlachten :-) :-) :-)
Ich habe im April vier DCF-Empfänger vom Ali für 10,44 € bekommen. Ich
habe leider den Link nicht gespeichert und es war eine längere Sucherei.
Aber warum schlachten, die kann man auch komplett verwenden?
Manfred P. schrieb:> Aber warum schlachten, die kann man auch komplett verwenden?
:-) das "schlachten" war ein Scherz und der Link von Frank
Frank M. schrieb:> https://www.pollin.de/p/dcf-empfangsmodul-dcf1-810054>> SCNR :-)
wohl auch, weil: Eine Antenne alleine wohl mehr kostet als eine Antenne
mit Modul. Der Autor dieses Threads hat es ja schon (als Fazit) gesagt
gehabt: Solange fertige Module (mit Antenne) so preiswert (billig) sind,
ist dieses Projekt hier eher etwas für die "Liebhaberei". Ich finde es
dennoch super dass so etwas gemacht wird.
Manfred P. schrieb:> Aber warum schlachten, die kann man auch komplett verwenden?
Eben. Es wäre doch zu schade, den DCF-Empfänger wegzuwerfen. Von daher
das "SCNR" am Ende :-)
Ralph S. schrieb:> ... Der Autor dieses Threads hat es ja schon (als Fazit) gesagt> gehabt: Solange fertige Module (mit Antenne) so preiswert (billig) sind,> ist dieses Projekt hier eher etwas für die "Liebhaberei". ...
Im Allgemeinen stimmt das. Die Fertigmodule sind allerdings ausnahmslos
AM-DCF77-Empfänger und unter schwierigen Empfangsbedingungen sind nun
mal PM-DCF77-Empfänger besser. Einen solchen Empfänger erhält man mit
dem zweiten Source-Code
Beitrag "Re: ATTINY85 als DCF77-Empfänger"!
Nochmals bessere Ergebnisse bekommt man mit folgendem Empfänger (auch
PM):
Beitrag "Ad-hoc-Frequenznormal und -Zeitzeichenempfänger"
Grund ist der schnellere und genauere AD-Wandler des STM32. Außerdem
wird dort der in Beitrag "Re: ATTINY85 als DCF77-Empfänger"
erwähnte Spezialdekoder" verwendet.
Daniel V. schrieb:> Nochmals bessere Ergebnisse bekommt man mit folgendem Empfänger
Mal über den Tellerrand geschaut...
Ich habe zum Spielen auch mal dieses hier auf einem RPi probiert.
https://blog.blinkenlight.net/experiments/dcf77/
Allerdings nicht die Library für den Pi die es scheinbar inzwischen
gibt, sondern noch den AVR-Code auf dem Pi laufen lassen und dort einen
Conrad DCF-Empfänger angeschlossen. Ist schon ein paar Jahre her. Aber
selbst bei einem stark gestörtem Signal decodiert der Code richtig
allerdings dann erst nach ca. 10 Minuten. Sind auch schöne
Diagnose-Tools dabei.
Rein optisch auf dem Scope hätte ich gesagt, da kann man nichts mehr
dekodieren. aber funktionierte.
Aber das hier auf 'nem Tiny85 ist interessanter :)
900ss (900ss)
06.01.2025 12:27
>Ich habe zum Spielen auch mal dieses hier auf einem RPi probiert.>https://blog.blinkenlight.net/experiments/dcf77/
Das hier ist wohl das zugehörige Repository:
https://github.com/udoklein/dcf77
Grundsätzlich finde ich es gut, Firmware zu "Arduinofizieren", weil es
dann jeder leicht benutzen kann.
Der Übersichtlichkeit halber sollte man den Library-Code in einen
separaten Ordner "src" stecken, so wie hier:
https://github.com/arduino-libraries/LiquidCrystal
Ein RP2350 ist zwar gegenüber einem Attiny13 etwas überdimensioniert,
aber man könnte den Matched-Filter dann mit sin/cos und höherer
Samplingrate realisieren, was die Störunterdrückung noch etwas verbesser
könnte.
Sieht jemand einen Matched-Filte im Code?:
https://github.com/udoklein/dcf77
( ich seh's nicht )
Christoph M. schrieb:> Ein RP2350 ist zwar gegenüber einem Attiny13 etwas überdimensioniert
Klar. Ich meinte sogar einen "echten" Raspberry Pi, nicht den Pico :)
Ich hab den genommen, da ich dort den ELF-File direkt laufen lassen kann
ohne diesen erst zu flashen. Klar ist es Kanonen auf Spatzen. Aber die
Binaries dieser Library werden auch riesig sodass mir ein RPi da auch
entgegen kam.
Ich habe den Code nicht sehr durchflügt, er ist auch sehr groß für "ein
wenig" DCF77 ;) War eher erstmal neugierig wie gut er funktioniert. Ist
lange her, ich erinnere mich nicht wo da der matched Filter steckt.
Ich habe den Code nur erwähnt weil er zum Thema DCF77 Decoder passt und
auch mit matched Filter arbeiten soll. Natürlich ist es eine andere
"Hausnummer" als das Projekt hier auf einem Tiny85, was ich eigentlich
beeindruckender finde weil es auf so einem sehr kleinen Controller
funktioniert.
Bei dem erwähnten Dekoder ist eher die Leistung im Bezug auf das
Dekodieren bei schlechtem Signal beeindruckend.
Nachtrag: Der erwähnte Dekoder wertet auch nicht das analoge Signal der
Antenne aus sondern dekodiert das Ausgangssignal ("Rechteck") eines
DCF77-Empfängers. Das aber wirklich gut.
900ss schrieb:> Nachtrag: Der erwähnte Dekoder wertet auch nicht das analoge Signal der> Antenne aus sondern dekodiert das Ausgangssignal ("Rechteck") eines> DCF77-Empfängers. Das aber wirklich gut.
Aber ist nach einem externen DCF77-Empfänger nicht quasi "alles schon
gelaufen"? Also Du kannst dann z.B. kein Empfang des phasenmodulierten
Signals mehr machen und nicht mehr verschiedene Filter umsetzen etc.
Natürlich sind die gängigen DCF77-Empfangsmodule nicht schlecht, aber
ich denke mit dem PM-Signal kann man evtl. noch ein bischen mehr
rausholen.
Gerd E. schrieb:> mit dem PM-Signal kann man evtl. noch ein bischen mehr rausholen.
Das mag sein, ich kann das ehrlich gesagt nicht beurteilen. Nur
funktioniert der Dekoder beeindruckend gut mit der Auswertung des
Rechtecksignals.
Gerd E.
>Aber ist nach einem externen DCF77-Empfänger nicht quasi "alles schon
gelaufen"?
Dieses Projekt hier verwendet ja Verstärker aus Transistoren, die das
Rohsignal liefern und der Gag an dem Projekt ist ja der digitale Filter
im Attiny.
Beitrag "Re: ATTINY85 als DCF77-Empfänger"
Gerd E. schrieb:> mit dem PM-Signal kann man evtl. noch ein bischen mehr rausholen
Ja! Haben will ;) Das ist doch garkein Vergleich mit einem Pollin-Modul
(nix gegen Pollin). Wenigstens glaube ich das, nachdem ich die Beiträge
hier gelesen hab. Noch dazu müsste so ein Empfänger in der Serie sogar
billiger sein. Warum also gibt es immer noch nur AM-Module? Wo ist der
Fehler? (Ja, für 4-stellige Euro gibt es welche bei Meinberg).
Egal, als Bastler will man so einen Empfänger mit ATTINY realisieren,
weil man es kann! Oder man will aus dem DCF-77 Signal alles rausholen,
was geht. Dann ist ein Cortex-M4 gerade richtig und sicher nicht zu
teuer.
Zwei Fragen hätte ich:
Gibt es irgendwo fertige, abgeglichene Ferritantennen? Und würde das
auch mit fADC = 65536 statt 62000 kHz funktionieren? Dann könnte man
einen Uhrenquarz für den ADC-Takt benutzen.
Bauform B. schrieb:> Warum also gibt es immer noch nur AM-Module? Wo ist der> Fehler?
Das ist eine absolut intelligente Frage. Die Antwort ist: Weil der
Empfang via PM kaum Vorteile bringt. Man kann (bei bekanntem Abstand zum
Sender) damit eine genaueren lokalen Zeittakt erzeugen. Das ist
eigentlich auch schon fast alles.
> Dann ist ein Cortex-M4 gerade richtig und sicher nicht zu> teuer.
Nun, wenn du einen Cortex-M4 dazu brauchst, dann bist du halt einer der
Leute, die mit Hardware prassen, wenn sie die Software nicht nicht
beherrschen. Nunja, Hardware ist billig, also mag das ein akzeptabler
Weg sein. Wenn es um Profit geht, wohl der zu bevorzugende.
> Zwei Fragen hätte ich:> Gibt es irgendwo fertige, abgeglichene Ferritantennen?
Das war schon im Thread Thema: du kaufst einfach eins der billigen
Fertigmodule und lötest die LC-Kombination des Eingangs-Schwingkreises
da raus. Billiger geht nicht, besser auch kaum.
> Und würde das> auch mit fADC = 65536 statt 62000 kHz funktionieren?
Mit Änderungen am Code: ja.
>Und würde das>auch mit fADC = 65536 statt 62000 kHz funktionieren? Dann könnte man>einen Uhrenquarz für den ADC-Takt benutzen.
Manche der STM32 Derivate können bis zu 5MHz ADC Abtastrate. Zusammen
mit einem Sin/Cos Demodulator sollten sich da noch ein paar dB beim
Empfang gewinnen lassen. Allerdings müsste die Software völlig neu
gebaut werden.
Ralph S. schrieb:> Ich habe mit 2 Drosselspulen, 680µH und 330µH, experimentiert und - für> mich unerwartet - lieferte die 330µH Spule die besseren (stabileren)> Ergebnisse. Zur Spule sind 2 Kondensatoren parallel geschaltet, 10nF und> 3.3nF.
Nicht unerwartet wäre es, wenn man die Resonanzfrequenz rechnet.
Ich bin jetzt zu faul für den Taschenrechner, frage Google und finde
https://wetec.vrok.de/rechner/cskreis.htm
330µH und 13,3nF gibt 76kHz, mit 10 + 2,7nF müsste es noch besser
passen.
Für 680µH braucht es 6,2nF um Resonanz bei 77,5kHz zu bekommen.
Gerd E. schrieb:> Aber ist nach einem externen DCF77-Empfänger nicht quasi "alles schon> gelaufen"? Also Du kannst dann z.B. keinEN Empfang des phasenmodulierten> Signals mehr machen und nicht mehr verschiedene Filter umsetzen etc.
Ist das schlimm?
> Natürlich sind die gängigen DCF77-Empfangsmodule nicht schlecht, aber> ich denke mit dem PM-Signal kann man evtl. noch ein bischen mehr> rausholen.
Mit "intelligenten" Algorithmen kann man auch viel holen. Man tastet das
Signal zyklisch ab, z.B. alle 5ms und prüft Fenster. Ist es zwischen 10
und 30, wird es low sein, über 30 ein high. Ist es deutlich über 40,
liegt wohl ein Ausfall vor. Kurze Gewitterpfurze oder Schalterknacken
ist man damit schon mal los. Ist man sich sicher, synchron zu sein, wird
die Abtastung nach dem erkannten Impuls für 750ms gesperrt.
Die Parity-Bits taugen wenig (Doppelfehler), aber nimmt man natürlich
trotzdem mit.
So etwa habe ich das vor ganz vielen Jahren in ASM auf der 6502-CPU
gebaut und mein Spielaufbau mit einem Arduino-Uno ist auch ziemlich
stabil. Wenn ich mal viel Langeweile habe, verfolge ich den weiter.
Da man dank µC rechnen kann, drängt sich noch eine mathematische Prüfung
auf Minute plus eins auf.
Christoph M. schrieb:> Dieses Projekt hier verwendet ja Verstärker aus Transistoren, die das> Rohsignal liefern und der Gag an dem Projekt ist ja der digitale Filter> im Attiny.
Das ist natürlich der Punkt, der diesen Thread zugrunde liegt.
Bauform B. schrieb:> Gibt es irgendwo fertige, abgeglichene Ferritantennen?
Glaube ich nicht. Ich habe mit dem Funktionsgenerator die Resonanz
ermittelt und die Kondensatoren verändet, bis die 77500Hz passen.
Ob S. schrieb:>> Warum also gibt es immer noch nur AM-Module? Wo ist der>> Fehler?> Das ist eine absolut intelligente Frage. Die Antwort ist: Weil der> Empfang via PM kaum Vorteile bringt. Man kann (bei bekanntem Abstand zum> Sender) damit eine genaueren lokalen Zeittakt erzeugen. Das ist> eigentlich auch schon fast alles.
Am Standort der PTB Braunschweig kommt das Signal fast genau eine
Millisekunde zu spät an, 300km vom Sender.
>> Dann ist ein Cortex-M4 gerade richtig und sicher nicht zu>> teuer.> Nun, wenn du einen Cortex-M4 dazu brauchst, dann bist du halt einer der> Leute, die mit Hardware prassen,
Mein erster Rechner war ein cbm3032, dem ich den DCF-Takt an den
Userport geklemmt hatte. In Basic programmiert habe ich nur jede zweite
Minute decodieren können. Umgekehrt hatte ich später mal einen
77,5kHz-Oszillator dran und ein DCF-Signal gefaket. Irgendwo gibt es ein
Raspberry-Projekt, wo der GPS empfängt und daraus DCF simuliert, für
Uhrensammler außerhalb dessen Empfangsbereiches.
von Franz schrieb:
>Bei C<10nF (bzw. L>1000µH) wird der Resonanzwiderstand relativ groß. Ein>beträchtlicher Teil der Spannung wird deshalb vom niederohmigen>Verstärker einfach vernichtet (wäre schade). Solche Schwingkreise>(übliche DCF77-Ferritspulen) sind aber optimal, wenn man die erste Stufe>durch eine hochohmige FET-Stufe (oder ähnliches) ersetzt.
Man kann auch durch eine Anzapfung (1/10) an den niederohmigen
Transistoreingang anpassen. Oder man bringt ein Auskoppelwicklung
so etwa 1/10 der Gesammtwindungszahl drauf.
Das war früher bei Transistor-Taschenradios so standard.
Das erhöht die Güte des Schwingkreises sehr stark.
Günter L. schrieb:> Das war früher bei Transistor-Taschenradios so standard.> Das erhöht die Güte des Schwingkreises sehr stark.
Die üblichen Empfänger-ICs sind CMOS, um Strom zu sparen. Daher ist dort
keine Anpassung nötig.
Stufen mit Bipolartransistoren sollte man aber anpassen oder die erste
Stufe in Kollektorschaltung (Emitterfolger) betreiben.
Die Blinkenlights-DCF77-Library ist kein DCF-Empfänger, sondern eine
hochgenaue Software-RTC für den Controller, die DCF-Synchronisation
beherrscht.
Durch den automatischen Quarzabgleich in Software läuft die RTC tagelang
frei auf wenige PPM genau, wenn DCF empfangen werden kann wird wieder
nachgestellt.
Der Empfänger ist ein normales Modul, der Decoder kann aber aus Scheiße
Gold machen, weil er aufgrund der RTC-Genauigkeit erahnt was kommen muss
und aus dem Gezappel dann DCF dekodieren kann.
Bis sich das eingespielt hat dauert es je nach Qualität des Signals 3-30
Minuten bis zur korrekten Zeit und dann nochmal ein Tag für die
Quarzabstimmung, und dabei ist es fast egal wie das Signal zappelt.
Er hofft also nicht auf ein auswertbares Signal und läuft frei sondern
kann tatsächlich gestörtes Signal korrigieren und läuft gekoppelt, so
das der Ausgang der RTC der "echten" Zeit möglichst genau nachläuft.
Ja, ein Standard-Empfangsmodul hat Signalverzögerungen und Jitter, die
werden aber ausgemittelt, man bekommt also am Standort die genaueste
Zeit die mit diesen Mitteln möglich ist.
Das Ding ist wirklich ein Wunderwerk, hat aber mit dem hier
vorgestellten nicht wirklich was zu tun.
Wenn man sich mal eben eine Uhr mit Arduino und DCF zusammenkloppen
will, sollte man ernsthaft die Blinkenlights-Lib ins Auge fassen, weil
es damit einfach geht und so gut ist wie möglich. Da braucht man sich um
das Modul, die Ausrichtung und den Standort beinah keine Gedanken mehr
zu machen, das funktioniert auch da wo es für's Auge und viele andere
Uhren nichts mehr zu sehen gibt.
Plus das die Kiste auch ohne Empfang (aber das zu bekommen ist schwer!)
sehr genau weiterläuft. 1PPM meine ich schafft er, aber natürlich machen
Temperaturverläufe und so das kaputt.
Jens M. schrieb:> Die Blinkenlights-DCF77-Library ist kein DCF-Empfänger, sondern eine> hochgenaue Software-RTC für den Controller, die DCF-Synchronisation> beherrscht.> Das Ding ist wirklich ein Wunderwerk, hat aber mit dem hier> vorgestellten nicht wirklich was zu tun.
Die lib ist ein Wunderwerk, das Prinzip ist eigentlich naheliegend und
die einzig vernünftige Methode. Nur nicht so ganz trivial zu
implementieren.
1
The best way to get rid of noise is of course by “cheating”. That is:
2
if the signal is known in advance then there is nothing to decode.
3
The only thing that remains is to determine the phase of the signal.
4
With other words: the received signal is matched against an already
5
known wave form.
Jetzt müsste man nur noch die Software-RTC durch eine Hardware-RTC
ersetzen und den AM-Empfänger durch den PM-Empfänger. Dann passt es auch
wieder in diesen Thread ;)
>Die lib ist ein Wunderwerk, das Prinzip ist eigentlich naheliegend und>die einzig vernünftige Methode.
Es gibt verschiedene Ebenen: Wenn ich es richtig sehe, bezieht sich die
Lib auf die Auswertung des digitalen Zeitsignals.
Das besondere an der Attiny-Version ist allerdings der Demodulator als
extrem scharfbandige Filter für das Analogsignal.
Ja, das sehe ich auch so.
Bauform B. schrieb:> ...implementieren.The best way to get rid of noise is of course by> “cheating”. That is:> if the signal is known in advance then there is nothing to decode.> The only thing that remains is to determine the phase of the signal.> With other words: the received signal is matched against an already> known wave form.> ...
Der Autor von Blinkenlight meint mit "phase of the signal" nicht die
77500Hz-Phase sondern die der Bits. Aber die wird vom TO auch (nebenbei)
"predicted": Die Phase vom Signal ist die blaue Linie im ersten
Thread-Post. Die wird statistisch über viele_Sekunden ermitteln. Ab
diesem Zeitpunkt/Phase werden dann genau 100ms vom Signal verwendet um
das Bit zu bestimmen.
Zur Frage nach der Herstellung einer magnetischen Antenne (oben „Spule“
genannt): Hat man einen so tollen (langen und querschnittsreichen)
Ferritstab ist es wohl das beste, einen Spulenträger passend
3D-zu-drucken und diesen mithilfe eines Akkuschraubers zu bewickeln.
Eine gute Antenne ist der beste HF-Verstärker.
Normalerweise lassen sich (einteilige) Spulenträger mit einem einfachen
„Wurstleger“ sehr schlecht drucken: Überall Stützen erforderlich, die
sich nur schwer entfernen lassen. Der Trick ist, den Spulenträger 45°
geneigt zu drucken: Stützen nur auf dem Druckbett. Mit 45-°-Überhängen
kommen Drucker heutzutage zurecht, wenn's nicht schön aussehen muss.
Der Vorteil eines Spulenträgers ist zweifelsohne die exakte
Abstimmbarkeit auf 77,5 kHz ohne Drehkondensator: Die Spule wird auf dem
Stab zum Rand hin verschoben, um die Induktivität leicht zu senken und
damit die Resonanzfrequenz zu erhöhen. Und dann mit Kleber fixieren.
Die Chinesen wickeln die Spule auf einen zerlegbaren Spulenträger aus
Teflon und fixieren die Wicklung im Grobvakuum mit kapillarfüllendem
Harz oder Sekundenkleber. Die Spule hält dann ohne Träger und wird unter
Abstimmung auf den Ferritkern geschoben. Das reduziert das Einbauvolumen
der Antenne (minimaler Abstand der inneren Lage zum Kern), senkt den
Kupferverbrauch, steigert die Güte und sieht ganz nebenbei auch noch
schön aus.
Für maximale Güte = Trennschärfe ist es richtig, den Resonanzkondensator
direkt an die Spule zu setzen. Bei langer Anschlussleitung sollte direkt
ein SFET als Sourcefolger folgen; ansonsten ist die Kabelkapazität des
geschirmten Kabels mit einzurechnen.
Warum denn unbedingt den 3D-Drucker bemühen, wenn es ein paar Lagen
Papier auch tun:
* Mit einem breiten Streifen Papier 2 Lagen auf den Ferritstab wickeln
und nur an den Enden mit Klebeband fixieren.
* Mit einem zweiten, schmaleren Streifen Papier zwischen den Fixierungen
zwei weitere Lagen aufbringen und verkleben.
* Auf dieser zweiten Lage die Spule wickeln.
* Von der ersten Lage das Klebeband entfernen und das Papier zwischen
Ferritstab und zweiter Papierlage entfernen.
Fertig ist die auf dem Ferritstab verschiebbare Spule.
Henrik H. (Firma: TU Chemnitz) (heha)
26.01.2025 01:23
>Zur Frage nach der Herstellung einer magnetischen Antenne (oben „Spule“>genannt): Hat man einen so tollen (langen und querschnittsreichen)>Ferritstab ist es wohl das beste, einen Spulenträger passend>3D-zu-drucken
Hast du dir Gedanken zum notwendigen Durchmesser und Anzahl der
Windungen gemacht?
Christoph M. schrieb:> Hast du dir Gedanken zum notwendigen Durchmesser und Anzahl der> Windungen gemacht?
Für einen 8 x 200 mm Ferritstab habe ich eine Spule mit 130 Windungen
CuL 0,3 mm gewickelt. Die Schwingkreiskapazität beträgt dabei 3nF für
77,5 kHz.