Mal wieder Manchester-Code dekodieren

Irgendwie erinnert mich diese Frage an MFM-Kodierung, wo nach gewisser 
Zeit ein zusätzliches Taktbit nötig war WENN zu viele gleiche Zeichen 
keinen Impuls ergeben hätten. 
http://de.wikipedia.org/wiki/Modified_Frequency_Modulation

Hier z.B. geht das System klasse.

Bei mir läuft die Decodierung mit einer simplen Schleife so ab:

Falls das Signal immer mit einer führenden "0" beginnt:
Schritt 1 und 2 voraus, dann in einer Schleife Schritt 3 bis 6 für jedes 
Bit.

Falls das Signal immer mit einer führenden "1" beginnt:
nur die Schleife Schritt 3 bis 6 für jedes Bit

Wird ein "high" Pegel eingelesen, war das Bit eine "0", bei "low" eine 
"1".

Die "Auf die Flanke warten" Routine wird noch zusätzlich über einen 
Timer überwacht, damit bei Signalausfall oder Signalende nicht unendlich 
weitergewartet wird.

Falls das Signal mit einer "1" oder "0" beginnen kann, wird es etwas 
komplizierter, da man dann erst im weiteren Signalverlauf entdeckt, 
welcher Pegel einer "0" bzw. einer "1" entspricht.

Das Startbit hat aber meistens keine wechselnde Logik, sondern ist 
konstant.

:-) schrieb:
> Bei mir läuft die Decodierung mit einer simplen Schleife so ab:
>
> Falls das Signal immer mit einer führenden "0" beginnt:
> Schritt 1 und 2 voraus, dann in einer Schleife Schritt 3 bis 6 für jedes
> Bit.
>
> Falls das Signal immer mit einer führenden "1" beginnt:
> nur die Schleife Schritt 3 bis 6 für jedes Bit

Das geht mit Sicherheit, aber ist es nicht so das der Manchester-Code 
ein selbst taktender Code sein soll aus dem man den Takt erkennen kann. 
Nur mal so gefragt ist Deine Vorgehensweise nicht so als würdest Du eine 
normale UART selber Takten. Klar kann ich mich einfach zuerst auf das 
erste 1/4 des Taktes stellen und dann im normalen Takt abfragen. Aber 
ist das Sinn und Zweck des Codes?

Ok, es geht auch etwas aufwändiger z.B.:

http://www.patent-de.com/20050504/DE69632376T2.html

:-) schrieb:
> Ok, es geht auch etwas aufwändiger z.B.:
>
> http://www.patent-de.com/20050504/DE69632376T2.html

Wobei sich das ja nur auf die Hardwareendkodierung bezieht oder?

Es geht zwar um eine Dekodierung per Hardware, aber gleich zu Beginn 
(die ersten 30-40 Zeilen) werden verschiedene Verfahren zur 
Manchesterdekodierung erläutert.

Entweder ist das Timing des Signals bekannt und man kann sich einfach 
darauf synchronisieren, oder es ist nicht bekannt und man muss mit mehr 
Aufwand herausfinden wie lange ein Bit dauert und das Signal muss vor 
den Nutzdaten eine ausreichende Menge von Hilfsbits haben, auf die sich 
der Dekoder synchronisieren kann.

Wobei mir leider noch nicht bekannt ist, ob ich ein Gedankenfehler mache 
bzw. mein Ansatz falsch ist oder nicht. Also die eigentliche Frage noch 
nicht geklärt ist.

Holger P. schrieb:
> Wo liegt mein Gedankenfehler. Oder ist der komplette Ansatz falsch?

Ich denke mal der Ansatz ist daher falsch, dass du durch die Zeitmessung 
zwischen fallenden Flanken mal die Länge von einem Bit, mal von 
eineinhalb Bit oder 2 Bit erhältst. In deinem Fall 8µs, 12µs oder 16µs.
D.h. in den Zeiten steckt nicht die Information von nur einem Bit, 
sondern von einer Folge. z.B. 101 ergibt 16µs.

Bekommst du aber 12µs, so kann das entweder eine 01 Folge oder eine 10 
Folge gewesen sein.

Ich denke du müsstest bei diesem Ansatz die Zeitabstände zwischen allen 
Flanken messen und nicht nur zwischen den fallenden Flanken.
Dann bekommst Du Zeiten von 4µs oder 8µs und kannst durch Testen des 
Pegels nach jede Flanke auf eine 0 oder 1 schließen. Ergibt die 
Zeitmessung 4µs, so bist du noch innerhalb desselben Bits. Ergibt die 
Zeitmessung 8µs, so bist du bereits in der Mitte des nächsten Bits.