Hallo,
mal ein paar Gedanken zu den hier angesprochenen Problemen bei der Realisierung serieller synchroner Kommunikation bzw zur Rückgewinnung des Signaltaktes aus dem Nutzsignal:
eine Möglichkeit wäre es, das Startframe auszumessen. Benötigt würde hierfür ein externer Interrupt am AVR, der auf Flankenwechsel konfiguriert ist, sowie ein Timer.
Die HDLC-Startframes lauten 01111110, d.h. sie beginnen einem Flankenwechsel. Wird ein solcher empfangen, startet der Timer und mißt die Zeit zum abschließenden Flankenwechsel. Bei einer angenommenen Datenrate von 1200Bd beträgt die erwartete "Länge" eines Bits 833ns, zwischen den beiden Nulldurchgängen müßten also (7 * 833ns = ) 5,83ms liegen. Liegt die wirklich gemessene Zeit nun außerhalb eines bestimmten Toleranzbereiches, so ist das Startframe ungültig und wird verworfen. Anderenfalls wird nun anhand der gemessenen Zeit eine Zeitbasis für den Timer berechnet, der nunmehr den genauen Empfangstakt bereitstellt.
Auf Basis dieses Taktes könnte der Rest des Datenpaketes nun bitweise in einen Empfangsbuffer eingelesen (Flankenwechsel-INT nach 833ns = "0", kein Wechsel = "1"), auf einen gültigen Stop-Frame überprüft und dann zur Verarbeitung weitergegeben werden. Mal als Pseudocode:
Eventuell könnte man sogar auf das "Ausmessen" des Start-Frames verzichten und mit festen Timerwerten arbeiten. Da der Timer durch den Interrupt bei jeder empfangenen "0" (also spätestens nach jeweils 6 Bit) neu auf die Flanke synchronisiert wird, sollte sich eine eventuelle Drift doch eigentlich in Grenzen halten?Code:Wenn [externer INT] wenn Bitzähler < 5 ; Bit-Striping, eine "0" nach 5x "1" wird ignoriert schreibe "0" in den Empfangspuffer wenn Bitzähler = 6 ; Stop-Frame empfangen? gib Empfangspuffer aus setzte Bitzähler := 0 lade Timer = 1,5*Bitlänge ; Timer auf "Flanke-zu-Mitte" nächstes Bit starte Timer Ende Wenn [Timer-INT] inkrementiere Bitzähler ; wieviele aufeinanderfolgende "1"-Bits bisher? wenn Bitzähler > 6 ; ungültiger Frame empfangen? setze Fehler-Flag Ende schreibe "1" in den Empfangspuffer setze Timer = Bitlänge ; Timer auf "Mitte-zu-Mitte" nächstes Bit starte Timer Ende
Steckt da irgendwo ein Denkfehler drin, oder könnte das so funktionieren? Daß hier Flanken und keine Pegel ermittelt werden müssen, bringt mich doch etwas ins Trudeln...
Viele Grüße,
Thomas
Nun, schon, aber du kriegst das Zeugs doch mit irgendeinem Manchestercode oder sowas, d.h. den Takt kriegst du doch sowieso mit, da ja auch vor dem Frame ein ganzer Haufen Padding Bytes/Bits zum Synchronisieren daherkommen ?
(Bin aber etwas entwöhnt von synchron-datenverkehr, müßt mich erst wieder schlau machen)
mfg robert
Wer glaubt zu wissen, muß wissen, er glaubt.
Die Kodierung ist NRZI mit Bit-Stuffing. Soll heißen, "0" wird durch einen Pegelwechsel (bzw dann bei der eigentlichen Übertragung durch eine Frequenzumtastung) dargestellt, "1" durch einen fehlenden solchen. Und nach 5 aufeinanderfolgenden "1" wird eine zusätzliche "0" eingefügt, die der Empfänger wieder entfernen muß.
Das sieht dann etwa so aus (Ausgabesignal beim Start auf L-Pegel):
Je nach Bitfolge tritt also nur irgendwo aller 1 bis 6 Bit zwangsläufig ein Pegelwechsel auf, den man zur Taktrückgewinnung nutzen könnte - ich habe nur keine Idee, wie das einfacher gehen könnte.Code:Daten: 0010001110101011111010 kodiert: L HLLHLHHHHLLHHLHHHHHLHHL ^ Stuff-Bit
Ein Problem ist auch, daß die AX.25-Spezifikation keine Sync-Bits vorschreibt. Das Datenpaket beginnt theoretisch mit den Startframe, und da wird's dann auch schon ernst... In der Praxis können je nach Gegenstelle Sync-Bits empfangen werden, oder eben auch nicht. Das scheint auch den bereits existierenden Projekten Schwierigkeiten zu bereiten (solange nicht direkt die NF mittels DSP ausgewertet wird). Daher wollte ich lieber auf Nummer Sicher gehen.
Das Ganze wird wohl auf "Versuch und Irrtum" hinauslaufen. Glücklicherweise habe ich einen PR-Digipeater in Hörweite, da mangelt es wenigstens nicht an Testsignalen für den Empfang
Es fehlen eigentlich "nur" noch Zeit, Zeit und eine (auch kleine Stückzahlen liefernde) Bezugsquelle für FX- bzw MX614-Modem-ICs. Ach ja, und Zeit.
Viele Grüße,
Thomas
Ja, die fehlt immer... Ach ja, und Zeit.
Ich krame mir mal das Zeugs raus, vielleicht find ich was.
mfg robert
Wer glaubt zu wissen, muß wissen, er glaubt.
Berechtigungen
Zitieren
Lesezeichen