Hi, hat eigentlich jemand mal ein wirklich ausgereiftes dcf empfangs und auswerte konzept entworfen??? vielleicht in schriftlicher form. also eine art ideensammlung zur auswertung, wie man die übernahme falscher werte ausschließen kann, wie oft üpberhaupt ein paket ausgewertet und sync werden sollte. wie man hochfrequente störungen durch annähern eines handys oder sonstige aussere einflüsse an der antenne ausschließen kann. z.B indem man ein paket empfängt und den minutenteil eines nächsten mit dem vorgänger vergleicht, und wenn der nicht um eins größer ist, dann 1) beim einschalten z.b das beide pakete zwischenlagern und wenn das dritte minutenpaket zu einem der beiden vorangegangenen um eins größer ist, dann sollte chance große sein das dies die richtigen infos enthält usw.... oder so ähnlich!? Martin
in der codesammlung finde ich keine konzepte, aber vielleicht bin ich ja nur zu blöde und sehe den baum vor lauter wälder nicht...
...speziell zum thema dcf nicht.... sonst wäre es nett wenn du mir den link posten könntest... gruß, martin
..ja ich weiß, gerade hier ist alles voll davon, aber mir gehts spziell um eine art erfahrung mit verschiedenen konzepten, gedankenansätzen oder wie soll ichs sagen. nicht nur um die generelle erfahrung wie werte ichs aus, und welchen timer nehme ich im register ..., den grünen oder blauen!? ... m.
Konzept: - für kompaktesten Code ist die Tabellenmethode (Byteadresse + Bitwertigkeit) am besten. - für Störungsunterdrückung definiert man entsprechende Zeitfenster für die Pulsdauer und Pulsabstand, da Störungen ja immer asynchron sind. Zusätzlich noch Pulsanzahl und Paritybits testen und fertig ist der störfreie Empfang. - bei praktischen Versuchen hat sich ein 8-Bit Zähler für die Zeitfenster als vollkommen ausreichend erwiesen. Mit 16-Bit kann man das dann absolut bulletproof machen. Peter
Peter Danneger schrieb: ""- für Störungsunterdrückung definiert man entsprechende Zeitfenster für die Pulsdauer und Pulsabstand, da Störungen ja immer asynchron sind. Zusätzlich noch Pulsanzahl und Paritybits testen und fertig ist der störfreie Empfang."" In störverseuchter Umgebung oder bei generell schlechtem Empfang empfiehlt sich noch ein Dummsinn-Filter, der ungültige/unsinnige Daten ausfiltert und das Empfangen mehrerer Zeittelegramme und ein Vergleich derselben, ob diese ausser der Minutenschaltung gleich sind. Die Paritybits reichen da leider nur für grobe Fehler (reihenweise Bits kaputt). Gruss Jadeclaw.
Dummsinn spricht an! im jahreswechsel sind nicht nur die minuten unterschiedlich!!und auf die 59 minute folgt auch nicht die 60igste, deswegen halt die frage nach einem konzept! ungültig/unsinnig ist leicht gesagt, mir gehts ja um die definition von dummsinn im eigenlichen sinn. ein paket schicke ich auch von a nach b und wenn b das ziel ist dann ist das auch richitg so wenn a dort ankommt.ansonsten würde ich gern einen dumsinnfilter bestellen, wenn der dann weiß was dummsinn ist! ""- für kompaktesten Code ist die Tabellenmethode (Byteadresse + Bitwertigkeit) am besten."" da werde ich mal nachsehen müssen was denn damit gemeint ist... danke Martin
Ich habe mir schonmal gedanken gemacht. Sinnig ist ne sycronisation ein mal pro tag. (Strom sparen) Bis dahin wird die Uhr nicht allzu verkehrt gehen... Die Empfangsstärke könnte man an den Impulsbreiten ausmachen. der AVRco compiler wertet das sogar irgendwie aus... Sollte eine impulsbreite total out-of-range sein würde ich das ganze paket vergessen. Ich würde für die decodierung einen kleinen Tiny45 oder so nehmen. der dann in den Standby geht oder ganz vom netz getrennt wird.
"ungültig/unsinnig ist leicht gesagt, mir gehts ja um die definition von dummsinn im eigenlichen sinn." Genau das ist das Problem des Dummsinns, man kann den Aufwand beliebig hoch treiben, ohne einen merkbaren Effekt zu erhalten. Wie gesagt, die Zeitfenster in meinem Code sind praktisch ermittelt (über 10 Jahre Laufzeit). Engere Zeitfenster bringen eine bessere Störfeststellung aber auch einen höhere Störempfindlichkeit. Es hindert einen keinen daran, z.B. für die Pulsdauer 99-101 und 199-201ms und für den Pulsabstand 999-1001 und 1999-2001ms festzulegen, da kommt keine Störung mehr durch. Es werden dann aber auch viele korrekte Pakete verworfen. Peter
@Rahul: Den must du dir schon selbst programmieren. @Martin: Unter Dummsinn fallen bei mir so Dinge wie 29:76 Uhr oder 35.14.03 als Datum. Habe ich leider alles schon erlebt, trotz korrekter Paritätsbits und engem Zeitfenster. Der Jahreswechsel würde allerdings nicht am Dummsinnsfilter scheitern, sondern bei der Redundanzprüfung. Aber das hätte sich dann bei korrektem Empfang der nächsten Zeittelegramme erledigt. Sebastian Heyn schrieb: ""Die Empfangsstärke könnte man an den Impulsbreiten ausmachen."" Nicht unbedingt. Das Conrad-Teil, mein Eigenbau und der Auerswald ACEM bringen unabhängig von der Feldstärke konstant gleiche Impulse. Das ändert sich erst, wenn die Signalstärke nicht mehr reicht. aber dann hat sich das Thema Dekodierung eh von selbst erledigt. Gruss Jadeclaw.
@Judeclaw: Dann ist das warscheinlich wirklich Empfängerabhängig. Ich würde generell Zwei bis drei pakete empfangen und vergleichen, ob die empfangene signalfolge sinn macht. Ich selber habe noch nie ein dcf decoder gemaut, weil ich dafür noch keine Zeit gefunden habe. Plane es aber in naher zukunft mal zu bauen (Ich will ne Uhr umbauen...)
Beim C64 gab es auch eine DCF-77-Uhr, die ca. 6 Minuten zum synchronisieren brauchte. Ich vermute das lag auch am Dummsinn-Filter.
..danke leute, ich merke schon, es gibt 1000 ansätze zum ziel zu kommen, und ideal ist wohl auch eine frage der anforderung nicht nur dem signal selbst gegenüber... ...für mich ist klar, wenn man sich zuvor ein wenig gedanken in konzeptioneller hinsicht macht, dann kommt man vielleicht schneller zum ziel auch wenn ich nciht vor habe in nächster zeit eine uhr zu basteln. die sache - aus den pulsen vielleicht auch noch rückschlüsse auf die empfangsqualität zu ziehen - ist echt eine gute idee - wenn das dort denn parallelen gibt... ich dachte immer mein funkwecker hat da vielleicht eine weitere verbindung zur internen antenne die informationen dazu liefert wie gut das signal ist, denn er gibt beim einlegen der bat auskunft über die qualität mit einer scala von 1-5. aus dieser info könnte auch noch eine zusätzliche error bestimmung erfolgen, denn ein frame aus einem guten signal ist höchstwarscheilich eher richtig als ein frame aus einem schlechteren signal - und schlecht mal nicht im sinne von dummsinn...
In diesem Paket http://www.mikrocontroller.net/forum/read-4-248219.html#289255 findest Du eine Dokumentation, in der mein DCF-Decoder beschrieben ist. Neben den Parity-Bits prüfe ich alle Zahlenbereiche (z.B. 1<=Monat<=12) und die Ziffern prüfe ich auf gültige BCD-Ziffern. Die elementare Dekodierung erfolgt ähnlich wie bei Peter. Erst ermittle ich über eine Pulslängenmessung die Polarität und den Sekundenbeginn und anschließend taste ich zu den vorberechneten Zeitpunkten das Signal gezielt ab. Mit dem Sammeln der Bits in einem Schieberegister kann ich eine schnelle erste Synchronisation erreichen. Den Empfänger habe ich über eine Zweidrahtleitung abgesetzt. Ich verwende ein chinesisches Modell aus einem 3-Euro-Funkwecker. Gruß Joachim
@Martin Wie jetzt, Du willst gar keine Uhr bauen? Du bist witzig! Mehr der Theoretiker, wie? Sonst hättest Du einfach mal angefangen zu programmieren. Und da fängst Du dann nicht mit einem ausgearbeiteten Konzept an, sondern versuchst einfach mal die Zeitpulse zu dekodieren. Später kommt dann der Überbau, "Dummsinn" usw. dazu. Insofern bemerktst Du dann auch selber, was noch Sinn macht und was nicht, aber es ist ja eh alles für die Katz'.
@CR: ...meine Herren... das ist doch nicht wahr, oder... sagmal schaust du eigentlich auch mal über den beckenrand hinweg!? und wenn ich das prinzip zur auswertung brauche um eine fehlersichere auswertesoftware für die synchronisation in einem netzwerk benutzen möchte??? ...muss ich dann gleich son blöden wecker bauen!? mai oh mai.... da fallen einem die haare aus... @JB: um das jahr 1992 rum habe ich das signal mit einem schieberegister ausgewertet... sehr interessant... G Martin
Schonmal hier gelesen? http://www.mikrocontroller.net/forum/read-1-181962.html#235281 @Martin: Mit Schieberegister ist sicher ein Software-Schieberegister gemeint. Noch eine andere Frage: Letztes Silvester war doch eine Schaltsekunde. Hat den Übergang jemand beobachtet. Im TV (ZDF) war nichts zu sehen. Hat jemands Uhr tatsächlich richtig angezeigt? Müsste so ausgesehen haben: 2005.1231 23:59:58 2005.1231 23:59:59 2005.1231 23:59:60 <-- Schaltsekunde 2006.0101 00:00:00 2006.0101 00:00:01 Fan von www.leapsecond.com
@Martin Ich verwende ein in Assembler erstelltes 64-bit-Schieberegister. 1974 hat man das so in Hardware gebaut. Seit 1984 gibt es das in Software (nachzulesen in der Funkschau). Der große Vorteil ist die schnelle Dekodierung (wie auch im Link von tsetse nachzulesen. @tsetse Die Schaltsekunde wird um 0 Uhr UTC eingefügt. Das bedeutet konkret, daß Du bei der Beobachtung des Effektes um ein Uhr Mitteleuropäischer Zeit noch nüchtern sein mußt! ;-) Gruß Joachim
@Martin: > sagmal schaust du eigentlich auch mal über den beckenrand hinweg!? Aber sicher, nur würde ich die Leute nicht auf diesem Wege auf die falsche Fährte schicken. Damit sinkt Deine Ausbeute deutlich. Sag' doch, was Du willst. Was Du hier aufziehst, ist eine Tarnvorrichtung, wo sich die Leute umsonst die Finger wund schreiben. Schaltsekunde? Uninteressant! Schieberegister? Pruuust! > und wenn ich das prinzip zur auswertung brauche um eine fehlersichere auswertesoftware für die synchronisation in einem netzwerk benutzen möchte??? Und warum sagst Du das nicht gleich? > ...muss ich dann gleich son blöden wecker bauen!? Das freut diejenigen, die sich die Mühe gemacht haben. > mai oh mai.... da fallen einem die haare aus... Sorry :-)
@CR,
schau mal ganz am anfang des posts...sorry wenn ich mich da vielleicht
nicht passend ausgedrückt habe...
> ...muss ich dann gleich son blöden wecker bauen!?
Das freut diejenigen, die sich die Mühe gemacht haben. -was zu tun!?-
(solche dinge wollte ich gerade in einem forum vermeiden, tragen nichts
zum thema bei, und da wir alle von uns überzeute elektrotechniker sind,
kann man es halt nicht immer jedem recht machen, es gibt halt immer
jemanden der das letzte wort hat-oder :-))
@JB,
das ganze in hardware aufzubauen war ein heidenspass. mir ging es halt
nach wie vor um ein konzept, um mal alle guten ideen von der auswertung
und dem empfang bis hin zur fehlerkontrolle und übernahme der daten und
letztendlichen anzeige und synchronisation eines parallel existierenden
uhrenwerkes.
ob ich da nun 8 TTl Ics 74164 anreihe usw.. oder das ganze in einem
softwareregister realisiere ist für mich zweitrangig gewesen.
...es gibt glaube ich immer noch menschen die ttl ics aus der 74 und
der 40 serie liegen haben, und sie nutzen...
klar kann ich ein feld aus boolischen vars nehmen...
klar kann ich ein hardwareschieberegister nutzen...
aber gerade das thema dcf77 ist doch immer wieder gern genommen, und es
gibt so viele gute ideen/erfahrungen ich hätte sie gern erfahren.
Martin
hi martin, habe mich auch schon mit dem thema beschäftigt und ein stückchen funktionierender software in der codesammlung stehen. peter danneger hat glaube ich bereits den nagel auf den kopf getroffen. man kann den auswerteaufwand beliebig treiben ohne praktischen effekt. das a & o ist die empfänger-hardware. entweder liefert sie ihre 59 bits + richtige pause am minutenende oder eben nicht. wenn nicht, übernimmt die für eine konstant laufende uhrzeit unverzichtbare rtc. impulsungenauigkeiten sind bequem über zeitfenster, die dateninformation bequem über die paritätsbits zu verifizieren. beides kombiniert angewandt ergibt bereits eine zuverlässige zeitinformation! irgendwelche angeblich mehrfach falschen bits, die dann durch's raster fallen würden kommen schlichtweg nicht vor. dcf77-dekodierung ist nicht sonderlich komplex und deshalb auch keine besondere wissenschaft. gruss pit9
Hi! @pit9 Noch einer der noch nie falsche Zeiten gesehen hat, Peter ist auch so einer. Aber glaube es ruhig, es geht mit 50ms Zeitfenster und Paritätsprüfung solch falsche Zeiten, wie sie Jadeclaw beschrieb, zu decodieren. Ein "Dummsinnfilter" macht schon Sinn. Ich prüfe schon lange kein Paritätsbit mehr, weil es zu unsicher ist. Meine Filter sind eigentlich nur noch das Zeitfenster und ein Quersummentest zwischen alten und neuen Daten. Falsche Werte? Das Thema ist gegessen. Viel Erfolg, Uwe
Quote: ""Noch einer der noch nie falsche Zeiten gesehen hat, Peter ist auch so einer."" Du, das kann gut sein. Ein ruhiger Standort, ländlich oder Vorortlage, weniger als 500km von Mainflingen entfernt, ein guter Empfänger, ggf. draussen montiert, da kann man auf fast jede Fehlerprüfung verzichten. Lege ich den Empfänger draussen aufs Balkongeländer, habe ich sofort fehlerfreien Empfang, selbst mit dem Conrad-Teil. Gruss Jadeclaw
@Martin: Lange Rede, kurzer Sinn: Habe schon seit einigen Jahren eine DCF77-Uhr erfolgreich in Betrieb, nach einem Buchvorschlag, auf 8051-Basis, aber reiner Assemblercode. Ich habe das damals auf einen Siemens 80C515A-Controller mit 2*40 Zeichen alphanumerischem LCD-Display implementiert. Jetzt möchtest du Details über Auswertung. Da sind z.B. Statusinformationen über die verwendete Antenne (Standard oder Reserve), Sommer- und Winterzeit, Update, Synchronisation, Parität usw. enthalten. Die Kern-Software darf ich aus Copyright-Gründen jedoch nicht hier veröffentlichen, entweder man entwickelt sie selbst nach eigenen Ansprüchen, oder aber ich nenne dir mal einen Literaturtipp: Feger, Otmar: Applikationen zur 8051-Familie Feger-und-Co.-Hardware-und-Software-Verl.-OHG. 1993 MC-Tools 13 ISBN 3-928434-17-9 Sicher gibt es das Buch nicht mehr, befindet sich aber meines Wissens noch in zahlreichen UNI- und FH- Bibliothehen, mit zugehöriger Software auf Diskette, die Beilage des Buches ist. Zur erweiterten Suche, haben die Uni- und FH- Bibliotheken auch noch bundesweite Suchmöglichkeiten. Das vollständige DCF77-Protokoll erhält man bei der PTB Braunschweig. Die DCF77-Uhr geht ja zu 99,9 Prozent aller Zeiten ultragenau. Aber die anderen 0,1 Prozent??? Habe schon mal abends um 21 Uhr gesehen, daß es mal für 3 Minuten lang z.B. 10 Uhr war. Die Paritätsprüfung alleine schafft es also nicht immer. Empfangsschwäche. Für zuverlässige Steuerungen ungeeignet. Hier muß man mal eigene Plausibilitätstests der gegenwärtigen Uhrzeit einbauen, und das ist einiges an Softwareaufwand. Also, je besser die Uhr, desto aufwändiger muß sie unbedingt sein. Gruß Dietmar
Die Paritätsprüfung kann auf Grund ihrerer Mathematik auch garnicht das schaffen. Paritätsprüfungen sind schön und gut aber sie sind sehr Fehleranfällig. Sie zählen nur die Anzahl der gesetzten Bits, und dabei trifft das Paritätsbit nur die Aussage ob diese Anzahl an gesetzten Bits nun gerade oder ungerade ist. Das kann garnicht sonderlich sicher Fehler erkennen. Ich bin also auch der Meinung das Plausibilitätsprüfungen nachgeschaltet werden sollten. Eine davon ist es dreimal nacheinander die Zeit zu empfangen und dann sicherzustellen das diese drei Zeiten sich um jeweils +1 Minute unterscheiden müssen. Somit hat man eine Fehlerwahrscheinlichkeit von 12.5%, das ist weit besser als die einer simplen Paritätsprüfung von 1/2 * Anzahl Bits. Dann noch die Überprüfungen das die Zeit-/Datumsangaben innerhalb ihrer Zahlenbereiche liegen. Gruß Hagen
@Hagen: Klar, 2 Paritätsfehler, und das Ergebnis ist wieder richtig. Passiert bei mir gelegentlich so. Hier wäre ein CRC-Verfahren vermutlich besser, aber da wäre ein DCF-Datenpaket etwas umfangreicher. Besser wäre kein Update der Uhr jede Minute, sondern: 1 Minute Uhrzeitdaten, eine weitere Minute Redundanzdaten, wäre aber auch denkbar. Eine Plausibilitätsprüfung per Software müßte erkennen, welche von mehreren empfangenen Uhrzeiten die wahrscheinlich richtige ist, möglicherweise anhand der anteiligen Dauer der auftretenden Uhrzeiten. Nun, bei mehrmals auftretenden Fehlerdaten kann man sicher davon ausgehen, daß ein Fehler nicht immer wieder die selbe falsche Uhrzeit erzeugt. Da wäre der Ansatzpunkt. Bei meiner Hobby-Uhr im Wohnzimmer, und zur Vorführung bei interessierten Menschen, ist das aber gerade mal völlig wurscht. Daran ändere ich nichts mehr. Gruß Dietmar
Also bei meiner DCF Uhr (Conrad Empfänger) habe ich folgendes Konzept angewendet: Eine sehr grobe Überprüfung der Pulsdauer, am Ende jeder Minute die Auswertung der Paritätsbits und eine Plausibilitätsprüfung. Zusätzlich muss das ganze Paket zwei mal derartig korrekt empfangen werden und darf sich nur in der Minutenstelle um +1 unterscheiden. Bei einem Wechsel von 59 auf 60 dauert dann die Syncronisation einfach eine Minute länger. Mit der Methode hatte ich bisher keine erkennbaren Anzeigefehler (1,5 Jahre Betrieb). Zusätzlich hat meine Uhr eine LED die die Syncronisation anzeigt. Sobald ein Minutenpaket Paket Fehler aufweist geht die LED an und wieder aus wenn zwei Pakete (wie oben zusammenpassend) fehlerfrei empfangen wurden. Bei mehr als 15min ohne zwei passenden Paketen fängt die LED an zu blinken. In der Praxis leuchet die LED öfters mal z.B. beim Einschalten des Rechners oder der ungünstigen Betätigung eines Lichtschalters. Blinken tut sie jedoch nur bei Gewitter oder wenn ich meinen Laptop 10cm entfernt stehen habe. Ich schalte den Empfänger übrigens nicht aus da er im Verhältnis zu den verwendeten 7 Segment LEDs wenig verbaucht. Aus meiner Sicht kann man die Signalqualitiät recht schön mit einem analogem Zeigerinstrument sehen. Kleiner Auschlag ist eine 0, ein großer eine 1 und wenn der Zeiger unruhig ist, so ist das Signal schlecht.
kann es denn mal passieren, dass das Signal kurzzeitige einbrüche bekommt und das Modul kurzzeitig einen falschen pegel am ausgang hat? da würde dann einen interrupt auslösen und man müsste das verarbeiten (kurze signalwechsel ignorieren). Oder ist sowas nicht möglich?
@Uwe "Aber glaube es ruhig, es geht mit 50ms Zeitfenster und Paritätsprüfung solch falsche Zeiten, wie sie Jadeclaw beschrieb, zu decodieren." Natürlich ist 50ms Zeitfenster für sich alleine Mist ! Hab ich doch auch nirgends behauptet, daß das ausreicht. Der Trick bei meiner Methode ist ja der, daß auch die Pulsabstände geprüft werden, ob sie im Zeitfenster (1s bzw. 2s) sind und dann natürlich die Pulsanzahl (59). Daß Störungen zufällig 100ms oder 200ms lang sind, kann durchaus passieren. Mit der zusätzlichen Abstandsmessung müßten aber die Störungen exakt synchron zum DCF77 sein und außerdem keinerlei zusätzliche Störungen in den Pulspausen. D.h. der Störimpuls muß genau 2 100ms-Impulse auf genau 200ms verlängern, um die Parität auszutricksen. In den 800/900ms Pause muß er aber immer mucksmäuschen still sein. Zusätzlich muß er auch eine ähnliche Amplitude haben, damit die AGC des Empfängermoduls nicht hochregelt und die nächsten echten Impulse verliert. Und sowas geht eben nur, wenn man einen echten DCF77-Code Störsender aufbaut. Gewitter, Staubsauger, Monitore können aber kein DCF77 empfangen und demzufolge keine dazu synchronen Störungen produzieren. Probier doch erstmal meinen Code aus, statt über etwas zu lästern, was Du nicht kennst. Peter
"Eine Plausibilitätsprüfung per Software müßte erkennen, welche von mehreren empfangenen Uhrzeiten die wahrscheinlich richtige ist," das ist imho der richtige Weg: das ganze Fuzzy-mäßig angehen. z.B. das Signal mit 100Hz abtasten, wenn mehr als 90% der Samples low sind, gilt dieser Zeitraum als low, und umgekehrt. Durch nachträgliches Drüberschieben einer "Bit-Bewertungs-Maske" über die vergangengen 255 Samples lassen sich der günstigste Zeitpunkt der Low/High-Entscheidung bestimmen und Störimpulse wirksam wegrechnen. Und man sollte drei Fälle unterscheiden: Erstes Einschalten: es ist keine gültige Uhrzeit vorhanden: Hier kommt es mir darauf an, möglichst schnell die Zeit zu erfahren. Wenn nur die Zeit ODER das Datum vernünftig ist, würde ich dies bereits anzeigen. Laufender Betrieb: gültige Uhrzeit: Hier müssten mehrere Minuten lang anderslautende Zeiten kommen, bevor die Zeit geändert wird. SZ/WZ-Umstellung / Schaltsekunde: Hier muss die Schaltung hellhörig sein und Änderungen (Umschaltzeitpunkte sind ja bekannt) prompt durchschalten. Eine CRC-Prüfung wäre auch damals (als die Auswertung noch mit Hardware geschah) mit dem vorhandenen Schieberegister recht einfach gewesen. Hat man aber nicht gemacht. Dafür aber doppeltes Parity.
also ich darf mich peter anschließen. man kann als fazit eigentlich nur sagen: es liegt in der natur von dcf77-empfangsstörungen, daß sich ebendiese wunderbar simpel in entsprechender software eleminieren lassen. ganz einfach indem die gesamte übertragungszeit des zeittelegramms mit dem genauem ausmessen der pulspausen (800/900/1800/1900ms) erfasst wird! jede grössere abweichung (die pulslängen varieren gern im bereich mehrerer 10 msek) macht den aktuellen zyklus ungültig. das ist radikal, aber hochwirksam. eine paritätsprüfung dient da fast nur noch der gewissensberuhigung. empfehlen darf ich dazu gerne auch meine zusammenfassung dieses verfahrens in nur 99 avr words- irgendeine falsche zeit habe ich da noch nicht gesehen! zu meinen empfangsbedingungen sei nur angemerkt: sensibler conrad-empfänger in gut 400 km entfernung inclusive reichlich mauerwerk & relativ unreiner versorgungsspannung --> gestörter empfang zu verschiedenen tageszeiten/wetterbedingungen. die software wird also rund um die uhr auf herz und nieren überprüft! pit9
@Lupin: Selbstverständlich ist das Signal genau so gut oder schlecht wie bei anderen Funkanwendungen: Fährt ein Bus oder LKW 10 m an deiner Wohnung vorbei, rauscht es vielleicht für ein paar Sekunden, d.h., es kommt nichts. Oder das Wetter ist schlecht. o.ä.. Damit ist dann die Signalauswertung für diese Minute "im Eimer". Gruß Dietmar
@Malte: Die Verifizierung der Daten mit der vorherigen und nächsten Uhrzeit (Minute), klingt schon sehr gut und nicht zu aufwändig, da die Uhr sowieso auch ohne Funksignal weiter läuft. Man muß aber die gesamte Uhrzeit einbeziehen: Wie ich weiter oben schrieb, war es bei mir anstatt 21 Uhr plötzlich mal 10 Uhr, aber die Minuten waren richtig. Gruß Dietmar
@tsetse: Bei mir wird das Signal mit 50 Hz abgetastet, und man kann noch ein Toleranzband der Bitbreiten angeben, das ist schon alles was man haben möchte. Da man nicht zweimal die selben Daten empfängt und verifizieren kann: Sollte sich eine Fuzzy-Logik nicht im Bereich der bereits erkannten Uhrzeiten, also etwas höherer Ebene, abspielen? Gruß Dietmar
Hi! Warum so aufwändig? Einfach alle empfangenen Datenbyts addieren(passt in ein Byte) und mit dem vorherigen +1(Minute) vergleichen. Sind sie gleich, synchronisieren, wenn nicht, Paket verwerfen und auf nächstes warten. Das erzeugt im besten Falle aller 10 min ein fehlerhaftes Paket(9->0)was aber nichts macht weil die interne Uhr eh weiterläuft. Mit deutlich mehr Software kann man das zwar erweitern, aber mir reicht das. Synchr. meistens in der 3. Minute. MFG Uwe
@Uwe: Klar, Aufwand, es ist letztendlich immer nur entscheidend, wofür man die Anwendung wirklich braucht. Wie bereits beschrieben, ich ändere die Basissoftware nicht mehr. In meinem Wohnzimmer kann die Uhr anzeigen, was sie will. Und das tut sie wenigstens zu über 99 Prozent, das reicht. Habe ich eine industrielle Anwendung, muß ich hingegen alle Register der Zuverlässigkeit ziehen. Es gibt da auch Firmen, die sich auf sowas spezialisiert haben. Gruß Dietmar
Ich mache auch nur den einfachen Vergleich zweier aufeinanderfolgenden Minuten. Eigentlich ist das ganz einfach, wenn man ein bischen mehr Aufwand in die sowieso nötige Software-Uhr steckt. Inzwischen berücksichtigt die, auch dank Peter Dannegger, die Sommer-Winterzeit Umschaltung. Meine Uhr-Routine wird mit einem Zeiger aufgerufen, der auf die interne Zeit oder auf die gespeicherte letzte Minute zeigt. In der 59. Sekunde wird die gespeicherte Zeit weitergezählt und mit der gerade empfangenen verglichen, nicht nur die Minuten, sondern die komplette Zeit. Bei Gleichheit wird neu synchronisiert, bei Ungleichheit nicht. Die gerade empfangene Zeit wird für die Prüfung in der nächsten Minute gespeichert. Angezeigt wird immer die interne Uhr. Unmöglich sind Fehldekodierungen nicht, aber doch extrem unwahrscheinlich, gesehen habe ich noch keine. Zusätzliche Plausibilitätsüberprüfungen der Impuls/Pausen-Zeiten erhöhen die Anzahl der erfolgreichen Synchronisationen und können kurze Störimpulse unterdrücken. Optimal wäre also wohl eine Kombination beider Methoden. Die Paritätsbits kann man dagegen getrost vergesssen, die waren vielleicht brauchbar, als man eben noch keine Prozessoren zur Auswertung benutzte, sondern die oben erwähnten Schieberegister. Uwe
Hallo Uwe, das hört sich finde ich schon recht rund ab, 1) interne uhr/gelegentlich synch -> bei gleichheit des gesamten zeitsatzes 2) plausibilität puls pause -> bereiche!? 200ms von bis 100ms von bis 3) aufeinanderfolgende minuten vergleichen (speicher mit empfang vergleichen - komplette zeit) 4) parität unnötig - sehe ich ähnlich zu 1) ich schätze du machst den synch indem du deinen interruptgesteuerten timer dann auch 0 setzt oder neu startest oder sowas!? zu 2) wurden ansonten ja auch schon bereiche genannt Die gerade empfangene Zeit wird für die Prüfung in der nächsten Minute gespeichert. -> ist die nach dem abgleich nicht gleich der internen uhr!? oder habe ich da was falsch verstanden..? und interessant ist auf jeden fall die anlaufphase... Martin
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.