Gibt es einen vernünftigen Grund dafür, daß daß die DCF77-Daten mit gerader Parität abgesichert sind? Ich sehe eigentlich nur den Nachteil des Verfahrens, daß der Zustand "kein Signal" damit nicht erkannt werden kann.
"Kein Signal" liefert ja keine 0-Bits, sondern einfach gar nichts. Insofern ist es egal, ob man gerade oder ungerade Parität verwendet.
Yalu X. schrieb: > "Kein Signal" liefert ja keine 0-Bits, sondern einfach gar nichts. > Insofern ist es egal, ob man gerade oder ungerade Parität verwendet. So ist es. Bevor man eine Parität auswertet, hat man in der Software ja schon mal irgendwo erkannt, ob die Sekundensignale innerhalb der neuen Minutenerfassung noch da sind. Wobei natürlich jede Auswertesoftware anders gestrickt ist, je nach Programmierer und Vorgaben. Aber wenn ein Signal an einer Stelle fehlt, wenn es eben auch nur eine einzige Sekunde ist, dann braucht man die Parität gar nicht erst zu betrachten.
Mir ist ungerade Parität immer sympathischer - damit kann man nicht nur das Sendersignal, sondern auch weitere Signalwege - egal ob in Hard-, oder Software überwachen. Ein abgeschnittenes Kabel, oder ein Übergabepuffer, der einfach nur ausgenullt ist, hat gerade Parität, wird also nicht erkannt.
Auch dieses Problem löst sich in Luft auf, da weder lauter Nullen noch lauter Einsen einen sinnvollen Inhalt abgeben.
A. K. schrieb: > Auch dieses Problem löst sich in Luft auf, da weder lauter Nullen noch > lauter Einsen einen sinnvollen Inhalt abgeben. "Sinnvolle" Sätze zu erkennen ist auch nicht das Problem... Überhaupt ist die Parität in den Datensätzen nur von sehr begrenztem Wert, der durch ungerade Parität geringfügig verbessert werden könnte.
>Mir ist ungerade Parität immer sympathischer
Oh, na Ärger aber auch, dass das bei der PTB offensichtlich keinen
interessiert. Bastel doch erstmal irgendwas. Wie ich sehe trollst Du
doch eh nur im OT.
Wenn da was im DCF-Protokoll nicht stimmt, ist es Wurst, ob die Parität gerade oder ungerade ist. Mit der Parität alleine, kann man ohnehin nur überhaupt einen Fehler erkennen, aber nicht, welcher. Oft reicht es bei einfachsten Übertragungssystemen aber. Bei zwei falschen Bits wird sogar überhaupt kein Fehler erkannt. Sowohl bei Parity EVEN, als auch bei Parity ODD. Schau mal nur in Wikipedia zum Thema Parität. Ob die Uhrzeit plausibel ist, das mußt du dir in der Anwendungssoftware zusammen stricken. Das wird die bessere Lösung sein. Ich habe ja auch noch so ein altes DCF-Teil. Und muß mir da auch mal was überlegen. Für den Wohnzimmerschrank reicht die Uhr, wie sie ist. Und als Gag. Aber für genaue Zeitprotokollierung, wie in zuverlässigen industriellen Anwendungen, muß ich die Auswerte-Software mal aufmöbeln bzw. aufbohren. Und schauen, daß der Quarztakt einigermaßen genau ist, und die Uhr autonom ohne DCF-Signal einfach eine Weile weiter läuft. Oder eine RTC nachrüsten.
Wilhelm Ferkes schrieb: > Wenn da was im DCF-Protokoll nicht stimmt, ist es Wurst, ob die Parität > gerade oder ungerade ist. Es kommt wohl darauf an, was für einen Auswertealgorithmus man nimmt, so pauschal kann man das nicht sagen. Parität als Absicherung ist natürlich das Schwächste, was es gibt und bei einer geraden Anzahl Fehler schon überfordert, klar. Aber meine Frage war auch nicht, wie man dieses tolle Verfahren nutzen kann, sondern ob "es einen vernünftigen Grund dafür, daß daß die DCF77-Daten mit gerader Parität abgesichert sind" gibt. > Ob die Uhrzeit plausibel ist, das mußt du dir in der Anwendungssoftware > zusammen stricken. Das wird die bessere Lösung sein. Eine sinnvolle Strategie sollte auf syntaktischer Ebene beginnen und erst wenn die Möglichkeiten ausgeschöpft sind, die Semantik der Daten benutzen.
Uhu Uhuhu schrieb: > Aber meine Frage war auch nicht, wie man dieses tolle Verfahren nutzen > kann, sondern ob "es einen vernünftigen Grund dafür, daß daß die > DCF77-Daten mit gerader Parität abgesichert sind" gibt. Wie hätte deine Frage denn gelautet, wenn das DCF-Protokoll eine ungerade Parität hätte? Meiner Meinung nach diente EVEN oder ODD nur zur Vereinbarung zwischen zwei Kommunikationspartnern. Mehr nicht.
Wilhelm Ferkes schrieb: > Wie hätte deine Frage denn gelautet, wenn das DCF-Protokoll eine > ungerade Parität hätte? Dann hätt ich sie nicht gestellt. Weil unterbrochene Datenwege gerade Parität "generieren", bevorzuge ich ungerade - es sei denn, es gibt irgend einen anderen guten Grund dafür. Einfache Gedankenlosigkeit ist nie ein guter Grund...
Uhu, versteh es doch endlich. Ein unterbrochener Datenweg generiert überhaupt kein Sekundensignal mehr, und das bemerkt die Software von einer auf die andere Sekunde sofort, und registriert es in einem Flag. Wenn in der Auswertung des Minutenprotokolles ein Bit fehlt, wird die Minute doch sowieso für ungültig erklärt. Da kommt es gar nicht mehr zur Parity-Auswertung, weil das total unerheblich ist. Es sei denn, du spinnst dir was zurecht, und glaubst, daß ohne Empfangssignal durch Störungen noch Zufallssignale entstehen.
Wilhelm Ferkes schrieb: > Uhu, versteh es doch endlich... Oh je, das brauchst du mir wirklich nicht zu erklären. Ein Rezept, den unterbrochenen Datenweg bei gerader Parität zu erkennen, ohne die Daten selbst zu analysieren, wirst du mir auch nicht nennen können und für einen Parity-Checker, der hinter diesem Datenweg hängt, ist es völlig schnuppe, wie die gerade Parität zustande kommt, die er sieht. Daß das DCF77-Protokoll so konstruiert ist, hat wohl letztlich nur historische Gründe: man wußte es seinerzeit einfach nicht besser. Aber vielleicht ist es doch eine gute Idee, erst mal nachzuforschen, ob da Überlegungen eingegangen sind, auf die ich nicht gekommen bin. Dem DES-Algorithmus wurden auch lange Zeit die dollsten Hintertüren angedichtet, nur weil lange niemand die clevere Konstruktion der S-Boxen durchschaute.
Uhu Uhuhu schrieb: > Wilhelm Ferkes schrieb: >> Wie hätte deine Frage denn gelautet, wenn das DCF-Protokoll eine >> ungerade Parität hätte? > > Dann hätt ich sie nicht gestellt. Weil unterbrochene Datenwege gerade > Parität "generieren"... Das ist so einfach Unsinn und hängt von mehreren anderen Faktoren ab.
Uhu Uhuhu schrieb: > Daß das DCF77-Protokoll so konstruiert ist, hat wohl letztlich nur > historische Gründe: man wußte es seinerzeit einfach nicht besser. Das ist wohl wahr und schon OK so. Ich habe da nichts zu beanstanden. Für große Datenströme war es nicht gemacht. Den Rest muß deine Software machen. Laß dir was schlaues einfallen. Bei defekter Hardware gibt es wohl im besten Falle einfach kein Signal. DCF77 funktioniert aber auch in industriellen käuflichen Anwendungen. Die Empfänger sind entsprechend teuer, und haben mit dem Hobby-DCF kaum noch was gemeinsam. Da wird auch Entwicklungsaufwand betrieben. Wohl in der Auswertesoftware. Hast du dir wenigstens überhaupt schon mal einen DCF-Core für deinen bevorzugten µC zum nackten Empfang angeschaut? Und weißt, wie das im Detail tickt?
Wilhelm Ferkes schrieb: > Hast du dir wenigstens überhaupt schon mal einen DCF-Core für deinen > bevorzugten µC zum nackten Empfang angeschaut? Und weißt, wie das im > Detail tickt? Ich hab einen Decoder mit Fehlererkennung und -korrektur programmiert. Der läuft mit Haar-Wavelets, so ähnlich, wie es Johann L. (gjlayde) beschrieben hat. Im Moment bin ich dabei, den Start noch robuster zu machen. Ist zwar bei den Empfangsbedingungen hier nicht unbedingt nötig, aber ich möchte einen stricken, der wirklich robust ist und der Start ist im Moment der einzige wunde Punkt, den ich sehe. Um kontrollierte Testbedingungen zu haben, hab ich ihn in einer Simulationsumgebung unter Linux gebaut - das hat den Vorteil, daß ich die Qualität der Testdaten sehr flexibel und vor allem definiert einstellen kann. Die Testsamples werden aus DCF77-Logs erzeugt. Logs vom Pollin-Modul verarbeitet er jedenfalls prima.
Uhu Uhuhu schrieb: > Weil unterbrochene Datenwege gerade Parität "generieren", bevorzuge > ich ungerade - es sei denn, es gibt irgend einen anderen guten Grund > dafür. Du gehst davon aus dass ein unterbrochener Datenweg immer 0-Bits liefert. In diesem Fall ist ungerade Parität tatsächlich die bessere Lösung. Was ist, aber, wenn der unterbrochene Datenweg immer 1-Bits liefert (weil bspw. beim Empfänger ein Pullup-Widerstand installiert ist) und die Anzahl der übertragenen Bits gerade ist? Richtig, dann kann die Unterbrechung nur mit gerader Parität erkannt werden. Bei DCF77 liegt der Fall aber ganz anders: Bei Unterbrechung des Daten- wegs werden weder 0-Bits noch 1-Bits erkannt. Eine Verbindungsunterbre- chung kann schon bei der Demodulation des Trägersignals erkannt werden. Die Paritätsprüfung dient nur noch dazu, bei funktionierender Verbindung Übertragungsfehler zu erkennen. Dafür ist es aber völlig unerheblich, ob gerade oder unegerade Parität verwendet wird. Da der Entwickler des Protokolls vielleicht an einer geradzahligen Datum geboren ist, hat er sich für gerade Parität entschieden. Sei's ihm gegönnt, einen Nachteil hat sein Geburtsdatum nicht ins System gebracht.
@Uhu Ich weiss nicht worauf du hinaus möchtest. Das DCF Signal (100/15% AM) besteht aus sekündlichen Signalen von 100 und 200ms Dauer für "0" und "1" und beinhaltet 59 Bits. Nr.60 wird nicht gesendet da als Sync genutzt. 1. Fall: Verlängert oder verkürzt sich eine Absenkung ,aus welchem Grund und wie auch immer, so das ein falsches Bit entsteht dann stimmt die Parität nicht, egal ob Gerade oder Ungerade, so daß das Telegramm verworfen wird da man ja nicht erechnen kann wo der Fehler lag. Es ist "hier" also erst mal völlig Latte wie die Parität ist. Bei Gerader Zahl an Fehlern greift die Parität nicht egal ob Gerade oder Ungerade. Es ist also auch hier "Latte" 2. Fall: Fällt ein Sekundensignal aus dann wird eine korrekte Auswerteschaltung bzw. heute mehr Auswertesoftware diese als Sync betrachten und das Telegramm überprüfen. Ist es zu kurz dann ist es ungültig, wird nicht angezeigt und demnach verworfen. Das nächste Telegramm wird dem nach auch kürzer da ja der echte Sync noch ansteht und damit ebenfalls verworfen. Es passiert also garnichts. Eine Parität, egal ob gerade oder ungerade, kann hier überhaupt nichts mehr retten da man ja nicht weiß wo man sich im Telegramm befindet. Fazit: Es ist also völlig Egal welcher Natur die Störung ist, eine einfache Parität ,egal welcher Polung, wird nie eine Möglichkeit geben die Daten zu restaurieren. Man erkennt nur "das" ein Fehler stattgefunden hat und man das Telegramm wegwerfen kann. Gängige Methode ist solange zu synchonisieren bis man 2 bzw. 3 gültige Telegramme hintereinander hat und dann das letzte zu übernehmen bevor der interne Taktgeber übernimmt. Das funktioniert schon seit Jahrzehnten bestens also warum ändern ? Mag sein das DCF alt ist aber es ist "Robust" Mal ne persönliche Frage: (Ich hab lange überlegt ob ich dich mal frage.Ich riskiers mal) Hast du einfach nur langeweile, leidest an einem Postwiedervereiniugungstrauma, oder schießt du einfach nur aus Prinzip immer quer, frei nach dem Motto "Hauptsache Kontra !!" ?
lasst doch mal den Uhu in Ruhe Er hat ne Annahme getroffen, versucht zu begründen und ne normale Frage dazu gestellt. Wo ist das Problem dabei? Das man sich irrt, einer falschen Annahme aufgesessen ist oder sonstewas nicht bedacht hat ist ja wohl normal und hat er ja selbst auch schon geschrieben. Wer von DCF77 auf Postwiedervereinigungstrauma kommt der sollte evtl. erstmal vor der eigenen Haustüre kehren. Da liegen sicherlich genug Haufen rum...
Es ist unnütz, sich Gedanken über Protokolle aus den Digitalanfängen zu machen. Die Leute haben mit nichts angefangen und vieles einfach nach Gutdünken irgendwie festgelegt. Sie haben sich daher oft garnichts dabei gedacht. Heutzutage würde man ein Zeitsignal nie in so einem kruden Format kodieren. Man würde vielleicht die Minuten seit 1.1.2000 übertragen + Fehlerkorrekturkode. Und ein Sommerzeitflag, falls die Regel mal geändert oder abgeschafft wird. Z.B. der GPIB-Bus ist auch so ein Relikt. Nirgends gibt es eine Timingspezifikation. Man hoffte einfach, daß die Treiberchips die Datenkämpfe beim Umschalten des ATN-Signals überleben. Heutzutage müßte man eine Sicherheitszeit spezifizieren, in der die Ausgänge von beiden Treiberseiten hochohmig sind. Und die Treiber wären dabei Bus-Friendly (Ziehwiderstände auf den vorherigen Pegel). Peter
Peter Dannegger schrieb: > Und ein Sommerzeitflag, falls die Regel mal > geändert oder abgeschafft wird. ??? Gibt's doch: Bit 17 (MEZ) und Bit 18 (MESZ).
Johann L. schrieb: > ??? Gibt's doch: Bit 17 (MEZ) und Bit 18 (MESZ). Ja, aber das restliche Format ist völlig veraltet. 2Bit-Fehler sollten mindestens korrigierbar sein. Ich sagte ja nicht, daß man es umstellen soll, sondern daß man es heute völlig anders machen würde. Jetzt muß man natürlich kompatibel bleiben. Peter
Sehr gelegentlich beobachtete ich an meiner DCF-Uhr tatsächlich auch 2 Paritätsfehler pro Minute. Dann wird das Telegramm für OK befunden, und die Zeit übernommen. Natürlich wird da eine falsche Zeit angezeigt, meistens nur in einer einzigen Ziffer. Tragisch, wenn es dann die Stunden-Zehner sind. Man muß da also tatsächlich in der dem Telegramm aufgesetzten Uhrzeitsoftware noch mal eine Plausibilitätsprüfung der Uhrzeit einbauen. Die einfach überprüft, ob es bei der Weiterschaltung unerlaubte Sprünge gibt. Am besten läßt man in der Software wohl eine zweite Uhr parallel mit laufen, und überwacht die Synchronisation über eine Zeitspanne. Ich habs noch nicht gemacht, aber irgendwie so würde ich das umsetzen.
Peter Dannegger schrieb: > 2Bit-Fehler sollten mindestens korrigierbar sein. Das ist doch billig: Von einer geraden auf eine ungerade Minute ändern sich ausschliesslich Minute.0 von 0 auf 1 und Minute.Parity wechselt. D.h. in zwei aufeinanderfolgenden Minuten gibt's so viel Redundanzen, daß selbst aus total verstörten Signalen noch was zu machen ist. Folgendes treibt diese Idee noch weiter und ist was komplizierter, zeigt aber, wie viel (ungenutztes) Potential in vielen DCF77-Auswertungen wohl noch ist: http://gjlay.de/pub/dcf77/konzept.html
Peter Dannegger schrieb: > Es ist unnütz, sich Gedanken über Protokolle aus den Digitalanfängen zu > machen. Das ist eine gute Nachricht für alle, die sich vor ihrer (erhofften) Himmelfahrt nicht mit weiterem Wissen beschweren wollen und natürlich auch für alle, die der Meinung sind, alles, was sie nicht verstehen, sei sowieso Unsinn. Da ich aber kürzlich darauf gestoßen bin, daß letztere Haltung nicht sonderlich brauchbar ist, wenn man erstere Hoffnung sowieso nicht hegt und ich nun eben mal kein Nachrichtentechniker bin, habe ich die Frage gestellt. Der bereits oben genannte DES-Algorithmus (ist zwar kein Protokoll, stammt aber aus den Anfängen des Digitalzeitalters) und z.B. die Electrologica X8, mit der ich zu Beginn meines Studiums etwas Bekanntschaft gemacht hatte, sind Beispiele, die zu hinterfragen sich allemal lohnt. Warum sollten es nicht mehr werden. Diejenigen Herrschaften, die sich durch derlei Fragen zu abwgigen Vermutungen, oder gar zum Pöbeln provoziert fühlen, sollten ihren Standpunkt hinterfragen - zumindest, wenn sie nicht auf Punkte im Himmel spekulieren. > Heutzutage würde man ein Zeitsignal nie in so einem kruden Format > kodieren. Man würde vielleicht die Minuten seit 1.1.2000 übertragen + > Fehlerkorrekturkode. So würde ich das auch machen. Bei den ganzen Streitereien um Kaisers Bart hier im Thread kann man doch ganz nett sehen, wie der Stallgeruch der Beteiligten mit eingeht. Ich habe mit Hardware - außer spielersch - nicht viel zu tun gehabt und hab immer das, was auf einem Port, oder so ankam als gegeben betrachtet. Wenn da Paritäts- oder CRC-Informationen vorhanden waren, habe ich die immer gerne auch in höheren Softwareschichten ausgenutzt, um einfache Plausibilitätskontrollen zu machen - das kostet nicht viel und erspart einem im Zweifelsfall Stunden an Suchzeiten, wenn man mal wieder mit dem Arsch irgendwas umgestoßen hat, was man vorher mit Kopf und Händen aufgebaut hatte. Und weil - zumindest bei mir - ein Hang besteht, Speicher in Zweierpotenzen zuzuordnen ist gerade Parität bei so simplen Fehlermustern, wie "alles mit 0x00, oder 0xff zugeklatscht" eben ein ziemlich zahnloser Hund. Beim DCF77-Protokoll kommt dazu, daß es nicht so toll geeignet ist, in Hardware decodiert zu werden; da spielen die Datenpfade in der Software durchaus eine Rolle. @Johann L. Diese ganze Fehlerkorrigiererei geht immer von der Annahme aus, die vorherige Zeitmarke sei korrekt. Das gibt ein nettes Anfangs-Problem. Ich habe mich vor Urzeiten mal mit Datums/Zeitarithmetik amüsiert und finde, daß die Korrektur auf diesem BCD-Mist, der von DCF77 kommt, eigentlich nur unötig kompliziert ist. Viel geradlieniger ist es, den Zeitstempel aus dem Decoder in "Sekunden/Minuten seit xx" umzurechnen und dann mit der vorhergehenden Marke zu vergleichen. Auf die Parity-Bits kann man dann locker verzichten. (Z.B. für Datenlogger ist so eine Sekundenmarke allemal handlicher und auch die Rückrechnung in ein Datumsformat ist kein Hexenwerk und im Zweifelsfall auch auf einem µC machbar.) Im Moment suche ich noch nach einem möglichst simplen Algorithmus, der eine Entscheidung fällen kann, ob eine Zeitmarke in die Reihe paßt, oder nicht. Damit könnte man vielleicht dem Anfangs-Problem auch etwas geschickter ausweichen.
Uhu Uhuhu schrieb: > Beim DCF77-Protokoll kommt dazu, daß es nicht so toll geeignet ist, in > Hardware decodiert zu werden; da spielen die Datenpfade in der Software > durchaus eine Rolle. Ach, das geht schon recht einfach, habe ich mal gemacht, brauchte etwa 10 TTL-ICs (nur Zeitanzeige hh:mm). Ein 74189 hat die aktuelle Zeit angezeigt und die neue Zeit gespeichert. Uhu Uhuhu schrieb: > Im Moment suche ich noch nach einem möglichst simplen Algorithmus, der > eine Entscheidung fällen kann, ob eine Zeitmarke in die Reihe paßt, oder > nicht. Wie schon gesagt wurde, Anzahl der Impulse pro Minute und Pulsdauer, Pulsabstand messen. Zusätzlich kann man noch eine ungerade Minute mit der davor vergleichen. Alle Datenbits außer das erste müssen gleich sein. Peter
Peter Dannegger schrieb: > Wie schon gesagt wurde, Anzahl der Impulse pro Minute und Pulsdauer, > Pulsabstand messen. Ich sample die DCF77-Rohdaten im 10-ms-Raster. Wenn ich in meinem Simulator 5% der Samples zufällig invertiere, sind zwar noch die meisten Daten richtig, oder korrigiert, aber es gibt doch schon vereinzelte Ausreißer. Vielleicht hilft, die Samplerate zu erhöhen, das hab ich aber noch nicht probiert. Wenn man so ein richtig versautes Signal hat, dann hilft auch das 300-ms-Abtastfenster nicht mehr, vorausgesetzt, der Decoder hat es überhaupt gefunden.
Ich habe seit Anfang 2008 ca. 25 DCF/RTC-Uhren in Betrieb, von denen noch keine einzige auch nur einen Fehler übernommen hat. Es kann bei Störungen halt mal mehrere Stunden dauern, bis die Synchronisation erfolgt, aber das ist kein Beinbruch, auch mehrere Tage läuft die RTC sehr genau. Die ganze Diskussion hier ist doch sehr theoretisch, in der Praxis ist das DCF77-Protokoll (gut ausgewertet) sehr gut, obwohl man mittlerweile dazugelernt hat. ;-)
Thilo M. schrieb: > Es kann bei Störungen halt mal mehrere Stunden dauern Mit einer geschickten Fehlerkorrektur läßt sich das stark verkürzen, sofern vom Signal noch was vorhanden ist.
Peter Dannegger schrieb: > Zusätzlich kann man noch eine ungerade Minute mit der davor vergleichen. > Alle Datenbits außer das erste müssen gleich sein. ...und das Minuten-Parity nicht vergessen. Uhu Uhuhu schrieb: > Überhaupt ist die Parität in den Datensätzen nur von sehr begrenztem > Wert, der durch ungerade Parität geringfügig verbessert werden könnte. Damit würde man weder mehr noch weniger Fehler erkennen. Die Wahrscheinlichkeit, versäbelte Daten am P zu erkennen, ist 1/2. > @Johann L. > Diese ganze Fehlerkorrigiererei geht immer von der Annahme aus, die > vorherige Zeitmarke sei korrekt. Das gibt ein nettes Anfangs-Problem. Das schwierigste bei meiser (mit mies wie in MIES) Empfangslage ist den Minutenanfang sicher zu detektieren. Bei schlechtem Signal gibt es nömlich viele Stellen, die so aussehen und Bits, die man garnicht zuordnen kann. Bevor man also nach dem Minutenanfang sucht, braucht man den Sekundenanfang. > Ich habe mich vor Urzeiten mal mit Datums/Zeitarithmetik amüsiert und > finde, daß die Korrektur auf diesem BCD-Mist, der von DCF77 kommt, > eigentlich nur unötig kompliziert ist. Nein, eine Korrektur auf einem Zeitstempel ist schwerlich möglich. Was geht ist ein Aussortieren, aber das hat man auch ohne Stempel. > Viel geradlieniger ist es, den Zeitstempel aus dem Decoder in > "Sekunden/Minuten seit xx" umzurechnen und dann mit der vorhergehenden > Marke zu vergleichen. Auf die Parity-Bits kann man dann locker > verzichten. Nö, nicht für die Anwendung: Es ist eine Uhr, die in Wien steht und von wo schlechter DCF-Empfang bekannt ist. Bei guter Empfangslage einen DCF-Auswerter zu schreiben ist Kinderkram; mit vollen Hosen ist gut stinken. Einfach einen Datensatz in die Tonne zu kloppen, wenn nicht alle Bits (korrekt) empfangen wurden, führt dann Endeffekt aber dazu, daß die Zeit überhaupt nicht mehr empfangen wird. Wenn man sinnvollte Bits hat, kann man natürlich großzügig sein, aber bei schlechter Empfangslage hat man immer auch Bits, die man nicht zuordnen kann, z.B. einen Puls von 140ms oder 160ms Länge. Welchen Zeistempel erzeugst zu dafür? Jeden möglichen Zeitstempel? Und was bei falsch empfangenen Bits, also 0 statt 1 oder umgekehrt? Bei falschen Minutenmarken, etc. Da hilft ein Zeitstempel nix. Ausserdem muss zum Vergleichen erstmal ein Datensatz vorliegen. Einfach DCF zu Stempel umrechenen bring für Fehlerkorrektur überhaupt nix.
Johann L. schrieb: > Bei falschen Minutenmarken, etc. ... kannst du auch nichts korrigieren, weil du nicht weißt, wo die Zeitinformation liegt. Die Minutenmarke zu finden ist die größte Hürde, einen Decoder bei schlechtem Signal zum Laufen zu bekommen. Da hilft auch die Fehlerkorrektur nicht. > Einfach einen Datensatz in die Tonne zu kloppen, wenn nicht alle Bits > (korrekt) empfangen wurden, führt dann Endeffekt aber dazu, daß die Zeit > überhaupt nicht mehr empfangen wird. Wenn du - wie auch immer - eine verläßliche Zeitmarke gefunden hast, weißt du fast immer, wie die nächste aussieht. Man kann sich dann darauf beschränken, den Sekundentakt synchron zu halten. Ob man die Zeit dann binär, oder im DCF-Format weiterzählt, ist Geschmacksache. Letzlich ist das Ganze also "nur" ein Startproblem.
Uhu Uhuhu schrieb: > Johann L. schrieb: >> Bei falschen Minutenmarken, etc. > > ... kannst du auch nichts korrigieren, weil du nicht weißt, wo die > Zeitinformation liegt. Wie ich iber bereits schrieb, gibt es mehrer Aufgaben zu lösen * Sekunden-Sync * Minuten-Sync * Fehlerkorrektur * Konsistenzprüfung * Auswertung Also nicht durcheinanderwürfeln. > Die Minutenmarke zu finden ist die größte Hürde, einen Decoder bei > schlechtem Signal zum Laufen zu bekommen. Da hilft auch die > Fehlerkorrektur nicht. Den Minuten-Sync bei schkechtem Signal zu finden kann eine Herausforderung sein. Ich hab's so gelöst: * Sekunden-Sync ist Voraussetzung Dann Falten mit einem zyklischen Wavelet, das folgende Eigenschaften "abscannt": * Bit 0 = 0 * Bit 20 = 1 * Bit 21 ^= 1 * Bit 59 = Minutenmarke (MM) Insbesondere Bit 21 ist sehr hilfreich, da es auch andere Bits gibt, die zwar nicht ständig, dafür aber lange auf 0 oder 1 sind wie Bits im Jahr oder im Monat. Aber hier sticht Bit 21 raus und ist eine wertvolle Hilfe zur Verbesserung der Wavelet-Eigenschaften. WIMRE dauerte der Minuten-Sync schon mindestens 9 Minuten... >> Einfach einen Datensatz in die Tonne zu kloppen, wenn nicht alle Bits >> (korrekt) empfangen wurden, führt dann Endeffekt aber dazu, daß die Zeit >> überhaupt nicht mehr empfangen wird. > > Wenn du - wie auch immer - eine verläßliche Zeitmarke gefunden hast, > weißt du fast immer, wie die nächste aussieht. Man kann sich dann darauf > beschränken, den Sekundentakt synchron zu halten. Beim Sekundentakt-Ssynchronhalten darf man nicht zu steif sein. Bei miesem Signal ist ein ziemlicher Jitter auf den Bits/Bitlängen und wenn ein unbrauchbare Phase kommt, läuft dir der Sekunden-Sync gegen das DCF-Signal weg (wegen Quarz-Ungenauigkeit).
In meinem Simulator kann ich Startphase, Noise, Jitter und Drift einstellen. Bei geringer Drift schafft es der Decoder, bei 7-8% Noise (implementiert als zufällige Invertierung von Samples) noch gute Zeitdaten zu finden. Die Minutenmarke finde ich im Moment mit einem 1000-ms-Wavelet. Der Driftausgleich geschieht über eine gleitende Mittelwertbildung über die Abweichungen der Sekundenposition: akku += deltaT - (akku >> 8) Wenn der Betrag (akku >> 8) größer als 1 wird, wird die Sekundenposition um 1 nachgeführt. Das funktioniert ganz ordentlich. Die Wavelet-Berechnung läuft ständig, 50 ms vor der Sekundenmarke werden die Maximum-Speicher zurückgesetzt. > Bei > miesem Signal ist ein ziemlicher Jitter auf den Bits/Bitlängen und wenn > ein unbrauchbare Phase kommt, läuft dir der Sekunden-Sync gegen das > DCF-Signal weg (wegen Quarz-Ungenauigkeit). Hast du nähere Informationen über real miese Signale? (Hier ist der Empfang so gut, daß man schon vorsätzlich sabotieren muß, um wirklich schlechte Daten aus dem Pollin-Modul zu bekommen. > Dann Falten mit einem zyklischen Wavelet, das folgende Eigenschaften > "abscannt": > > * Bit 0 = 0 > * Bit 20 = 1 > * Bit 21 ^= 1 > * Bit 59 = Minutenmarke (MM) Wie machst du das?
Angehängte Dateien:
Uhu Uhuhu schrieb: > Hast du nähere Informationen über real miese Signale? (Hier ist der > Empfang so gut, daß man schon vorsätzlich sabotieren muß, um wirklich > schlechte Daten aus dem Pollin-Modul zu bekommen. Es ist tatsächlich nicht so einfach, an "real" miese Daten zu kommen, d.h. an solche, die in der Zielschaltung und am Zielstandort eingesammelt wurden. Anbei eine PNG-Grafik mit einem Mitschnitt, wobei es sich dabei nur um einen Ausschnitt handel, dem Filetstück sozusagen. Der Rest ist noch mieser. Die PNG-Grafik wandelt man mit ImageMagick oder sonstwie in PBM um wie in http://gjlay.de/pub/dcf77/konzept.html bereits beschrieben. Wenn man's richtig anstellt erhält man einen ASCII-Text, siehe http://de.wikipedia.org/wiki/Portable_Bitmap Auf der Seite ist auch eine weitere schwarz-weiße PNG-Grafik links am Rand die du analog verwenden kannst. Im Gegensatz zum obigen PNG bieten diese Daten die reale Chance was zu erkennen und nicht nur aus dem Kaffeesatz zu lesen. >> Dann Falten mit einem zyklischen Wavelet, das folgende Eigenschaften >> "abscannt": >> >> * Bit 0 = 0 >> * Bit 20 = 1 >> * Bit 21 ^= 1 >> * Bit 59 = Minutenmarke (MM) > > Wie machst du das? Ein zyklisches Wavelet von 120 Sekunden Länge. Alternativ geht ein zyklisches Wavelet von 60 Sekunden länge, das alle 60 Sekunden so gepatcht wird, daß der Toggle von bit 21 abgebildet wird.
Angehängte Dateien:
-
dcf-10ms-pulses-ec.png
9,3 KB
Johann L. schrieb: > Anbei eine PNG-Grafik mit einem Mitschnitt, ... Diese Daten-Grafiken haben übrigens 100 Pixel/Zeile und sind von oben nach unten zu lesen. Jede Zeile entspricht einer Sekunde, d.h. es wurde im Abstand von 10ms gesamplet. Anbei noch das Ergebnis einer Fehlerkorrektur auf realen, verauschten Daten. Die Grafik ist durch eine senkrechte, hellblaue Mitellinie in einen linken und einen rechten Teil unterteilt, jede Zeile entspricht einer Minute. Links die Originaldaten, rechts nach Fehlerkorrektur. Farben: * Blau = Minutenmarke * Grün = Hää? Schrott-Bit * Schwarz: Bit 0 * Weiß: Bit 1 * Rot: Bitfehler erkannt und korrigiert * Braun: Bit 20. Hier beginnt die Zeit-Info (abgesehen von MEZ/MESZ, die stehen links davon) Der Mittelstreifen hat eine besondere Bedeutung: er ethält die drei Paritybits für Minute, Stunde und Datum * Grün: Parity ok * Gelb: Parity unbekannt * Rot: Parity-Fehler erkannt Danach kommt dann die inhaltliche Analyse, d.h. Vergleich gegen Daten einer Vorminute. Naturlich nur dann, wenn alle dreo Patitys auf "grün" sind.
Uhu Uhuhu schrieb: > In meinem Simulator kann ich Startphase, Noise, Jitter und Drift > einstellen. Mal rein interessehalber: Was hast du da für einen Simulator?
Johann L. schrieb: > Ein zyklisches Wavelet von 120 Sekunden Länge. > Alternativ geht ein zyklisches Wavelet von 60 Sekunden länge, das > alle 60 Sekunden so gepatcht wird, daß der Toggle von bit 21 > abgebildet wird. Verstehe ich das recht: + das Wavelet läuft über die Bits, die mit den 100/200 ms Wavelets gewonnen wurden + man addiert für jede erfüllte Bedingung 1 + die Stelle, an der das Wavelet 4 erreicht, gibt die Lage der Minute Die Grafiken kenne ich bereits von deiner Seite. Hast du echten Daten untersucht, um mit den Daten synthetische Daten generieren zu können? Wilhelm Ferkes schrieb: > Mal rein interessehalber: Was hast du da für einen Simulator? Das ist ein Programm, das aus DCF-Mitschnitten von http://www.dcf77logs.de/ 10-ms-Samples erzeugt, die dann vom zu entwickelnden Decoder verarbeitet werden. Die Datenquelle des Simulators hat 4 Parameter: + Phase (wieviele Ticks nach Start sollen die ersten Daten kommen) + Noise (wieviele 10000stel der Samples sollen zufällig invertiert werden) + Jitter (wie heftig sollen die Samples zufällig "tanzen") + Drift (Asynchronität zwischen der DCF-Uhr und dem Systemtakt) Damit kann man alles zwischen einem klinisch reinen Signal und totalem Chaos erzeugen und den Decoder damit füttern. Nur ob das Chaos realistisch ist, weiß ich natürlich nicht. Der Decoder wird einfach im Simulator-Programm entwickelt. Ein Tag ist in einem Augenblick simuliert und man hat den Debugger des verwendeten Compilers zur Verfügung.
Uhu Uhuhu schrieb: > Johann L. schrieb: >> Ein zyklisches Wavelet von 120 Sekunden Länge. >> Alternativ geht ein zyklisches Wavelet von 60 Sekunden länge, das >> alle 60 Sekunden so gepatcht wird, daß der Toggle von bit 21 >> abgebildet wird. > > Verstehe ich das recht: > + das Wavelet läuft über die Bits, die mit den 100/200 ms Wavelets > gewonnen wurden Nein, idealerweise auf den Originaldaten > + man addiert für jede erfüllte Bedingung 1 Welche Bedingung? Mit dem Wavelet wird gefaltet http://de.wikipedia.org/wiki/Faltung_(Mathematik)#Diskrete_Faltung nachdem man den Sekunden-Sync hat, d.h. es muss nicht 100x pro Sekunde gefaltet werden, sondern nur 1x. > + die Stelle, an der das Wavelet 4 erreicht, gibt die Lage der Minute Nein. Die Faltungen werden über mehrere Minuten akkumuliert und wenn sich an einer Stelle ein signifikantes Maximum im 60-Sekunden-Zykel zeigt, hast du den Minuten-Sync gefunden. Was ein "signifikantes Maximum" ist musst du eruieren, ist zu lange her das alles... > Die Grafiken kenne ich bereits von deiner Seite. Hast du echten Daten > untersucht, um mit den Daten synthetische Daten generieren zu können? Die Daten-Inputs sind alles reale Daten, aufgenommen mit einem 641138 vom C an ATmega. Wobei die Daten wegen angeschlossenem UART/RS232 nicht 100% "real" sind da keine Potentialtrennung vorhanden war (Erdung der Schaltung bringt evtl. bessere Daten, z.B. wenn SNT im Spiel sind da es weniger einstört).
Für die MinutenKennung und die Plausiblitätspüfung ergibt diese schrift http://www.ptb.de/cms/fileadmin/internet/fachabteilungen/abteilung_4/4.4_zeit_und_frequenz/4.42/dcf77.pdf Eine zusätzliche Auswertemöglichkeit man beachte das Kapitel 4.3 Phasen modulation. dort wird beschrieben wie die Phase moduliert ist und das während der sekunden 1 - 14 einer Minute durch invertieren der PRN die minute binär codiert wird. Wenn ich wieder daheim bin werde ich mich daran machen ein Empfangsmodul zu stricken welches die Phasenverschiebung des Trägers ausgibt. somit stünde binnen 14 Sekunden eine redundante Minuteninformation zur Verfügung. noch sinnvoller erscheint mir den Träger unmittelbar auszuwerten undzwar nach Amplitude und Phase. Zudem bietet die Phaseninformation in Kombination mit dem PRN eine Bewertungsmöglichkeit für die Gültigkeit jeder einzelnen Trägerflanke auf Plausiblietät. im Kapitel 7.3.3 wird näher auf den empfang desPRN und die sich daraus er gebenden Möglichkeiten zur korrellation eingegangen genaugenommen ließe sich nach dem einrasten ein PLL aufbauen welche die folgende Flanke vorherbestimmt, zumindest jene welche nicht unveröffentlicht codierte Informationen enthalten und somit nach diesen korrellierenden Flanken suchen. Namaste
Daß durch verbesserte Empfänger viel zu holen ist, ist klar. Nur sind die wohl kaum für 5 Euronen zu haben... Hier ist was interessantes zum Thema: http://tams-www.informatik.uni-hamburg.de/paper/1998/DA_Wierich/mwdiplom.ps.gz
naja Uhu, AM ist nun mal ein sehr störanfälliges Verfahren und die 77.5khz nicht gerade berühmt für störfreien und einfachen Empfang. was ich noch überlege ist die Gestaltung der Antenne und der Eingangsstufe um das Phasensignal nicht zu vermatschen, da ja der gesendete Sinus gar keiner ist, währe einen schmalbandigen Schwingkreis in Resonanz zu betreiben schon mal keine gute Idee? Namaste
Winfried J. schrieb: > währe einen schmalbandigen Schwingkreis > in Resonanz zu betreiben schon mal keine gute Idee? Irgendwo hatte ich gelesen, daß die Konsumer-Empfänger sehr schmalbandig sind und deswegen die Bitflanken nur ziemlich ungenau detektiert werden können. Aber wenn die Phase ausgewertet wird, ist das wohl egal. Was man für so einen Empfänger für eine Antenne braucht, würde mich auch interessieren.
Eigentlich wäre die DCF77-Decodierung doch ein prima Anwendungsfall für Fuzzy Logic.
naja, Schmalbandigkeit ist bei der AM-Demodulation schon wegen der Trennschärfe notwendig, zumal die Nachbarstationen nur wenige khz daneben liegen. Und Schwebungen(dank PNR) und Interferenzen machen die AM-Demodulation nicht einfacher, will man nicht zur PLL mit Gain-Controll oder Superhet greifen so braucht es schon ziemlich gute Empfangsbedingungen. Ich denke als für die Phasendemodulation sollte man als Eingangsschaltung ein Bandfilter aus zwei Spulen auf dem Ferrit und wählen und diese mit je einem C + Trimmer abstimmen.
Uhu Uhuhu schrieb: > Das ist ein Programm, das aus DCF-Mitschnitten von > http://www.dcf77logs.de/ 10-ms-Samples erzeugt, die dann vom zu > entwickelnden Decoder verarbeitet werden. Sorry, Uhu, aber ich bemerke an deiner Antwort gerade, daß ich die Frage ewas falsch formulierte. Besser wäre gewesen: Wie heißt der Simulator, und wo bekomme ich den? Simulierst du etwa auf Codeebene für den µC, und verwendest die Mitschnitte einfach als Stimuli-Files für einen I/O-Pin? Aber Danke für die weitere Erläuterung dazu. Nach allem, was bisher oben so zusammen kam, bin ich geneigt, meine eigene DCF-Uhr noch mal komplett zu überholen. Denn sie macht ja gelegentlich auch Fehler. Mein DCF-Modul verwendet ausschließlich nur den Empfangsbaustein U2775, hat noch etwas Hühnerfutter, Quarz, und die Ferritantenne. Ein Datenblatt finde ich nicht mehr. Es ist aber klar, daß sowas kein ausgewachsener höchst qualitativer AM-Empfänger ist. Eher sowas, wie früher mal die Mittelwellenradios von einem Kaffeehändler für 9,90DM. Die benutzte ich gleich neu immer zum Ausschlachten, denn einfacher und billiger kam ich als Jugendlicher nicht an elektronische Bauelemente (Transistoren) heran. ;-)
Wilhelm Ferkes schrieb: > Wie heißt der Simulator, und wo bekomme ich den? Er heißt Fritz, ist ganz zahm und du bekommst ihn bei mir ;-) > Simulierst du etwa auf Codeebene für den µC, und > verwendest die Mitschnitte einfach als Stimuli-Files für einen I/O-Pin? Es ist im Prinzip ein vollständig in C geschriebenes Testbett für den Decoder, das die Samples aus echten Mitschnitten erzeugt und sie auch pseudozufällig verfälschen kann, um schlechte Empfangsbedingungen, oder einen driftenden Controllertakt zu simulieren. Von einem µC ist da weit und breit nicht viel zu sehen - außer vielleicht ein paar Definitionen, die AVR-spezifisch sind und in den zu portierenden Routinen erst im AVR zum Leben erwachen. Letztlich füttert man den Decoder ja mit Samples vom Ausgangssignal des DCF77-Empfängers und die kann man der Software auch zuführen, ohne den Lötkolben anzuheizen. Die Rangehensweise hat den Vorzug, daß die Tests deutlich schneller laufen, als mit einer echten DCF-Datenquelle und daß man sie beliebig wiederholen und mit einem richtigen Debugger dran arbeiten kann. Ich habe Eclipse mit gcc unter Linux dafür genommen.
hallo uhu, ich könnte mir vorstellen das PNR auch die Auswertung des Amplitudensignals da hingehend beeinflusst da die Fallende Flanke des sekundentaktes zwar zeitgercht gesendet wird die Eigenfrquenz des LC Kreises welcher schmalbandig auf mittenfrequenz abgestimmt ist ein Problem damit hat diesen Phasenverschiebungen zu folgen, da er ja selbst schwingt. Wenn auch gedämpft so speichert er doch energie und schwingt nach weshalb auch die Ampitude nicht so schnell abfällt wie am Sender. Das bedürfte einer höheren Dämpfung um das auf einer Flanke zu schaffen,was jedoch Güte kostet und damit Selektivität. Schon von daher wirkt jeder Schwingkreis integrierend bezüglich der Amplitude was für harmonische Hüllkurven ideal, für Digitale trägertastung mit steilen modulationsflanken aber nur die zweitbeste lösung ist. Um aber genug signalstärke bei so kleiner frequenz und und möglicht kleiner Bauform zu bekommen braucht es sicher eine Feritantenne. wnn man die spule bifilar wickelt und je einen schwingkreise auf eckfrequenz der von fm+-df abstimmt könnte man beide signalwege getrennt verstärken mit je einem gaincontrolkanal ausregeln. die beiden regelabweichungen werden nicht nur zur regelung der HF verstärker vewand, ihre größe entspricht der invertierten amplitude. sie können einen Fensterdiskriminator zugeführt werden. Im inneren Fenster ist Ufu= Ufo --> kein PNR Sekunden puls (auch der 59.) oberhalb ist PNR normal ---> MinutenBit 0 unterhalb ist PNR = invertiert MinutenBit = 1 Gleichzeitig kann man beide Signale entkoppelt addieren und anschließend amplitudendemoulieren. Differenziert erscheinen negative spikes an den vorderflanken des Sekundentaktes und positive an deren Rückflanke. Ein monoflop auf 0,15ms liefert den Diskriminator für die aus der AM gewonnen PW modulierten Bits der Standardauswertung. Namaste
Thread beobachten
Seitenaufteilung abschaltenBitte 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.