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? ;-)
(Ich hatte den Fehler zu spät bemerkt.) Es ist der Abstand der Antenne zur linken CCFL-Monitor-Kante. Viel Aussagekraft hat der Test natürlich nicht.
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.
Die Schaltung finde ich wirklich interessant. Welche Werte haben den Lxx und Cxx? Bei der Spule sehe ich die größte Schwierigkeit.
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.
:
Bearbeitet durch User
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.
Was kommt denn genau aus der Uart raus? Das könnte dann die "fertig für 5€" wieder wettmachen.
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 Ostern Beitrag "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) + ... |
anders geschrieben...
1 | a = ADC0*cos(0*90°) + ADC1*cos(1*90°) + ... |
2 | b = ADC0*sin(0*90°) + ADC1*sin(1*90°) + ... |
nochmals anders geschrieben..
1 | a = ADC0*(+1) + ADC1*( 0) + ADC2*(-1) + ADC3*( 0) + ADC4*(+1) + ... |
2 | b = ADC0*( 0) + ADC1*(+1) + ADC2*( 0) + ADC3*(-1) + ADC4*( 0) + ... |
und nocheinmal...
1 | a = ADC0 - ADC2 + ADC4 ... |
2 | b = + ADC1 - ADC3 ... |
( 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?
:
Bearbeitet durch User
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?
Noname schrieb: > Kann ich allein durch Abtastung ein IQ-Signal aus dem reellen Signal > gewinnen? Ja, nennt sich Direct Sampling Receiver.
>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.
@ chris_ und Mario M. Danke für eure Erklärungen. Werd mich mal einlesen.
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.
@chris_ Wäre ja nett wenn du deinen Aufbau, Schaltung und Code auch einmal hier zur Verfügung stellst.
:
Bearbeitet durch User
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/
Fängt die nicht erst hinter dem Fertigmodul an, das damit getestet werden soll?
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.
Hier noch eine für mich sehr erstaunliche Sache: Die Funkmaus stört den Empfänger und zwar auch bei ausgeschaltetem Zustand.
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?
Franz schrieb: > Auch dieser PM-Empfänger macht gegenüber einem Fertigmodul wenig Sinn. Am Wochenende kannst du noch NAVTEX und die Wetterberichte aus https://de.wikipedia.org/wiki/Sendeanlage_Pinneberg einbauen, dann ergibt alles einen Sinn :-)
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)
Dieses Projekt auf einem ATTINY aus Spaß (!) zu machen - naja. In ASM wärs SM.
>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.
c-hater schrieb: > Mit Assemblern hat man noch sehr viel mehr Luft. Das wissen alle. Machen, nicht labern.
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 ### |
3 | // |
4 | // - Hardware |
5 | // STM32F103C8 - "Blue Pill Development Board" |
6 | // |
7 | // - Anschlüsse |
8 | // GPIO-PA7: Antenneneingang: 147.3 MHz, mind. 0.1mV |
9 | // 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!
Ist ja etwas OT, aber vielen Dank, hoffentlich komme ich bald zum Nachbau. In deiner main.c muss KHz, nicht MHz stehen (2x) ;-) 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? DWD: http://websdr.ewi.utwente.nl:8901/?tune=147.3am DCF77: http://websdr.ewi.utwente.nl:8901/?tune=77.5am Antenne: https://www.pa3fwm.nl/projects/miniwhip/ Das Forum hat schon ein paar Threads: https://www.mikrocontroller.net/search?query=navtex Guten Abend.
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.
:
Bearbeitet durch User
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/
:
Bearbeitet durch User
... 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: > Wo habt ihr die schönen Antennen her. https://www.pollin.de/p/dcf-empfangsmodul-dcf1-810054 SCNR :-)
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.
Frank M. schrieb: > Ralph S. schrieb: >> Wo habt ihr die schönen Antennen her. > > https://www.pollin.de/p/dcf-empfangsmodul-dcf1-810054 > SCNR :-) Smile Frank... :-) sehr super. Da kann ich mir super eine Antenne herausschlachten :-) :-) :-)
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 :-)
:
Bearbeitet durch Moderator
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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.
Ralph S. schrieb: > Wo habt ihr die schönen Antennen her anscheinend braucht man garkeinen Ferritkern, deshalb sollten 125kHz RFID Spulen fast perfekt funktionieren. Und: wie groß wäre der Unterschied zu "aufgewickeltem Draht" z.B. für Lautsprecherweichen? Beitrag "DCF77 Selbstbauempfänger" https://www.pollin.de/p/luftspule-250324 https://www.reichelt.de/de/de/shop/produkt/visaton_sp-spule_1_0_mh_0_6_mm-24237
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.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.