Ich versuche gerade die Manchesterdecodierung auf Fehlertoleranz zu optimieren. Das Problem ist, dass das Signalverhältniss des Biphasensignals (Highphase:Lowphase bzw. umgekehrt) laut Hersteller der Funkmodule von senderseitig (Eingangssignal)5:5 empfängerseitig (Ausgangssignal) bis
7:3 verschoben sein kann. D.h. der Pegelwechsel der sich in Bitmitte befinden sollte kann deutlich ausserhalb der Mitte liegen. Erschwerend kommt hinzu dass sie "Mittenverschiebung" nicht mal während eines Frames konstant ist, sondern mit der maximal zulässigen Abweichung bei den ersten Bits anfängt und nach einigen Bits allmählich Richtung tatsächliche Bitmitte wandert.
Also in etwa so:
|1 Bit | ___ |_______| |_ 1.Bit
. . . _____ |_____| |_ 60.Bit
Ausgewertet wird das ganze mit einem Atmega-Interrupt-Eingang.
Ok - hast Du das schon mal realisiert oder ist das nur ein Stichwort das Dir dazu eingefallen ist. D.h. habe ich eine Chance mit gegebener Hardware damit das Problem lösen oder wird das unrealisierbar weil es einen DSP o.ä. voraussetzen würde?
Vielleicht solltest Du dich mal damit anfreunden, dass nicht jeder grade auf dem Laufenden ist, was so auf deinem Tisch rumliegt. Weder die Bitrate noch die Geschwindigkeit deines Rechenkünstlers hast Du erwähnt. Wie soll man da ernsthaft eine Antwort geben können?
Du schreibst, dass Du das Verfahren fehleroptimieren willst. Wie ist es bisher gelöst?
Auf Anhieb kaeme z.B. eine Fensterfunktion in den Sinn, nach dem Motto "Fahnde zwischen xx usec und xx usec hinter einem erkannten Flankenwechsel nach dem naechsten, aber nicht ausserhalb dieses Fensters". Dann einen Tiefpass, ueber den dieses Fenster enger geschnuert wird, geht aber nur wenn das Zeitverhalten des "Run-in" bekannt und zuverlaessig ist.
--
Gruesse, Joerg
http://www.analogconsultants.com/
"gmail" domain blocked because of excessive spam.
Use another domain or send PM.
Aktivierung der Flankentriggerung nach jeweils 3/4 der Vollbitzeit, Signalpegelabtastung nach dem jeweils folgenden Flankeninterrupt in Bitmitte, also zum Halbbitwechsel.
Ich kann momentan nur davon ausgehen dass die Vollbitfrequenz konstant ist, die Flanken sich aber während eines Frame-Empganges sowie von Frame zu Frame im Rahmen des 7:3-Verhältnisses verschieben können.
Wenn dieses "Verschieben" eher als wildes "Rappeln" auftritt, kannst Du die Reaktion auf Aenderungen im Fenster kaum bandbegrenzen. Da geht natuerlich auf das SNR. Aber das es nur 2400bd sind, kann man ja wenigstens vorher einen Tiefpass setzen.
--
Gruesse, Joerg
http://www.analogconsultants.com/
"gmail" domain blocked because of excessive spam.
Use another domain or send PM.
Das ist ja einfach (oder habe ich es nur falcsh verstanden?). Da kannst Du doch die Flankenwechsel der Vollbitfrequenz als sicher annehmen und von denen ausgehend dann kurz danach (bei ca. 15% der Zeit) und kurz vor dem nächsten Wechsel (85%) abtasten. Der jeweilige Wechsel in der Mitte der Vollbitflanken wird einfach ignoriert.
Bleibt zu hoffen daß das Signal nicht prellt. Bei dem Decoder der in
formatting link
Heft 6 ( kostenpflichtig ) beschrieben ist wird der Empfang mit fallender Flanke am IRQ gestartet, aber dann abgetastet bis das Datenpaket zuende ist. Dort wird die Dauer der Puls bestimmt und dann in einen Decoder gefüttert.
Meiner Ansicht nach solltest Du das Signal bei 25% und bei 75% abtasten. Das setzt eine DPLL-Funktionalität voraus, die diese Zeitpunkte einwandfrei aus dem Signal ableitet.
Eine Alternative wäre das Sampling mit n-facher Frequenz und anschliessender "gemütlicher " Analyse des Signalverlaufs. Das würde sich bei Datenpaketen mit geringer Wiederholrate anbieten, setzt aber Speicher voraus.
Wenn der Bitclock bekannt und einigermaßen konstant ist, ist die Sache eigentlich recht simpel:
Du benutzt die Zeitdifferenz zwischen zwei aufeinanderfolgenden _gleichen_ Flanken (erstmal egal welche!). Dieser Wert kann (idealisiert) genau einer von drei möglichen sein, nämlich 1xBitperiode,
1.5xBitperiode oder 2xBitperiode. Für die realen Werte benutzt du zwei Vergleichswerte mit 1.25 und 1.75 der bekannten Bitperiode und sortierst damit den realen Wert in einen von drei Fächern ein.
Fach 1 enthält genau 1 Bit der Nutzinformation Fach 2 enthält 1.5 Bit der Nutzinformation und die Information, daß sich der Pegel des Nutzbits einmal geändert hat Fach 3 enthält 2 Bits der Information, und die Information, daß sich der Pegel des Nutzbits zweimal geändert hat
Der Einfachheit halber hantiert man natürlich nicht mit halben Bitlängen, sondern benutzt bei der Implementierung statt dessen jeweils die doppelte Zahl, also 2,3 und 4.
Der Rest sollte klar sein. Man fängt mit einem beliebigen Bitwert an, zählt Takte und läßt Bits togglen oder auch nicht (Besondere Beachtung ist der Behandlung der Ereignisse in Fach 2 zu schenken, das niedrigstwertige Bit des Taktzählers ist hier eine große Hilfe!). Kommt Scheiße raus, invertiert man alle Bytes, die sich ergeben haben. Die Information über die Phasenlage steckt nämlich nicht im Manchestercode. Ist sie senderseitig konstant, wählt man für die Messung halt zukünftig die inverse Flanke des Signals.
Ist der Bitclock unbekannt, läuft's im Prinzip genauso, bloß muß man hier erstmal solange Ereignisse akkumulieren, bis man sie mit hinreichender statistischer Sicherheit in die drei Gruppen clustern kann. Dazu muß aber natürlich das Signal des Senders geeignet sein. Wenn der z.B. permanent Dauer-Low sendet oder Dauer-0x55, wird's natürlich nie was mit dem Clustern. Hat man die Cluster signifikant, kann man aus den aufgelaufenen Werten ganz einfach die 1.25 und 1.75-Schwelle für den Bitclock errechnen. Von dem Moment an, wo man die Schwellen hat, läuft's dann genau wie oben weiter, die akkumulierten Ereignisse muß man dann natürlich zuerst aufarbeiten und nebenher weiter fleißig Ereignisse aufzeichnen. Irgendwann ist man synchron (naja, ein bis zwei Bit hinterher bleibt man immer).
Und wenn der Bitclock nicht nur unbekannt, sondern auch noch instabil ist, muß man halt die Sache mit dem Clustering ständig "gleitend" weiterbetreiben, um die Schwellen laufend nachzuregeln.
Für die Zeitmessung wäre natürlich die Capture-Einheit der ATmegas wie gemacht. Als Eingang wäre dann entweder der ICP-Eingang zu verwenden bzw., wenn das Signal analog kommt, kann man auch den Analog-Komparator verwenden und spart damit einen externen Trigger.
So wie es aussieht wird immer die fallende Flanke verzögert, d.h. das Abfallen des Pegels erfolgt zu einem späteren Zeitpunkt(ohne Einfluss auf die Flankensteilheit). Diese Verzögerung wird nach jedem Bit geringer.
Aha, also nimmt sie doch ab. Dann koenntest Du nach Einsatz des Bit Stream das Fenster langsam zuschnueren und zurueckfahren, um SNR zu gewinnen. Dafuer muesste dieses "nach jedem Bit geringer werden" allerdings charaktisiert werden, dann entsprechend Margin (Reserve?) draufgeben, falls es doch mal nicht so schnell wie erwartet abnimmt.
Auch ein Error Handler wuerde noetig, falls die Sache ausrastet.
--
Gruesse, Joerg
http://www.analogconsultants.com/
"gmail" domain blocked because of excessive spam.
Use another domain or send PM.
Danke für die ausführliche Antwort - inzwischen scheint das Problem durch Anpassen der Zeifenster gelöst nach dem sich gezeigt hat dass immer nur die fallende Flanke sich mit abnehmender Tendenz verschiebt.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.