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?
Beitrag #5865896 wurde von einem Moderator gelöscht.
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
:
Bearbeitet durch User
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.
Dussel schrieb: > Unter welchem Begriff findet man was dazu? Wie wäre es denn mit "UART": https://de.wikipedia.org/wiki/Universal_Asynchronous_Receiver_Transmitter
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.