Übersicht serieller Grafik-LCD's?

    Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

    Aufgrund technischer Veränderungen ist der Mailverkehr innerhalb des Forums (Private Nachrichten) nur noch eingeschränkt möglich. Die Einschränkung ist notwendig, um zusätzliche Betriebskosten für das Forum zu vermeiden. Näheres zu den Hintergründen im Thread "Aktuelles zum Forum".Wir bitten um Verständnis.

    Hinweis kann nach Kenntnisnahme deaktiviert werden!

    • Hallo!

      Mitch64 schrieb:

      DG7GJ schrieb:

      Und das auch nur in der Hoffnung das bei einer Restspannung von 1,6V (wo er noch sendet!) die Reset-Auswertung überhaupt noch funktioniert.
      Im Datenblatt steht, dass der Betriebsspannungsbereich 1,8 bis 3,3 Volt sein soll.Wenn da dann nur 1,6V dran sind, darf das Modul auch "spinnen"!

      Aber wie tief fällt denn deine Spannung ab und warum?

      War letztens eine zufällige Entdeckung:
      Beim vorletzen zerlegen des Repeaters zwecks Antennenkontrolle habe ich beim anschließenden Zusammenbau die Repearerplatine versehentlich versetzt auf die im Steckergehäuse eingeklebte Stiftleiste gedrückt.
      Gute 2,5 Wochen war das Teilchen dann zwar häufig in der Steckdose, wurde aber dennoch nicht geladen.
      Als mitte letzte Woche dann mein Terminal anfing tausende "RSSI-Timeouts" zu melden, entdeckte ich den Schlamassel.
      Repeater war auf Dauersenden und an Vcc konnte ich knapp 1,6xV messen.
      Dumm, somit hat die LiPo ihre erste fatale Tiefentladung wech, wovon sie sich aber augenscheinlich wieder erholt hat.

      Generell ist es aber ein Problem bei Batteriebetriebenen Projekten. Beherrschbar wenn man diese Gefahr berücksichtigt und schaltungstechnisch sicherstellt das die RFM69 definitiv still bleibt wenn der µC nicht mehr funktioniert.



      Mitch64 schrieb:

      Ich würde Pakete in einem Frame senden. Heißt da gibt es ein definiertes Startbyte und ein definiertes Schlussbyte. Checksumme (CRC) ist das
      letzte Byte vor den Schlussbyte.
      So könnte man, wenn man schon im Fifo suchen will, einfach nach dem Startbyte suchen. Ist das gefunden, zu prüfen, ob das Schlussbyte auch vorhanden ist (Offset 25). Dann die Daten nehmen und mit CRC verrechnen.
      Diese Vorgehensweise würde vermutlich weniger Rechenleistung (Zeit) abverlangen, als zig mal eine CRC-Berechnung durchzuführen, bis die CRC-Summe stimmt.

      Habe ich auch schon dran gedacht, ist aber nicht so einfach.
      Die Müll-Bytes am Anfang des FIFO's sind eher zufällig, warscheinlich durch Rauschen verursacht.
      Die meißten Bytes in meinem Paket können auch eher zufällig sein, da es eben Rohdaten.
      Ein wie auch immer definiertes Startbyte könnte also zigmal an beinahe beliebiger Stelle auftreten.

      Aber wie dem auch sei:
      Ob ich eine Korrektur versuche, oder einfach durch Nichtaussendung des nötigen Ack's das Paket nochmals senden lasse, weis ich noch nicht.
      Das mache ich später Abhängig von der maximalen Rechenzeit im Vergleich zur nochmaligen Übertragung.

      Ein weiteres Problem nervt mich gerade gewaltig, nämlich die Zuverläsigkeit meiner Referenzuhr.
      Seit Samstag Abend steckt der Repeater in der vorgeplanten Steckdose.
      Genau die Steckdose wo ich schon rumoptimiert habe, damit dort zumindestens halbwegs zuverlässig DCF77-Empfang möglich ist.

      Was soll ich sagen:
      Heute morgen dann auf das LCD des Terminals geschaut...Zeit stimmte. Beim exakteren vergleich maximal eine Abweichung von +0,2-0,3s zu meiner komerziellen Funkuhr am Monitor.
      Im Echtzeitlog dann aber die ernüchterung.
      Von Samstag Abend bis heute morgen schaffte der Repeater keine einzige DCF-Synchronisierung.
      Byte 22 stand auf h1F entsprechend 31 Stunden ohne DCF77-Sync.
      Der minütliche Zeitstempel kam dann am Terminal nicht so an wie gedacht:
      08:10:00
      08:11:00
      08:12:00

      sondern:
      08:10:09
      08:11:09
      08:12:09

      Wie ich vor einigen Tagen (Posting 74, letzter Absatz) ankündigte habe ich schon ein Experimentierentwurf um mich mal komplett und grundlegend neu damit auseinander zu setzen.
      Das Teil hat auf jeden Fall schon mal drei Antennenschnittstellen wo ich zum Vergleich der üblichen Ferritkern-Antennen auch noch undefinierte Signaladern (im Stromnetz z.B. den PE oder sonstige Kabel) als Antenne testen will, sowie eine miniaturisierte Aktivantenne.
      Statt dort einen DDS oder eine PLL drauf zu pappen habe ich mich für ein Direktmischer entschieden.
      Mischfrequenz soll vom Timer kommen und das Signal auf wenige 100Hz herab mischen.

      Und das wichtigste:
      Alternative Zeitzeichensender!
      Neben DCF77 auf 77,5kHz gibt es nämlich noch DCF49 (127,5kHz) und DCF39 (138,5kHz) die Zeitstempel aussenden welche mit DCF77 synchron laufen. Jedoch in mehrfacher Hinsicht Effektiver:
      DCF49 und DCF39 haben grob die selbe Sendeleistung wie DCF77, jedoch durch die zwei unterschiedlichen Senderstandorte eine weitere Ausleuchtung:
      DCF49 steht am gleichen Standort wie DCF77, in Mainflingen/Frankfurt, sowie DCF39 bei Burg/Magdeburg.
      Und das Sendeformat ist deutlich günstiger:

      Während bei DCF77 die 58 Bits mit 1Baud in 58 Sekunden empfangen werden müssen, wo schnell einzelne Impulse (Gewitter, lokale Funkenstörungen wie Lichtschalter u.v.m.) Fehlauswertungen verursachen, senden die DCF39/49 ein 200Bd FSK Signal wo alle 10 Sekunden ein DCF77-exakter Zeitstempel mit Uhrzeit, Zeitzone, Datum ausgestrahlt wird.
      Sieht dann grob so aus wie der Screenshot im Anhang (aktueller Mitschnitt von DCF49).

      Statt also mindestens 60 Sekunden (CHECK=0) oder sogar 180 Sekunden (CHECK=2) durchweg feherfreien Empfang wie man ihn für DCF77 brauchte, brauch mal bei DCF39/49 nur 10 Sekunden (ähnlich CHECK=0) bis 30 Sekunden (ähnlich CHECK=2).

      Will da demnächst mal experimentell schauen was da effizienter geht und den dadurch gefundenen Alternativweg versuchen zu optimieren bezüglich Größe und Strombedarf.

      Grüße

      Jürgen
      Dateien
      • Screen4.jpg

        (132,63 kB, 10 mal heruntergeladen, zuletzt: )
    • DG7GJ schrieb:

      Habe ich auch schon dran gedacht, ist aber nicht so einfach.
      Die Müll-Bytes am Anfang des FIFO's sind eher zufällig, warscheinlich durch Rauschen verursacht.
      Die meißten Bytes in meinem Paket können auch eher zufällig sein, da es eben Rohdaten.
      Ein wie auch immer definiertes Startbyte könnte also zigmal an beinahe beliebiger Stelle auftreten.
      Die Müllbytes kann man mit einer sogenannten Preamble umgehen (4 oder 5 Byte $AA senden als Beispiel). Dann kann sich der Empfänger auf den Empfang einstellen. Dann erst kommt das Startbyte mit den Daten, CRC und den Endbyte. Beim Empfang reagiert man nicht auf auf die Bytes, auch nicht auf die Preamble. Sondern erst mit dem erkennen des Startbytes werden dann Daten in den Buffer geschriegen. Du liest ja den integrierten Fifo vom RFM-Modul aus. Da kommen also Müllbytes, dann die Preabmle ($AA) und dann das Startbyte. Jetzt brauchst du ja nur die Bytes, die nach dem Startbyte kommen in ein Array übertragen (die vor dem Startbyte ignorieren), bis ein Stopbyte empfangen wird. Das landet aber nicht in dem Array, sondern triggert das Prüfen den Pakets. Z. B. per Flag. Stimmt die CRC, kann das Paket verarbeitet werden.

      Schau mal in der Bascom-Hilfe (ASCII-Chart) da gibt es für Startbyte STX ($02) und für das Endebyte das EOT ($04). Sowas verwende ich meist.


      DG7GJ schrieb:

      Alternative Zeitzeichensender!
      Neben DCF77 auf 77,5kHz gibt es nämlich noch DCF49 (127,5kHz) und DCF39 (138,5kHz) die Zeitstempel aussenden welche mit DCF77 synchron
      Ist ja schön, wenn es Alternativen gibt. Aber wenn man nicht alle einbauen will, muss man sich für eins entscheiden.
      Ich denke für die unterschiedlichen Varianten ist auch ein unterschiedlicher Empfänger notwendig. Und die Dekodierung ist noch ein Thema, falls das Modul die Zeit nicht in Klartext ausspuckt.
    • Hi Mitch64!

      Mitch64 schrieb:

      DG7GJ schrieb:

      Habe ich auch schon dran gedacht, ist aber nicht so einfach.
      Die Müll-Bytes am Anfang des FIFO's sind eher zufällig, warscheinlich durch Rauschen verursacht.
      Die meißten Bytes in meinem Paket können auch eher zufällig sein, da es eben Rohdaten.
      Ein wie auch immer definiertes Startbyte könnte also zigmal an beinahe beliebiger Stelle auftreten.
      Die Müllbytes kann man mit einer sogenannten Preamble umgehen (4 oder 5 Byte $AA senden als Beispiel). Dann kann sich der Empfänger auf den Empfang einstellen. Dann erst kommt das Startbyte mit den Daten, CRC und den Endbyte. Beim Empfang reagiert man nicht auf auf die Bytes, auch nicht auf die Preamble. Sondern erst mit dem erkennen des Startbytes werden dann Daten in den Buffer geschriegen. Du liest ja den integrierten Fifo vom RFM-Modul aus. Da kommen also Müllbytes, dann die Preabmle ($AA) und dann das Startbyte. Jetzt brauchst du ja nur die Bytes, die nach dem Startbyte kommen in ein Array übertragen (die vor dem Startbyte ignorieren), bis ein Stopbyte empfangen wird. Das landet aber nicht in dem Array, sondern triggert das Prüfen den Pakets. Z. B. per Flag. Stimmt die CRC, kann das Paket verarbeitet werden.
      Schau mal in der Bascom-Hilfe (ASCII-Chart) da gibt es für Startbyte STX ($02) und für das Endebyte das EOT ($04). Sowas verwende ich meist.

      Hab ich doch..:-)
      Als erfahrener Funktechniker (offenbar einige der wenigen in Deutschland die sogar noch das alte Bosch DigiS kennen und supporten) ist mir der prinzipielle Funktionsaufbau von FFSK bekannt und wird auch angewendet.
      Das sogenannte Dotting bzw. Preamble zwecks Timing/Synchronisierung des asynchronen Datenstroms (immer b010101, also h55 oder hAA) sende ich mit der Konfiguration in den Register h2C - h2E mit 3 byte (24Bit).
      Das anschließende Synchronisationswort, also die "Systemkennung" besteht bei mir aus h22F7, so definiert in den Register h2F- h30.
      Dann kommt mein Nutzdatenpaket (payload) mit 25Bytes, das letzte davon eine eigene CRC8.

      Der RFM69 hat wie viele aktuelle RFM's eine Packet-Engine eingebaut, welche die alten Vorläufer (RFM12 usw.) nicht kannten.
      Diese Packet-Engine kümmert sich - wenn anständig eingestellt, um folgendes:

      Bei senden packt er vor den Nutzdaten im FIFO (bei mir 25Bytes) automatisch die gewünschte menge Preamble (3 x hAA) sowie das gewünschte Syncronisationswort (h22F7) davor und berechnet über die 25Bytes Nutzdaten zusätzlich eine CRC-16 und hängt diese an.
      Um das Timing welches beim Dotting gemessen wurde nicht aus dem Takt zu bringen muss der Datenstrom halbwegs DC-frei sein. Die Anzahl der aufeinanderfolgenden gleichpeleigen Bits (111111 oder 000000) darf nicht zu hoch sein.
      Da ich bei meinen Rohdaten aber nicht ausschließen kann das mitunter mehrere Bytes aufeinanderfolgend h00 oder hFF haben, nutze ich noch die Funktion Whitening.
      Eine Datenmanipulation welche für eine ausgewogene High-Low-Gewichtung mit ausreichend Änderungen sorgt.
      Diese 3 + 2 + 25 + 2 = 32 Bytes werden dann ausgesendet.

      Auf der Empfängerseite Will der RFM69 das selbe können, vollkommen autonom:
      Sobald er ein Paket empfängt schreibt er alles in das FIFO.
      Anschließend wird, falls konfiguriert die Datenmanipulation des Whitening beseitigt, dann die CRC16 geprüft.
      Die CRC16 selbser sowie eventuell nachfolgend aufgeschnappte Bytes sollen im FIFO auf h00 gesetzt werden.
      Am Anfang des FIFO's sollen auch alle nicht zur Payload gehörenden Bytes abgeschnitten werden.

      Das ganze ist nur soweit transparent für den User, so weit die Registerprogrammierung es zulässt.
      Als User hat man z.B. nicht mal die Möglichkeit die vom RFM69 verwendete CRC16 zu lesen, weil sie nie abrufbar ist.

      Das eigendlich kuriose an meinem Effekt ist:
      Wie oben umschrieben funktioniert das bei mir in gefühlt etwa 95% aller Fälle.
      Die restlichen 5% aller pakete werden gar nicht empfangen (also kein CRCok-INT), oder aber verschoben empfangen.
      Wie berets dargestellt sind in diesen Fällen Mülldaten vor und nach meinem Paket, welche weder meine Preambel noch mein Synchronisationswort enthalten.
      Ganz im Gegenteil, 1-30Bytes die für mich nach zufälligem Rauschen aussehen, denn das Dotting oder das Syncwort würde ich sofort erkennen - ist da aber nicht vor.
      Gut, ob die letzten zwei Müllbytes hinter meinem Payloadpaket nun eventuell die CRC16 der RFM sein könnte, habe ich bislang noch nicht gecheckt.

      Wie dem auch sei:
      Ich habe mich schon in der Planungphase auf ein konkretes Paketprotokoll festgelegt welches auf die Erfordernisse angemessen sind.
      So sollen die bis zu 14 Sensoren ihre Meßwerte minütlich zum Repeater senden, wozu jeder Sensor einen möglichst exakten Timeslot von maximal 2 Sekunden treffen soll.
      Sensor 1 hat z.B. ein Zeitfenster von Sekunde 3-5, Sensor 2 von Sekunde 6-8, der letzte Sensor 14 hat sein Sendefenster von Sekunde 42-44.
      Daran fügt sich(45-47) dann der Timeslot für das Terminal, wird nur genutzt wenn Parameter umkonfiguriert werden müssen (aktivieren, deaktivieren von einzelnen Sensoren).
      Der Zeitbereich von Sekunde 48-02 gehört ausschließlich dem Repeater.

      Und genau dieses Prinzip wankt gerade etwas, weil die Referenzuhr trotz mühseligen und monatelangen Langzeitabgleich nun nicht mehr +-2sek in 7 Tagen sondern plötzlich +9s in nicht mal 1,5 Tagen zeigt...brrrr

      Mitch64 schrieb:

      Ist ja schön, wenn es Alternativen gibt. Aber wenn man nicht alle einbauen will, muss man sich für eins entscheiden.Ich denke für die unterschiedlichen Varianten ist auch ein unterschiedlicher Empfänger notwendig. Und die Dekodierung ist noch ein Thema, falls das Modul die Zeit nicht in Klartext ausspuckt.

      Vom Empfänger her gibt es keinen Unterschied, nur die Software muss eben beides können.
      Es ist eben nur der Unterschied ob man nun mittels geeignetem Timer die 100/200ms-Lücken vom DCF77 misst, oder eben die Nulldurchgänge eines 200Bd Signals.

      Das angedachte Empfängerprinzip ist simpel und uralt:
      Man nimmt das Antennensignal, verstärkt es, und mischt es mit einer Frequenz die sehr nahe daneben liegt.
      Dieses könnte z.B. von einem Timer kommen (Timer1).
      Für DCF77 bräuchte man ca. 77kHz
      Für DCF49 bräuchte man ca. 127kHz
      Für DCF39 bräuchte man ca. 138,5kHz

      Alle Signale würden so direkt auf NF (Träger auf schnarchlangsame 500Hz) gemischt werden.
      Die DCF77-Routine müsste dann die 100/200ms-Lücken im 500Hz-Signal erkennen.
      Die FSK-Routine müsste messen ob und wie lange der 500Hz-Ton auf 840Hz springt.

      Das es solch eine Kombination noch nicht fertig gibt mag damit zu tun haben das die EFR-Systeme weitaus weniger bekannt sind wie DCF77. EFR-Empfänger können bislang auch kein DCF77.

      Wer mal reinhören möchte, aber keinen geeigneten Langwellenempfänger hat, kann z.B. hier reinschnuppern:

      DCF77 auf 500Hz : websdr.ewi.utwente.nl:8901/?tune=77usb
      DCF49 auf 500Hz : websdr.ewi.utwente.nl:8901/?tune=128.5usb

      DCF39 auf 500Hz : websdr.ewi.utwente.nl:8901/?tune=138.5usb

      Naja, das ist aber eine Baustelle die erst irgendwann im Laufe des restlichen Jahres auf meiner ToDo-Liste steht.

      Grüße

      Jürgen
    • DG7GJ schrieb:

      Wie dem auch sei:
      Ich habe mich schon in der Planungphase auf ein konkretes Paketprotokoll festgelegt welches auf die Erfordernisse angemessen sind.
      So sollen die bis zu 14 Sensoren ihre Meßwerte minütlich zum Repeater senden, wozu jeder Sensor einen möglichst exakten Timeslot von maximal 2 Sekunden treffen soll.
      Sensor 1 hat z.B. ein Zeitfenster von Sekunde 3-5, Sensor 2 von Sekunde 6-8, der letzte Sensor 14 hat sein Sendefenster von Sekunde 42-44.
      Daran fügt sich(45-47) dann der Timeslot für das Terminal, wird nur genutzt wenn Parameter umkonfiguriert werden müssen (aktivieren, deaktivieren von einzelnen Sensoren).
      Der Zeitbereich von Sekunde 48-02 gehört ausschließlich dem Repeater.
      Wenn Sender in einem festgelegten Zeitsplot daten senden sollen, dann müssen die Slots immer synchron gehalten werden.
      Das leuchtet ein. Jeder Quarz ist anders, also gibt es Drift, die irgendwann zu groß wird und der Timeslot nicht mehr passt. Also braucht jeder Slot-abhängige eine Synchronisierung. Entweder jeder eine eigene DCF. Oder der Master sendet z.B. alle 5 Minuten ein Sunc-Paket. Darauf können dann die Sender ihre innere Uhr nachstellen, damit der Slot wieder passt. Dann braucht nur ein Gerät eine DCF. Also beispielsweise der Repeater. Und der könnte sogar drauf verzichten, sofern eine Uhrzeit für die empfangenen Daten nicht so die Prio hat.

      Also ob die Tempoeratur jetzt von 7:00 Uhr oder von 7:01 Uhr ist. Hängt aber immer vom Fall ab.

      DG7GJ schrieb:

      Alle Signale würden so direkt auf NF (Träger auf schnarchlangsame 500Hz) gemischt werden.
      Die DCF77-Routine müsste dann die 100/200ms-Lücken im 500Hz-Signal erkennen.
      Die FSK-Routine müsste messen ob und wie lange der 500Hz-Ton auf 840Hz springt.
      Wie solche Teile funktionieren ist mir schon klar. Bin ja auch Funkelektroniker.

      Fragt sich nur, ob der Aufwand da mit den ganzen Varianten von DCF Sinn macht.
      Vielleicht braucht es keine Senkundengenaue Uhr? Vielleicht reicht es, wenn die Uhr beim Abrufen der Daten mit dem PC synchronisiert werden? Alternativ gabs hier auch mal ein Thema bezüglich GPS-Datendekodierung. Ist ein serielles Signal, Text, mit Uart lesbar. Je nach Standort von dem Repeater wäre das vielleicht auch eine alternative.

      Gruß Mitch

      Nachtrag:
      Hier der Link zum Thema
    • Hallo Mitch!

      Mitch64 schrieb:

      Wenn Sender in einem festgelegten Zeitsplot daten senden sollen, dann müssen die Slots immer synchron gehalten werden.Das leuchtet ein. Jeder Quarz ist anders, also gibt es Drift, die irgendwann zu groß wird und der Timeslot nicht mehr passt. Also braucht jeder Slot-abhängige eine Synchronisierung. Entweder jeder eine eigene DCF. Oder der Master sendet z.B. alle 5 Minuten ein Sunc-Paket. Darauf können dann die Sender ihre innere Uhr nachstellen, damit der Slot wieder passt. Dann braucht nur ein Gerät eine DCF. Also beispielsweise der Repeater. Und der könnte sogar drauf verzichten, sofern eine Uhrzeit für die empfangenen Daten nicht so die Prio hat.

      Also ob die Tempoeratur jetzt von 7:00 Uhr oder von 7:01 Uhr ist. Hängt aber immer vom Fall ab.
      Jawoll, deshalb habe ich das auch so gelöst das meine Referenzuhr ihren Zeitstempel zu jeder Sekunde 0 aussendet.
      Aufgrund der probleme mit stunden bis fagelangen DCF-Empfangsproblemen eben mit einem Qualitätsmerkmal.
      Das ursprünglich als Repeater-Status geplante Byte 22 im Paket enthält nun einen Stundenzähler der bei erfolgreicher DCF-Synchronisierung gelöscht wird.

      Erst mal, in diesem Stadium haben die anderen Geräte (Terminal und Sensoren) die Anweisungen ihre RTC nur mit dem Repeater zu synchronisieren wenn dieser Stundenzähler h00 ist. Ist aber auch erst eine Notlösung.

      Mitch64 schrieb:

      Fragt sich nur, ob der Aufwand da mit den ganzen Varianten von DCF Sinn macht.Vielleicht braucht es keine Senkundengenaue Uhr? Vielleicht reicht es, wenn die Uhr beim Abrufen der Daten mit dem PC synchronisiert werden? Alternativ gabs hier auch mal ein Thema bezüglich GPS-Datendekodierung. Ist ein serielles Signal, Text, mit Uart lesbar. Je nach Standort von dem Repeater wäre das vielleicht auch eine alternative.

      Für das aktuelle Projekt erst mal nicht, da muss ich mir was anderes einfallen lassen. GPS-Empfang ist am Einsatzort alles andere als garantiert (mehrere Betonwände drummherrum). Sowohl meine alten Meastro A2200-A als auch die NEO6M die ich seit knapp 2 Wochen habe, scheinen zwar erstaunlich empfindlich zu sein, aber für den Anwendungsfall bzw. Örtlichkeit befürchte ich das GPS eine Krücke wäre die sich zum Schluss als ähnlich zuverlässig entpuppt wie das DCF-2 welches aktuell im Repeater sitzt. Wird wohl eher dann darauf hinauslaufen das ich wohl noch den I²C abgreife und schaue wo im Steckergehäuse noch nen DS323-Breakoutbord hinquetschen kann.
      Müsste ich dann halt nur in Software die Sommerzeit/Winterzeit-Anpassung berücksichtigen, was ich eigentlich dem DCF-Modul überlassen wollte.

      Das angesprochene DCF-Testprojekt soll primär meinen Erkentnissgewinn pushen.
      Auf der einen Seite will ich möglichst bei zukünftigen Projekten weg von diesen überteuerten Schranzmodulen DCF-1 (Pollin) und DCF-2 (ELV). Eben weil sie m.E. ihren Preis nicht wert sind.
      Ich weis nicht woran es liegt, vermute aber das die Antennenkreisabstimmung enorm daneben liegt.
      Auch das Ferritmaterial des Kerns misstraue ich etwas.
      Zumindest habe ich vor Monaten, bevor mein Entschluss viel doch mal soein DCF-Zeitempfänger neu zu erforschen, mal diverse Antennen von den DCF-1 und DCF-2 durchgemessen.
      Das Maximal der Empfindlichkeit lag, wenn ich mich noch richtig erinnere beim DCF-2 bei ca. 85kHz und beim DCF-1 auf 65kHz.

      Sowas ist bei derart schmalbandigen Antennen wie Ferritkernen weit mehr als Suboptimal sondern eher tödlich.

      Ich erhoffe mir einen Erkentnissgewinn zu einer neuen DCF-Lösung abseits der Fertigmodule mit mehr Zuverlässigkeit und mehr Funktionen und beliebig parametrierbar: Festgenagelt auf einen Sender, oder automatische Wahl des am besten empfangbaren aller drei verfügbaren usw.
      Muss ich mal schauen wann ich dazu komme.

      Grüße

      Jürgen
    • DG7GJ schrieb:

      Zumindest habe ich vor Monaten, bevor mein Entschluss viel doch mal soein DCF-Zeitempfänger neu zu erforschen, mal diverse Antennen von den DCF-1 und DCF-2 durchgemessen.
      Das Maximal der Empfindlichkeit lag, wenn ich mich noch richtig erinnere beim DCF-2 bei ca. 85kHz und beim DCF-1 auf 65kHz.
      Ich schätze dich als einer ein, der von HF mehr Ahnung hat als ich. Und ganz besonders was die Praxis angeht mit Impedanzen, Anpassungen, Verkürzungsfaktoren usw.
      Aber wenn die Abstimmfrequenz von der Ferrit-Antenne so daneben liegt, kannst du die nicht nachstimmen durch verschieben der Spule auf dem Ferrit?

      Ich habe jetzt weil ich kein HF-Freak bin auch keine Messgeräte und Antennen auszumessen. Nur ein HF-Mini-Analyzer habe ich, und der geht erst bei 1MHz los. Ich Habe ein Oszi mit integriertem Funktionsgenerator.

      Kann man damit die Antenne ausmessen?

      Wie hast du das gemacht?
    • Macht doch mit dem Thema 'Dcf-optimieren' einen neuen thread auf. Wenn sich da was entwickelt, wie eigene Empfängerschaltungen oder anpassen der Antennen, das findet hier doch niemand mehr.
      Raum für Notizen

      -----------------------------------------------------------------------------------------------------

      -----------------------------------------------------------------------------------------------------
    • Hallo!

      Pluto25 schrieb:


      DG7GJ schrieb:

      ca. 85kHz und beim DCF-1 auf 65kHz.
      war es eine spürbare Verbesserung nachdem sie abgestimmt wurden?
      Die vom Pollin-Modul ging nicht ab zu gleichen, weil der Kondensator da dran einfach zuviel Kapazität hatte.
      Bei der vom ELV-Modul (~85kHz) habe ich versucht durch parallelschalten diverser Kondensatoren die Resonanzfrequenz bissel runter zu ziehen.
      Allerdings wurde die erzielbare Signalspannung mit sinkender Frequenz schwächer.
      Genau deswegen zweifel ich zudem an der Ferrit-Qualität.

      So habe ich den leisen Verdacht, das es sich weniger um speziell für DCF77 gebaute Ferritantennen eher um globalen Massenprodukt für RFID (136kHz oder so) handeln könnte.

      Mitch64 schrieb:

      Ich schätze dich als einer ein, der von HF mehr Ahnung hat als ich. Und ganz besonders was die Praxis angeht mit Impedanzen, Anpassungen, Verkürzungsfaktoren usw.Aber wenn die Abstimmfrequenz von der Ferrit-Antenne so daneben liegt, kannst du die nicht nachstimmen durch verschieben der Spule auf dem Ferrit?

      Ich habe jetzt weil ich kein HF-Freak bin auch keine Messgeräte und Antennen auszumessen. Nur ein HF-Mini-Analyzer habe ich, und der geht erst bei 1MHz los. Ich Habe ein Oszi mit integriertem Funktionsgenerator.

      Kann man damit die Antenne ausmessen?

      Wie hast du das gemacht?
      Testsignal mit variablen Pegel (zwischen 10-500mV an 50 Ohm) mittels Funktionsgenerator erzeugt und über eine lose Ankopelung (2 Windungen) neben dem Kern positioniert.
      An der Antenne dann ein Oszi zur Messung der erzielbaren Spannung.

      Nachstimmen durch verschieben der Spule auf dem Kern geht gar nicht, mit Gießharz oder sonst was glasartigem verklebt.

      Bei 500mV Einkoppelung konnte ich in den gefundenen Resonanzpunkten Maximal von 120 und 165mV erzielen, auf der Sollfrequenz 77,5kHz sackte die erzielbare Spannung auf maximal 20mV

      Bei der ELV-Antenne (~85kHz) habe ich schrittweise gute 7xxpF zusätzlich parallel geschaltet, was die maximalspannung aber nur auf knapp 35mV bewegte.

      Gefrustet also nen alten Reisewecker aus der bastelkiste geholt und seine Antenne vermessen.
      Ziemlich genau selbe Baugröße wie die der heutigen Module.
      Schwupps: Unter gleichen bedingungen, Entfernungen und 500mV Einspeisung zeigte sich das Bild was man erwarten würde...

      60kHz 100mV
      65kHz 120mV
      70kHz 250mV
      75kHz 285mV
      77,5kHz 395mV
      80kHz 270mV
      85kHz 230kHz
      90kHz 108mV

      Das dumme ist nur: Wo bekommt man solche gut abgeglichenen und optimierten Antennen her?
      Meine Suche damals brachte nur fragwürdige und überteuerte Sachen ohne ernshafte Datenangaben.

      Mit ein Grund weswegen ich mein geplantes Experimentierprojekt nicht nur auf Ferritantennen festlege.
      Bei den EFR-Rundsteuerempfängern habe ich vor ein paar Wochen die Info bekommen das diese Teile eine PE-Klemme haben.
      Und der Kollege wusste auch zu berichten das man den an PE auflegen muss, weil das Teil seine Signale (DCF49/DCF39) sonst nicht bekommt.
      Aha, womit klar ist wie die etwa die Antennenlösung geplant haben. Sicher nicht mit Ferritantenne im Schaltschrankeinbau..:-)

      Auf der anderen Seite als dritte Option will ich dort ne Aktivantenne vorsehen.
      Denn prinzipiell sind die Signale monströß stark - bislang alle Aktivantennen die ich hatte bringen mir alle drei Sender mit Signalstärken die schon durchaus in den zweistelligen mV-bereich reichen.
      Das sollte also reichen.

      tschoeatsch schrieb:

      Macht doch mit dem Thema 'Dcf-optimieren' einen neuen thread auf. Wenn sich da was entwickelt, wie eigene Empfängerschaltungen oder anpassen der Antennen, das findet hier doch niemand mehr.

      Sicherlich! Wenn das Projekt dran ist und ich dort neue Erkentnisse habe, werde ich das hier in einem gesonderten bereich veröffentlichen, beispielsweise im Bereich Projektvorstellungen.
      Wie bereits erwähnt wird es nicht darum gehen die üblichen DCF-Module zu optimieren, da ich einige Versuche dazu als gescheitert wechsortiert habe.
      Wird dann eher ein komplett neuer Empfänger der mit einem Atmel die Signale empfängt, decodiert, und eine RTC synchron hält.
      Ich vermute mal das es kein Drop-In-Ersatz vergleichbar zu den DCF-Modulen werden kann. Also deutlich größer als DCF-1/DCF-2 und auch eher einige mA statt µA.
      Allerdings sind meine Bestrebungen das Teil ähnlich parametrierbar zu machen wie die Config DCF77.
      Also mit unterschiedlichen Fehlersicherungseinstellungen (vgl. Check= 0/1/2) sowie einer Taktung (Permanent/Stündlich/Täglich) zwecks Batterietauglichkeit falls man das mal braucht.
      Datenausgabe zunächst via UART, später mal gucken ob man da was als SPI-Slave oder so realisieren kann.

      Grüße

      Jürgen
    • Du bist doch Funker. Da lernt man doch, wie man kleine Empfänger für Mittelwelle und Langwelle baut.
      Mit gehts jetzt aber um die Antenne und Spule wickleln.

      Sowas kann man doch selber wickeln.
      Wäre das eine Option anstatt die fertigen Ferrit-Antennen mit falschem Abgleich und schlechter Güte?

      Mein Oszi (Funktionsgenerator) hat High-Impedanz und 50 Ohm.
      Klar muss ich auf 50 Ohm schalten.
      Aber ne Luftspule mit 2 Windungen, da bricht doch das Signal zusammen.
      Vielleicht doch ein paar Windungen mehr?

      Das mit der losen Kopplung habe ich mir schon fast gedacht.
      Genaugenommen müsste ich aber das Signal für das Oszi auch lose auskoppeln.
      Der Tastkopf hat ja auch Kapazitäten, die den Schwingkreis verstimmen.

      Noch eine Frage, bevor es Offtopic wird.

      Ich habe mal vor längerem eine quadratische Loop-Antenne gewickelt gewickelt auf einem Holzkreuz mit genau 10 Windungen.
      Ist also eine quadratische Luftspule mit 6mm Länge und Kantenkänge 36x36 cm.

      Die Antenne sollte zum Blitzdetektion verwendet werden. Kamen auch mal paar Haken raus, wenn es in der Nähe gewitterte.

      Wie kann ich jetzt die Eigenresonanz ohne zusätzlichem C feststellen?
      Mein Mini60-Analyzer spukte da keine Resinanz aus. Versuche mit dem Frequenzgenerator sind auch irgendwie gescheitert.

      Hast du da ein Tip, wie ich vielleicht auch mit einem C erst mal die Resonanzfrequenz finde?
      Die kann ja sonst wo liegen. Vielleicht im kHz Bereich oder viel höher. Der Frequenzgererator ist irgendwann auch am Ende.

      Vielleicht mit Rechteck anregen (lose Kopplung).