Moin,
wie kann an einem Bus mit einer Leitung pro Richtung (also kein
Taktsignal und nicht differentiell) der Anfang eines Datenpakets erkannt
werden? Mit zwei Leitungen zeigt man den Anfang durch 'ungültige'
Zustände, wie bei I2C. Aber ohne Takt?
Unter welchem Begriff findet man was dazu?
Bei DMX erzeugt man mit Break und Mark after Break Zustände, die als
Daten nicht auftreten können. Das senkt aber die
Übertragungsgeschwindigkeit unter Umständen deutlich.
Bei MIDI (kein Bus) ist das erste Bit des ersten Bytes anders als die
der folgenden Bytes. Das verschenkt aber die Hälfte des Datenbereichs
pro Byte.
Man könnte eine bestimmte Folge als Paketanfang festlegen, aber die
könnte man nicht mehr als Datenwert nutzen.
Bei Manchestercode und ähnlichen könnte man für zwei oder mehr Bitlängen
die Flanken auslassen. Dafür müsste man aber erstmal Manchestercode
verwenden.
Gibt es noch andere Verfahren?
Dussel schrieb:> Man könnte eine bestimmte Folge als Paketanfang festlegen, aber die> könnte man nicht mehr als Datenwert nutzen.
Man kann auch die Zeit nutzen, um Pakete voneinander zu trennen. Wenn
eine gewisse Zeit vergeht, ohne daß Daten empfangen werden, ist
offensichtlich das Paket beendet, d.h. das nächste Paket fängt mit dem
nächsten Byte an.
Das Problem von Paketanfangskennungen lässt sich mit sinnvoll
strukturierten Paketen in den Griff bekommen - das Paket bekommt eine
Prüfsumme und eine Längeinformation, die Längeninformation steht im
Paket vor den Nutzdaten.
Damit können die Nutzdaten beliebige Bitmuster enthalten.
Beim unsynchronisierten Paketempfang wird auf die Paketanfangskennung
gewartet und der nachfolgende Bytestrom auf Plausibilität geprüft, d.h.
die Längeninformation wird erfasst und nach der entsprechenden Anzahl
von Bytes die Prüfsumme verglichen.
Passt das nicht, weil z.B. die Längenangabe zu groß ist, oder die
Prüfsumme falsch ist, wird im empfangenen Datenstrom nach der nächsten
Paketanfangskennung gesucht und der Vorgang wiederholt.
Hat das empfangene System zu wenig Speicher, um ein komplettes Paket zur
Analyse aufzuheben, wird halt alles bis zum Zeitpunkt der
Fehlererkennung empfange verworfen und der Vorgang wiederholt, bis sich
Synchronität einstellt.
Länge und Prüfsumme wäre dann ja eine Ebene höher (nicht unbedingt auf
das OSI-Modell bezogen).
Den Paketanfang muss man ja trotzdem irgendwie erkennen können. Wenn man
jedes Byte als potentielles Anfangsbyte mit Längeninformation sieht,
müsste man ja bis zum wirklichen Anfang alle potentiellen Pakete
annehmen und untersuchen.
Du kannst eine bestimmte Datenfolge einmalig machen durch Umschreiben
(escaping würde man auf gut Englisch vermutlich sagen) dieser Datenfolge
in den Nutzdaten.
Also, Du legst z.B. fest : jedes 0x1b in den Nutzdaten wird doppelt
gesendet.
Jeder Block fängt mit 0x1b 0x00 an (dabei wird das 0x1b natürlich nicht
verdoppelt)
Damit findest Du einen Paketanfang auch wenn Dir Bytes verloren gegangen
sind. Das wäre nämlich der Haken an der Lösung mit der übertragenen
Datenlänge.
Wenn die Pakete dann noch ein Format und Prüfdaten haben, die man
abtesten kann, steht dem Verwerfen von fehlerhaften Paketen nix im Wege.
Wie man den Sender dazu bekommt, nicht oder falsch angekommene Pakete zu
wiederholen erzählen wir Dir später.
Dussel schrieb:> Man könnte eine bestimmte Folge als Paketanfang festlegen, aber die> könnte man nicht mehr als Datenwert nutzen.
Man kann auch ein spezielles Byte oder mehrere als Steuerbytes
definieren und diese im Datenstrom "escapen" also durch ein weiteres
spezielles Steuerbyte als Datenwert kennzeichnen.
fop schrieb:> Du kannst eine bestimmte Datenfolge einmalig machen durch Umschreiben> (escaping würde man auf gut Englisch vermutlich sagen) dieser Datenfolge> in den Nutzdaten.
Stimmt, das könnte man auch machen.
fop schrieb:> Wenn die Pakete dann noch ein Format und Prüfdaten haben, die man> abtesten kann, steht dem Verwerfen von fehlerhaften Paketen nix im Wege.
Das wäre ja dann die Paketsicherung.
Die Frage war allgemein gemeint, aber eher im Hinblick auf
Mikrocontroller und kleine Pakete. Bei Ethernet mit Paketen bis über
1500 Byte kann man sich da natürlich mehr erlauben.
Moin,
8B10B waere noch so ein Verfahren, wo man erstmal den Takt leichter
wieder gewinnen kann und auch noch ausser den Datenbytes noch ein paar
weitere Steuercodes verschicken kann.
Gruss
WK
In diesem Zusammenhang, gibt es eigentlich ein Prüfverfahren, so was
ähnliches wie CRC, wo man jedoch frühzeitig eventuelle Fehler erkennen
kann, d.h. noch bevor man über die gesamte Länge getestet hat (also ein
Early-Break-Verfahren)?
Dergute W. schrieb:> 8B10B waere noch so ein Verfahren, wo man erstmal den Takt leichter> wieder gewinnen kann und auch noch ausser den Datenbytes noch ein paar> weitere Steuercodes verschicken kann.
Vergrößert aber auch die Datenmenge um ein Viertel, wenn ich mich nicht
vertue. Aber möglich wäre das natürlich auch.
Mutluit M. schrieb:> In diesem Zusammenhang, gibt es eigentlich ein Prüfverfahren, so was> ähnliches wie CRC, wo man jedoch frühzeitig eventuelle Fehler erkennen> kann, d.h. noch bevor man über die gesamte Länge getestet hat (also ein> Early-Break-Verfahren)?
Stimmt. Man müsste aber die CRC vorher übertragen und Bytes
zwischenspeichern.
Danke für die Antworten. Da gibt es ja doch noch einige Möglichkeiten.
Dussel schrieb:> Mutluit M. schrieb:>> In diesem Zusammenhang, gibt es eigentlich ein Prüfverfahren, so was>> ähnliches wie CRC, wo man jedoch frühzeitig eventuelle Fehler erkennen>> kann, d.h. noch bevor man über die gesamte Länge getestet hat (also ein>> Early-Break-Verfahren)?> Stimmt. Man müsste aber die CRC vorher übertragen und Bytes> zwischenspeichern.
Ja, das sollte natürlich im PktHeader sein, nicht am PktEnde.
Aber: das was ich meine ist kein normaler CRC, sondern eine neuartige(?)
Methode um Fehler frühzeitig zu erkennen...
Hab auf die schnelle folgende Paper gefunden, aber hab sie noch nicht
studiert:
"Early Detection Using CRC Precoding and Polar Codes for Low Latency
Communications"
http://espace.etsmtl.ca/1905/1/RIVADENEIRA_ERAZO_Alex_Homero.pdf
"Techniques for early stopping and error detection in turbo decoding"
https://ieeexplore.ieee.org/document/1237429
Moin,
Dussel schrieb:> Vergrößert aber auch die Datenmenge um ein Viertel, wenn ich mich nicht> vertue. Aber möglich wäre das natürlich auch.
Umsonst ist der Tod und der kost's Leben...
Mutluit M. schrieb:> gibt es eigentlich ein Prüfverfahren, so was> ähnliches wie CRC, wo man jedoch frühzeitig eventuelle Fehler erkennen> kann,
Mach' kleinere Pakete, wenn du frueher wissen willst, ob was schief
gegangen ist.
Macht aber auch wieder mehr Overhead.
Gruss
WK
Dergute W. schrieb:> Moin,>> Dussel schrieb:>> Vergrößert aber auch die Datenmenge um ein Viertel, wenn ich mich nicht>> vertue. Aber möglich wäre das natürlich auch.>> Umsonst ist der Tod und der kost's Leben...>> Mutluit M. schrieb:>> gibt es eigentlich ein Prüfverfahren, so was>> ähnliches wie CRC, wo man jedoch frühzeitig eventuelle Fehler erkennen>> kann,>> Mach' kleinere Pakete, wenn du frueher wissen willst, ob was schief> gegangen ist.> Macht aber auch wieder mehr Overhead.
Nein, nein! Mir ist eben eine wirksame Methode eingefallen! :-)
Muss die Idee noch bischen reifen lassen in meinem Kopf... :-)
Ich melde mich dann hier nochmal...
USB sendet gar keine Datenpakete, solange kein Gerät angesteckt ist. Das
Gerät wird anhand des Pullup-Widerstands auf der Datenleitung erkannt,
worauf der Host die ersten Pakete sendet; zu diesem Zeitpunkt sollte das
Gerät empfangsbereit sein.
In dem unwahrscheinlichen Fall dass ein Gerät während eines Pakets aus-
und wieder eingesteckt wird, wird die CRC-Prüfung dieses Paktes
fehlschlagen und das Gerät keine Antwort senden, worauf ein Timeout
auftritt und eine Neuübertragung gestartet wird.
Dadurch wird weder ein Escaping noch lange Pausen noch eine spezielle
Zeichenfolge benötigt.
Die USB-Hardware von Mikrocontrollern macht das alles komplett
automatisch; daher ist dieser Aspekt bei der Programmierung von
USB-Geräten komfortabel erledigt.
Mutluit M. schrieb:> Aber: das was ich meine ist kein normaler CRC, sondern eine neuartige(?)> Methode um Fehler frühzeitig zu erkennen...
Klar, mit CrC geht das natürlich nicht, da habe ich mich vertan.
Mutluit M. schrieb:> Hab auf die schnelle folgende Paper gefunden, aber hab sie noch nicht> studiert:
Danke.
Dr. Sommer schrieb:> USB sendet gar keine Datenpakete, solange kein Gerät angesteckt ist.
Das geht aber nicht an einem Bus mit mehreren Teilnehmern.
Udo S. schrieb:> Man kann auch ein spezielles Byte oder mehrere als Steuerbytes> definieren und diese im Datenstrom "escapen" also durch ein weiteres> spezielles Steuerbyte als Datenwert kennzeichnen.
Siehe asynchrones PPP. 2 Codeworte. Eines trennt Pakete, das andere
codiert Folgebytes so um (z.B. XOR irgendwas), dass diese beiden Codes
im Datenbereich nicht vorkommen.
Allerdings gibts das Problem mitunter auf zwei Ebenen. Ein nicht durch
ausreichend Pause unterbrochener UART Strom kann von Haus aus weder auf
Bytes noch auf Pakete sicher syncen. Paket-Sync geht über den
beschriebenen Mechanismus, setzt aber einen sichere Byte-Sync voraus.
Das in den Anfängen der Datenkommunikation bei asynchronen
Verbindungen meist verwendet Protokoll kennt anscheinend heute niemand
mehr:
STX DATEN ETX (BCC)
0x02 DATEN 0x03 (BCC)
BCC:
The BCC is a 2 digit checksum calculated using the Exclusive OR (Xor) of
all the characters in the transmitted or
received message between (but NOT including) <STX> and <ETX>.
Was man in die DATEN packt ist dann jedem überlassen.
Einfacher geht es nicht.
Codix schrieb:> Was man in die DATEN packt ist dann jedem überlassen.
Protokolle, die nicht 8-Bit-transparent sind, sind nur für
Textübertragung wirklich zu gebrauchen. Wenn man seine Anwendung danach
ausrichtet, ist das durchaus sinnvoll.
Codix schrieb:>> STX DATEN ETX (BCC)>> 0x02 DATEN 0x03 (BCC)>> Was man in die DATEN packt ist dann jedem überlassen.
Zumindest den ETX muss man "escapen" wenn er in den Daten vorkommt.
Oder man beschränkt sich auf den "Zeichensatz" wo ETX (und STX) nicht
vorkommen kann, wie der Vorposter A.K. auch schrieb.
Bei Binärdaten (im Gegensatz zu Textdaten) wird das aber nicht einfach;
da muss man zwangsläufig entspr. "escapen"...
Ich pers. würde eine andere Methode nehmen, also Paketverfahren.
Geh' mal ins Museum. Ganz hinten, wo die Antiken stehen, gibt es eine
Vitrine auf der steht: RS232.
Schau Dir mal an, wie einfach und sicher die das Problem gelöst haben.
Anno Fernschreiber, also in einer Zeit, in der noch mit 50 Hz gehechelt
wurde, lief das Problemlos.
Auch andere Protokolle haben irgendeine Sequenz ausgemacht, mit der sie
sich vom großen Nichts unterscheiden und mit der sie anfangen.
