synchrone Kommunikation: praktikabler Lösungsansatz?

[ThSteier]

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:

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

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?

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

[PicNick]

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)

[ThSteier]

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

Daten:      0010001110101011111010

kodiert:  L HLLHLHHHHLLHHLHHHHHLHHL
                               ^
                           Stuff-Bit

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.

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

[PicNick]

.. Ach ja, und Zeit.

Ja, die fehlt immer.
Ich krame mir mal das Zeugs raus, vielleicht find ich was.