Forum: Mikrocontroller und Digitale Elektronik DCF Auswerte Konzept


von Martin (Gast)


Lesenswert?

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

von Rahul (Gast)


Lesenswert?

>ideensammlung
in der Codesammlung vielleicht...

von Martin (Gast)


Lesenswert?

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...

von Martin (Gast)


Lesenswert?

...speziell zum thema dcf nicht....
sonst wäre es nett wenn du mir den link posten könntest...

gruß, martin

von Rahul (Gast)


Lesenswert?

Es gibt aber ne Menge Projekte zu dem Thema...

von Martin (Gast)


Lesenswert?

..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.

von peter dannegger (Gast)


Lesenswert?

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

von Jadeclaw D. (jadeclaw)


Lesenswert?

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.

von Rahul (Gast)


Lesenswert?

>Dummsinn-Filter

Gibst den schon als fertiges Bauteil?

von Martin (Gast)


Lesenswert?

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

von Sebastian Heyn (Gast)


Lesenswert?

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.

von peter dannegger (Gast)


Lesenswert?

"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

von Jadeclaw D. (jadeclaw)


Lesenswert?

@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.

von Sebastian Heyn (Gast)


Lesenswert?

@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...)

von Rahul (Gast)


Lesenswert?

Beim C64 gab es auch eine DCF-77-Uhr, die ca. 6 Minuten zum
synchronisieren brauchte. Ich vermute das lag auch am Dummsinn-Filter.

von Martin (Gast)


Lesenswert?

..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...

von Joachim B. (joachimb)


Lesenswert?

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

von Christian Rötzer (Gast)


Lesenswert?

@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'.

von Martin (Gast)


Lesenswert?

@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

von tsetse (Gast)


Lesenswert?

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

von Joachim B. (joachimb)


Lesenswert?

@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

von Christian Rötzer (Gast)


Lesenswert?

@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 :-)

von Martin (Gast)


Lesenswert?

@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

von pit9 (Gast)


Lesenswert?

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

von Uwe (Gast)


Lesenswert?

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

von Jadeclaw D. (jadeclaw)


Lesenswert?

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

von Dietmar (Gast)


Lesenswert?

@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

von Hagen (Gast)


Lesenswert?

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

von Dietmar (Gast)


Lesenswert?

@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

von Malte _. (malte) Benutzerseite


Lesenswert?

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.

von Lupin (Gast)


Lesenswert?

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?

von peter dannegger (Gast)


Lesenswert?

@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

von tsetse (Gast)


Lesenswert?

"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.

von pit9 (Gast)


Lesenswert?

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

von Dietmar (Gast)


Lesenswert?

@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

von Dietmar (Gast)


Lesenswert?

@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

von Dietmar (Gast)


Lesenswert?

@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

von Uwe (Gast)


Lesenswert?

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

von Dietmar (Gast)


Lesenswert?

@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

von Uwe Nagel (Gast)


Lesenswert?

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

von Martin (Gast)


Lesenswert?

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
Noch kein Account? Hier anmelden.