DE102004061803A1

DE102004061803A1 - Verfahren und Vorrichtung zur Fehlerbehandlung bei der Übertragung von Daten über ein Kommunikationssystem

Info

Publication number: DE102004061803A1
Application number: DE102004061803A
Authority: DE
Inventors: Eberhard Böhl; Michael Böhl
Original assignee: Robert Bosch GmbH
Current assignee: Robert Bosch GmbH
Priority date: 2004-04-08
Filing date: 2004-12-22
Publication date: 2005-10-27
Also published as: EP1735936A2; WO2005099153A1; WO2005099153A9; US20070234174A1; JP2007533184A

Abstract

Verfahren und Vorrichtung zur Fehlerbehandlung bei der Übertragung von codierten Daten in Form wenigstens eines Datenwortes über ein Kommunikationssystem, wobei zu dem wenigstens einen Datenwort ein Codedatenwort nach einer vorgebbaren Codiervorschrift ausgewählt wird, wobei die Daten als Bits, die zwei verschiedene Werte, Einsen und Nullen, annehmen können, dargestellt werden, wobei wenigstens eine laufende digitale Summe derart gebildet wird, dass eine aufsummierte Differenz der Gesamtzahl der Einsen und der Gesamtzahl der Nullen wenigstens über das Codedatenwort gebildet wird und diese laufende digitale Summe übertragen wird, wobei die laufende digitale Summe zum folgenden Codedatenwort bestimmt und mit der dann übertragenen verglichen wird, wobei bei Abweichung auf Fehler erkannt wird.

Description

Die Erfindung geht aus von einem Verfahren und einer Vorrichtung zur Fehlerbehandlung bei der Übertragung von codierten Daten in Form wenigstens eines Datenwortes über ein Kommunikationssystem mit wenigstens zwei Teilnehmern sowie einem entsprechenden Teilnehmer des Kommunikationssystems und einem entsprechenden Computerprogramm und Computerprogrammprodukt gemäß den Oberbegriffen der Ansprüche.

Codes für die Übertragung von Daten über ein Kommunikationssystem, insbesondere über serielle Busse unterscheiden sich, je nach dem Übertragungsmedium, der Bitrate und dem Erfordernis einer Taktrückgewinnung und der EMV-Kennwerte. Für die Übertragung von Daten mit bis zu 25 Mbits/s wurde zum Beispiel im MOST-System eine optische Übertragung vorgesehen, um die EMV-Verträglichkeit zu garantieren. Dabei sind elektrisch-optische Wandler aber sehr teuer und die benutzten Plastik-Optikfasern haben spezielle Anforderungen an die Verlegung in der Karosserie. Zu diesem Zweck sind die Signale im MOST-Bus nach dem Bi-Phase marc Code (Bi-Frequenz-Code) codiert. Jedes Informationsbit wird dabei durch zwei Codebits dargestellt. Haben beide Codebits den gleichen Wert, dann entspricht das dem Wert des Informationsbits 0. Durch unterschiedliche Werte der Codebits wird eine 1 dargestellt. Zusätzlich erfolgt nach den zwei Codebits immer ein Wechsel des Pegels, unabhängig von dem Informationswert:
Codebits 00 10 10 11 00 11 01 01 ..
Info-bits 0 1 1 0 0 0 1 1 ...

Dabei hat der Code im Verhältnis zu den Nutzbits 100%-ige Redundanz. Überträgt man aber eine solche Codebitfolge über elektrische Leitungen, so erfolgt wegen der häufigen Änderung des Pegels eine hohe EMV-Abstrahlung entsprechend der Bitrate (bei vorzugsweise Nullen) und der doppelten Bitrate (bei vorzugsweise Einsen). Für die Übergänge zwischen Einsen und Nullen ergeben sich im Frequenzspektrum auch andere Frequenzwerte, ohne aber die dominierenden zwei Frequenzen wesentlich zu dämpfen. Das kommt dadurch zu Stande, weil an den Bitgrenzen durch die Codevorschrift immer ein Pegelwechsel gefordert ist. Überträgt man die Daten ohne Redundanz, d.h. in einer Binär-Codierung mit den Wertigkeiten 1, 2, 4 , 8 usw., z.B. auch darstellbar in einer hexadezimalen Codierung (0x0 entspricht binär 0000 und 0xF entspricht binär 1111), so hat man den Nachteil, dass es zum einen nicht notwendig Pegelwechsel geben muss (ständig 0x0 oder 0xF) oder diese in einer ähnlichen Häufigkeit wie oben bei jedem Bit erfolgen, sofern ständig 0x5 oder 0xA gesendet wird. Da hier jedoch keine Code-Redundanz vorliegt, sondern alle Bits Informationsbits sind, kann die Übertragungsfrequenz auf den halben Wert gesenkt werden. Damit kann dieser verwendete Code aber nicht gleichstromfrei sein und bietet gleichzeitig nicht die Möglichkeit der Taktrückgewinnung mittels einer PLL (phase locked loop), da es keine vorgebbare maximale Bitanzahl ohne Pegelwechsel gibt. Eine PLL benötigt zur Einsynchronisierung mindestens aller n Bits einen Pegelwechsel. Damit zeigt der Code, wie soeben beschrieben, einige unerwünschte Nachteile.

Teilweise können die Nachteile durch Verwendung eines bekannten Blockcodes, wie beispielsweise in "A new 8B10B Blockcode for High Speed Data Transmission Over Unshielded Twisted Pair Channels", von Alistair Coles, Hewlett Packard, Oktober 1996, vermieden werden. Hierbei liegt die Coderedundanz bei 25%, da an Stelle der 8 Informationsbits 10 Codebits übertragen werden. Der Code ist im Durchschnitt gleichstromfrei, weil in Abhängigkeit von der Anzahl der übertragenen Einsen im Vergleich zu den Nullen (running digital sum – RDS) das Codewort entweder invertiert oder nichtinvertiert übertragen wird. Die maximale Anzahl gleicher Codebitwerte (maximum run length MRL) ist 17. Damit wäre prinzipiell noch ein Anschluss einer PLL zur Taktrückgewinnung möglich, wobei hier aber hohe Anforderungen an die Stabilität der PLL gestellt werden und die Einschwingzeiten erheblich länger werden.

Ein außerordentlicher Nachteil von den Blockcodes ist, dass es kein systematischer Code ist und somit keine Codiervorschrift wie zum Beispiel bei einem Hexadezimalcode mit einer Wertigkeitszuordnung der entsprechenden Codebits entsprechend ihrer Position gibt.

Das wirkt sich insbesondere bei der Realisierung eines Incrementers oder auch Vergleichers aus, weil zunächst, insbesondere beim Incrementer, das gesamte Codewort empfangen werden muss, der Codewert durch Decodieren mittels einer Tabelle ermittelt werden muss und für den um 1 erhöhten Codewert das entsprechende Codewort mittels Tabelle generiert wird, welches dann erst wieder ausgesendet werden kann, synchronisiert durch mindestens ein Flip-Flop. Für den oben genannten Blockcode ergibt sich damit eine Verzögerung von mindestens 11 Takten; bei der Abspeicherung der Codetabellen in synchronem RAM ergeben sich sogar mindestens 13 Takte Verzögerung.

Wie soeben dargestellt, zeigt der genannte Stand der Technik nicht in jeder Hinsicht optimale Eigenschaften.

Aufgaben und Vorteile der Erfindung

Insbesondere die Summe der Eigenschaften, dass der verwendete Code gleichstromfrei sein sollte und wegen der benötigten Taktrückgewinnung häufige Flanken enthalten sollte, sowie die Möglichkeit der seriellen Incrementierung bieten sollte, um die Netzwerkposition eines Knotens durch einfache Incrementierung eines speziellen Kontrollbytes zu erzeugen und ohne große Verzögerung weiter zu leiten. Dabei ist es insbesondere wünschenswert, eine elektrische Lösung zu finden, die deutlich geringere Kosten aufweist, d.h. insbesondere ohne die Notwendigkeit einer Abschirmung im Rahmen der EMV-Verträglichkeit eingesetzt werden kann.

Dabei sind die Codes zur Fehlerbehandlung, also zur Fehlererkennung und/oder Fehlerkorrektur je nach Mächtigkeit, insbesondere Mächtigkeit der Korrekturmöglichkeiten, mit einer unterschiedlichen Coderedundanz zu versehen, die es ermöglicht, Codewörter von Nicht-Codewörtern bzw. Nicht-Codedatenwörtern zu unterscheiden. Nicht-Codewörter sind dann eben die Codewörter, die nicht nach der Codiervorschrift, die zur Codierung der Daten vorgesehen ist, codiert wurden und sich von diesen unterscheiden lassen. Bei einem geringen Hammingabstand, also Fehlerabstand des empfangenen Nicht-Codewortes oder Nicht-Codedatenwortes zu genau einem Codedatenwort ermöglicht die unterschiedliche Coderedundanz, darauf zu schließen, dass es sich um das betreffende Codedatenwort handelt, welches auf der Übertragungsstrecke in beispielsweise einem Bit verfälscht wurde. Diese Korrekturmöglichkeit setzt voraus, dass alle Codewörter mindestens einen Hammingabstand von 2 zueinander haben, wenn Einzelbitfehler erkannt und mindestens einen Hammingabstand von 3 haben wenn Einzelfehler korrigiert werden sollen. Dabei ist es zunehmend schwierig, diese Bedingung einzuhalten, wenn zu einem Datenwort mehrere Codierungsmöglichkeiten bestehen, d. h. in Abhängigkeit von anderen Bedingungen entweder das eine oder das andere Codedatenwort gesendet wird.

Bei gleichbleibender Coderedundanz wird die Hammingdistanz entsprechend kleiner, wenn mehr Codedatenwörter benutzt werden. Die alternative Sendung von verschiedenen Codewörtern wird benötigt, wie bereits genannt, wenn beispielsweise ein Code im Mittel gleichstromfrei sein muss. Das ist beispielsweise bei unterschiedlichen Übertragungsmöglichkeiten über verschiedene Übertragungsmedien (elektrisch, optisch) erforderlich und möglich. Dabei wird dann zugelassen, dass zur Erzielung der Gleichstromfreiheit beispielsweise das invertierte Codedatenwort für das eigentliche Codedatenwort genau dann gesendet wird, wenn es die Anzahl der bisher gesendeten Einsen und Nullen bedingt durch die Darstellung der Daten als Bits (Eins oder Null) besser ausgleicht. Bei einem vollständig gleichstromfreien Code sollte die Anzahl der gesendeten Einsen und Nullen zu jeweils 50% aufgeteilt sein. Mit den erfindungsgemäßen alternativen Codewörtern erreicht man dies im Durchschnitt, insbesondere mit einem Codewort 1 und einem dazu inversen Codewort 2, wenn man sich die Differenz der bisher gesendeten Bitwerte merkt, insbesondere also eine laufende Summe bildet. Sind eben bisher mehr Einsen gesendet, wird man das Codedatenwort mit mehr Nullen auswählen oder umgekehrt.

Um nun eine Codeerkennung mit anschließender Codekorrektur zu ermöglichen, ist mindestens ein Hammingabstand von drei zwischen zwei beliebigen Codedatenwörtern erforderlich. Das setzt voraus, dass im Coderaum für n (n aus N) mögliche Codeworte 2n Nicht-Codedatenworte zur Verfügung stehen. Sollen nun m Datenworte (m aus N) übertragen werden, so muss n mindestens gleich 2m sein, um die alternative Codeauswahl zu ermöglichen. Es müssen demnach 2m Codedatenworte und 2 mal 2m Nicht-Codedatenworte im Coderaum genauso untergebracht werden, d. h. 6m Code- und Nicht-Codedatenworte so untergebracht werden, dass immer der Hammingabstand 3 zwischen zwei Codedatenworten gewährleistet ist. Wird nun zur Codierung eines Datenwortes, also zur Erzeugung eines Codedatenwortes mit k Bits (k aus N) zusätzlich eine Anzahl von 3 Bits zur Codierung verwendet, ergibt sich theoretisch die Möglichkeit, in dem 2^(k+3) Coderaum diese Bedingungen zu erfüllen. Für ein Datenwort mit 4 Bits werden deshalb mindestens 75% Coderedundanz (3Bits) benötigt.

In der praktischen Durchführung scheitert man jedoch häufig an zusätzlichen Randbedingungen für die Codierung, wie z. B. für EMV-gerechte Codierung mit möglichst wenigem Bitwechseln/Pegelwechseln im Codedatenwort oder an den Codedatenwortgrenzen. Dadurch kann sich die Coderedundanz noch erhöhen. Auch kommen zu den Codedatenworten gegebenenfalls noch Steuercodeworte hinzu, die besondere Funktionen erfüllen und nicht mit Codedatenworten verwechselt werden dürfen. Deshalb sind Codes mit 100% Coderedundanz ebenfalls in der Anwendung, insbesondere bei kurzen Datenworten.

Die nachfolgend im Detail ausgeführte diese Überlegungen fortführende, erfindungsgemäße Lösung kann die oben genannten Nachteile des Standes der Technik vermeiden und gleichzeitig die geforderten Eigenschaften wenigstens für einen Teil der Daten bieten, insbesondere einen gewünschten vorgebbaren Hammingabstand zu erzielen (insbesondere Hammingabstand 2 oder 3) bei gleichzeitig deutlich geringerem Aufwand.

Um im Mittel gleichstromfrei zu übertragen, existiert eine erfindungsgemäße Vorschrift, die eine Auswahl des Codedatenwortes im Sender, insbesondere in dem ersten Teilnehmer vorschreibt. Wenn der Empfänger, insbesondere der zweite Teilnehmer, vorteilhafter Weise über die gleichen Informationen wie der Sender verfügt, ist es ihm auch möglich zu entscheiden, ob eine Invertierung des Codedatenwortes vorgenommen werden müsste oder nicht. Dazu muss dem Empfänger nur erfindungsgemäß mitgeteilt werden, unter welchen Bedingungen der Sender die Codierung vorgenommen hat. Geht man davon aus, dass der Empfänger nicht alle Daten des Senders empfangen hat, weil er bei einer kontinuierlichen Übertragung sich erst später dazugeschaltet hat oder im Falle einer Störung ein Teil der Daten verlorengegangen ist, so würde der Empfänger nicht über diese Information verfügen.

Kern der Erfindung ist deshalb eine Möglichkeit der Übertragung dieser Information zusätzlich zu den Daten insbesondere mittels Nicht-Codedatenwörtern.

Solche Nicht-Codedatenwörter werden üblicherweise benötigt, um z. B. den Beginn einer Übertragung zu kennzeichnen oder die Art der nachfolgenden Daten zu unterscheiden und bei einer kontinuierlichen Übertragung auch die Möglichkeit der Einsynchronisation der neu hinzugefügten Empfänger zu ermöglichen. So gibt es beispielsweise Bussysteme, also Kommunikationssysteme, bei denen die Daten in Rahmen, sogenannten Frames organisiert sind, die mit einer Präambel beginnen. Diese Präambel muss sich von den Codedatenworten unterscheiden. Wenn die Codierungskriterien für den Empfänger bekannt sind, braucht er nicht mehr alle Codedatenworte bei einer erforderlichen Fehlererkennung oder Fehlerkorrektur einzubeziehen, sondern nur noch die Hälfte. Damit ist zweckmäßiger Weise zwischen den verbleibenden Codeworten der geforderte Hammingabstand besser einzuhalten, ohne die Coderedundanz zu erhöhen.

Somit geht die Erfindung vorteilhafter Weise von einem Verfahren zur Fehlerbehandlung bei der Übertragung von codierten Daten in Form wenigstens eines Datenwortes über ein Kommunikationssystem mit wenigstens zwei Teilnehmern aus, wobei zu dem wenigstens einen Datenwort ein Codedatenwort nach einer vorgebbaren Codiervorschrift ausgewählt wird, wobei die Daten als Bits, die zwei verschiedene Werte, Einsen und Nullen annehmen können, dargestellt werden. Zweckmäßiger Weise wird dabei eine laufende digitale Summe, die sogenannte running digital sum RDS derart gebildet, dass eine aufsummierte Differenz der Gesamtzahl der Einsen und der Gesamtzahl der Nullen wenigstens über das Codedatenwort gebildet wird und diese laufende digitale Summe RDS vom ersten zum zweiten Teilnehmer übertragen wird, wobei der zweite Teilnehmer die laufende digitale Summe zum folgenden Codedatenwort des ersten Teilnehmers bestimmt und mit der dann übertragenen vergleicht, wobei bei Abweichung auf Fehler erkannt wird. D. h. es wird vorteilhafter Weise die Entscheidung für das aktuelle Codedatenwort von der aktuellen running digital sum rds abhängig gemacht. Durch die Übertragung ist dieser RDS Wert dem Empfänger, also insbesondere einem zweiten Teilnehmer bekannt, wodurch dann die Auswahl der möglichen Codedatenworte auf c.a. die Hälfte beschränkt werden kann. Es wird deshalb vorteilhafter Weise vorgesehen, die RDS insbesondere periodisch zu übermitteln und im Empfänger, also insbesondere im zweiten Teilnehmer auf dieser Basis weiter zu berechnen bis zur nächsten Aktualisierung. Dann kann erfindungsgemäß mit dem neu empfangenen RDS-Wert die Richtigkeit der bisherigen Codedatenworte respektive der schon vorgenommenen Datenkorrekturen bestätigt werden oder gegebenenfalls bei Abweichung auf Fehler erkannt werden.

Zweckmäßiger Weise werden neben den codierten Daten auch wenigstens ein Nicht-Codedatenwort zwischen dem ersten Teilnehmer und dem wenigstens zweiten Teilnehmer übertragen, welches nicht nach der vorgebbaren Codiervorschrift codiert ist und die laufende digitale Summe wenigstens als Teil des Nicht-Codedatenwortes übertragen wird.

Dabei wird zweckmäßiger Weise, wie oben genannt, ein Codewort oder Codedatenwort ausgewählt entsprechend der vorgebbaren Codiervorschrift, welches jeweils einem ersten oder zweiten Codedatenwort entspricht, die zueinander invertierte Codedatenworte darstellen.

Vorteilhafter Weise wird entsprechend der vorgebbaren Codiervorschrift das Codedatenwort aus mehreren, also wenigstens zwei verschiedenen Codedatenwortsätzen ausgewählt.

Vorteilhafter Weise wird bei Erkennen auf Fehler ein Fehlersignal des Teilnehmers erzeugt, der den Fehler erkannt hat und dieses Fehlersignal wenigstens zum Teilnehmer übertragen wird, von dem der Fehler übertragen wurde.

Als Fehlerreaktion werden zweckmäßiger Weise bei Erkennen auf Fehler die fehlerhaften Daten verworfen und der diese übertragende Teilnehmer erhält ein Anforderungssignal, diese Daten erneut zu senden.

Weiterhin vorteilhaft ist, dass neben den codierten Daten auch wenigstens ein Nicht-Codedatenwort zwischen dem ersten Teilnehmer und dem wenigstens zweiten Teilnehmer übertragen wird, welches nicht nach der vorgebbaren Codiervorschrift codiert ist und die laufende digitale Summe auch über das Nicht-Codedatenwort gebildet wird.

Weiterhin zweckmäßig wird erfindungsgemäß eine Korrektur des Fehlers vorgenommen, in dem abhängig von der laufenden digitalen Summe, also der running digital sum RDS die folgende RDS erneut ermittelt wird und abhängig davon die fehlerhaften Daten ersetzt werden.

Vorteilhafter Weise erfolgt abhängig von der Anzahl der Fehler eine Strategievorgabe zur Fehlerbehandlung. Dabei kann die Strategie neben der Fehlerkorrekturt auch vorsehen, unter vorgebbaren Voraussetzungen keine Fehlerkorrektur erfolgt oder aber dass eine Korrektur des Fehlers derart vorgenommen wird, indem das fehlerhafte Datenwort durch ein bestimmtes fesgelegtes Datenwort ersetzt wird.

Insbesondere vorteilhaft ist es, das erfindungsgemäße Verfahren im Rahmen eines Computerprogramms oder eines Computerprogrammprodukts mit Programmcode, der auf einem Datenträger gespeichert ist, darzustellen, wobei das Verfahren ausgeführt wird, wenn das Programm in einem computergestützten Kommunikationssystem, wie oben genannt, ausgeführt wird. Als Datenträger des Computerprogrammprodukts ist dabei jeder mögliche Datenträger einsetzbar, wie z.B. ROM, CD-ROM, EPROM, EEPROM, Flash-EPROM, PROM, DVD, Diskette, RAM, usw. D.h. die Wahl des Datenträgers hängt von Computersystem ab in dem das Verfahren ablaufen soll, hat aber keinerlei limitierenden Effekt bezüglich der Erfindung.

Weitere Vorteile und vorteilhafte Ausgestaltungen ergeben sich aus der Beschreibung sowie den Merkmalen der Ansprüche.

Zeichnung
Die Erfindung wird im Weiteren anhand der in der Zeichnung dargestellten Figuren und der Tabelle näher erläutert. Dabei zeigt
1 ein Kommunikationssystem mit Teilnehmern.
2, 2a, 3 und 4 sowie 4a zeigen schematisch die Wandlung eines Eingangscodes in einen Ausgangscode mit Hilfe eines Codegenerators (2), Decodierer – „Pfeilrichtung umgekehrt"(2a), eines Incrementers (3) oder eines Komparators, also Vergleichers (4) sowie eine Arbitrierungseinheit mit Comparator (Vergleicher ) und Umschalteinheit (4a)
Ein erfindungsgemäßes serieller Incrementer ist in 5 dargestellt.
6 zeigt einen erfindungsgemäßen seriellen Komparator oder Vergleicher.
7 zeigt einen seriellen Sender als Schnittstelle des oder zum Kommunikationssystem(s).
Ein entsprechender serieller Empfänger ist in 8 dargestellt.
9 zeigt noch einmal in den 9a und 9b einen Codegenerator mit alternativen Codedatenwörtern und deren Übertragung über eine Übertragungsstrecke sowie den entsprechenden Empfänger mit Decodierer und der Rückgewinnung der Zusatzinformation aus dem RDS.
10 zeigt ein Beispiel für erfindungsgemäße Frames mit den unterschiedlichen Präambeln.
11 schließlich zeigt noch einmal einen Decoder mit Fehlerkorrektur nach einer vorgebbaren Strategie und Anpassungsfähigkeit.
Tabelle 12 zeigt ein Beispiel für eine Codekorrekturvorschrift für eine partielle Korrektur bei geringer Coderedundanz.
Die Erfindung wird im weiteren anhand der Ausführungsbeispiele näher erläutert.
Ausführungsbeispiele
Dabei zeigt 1 Kommunikations- oder Bussystem 100 mit Eingangsschnittstellen 110, 108 und 112, also Empfängern oder Empfangsbausteinen und Ausgangsschnittstellen 109, 107, 111, also Sendern oder Sendebausteinen. Mit diesen Sendern und Empfängern sind Teilnehmer 101, 102 und 103 mittels des Kommunikationssystems 100 miteinander verbunden. Mit 106 ist eine Verarbeitungseinheit dargestellt, die entsprechend der Erfindung die Funktion der Codegenerierung und/oder Decodierung und/oder Incrementierung und/oder des Vergleichs, respektive der Arbitrierung ausführt. Mit 104 ist eine dem Kommunikationssystem 100 externe Einheit dargestellt, die uni- oder bidirektional über die Schnittstelle 105 mit einem Teilnehmer, insbesondere hier Teilnehmer 101, verbunden ist. Diese externe Einheit 104 steht stellvertretend für die Anbindung weiterer Geräte, Einheiten oder Elemente über Schnittstellen oder Bus- oder Kommunikationssysteme an einzelnen Teilnehmern.
Hierbei soll nun bei Übertragung der Daten über serielle Busse, also insbesondere das Kommunikationssystem 100, entsprechend der gestrichelten Übertragungspfeile bei der Übertragung der codierten Daten, insbesondere eine Incrementierung oder auch eine Arbitrierung, also ein Vergleich, erfolgen. Gleichermaßen ist es aber auch möglich, über einen externen Teilnehmer 104 Daten an den Teilnehmer 101 einzugeben und diese dann codiert, beispielsweise hier an den Teilnehmer 103, wieder entsprechend der gestrichelten Pfeile weiterzuleiten, oder auch codierte Daten vom Teilnehmer 102 an den Teilnehmer 101 zu empfangen und diese dann an einen externen Teilnehmer 104 decodiert weiter zu leiten.
Insbesondere soll aber auf dem Kommunikationssystem 100, hier beispielsweise von Teilnehmer 102 zu Teilnehmer 101 und dann zu Teilnehmer 103 eine Weiterleitung der codierten Daten, eben unter Einbeziehung von Incrementierung oder Vergleich, respektive Arbitrierung, erfolgen.
Bei Verwendung eines Bi-Frequenzcodes zur Codierung sind zur seriellen Incrementierung nur 2 Takte Verzögerung nötig, wenn man beispielsweise das niederwertigste Bit eines Datenwortes, also das LSB (Least Significant Bit) zuerst überträgt. Dabei ist nur notwendig zu wissen, welchen Wert der momentan empfangene Code-Bitwert und der vorherige haben, um den auszusendenden, also den weiter zu leitenden Wert des jeweiligen Bits zu bestimmen.
Es wird nun erfindungsgemäß vorgeschlagen, eine Codierung von zwei Informationsbits mit drei Codebits in folgender Weise vorzunehmen (Vorschrift 1):
Damit wird hier mit einer Coderedundanz von 50% erreicht, dass die Codeworte 010 und 101 vermieden werden, wodurch der Einfluss der hohen Spektralanteile im Codewort verringert wird. Während den Informationsbits von links die Werte 2¹ bzw. 2⁰ zugeordnet werden, sind die Gewichte aller Codebits 2⁰. Zur Unterscheidung der Einzelbits im Code wird hier von links nach rechts die Nomenklatur 2⁰⁽³⁾, 2⁰⁽²⁾ bzw. 2⁰⁽¹⁾ verwendet Entsprechend den nachfolgenden Vorschriften 2, 3 und 4. Damit ist eine systematische Codiervorschrift gegeben, die auch von jedem anderen Code ausgehend funktioniert. Hat man zum Beispiel eine one-hot Codierung, so sind die 4 Codeworte 0001, 0010, 0100 und 1000 ebenfalls den Werten 0, 1 ,2 und 3 zuordenbar, wie bei einem Graycode 00, 01, 11 und 10.
Aus einem Eingangscodewort oder Eingangsdatenwort EC2 entsprechend 2 ist damit immer eindeutig eine Codegenerierung durch den Codegenerator 200 CG in ein Ausgangscodewort oder Ausgangsdatenwort AC2 möglich. Gleichermaßen ist in 2a eine Decodierung eines Datenwortes EC2a in ein Datenwort AC2a durch den Decodierer DC 201 gezeigt. Dieser erfindungsgemäße Code eignet sich nun auch dafür, eine serielle Incrementierung durchzuführen, wie dies im Weiteren noch erläutert wird. Entsprechend der Vorschriften 2, 3 und 4 (nachfolgend) können nun diese Einzelbits im Code von links nach rechts entsprechend der die Nomenklatur 2⁰⁽³⁾, 2⁰⁽²⁾ bzw. 2⁰⁽¹⁾ unterschieden werden, wobei der incrementierte Wert angegeben ist und entsprechend der Übertrag oder Overflow OF entsteht. Dieser generierte Übertrag oder Overflow OF wird bei einer seriellen Codierung benutzt, wie nachfolgend Vorschrift 5 oder dargestellt in 5. Vorschrift 2
Vorschrift 3:
Vorschrift 4:
So wird aus einer Eingangsbitfolge oder eines Eingangsdatenwortes oder Eingangscodewortes EC3 gemäß 3 durch den Incrementer INC 300 eine Ausgangsfolge AC3 erzeugt. Dies ist auch gemäß 4 im Rahmen eines Vergleiches durch den Komparator COMP 400, insbesondere bei Arbitrierung aus der Eingangscodefolge oder des Eingangsdatenwortes EC4 in das Ausgangsdatenwort AC4 gemäß 4 möglich.
Der Wechsel von Incrementierung zu Arbitrierung erfolgt dabei in der Richtungsumschaltung, und zwar dahingehend, dass entweder das LSB, also das Least Significant Bit, das niedrigstwertige Bit, zuerst ausgewertet wird, wie dies für die Incrementierung erforderlich ist, oder, bei einem Wechsel der Senderichtung, das Most Significant Bit, MSB, also das höchstwertige Bit zuerst ausgewertet wird und somit zum Vergleich, insbesondere der Arbitrierung führt. Dies wird später noch anschaulich erläutert. Der Codegenerator in 2 CG 200 führt also eine Zuordnung nach Vorschrift 1 durch, der Incrementer nach 3 eine Zuordnung nach den Vorschriften 2, 3 und 4, wobei bei 2 aus dem Eingangscode EC2 der generierte erfindungsgemäße Ausgangscode AC2 erzeugt wird und in 3 aus dem schon codierten Eingangscode EC3 der incrementierte erfindungsgemäße Ausgangscode AC3.
Die serielle Incrementierung wird nun anhand 5 mit den jeweiligen Werten c oder u, x, y, z, w gemäß Vorschrift 5 näher erläutert: Vorschrift 5
5 zeigt den Incrementer 300 gemäß 3 mit einem Incrementierbaustein 306 INC, einem Incrementmittel 301 und einem Rückkoppelzweig, der ein Flip-Flop 305 enthält. Weitere Flip-Flops sind mit 302, 303 und 304 dargestellt. Diese Flip-Flops können durch beliebige taktgesteuerte Speicherelemente realisiert werden. In diesem Incrementer 300, also dem Incrementiermittel 301 mit Rückkopplung, wird nun zum einen eine Eingangsbitfolge EBF entsprechend eines Datenwortes oder Datenrahmens mit mehreren, wenigstens zwei, Datenworten, wie dargestellt, eingebracht, gleichzeitig der Übertrag, also Overflow OF, wie dargestellt, berücksichtigt und in eine erfindungsgemäße incrementierte Ausgangsbitfolge ABF oder Ausgangsdatenwort oder auch Ausgangsdatenrahmen gewandelt. Für die serielle Incrementierung des Codes ist zur Erzeugung des Codebits x immer die Information über das nächstfolgende Codebit y erforderlich, wenn man mit dem Least Significant Bit LSB, also dem niederwertigsten Bit der Bitfolge, die Übertragung beginnt. Der Code muss deshalb um mindestens einen Takt verzögert weitergeleitet werden. Zur Synchronisation der empfangenen und der zu sendenden Datenbitfolge wird vorteilhafter Weise jeweils am Eingang und Ausgang ein Flip-Flop, also 302 und 304 eingefügt. Die Incrementierung erfolgt für den Eingangsübertrag oder Overflow OF ist c, den Zwischenübertrag u, die Eingangsbits x und y nach Vorschrift 5 für das Ausgangsbit z sowie den generierten Zwischenübertrag w. Damit ist es nun möglich, auch größere Codewörter unter gegebenenfalls mehrfacher Ausnutzung der Vorschrift 1 für jeweils Teile des Codewortes zusammenzusetzen, oder auch Teile ohne weitere Codierung, eben die Informationsbits in Vorschrift 1, direkt einzufügen, wie dies in Vorschrift 6 näher erläutert ist. Vorschrift 6:
Gegenüber der Incrementierung eines Blockcodes (die, wie schon gezeigt wurde, seriell nicht möglich ist) ergibt sich mit der Anordnung nach 5 auch im Falle von Vorschrift 6 immer nur eine Verzögerung um 3 Takte, da beide Codeteile nacheinander verarbeitet werden. Der Code von Vorschrift 6 verarbeitet ein Halbbyte, also vier Informationsbit = 1 Nibbel als Informationswort. Die Coderedundanz beträgt 50%. Nachteilig ist hierbei allerdings, dass durch Aneinanderreihung der Werte 0 oder 7 größere Blöcke ohne Pegelwechsel entstehen können und der Code nicht gleichstromfrei ist.
Um dies zu beheben wird zunächst ein Code nach Vorschrift 7 gewählt, welcher nur 25% Coderedundanz aufweist, wenn man einen Teil des Originalcodes unverändert übernimmt. Vorschrift 7:
Um den Code nach Vorschrift 7 gleichstromfrei zu gestalten, fügt man unterhalb des Least Significant Bit, also des niedrigwertigsten Bits, noch ein Invertierungsbit ein, das zunächst den Wert 0 hat. Die Invertierung des gesamten Codewortes, also einschließlich des Invertierungsbits), führt dann nicht zu einer Änderung des Wertes. Damit gibt es zwei Codeworte mit dem gleichen Wert, die mit unterschiedlichem Bitwert beginnen. Bei einer Folge von Nullen kann man dann abwechselnd das Codewort 000000 und 111111 senden. Damit erhält man eine vollständige Kompensation der Gleichstromanteile, also unterschiedliche Anzahl von Einsen und Nullen nach jeweils zwei Codeworten. Weiterhin liegt hier bei jedem Beginn eines Codewortes ein Pegelwechsel vor, der für eine Taktrückgewinnung mittels PLL genutzt werden kann. Damit ergibt sich nun, wie nachfolgend dargestellt, Vorschrift 8. Vorschrift 8:
Vorschrift 9 nachfolgend zeigt nun alle Datenworte mit ihren zwei möglichen Varianten. Vorschrift 9 (für das Aussenden mit dem LSB zuerst):
Vorschrift 9 stellt ein vorzugsweises Ausführungsbeispiel für die Aussendung des Codes mit dem LSB zuerst dar. Wird bei der Übertragung ständig die Anzahl der Einsen addiert und davon die Anzahl der Nullen subtrahiert, so erhält man die RDS, die running digital sum, die Aufschluss darüber gibt, ob mehr Einsen oder Nullen übertragen werden. Mit Codeworten, die eine unterschiedliche Anzahl von Einsen und Nullen enthalten, lässt sich damit die RDS durch die Wahl zwischen Codewort 1 und Codewort 2 beeinflussen. Günstigerweise versucht man den Wert RDS = 0 zu erreichen und damit den Code im Durchschnitt gleichstromfrei zu gestalten. Dabei sind aber auch geringe Abweichungen von dieser Regel möglich und denkbar, wenn man entweder zwischen den Codeworten einen Pegelwechsel erzwingen will, z.B. wegen der Taktrückgewinnung, also der PLL, oder aber vermeiden will, z.B. wegen des Frequenzspektrums.
Wird das Eingangscodewort nach Vorschrift 9 im Incrementer seriell incrementiert, also vom Wert her verändert, so kann es zu einer Änderung des RDS-Wertes nach dem incrementierten Datenwert gegenüber dem ursprünglichen Wert kommen. Für das zu sendende incrementierte Datenwort besteht dabei nicht die Möglichkeit, das inverse Codewort zu wählen, weil das Invertierungsbit schon gesendet werden muss, bevor das gesamte Codewort empfangen wurde. Eine Korrektur ist hier durch nachfolgende Nicht-Daten Kodeworte möglich, die zum Beispiel den Anfang eines Daten-Rahmens kennzeichnen, wenn eine Auswahl aus mehreren Werten mit unterschiedlichen RDS-Werten bei gleicher Bedeutung bezüglich der Rahmenkennzeichnung zulässig ist.
Der erfindungsgemäße Code kann aber auch für Arbitrierungszwecke, also Vergleichszwecke Verwendung finden. So ist der beschriebene Code, insbesondere nach Vorschrift 9, auch für Arbitrierungszwecke mit variablen Prioritäten einsetzbar. Dazu ist es erforderlich, mit dem Senden des höchstwertigen Bits, also des Most Significant Bits, zu beginnen, während für das Incrementieren, wie vorher erwähnt, mit dem Least Significant Bit, also dem LSB, dem niedrigstwertigen Bit, begonnen wird. Das Invertierungsbit wird jedoch auch dann zuerst übertragen (Vorschrift 10). Vorschrift 10 für das Senden mit dem MSB zuerst:
Eine Schaltung zu diesem Vergleich oder Arbitrierung ist mit dem Komparator 400 gemäß 6 und 6a dargestellt. Darin ist ein Komparatorbaustein 401 bzw. 408 mit dem eigentlichen Komparator 405 bzw. 409 COMP dargestellt, wobei hier lediglich je zwei Flip-Flops 402, 403 bzw. 412, 413 für die Verögerung und Synchronisation der beiden zu vergleichenden Eingansbitfolgen erforderlich sind, die auch hier durch beliebige taktgesteuerte Speicherelemente darstellbar sind. Für die Arbitrierung des Codes ist zur Entscheidung über die Aussendung des Codebits x oder r in 6 oder 6a im allgemeinen Fall wieder die Information über das nächstfolgende Codebit y oder s erforderlich. Hier, wenn man mit der MSB, also dem Most Significant Bit die Übertragung beginnt. Auch hier muss der Code deshalb um mindestens einen Takt verzögert weitergeleitet werden. Zur Synchronisation der empfangenen und der zu sendenden Datenbitfolge wird auch hier vorteilhafter Weise jeweils am Eingang und Ausgang ein Flip-Flop 402 bzw. 412 und 404 eingefügt. Nach der erfindungsgemäßen Vorschrift wird hierbei nun aus den Eingangbits x und y bzw. r und s das Ausgangsbit z und somit die Auswahl der Eingangsbitfolge EBF bzw. EBF1 oder EBF2 und deren Umsetzung in die Ausgangsbitfolge ABF im Rahmen der Arbitrierung durchgeführt. Die Komparatorentscheidung bleibt dabei in 6a in dem Speicherelement 406 gespeichert, bis die Entscheidung mittels einer Steuereinheit 407 zurückgesetzt wird. Die einmal getroffene Komparatorentscheidung kann auch im folgenden Verlauf der Datenübertragung benutzt werden, um eine weitere Umschaltung zwischen den beiden Eingangsbitfolgen gezielt vorzunehmen. Dazu wird die aktuell getroffene Komparatorentscheidung an die Steuereinheit 407 übermittelt und dort gespeichert. Mit Hilfe dieser Information kann das Speicherelement 406 von 407 beliebig gesetzt und rückgesetzt werden. In 6a ist weiterhin ein Schalter bzw. Umschalteinheit S2 vorgesehen, der einen Wechsel zwischen den Eingangsbitfolgen EBF1 und EBF2 ermöglicht bei weiterer Abfolge wie eben zu 6 und 6a beschrieben.
4a zeigt diesen Wechsel, diese Schaltung mittels Schalter bzw. Umschalteinheit S1 für zwei Eingangsdatenworte EC4 und EC5 für einen Vergleicher 401 gemäß 4 und einem Ausgangsdatenwort AC4.
Incrementieren und Arbitrieren schliessen sich gleichzeitig in einem Datenwort aus. Es kann aber im Rahmen der Umstände, unter denen entweder zu Arbitrieren oder zu Inkrementieren ist, ein Wechsel der Übertragungsreihenfolge oder Sendereihenfolge vorgenommen werden. Abhängig von der Senderichtung ergibt sich nun zu Vorschrift 9, dem vorzugsweisen Ausführungsbeispiel eben die LSB first und damit die Incrementierungsvariante oder die MSB first mit Vorschrift 10 und damit die Arbitrierungsvariante. Dabei sind nun die ersten beiden Bits des Datums entsprechend der Zweibit- in Dreibitcodierung umgesetzt und die zweiten Zweibit, also Bit 3 und 4 des Datums uncodiert übernommen. Gleichzeitig ist das Invertierungsbit, also das Bit, das anzeigt, ob es sich um die invertierte oder nicht invertierte Variante handelt, nach Vorschrift 9 als Least Significant Bit in Codewort 1 und Codewort 2, also ganz rechts, angefügt. Bezüglich der MSB-Seite stellt es sich nun ähnlich dar, so dass die ersten beiden Bit des Datums jeweils im mittleren Dreierblock in die Dreierbits codiert sind und die beiden letzten Bits des Codeworts 1 oder 2 einfach Bit 3 und 4 des Datums übernommen ist. Das die Invertierung anzeigende Bit ist hierbei allerdings als höchstwertiges Bit, MSB, jeweils links am Codewort 1 und Codewort 2 der MSB-Variante angefügt.
Als Beispiel eignet sich hier auch zur Darstellung wieder ein Bus, bei dem wie beim MOST-Bus die Daten in Rahmen fester Länge übertragen werden, wobei je nach Rahmen (Frame-) Position ein Wechsel der Übertragungsreihenfolge oder Senderichtung vorgenommen werden kann. Soll zum Beispiel das Senden einer Control-Frame-Information nach einer Priorisierung entschieden werden, indem die empfangene Priorität mit der eigenen Priorität verglichen wird, so ist es vorteilhaft, das MSB zuerst zu senden. Damit kann man wie in 6a gezeigt, eine unmittelbare Umschaltung vornehmen. Wenn dagegen die Netzwerkposition bestimmt werden soll und gleichzeitig (ohne Zwischenspeicherung) dem nachfolgenden Knoten übermittelt werden soll, dann muss das entsprechende Controlbyte mit dem LSB zuerst gsendet werden, um seriell incrementieren zu können (gemäss 5). Da die Control-Frame Information immer an einer festen Stelle im Datenrahmen, also dem Frame übertragen wird, bei MOST immer das 61. Und 62. Byte, wird hier vorteilhafterweise in Abhängigkeit vom Wortzähler oder Byte- bzw. Bitzähler innnerhalb eines Datenrahmens, also Zähler, die Übertragungsreihenfolge geändert.
Dabei ist grundsätzlich, also nicht nur für den MOST-Fall, zu beachten, dass erfindungsgemäß immer das Invertierungsbit zuerst gesendet wird, also unabhängig davon, ob mit dem LSB oder dem MSB begonnen wird.
Bezogen auf die vorgenannte Vorschrift 1, welche die günstigste systematische Lösungsvariante zur erfindungsgemäßen Codierung von zwei Informationsbits in drei Codebits hinsichtlich der EMV-Eigenschaften darstellt, sind auch nachfolgende Varianten für die Vorschrift 1 denkbar und möglich:
Dabei besitzt die Codevorschrift nach 1d im Vergleich zu Vorschrift 1 die wenigsten Nachteile.
Entsprechend der bevorzugten Ausführungsvariante nach Vorschrift 1 respektive der daraus entwickelten Vorschriften 9 und 10 können nun besondere Sende- und Empfangsbausteine gemäß 7 und 8, also Sender und Empfänger, dargestellt werden. 7 zeigt einen seriellen Sender, bei dem paralleler Dateninput, PDI, also beispielweise nBit parallel in ein Register und Codegenerator 705 eingebracht werden. In diesem Beispiel ist n vorzugsweise 4. Mittels eines Schieberegisters 704, das k Bit aufnehmen kann, wobei hier k vorzugsweise 6 ist, kann dann eine Ausgangsbitfolge ABF auf das Kommunikationssystem 100 ausgegeben werden. Dabei enthält der Sendebaustein 700 nun optionale Elemente 701 bis 703, die noch erläutert werden. Wird beispielsweise bei der Umschaltung zwischen LSB und MSB first, also zwischen Incrementierung und Arbitrierung in Abhängigkeit von einem Wortzähler oder Zähler die Überragungsreihenfolge geändert, ist ein solcher Zähler 701 erforderlich. Gleichzeitig ist eine Kontrollschaltung 703 erforderlich, die insbesondere die Invertierungskontrolle, also die Vorgabe des Invertierungsbit entsprechend LSB und MSB gemäß Vorschrift 9 bzw. 10 steuert. Gleichzeitig kann eine Überwachung des RDS-Wertes, respektive Vorgabe, durch diese Schaltung 703 erfolgen. Block 702 dient zum Einsetzen von Nicht-Datenworten, die später noch erläutert werden. Ebenso kann in Block 703 noch die Funktion der D-Kontrolle implementiert sein, was auch später noch näher erläutert wird.
Entsprechend dem Sendebaustein 700 zeigt 8 mit 800 einen Empfangsbaustein oder seriellen Empfänger. Eine Eingangsbitfolge EBF wird einem Schieberegister 804 mit k Bit, auch hier vorzugsweise k = 6, in diesem Ausführungsbeispiel zugeführt. Mit 803 ist der entsprechende Decoderbaustein, insbesondere mit Register, dargestellt. Um eine parallele Bitfolge erfindungsgemäß, also PDO, beispielsweise n Bit mit n = 4 auszugeben, wird wieder vom der Umschaltung Gebrauch gemacht und beispielsweise in Abhängigkeit vom Wortzähler die Übertragungsreihenfolge geändert, ist auch hier dieser Zähler 801 optional eingesetzt. Block 802 dient wieder des Einsatzes der Nicht-Datenworte, also zur Codierung derselben, wodurch ein partielles Setzen des Zählers erfolgen kann, wie dies später noch erläutert wird. D.h. Sender und Empfänger gemäß 7 und 8 können erfindungsgemäß die vollständige Codierung bzw. Decodierung vornehmen.
Die schon angesprochenen Nicht-Datenworte in Zusammenhang mit den Elementen 702 und 802 werden nun näher erläutert. Der Coderaum für 6 Codebits lässt 2⁶ = 64 verschiedene Möglichkeiten zu, von denen nach Vorschrift 9 nur 32 Daten-Codeworte zugeordnet sind. Für manche Anwendungsfälle ist es sinnvoll, einige nicht-Daten Codeworte oder nicht-Daten Worte mit weiteren Informationen, insbesondere mit Steuerinformationen, zu Steuerzwecken zu vereinbaren. Damit kann man zum Beispiel den Beginn einer Übertragung kennzeichnen oder andere Steuerfunktionen, wie zum Beispiel Übergang in einen anderen Betriebsmodus veranlassen, sowie die Übertragung von besonderer Folgeinformation einleiten. Diese nicht-Daten Codeworte können beispielsweise eine Blockpräambel oder eine Datenrahmenpräambel, also eine Frame-Präambel, sein. Beispiele hierfür sind in Tabelle 1 angegeben, wobei diese Tabelle nicht abschließend ist. Tabelle 1:
Eine besondere Rolle bei den nicht-Daten Codeworten spielt die Bitfolge 010101 bzw. invertiert 101010. Diese Bitfolge wird zur Synchronisation verwendet und sollte nicht ungewollt, auch durch Kombination von zwei Datenworten hintereinander, entstehen. Ohne zusätzliche Bedingung entsteht die Folge nach Vorschrift 9 beispielsweise durch die Verbindung der Datenworte D (Codewort 1) nach 4, 5, 6 oder 7 (aus Codewort 1) : 111010 100xx0 bei einer Übertragung von LSB beginnend, wobei ein Pegelwechsel zwischen diesen beiden Datenworten durch die RDS-Vorschrift vorgesehen ist. Die Erzeugung dieses Bitmusters durch eine Kombination von Datencodeworten wird vermieden, wenn unter Missachtung der RDS-Vorschrift immer bei Übertragung eines D dafür gesorgt wird, dass kein Pegelwechsel stattfindet. Im obigen Beispiel nach Vorschrift 9 erhält man damit die Bitfolge 000101 100xx0 und die ausgewählte Bitfolge kann nicht entstehen. Dies kann unter Umständen kurzzeitig zur Erhöhung des Gleichstromanteils führen. Es ist aber ausgeschlossen, dass das mehrfache Aufeinanderfolgen der Aussenden von D zu einer ständigen Erhöhung von RDS führt, weil dann genau immer zwischen Codewort 1 und Codewort 2 entsprechend Vorschrift 9 gewechselt wird. Sorgt man darüber hinaus dafür, dass bei einem allen auf den Wert D folgenden Codeworte mit gleichgewichtiger Anzahl von Nullen und Einsen (7, 9, A, C und nicht-Daten Codeworte) immer ein Pegelwechsel stattfindet (so lange nicht ein ungleichgewichtiges Codewort diese Regel unterbricht), so wird die RDS auch bei danach nochmals gesendeten Datenwert D nicht aufsummiert, da dann das andere Codewort von D benutzbar ist und nach obiger Vorschrift auch zwingend eingesetzt wird. Eine spezielle Steuereinheit im Sender steuert die Aussendung des Datenwortes D, wie dies in 7 im Block 703 implementierbar ist. Eine weitere Vorschrift ist, dass bei RDS = 0 der RDS-Wert erhöht wird, so dass RDS nicht negativ nach Null wird und damit Eindeutigkeit gegeben ist.
Unter diesen Randbedingungen erlaubt die Übertragung des besonderen Codewortes 010101 und dessen Invertierung die Auslösung von speziellen Steuersignalen im Empfänger, die zu einem ausgewählten Systemzustand führen. Das kann zum Beispiel das Setzen eines Zählers im Empfänger sein, wie beispielsweise durch Block 802 im Zähler 801 in 8. Wenn nicht-Daten Codeworte oder nicht-Daten Worte nur an regelmäßigen Zeitpunkten erlaubt sind, da sie zum Beispiel den Beginn eines Daten-Rahmens mit konstanter Länge markieren, ist es auch sinnvoll alle anderen nicht-Daten Worte nur bei einem Vielfachen oder Bruchteil dieser Zeitpunkte zu erlauben. Dann kann man diese Codeworte nicht mit Datenworten verwechseln oder für Muster, die aus zwei aufeinanderfolgenden Datenworten gebildet werden und mit der Bitfolge des nicht-Daten-Codewortes übereinstimmen, nicht mit diesem speziellen Steuersignal verwechseln. Damit ist auch eine eingeschränkte Möglichkeit der Fehlererkennung realisierbar. Außer den gezeigten Codevarianten mit Vorzugsvarianten nach den Vorschriften 9 oder 10 sind weitere Komponenten oder Zusammensetzungen von Vorschrift 1, also eine Mehrfachverwendung dieser Vorschrift und direkter Binärcodierung, ebenfalls mehrfach möglich. Der Code der vorzugsweisen Ausführungsbeispiele vermeidet das einsame Spektrum einer Bi-Phase marc Codierung. Er ist im Durchschnitt gleichstromfrei und hat eine maximale run length von ca. 9, wenn man keine nachträglichen Datenänderungen durch Incrementierung berücksichtigt. Diese Datenänderuingen kann man aber durch nachfolgende Nicht-Daten Codeworte wieder kompensieren. Vorzugsweise nicht-Daten Codeworte sind beispielsweise entsprechend der Tabelle 101010, 001110, 001100, 011110, 011100 sowie die dazu inversen Werte, aber auch alle anderen nicht-Daten Worte sind prinzipiell einsetzbar.
Die Vorschriften zur Vermeidung der Bitfolge 101010 durch Zusammensetzen von codierten Datenwörtern gemäß Ausführungsbeispiel der Vorschrift 9 sind bei einer Umschaltung von Incrementierung und Arbitrierung entsprechend anzupassen:
Wird von LSB-first auf MSB-first gewechselt, ergibt sich keine Vorschrift bezüglich Invertierung, außer Reduzierung des RDS-Wertes im Betrag.
Zwischen zwei MSB -first Werten muss ein Pegelwechsel (anstelle vor „D") nach dem Hexadezimalwert „A" vermieden werden.
Für alle gleichgewichtigen Codeworte nach einem „A" gibt es hier keine Vorschrift, da „A" selbst gleichgewichtig ist (keine RDS-Wert-Veränderung mit A, womit keine Vorschrift für mittelbar aufeinanderfolgende „A"s erforderlich ist.
Für einen Übergang von MSB-first zu LSB-first ist ein Pegelwechsel generell zu verhindern, sofern die letzten 3 Bits alternierend waren (nach 2, 6, A, D).
Für ein folgendes „D" gelten die gleichen Bedingungen wie sonst, also kein Pegelwechsel.
Zur Fehlererkennung und Fehlerkorrektur wird nun erfindungsgemäß die Entscheidung für das aktuelle Codedatenwort von der aktuellen running digital sum RDS, also der laufenden digitalen Summe abhängig gemacht. Wenn dieser Wert dem Empfänger, insbesondere dem zweiten Teilnehmer bekannt wäre, dann kannn wie gesagt die Auswahl der möglichen Codedatenworte auf ca. die Hälfte beschränkt werden. Es wird deshalb erfindungsgemäß vorgesehen, die RDS insbesondere periodisch zu übermitteln und diese in dem Empfänger auf dieser Basis weiter zu berechnen bis zur nächsten Aktualisierung. Dann könnte auch mit dem neu empfangenen RDS-Wert die Richtigkeit der bisherigen Daten und/oder Datenkorrekturen bestätigt werden oder gegebenenfalls ein Fehlersignal generiert werden, das die Richtigkeit der vorangegangenen Daten in Frage stellt. Diese Daten, die dann als fehlerhaft erkannt werden, können dann nochmals überprüft oder auch verworfen werden mit der Anforderung an die nochmalige Sendung der Daten vom Sender, also insbesondere dem ersten Teilnehmer. Legt man z. B. einen Code für die EMV-reduzierte elektrische Übertragung zu Grunde, wie er in der bereits genannten Vorschrift 9 beschrieben ist, ergeben sich die Möglichkeiten für Informationsbits Codewort 1, Codewort 2 und Wertzuordnung (hexadezimal), wie bereits zu Vorschrift 9 beschrieben. Dieser Code der Vorschrift 9 hat eine Coderedundanz von 50% und ist ohne zusätzliche Information über die RDS nicht in der Lage, Fehler zu korrigieren. Im Gegenteil können Einzelbitfehler hier schon zu einem anderen Codewort führen. Nimmt man z. B. das Codewort 1 des Hexadezimalwertes C mit 111000 und verfälscht lediglich das letzte Bit, so erhält man das Codewort 2 des Hexadezimalwertes 3 mit 111001. Entsprechend ergeben sich hier folgende Nachbarschaftsbeziehungen zwischen Codedatenworten:
Das hätte zur Folge, wenn gerade das letzte Codebit verfälscht würde, das mit einer massiven Änderung des Wertes ohne Fehlererkennungsmöglichkeit gerechnet werden muss, sofern man nicht die erfindungsgemäße Übertragung der Zusatzinformation gewährleistet.
9a zeigt noch einmal symbolisch in einem Block 900 einen Codegenerator mit alternativen Codewörtern und geringer Coderedundanz, aber verschiedenen Nicht-Codedatenwörtern. Mit 901 ist eine Übertragungsstrecke ohne zusätzliche Ressourcen (Leitungen/Daten) dargestellt: Die Information wird durch Wahl der alternativen Steuerworte übermittelt. Block 902 schließlich zeigt den Empfänger mit Decodierer, welcher die Information, also die RDS über die Codegeneratorentscheidungskriterien zurückgewinnt, insbesonderen aus den Nicht-Codedatenworten bzw. den Steuerworten, wodurch die Codedatenwortauswahl aus der Teilmenge der gesamten Codedatenworte möglich wird, um eine Fehlererkennung und Fehlerkorrektur durchzuführen.
In 9b ist dies noch einmal detaillierter dargestellt. Darin sind wieder mit 900 der Codegenerator, mit 902 der Empfänger mit Decodierer und mit 901 die Übertragungsstrecke dargestellt, wobei zusätzlich im Codegenerator 900 verschiedene alternative Codewortdatensätze 903 bis 905 dargestellt sind, welche die Codedatenwortsätze 1, 2 bis n repräsentieren. Mit 906 ist der eigentliche Codierer dargestellt und mit Block 907 die Auswerte- respektive Generierungseinheit für die Zusatzinformation, eben den RDS-Wert, durch welchen dann ein bestimmter Codedatenwortsatz und daraus ein bestimmtes Codedatenwort über einen Auswahlbaustein 908 auswählbar ist.
Analog ist nun der Empfänger 902 mit Decodierer aufgebaut, in dem ebenfalls die alternativen Codedatenwortsätze 1, 2 bis n mit 909, 910 und 911 dargestellt sind und über den Auswerte- oder Rückgewinnungsbaustein 912 Zusatzinformation aus dem RDS-Wert, insbesondere aus dem Nicht-Codedatenwort ermittelt wird und somit insbesondere zur Korrektur des Fehlers ein korrektes Codedatenwort aus den entsprechenden Codedatenwortsätzen über den Auswahlbaustein 913 ausgewählt wird. Der eigentliche Decoder ist mit 914 dargestellt.
Werden nun die Daten über die Übertragungsstrecke im Rahmen entsprechend 10 und 10a, also Frames zu je i-Bytes übertragen, wobei i beispielsweise 1, 8, 16, 32, und vorzugsweise 64, 128, 256 usw. ist und jeder Rahmen, also Frame mit einer Präambel FP beginnt, die insbesondere ein Nicht-Codedatenwort darstellt, ergeben sich folgende Möglichkeiten: Eine besonders ausgezeichnete Präambel, eben die Rahmenpräambel FP hat die Aufgabe, zur ersten Synchronisation mit dem Frame- oder Rahmensystem und darf deshalb nicht mit einer Kombination von Daten erzielt werden. Diese reservierte Präambel hat beispielsweise den Code 101010 oder 010101. Da diese Präambel mit ihren ständigen Wechseln von Bitwerten bei der elektrischen Übertragung eine hohe EMV-Aktivität verursacht, kann diese vorteilhaft auch insbesondere nicht für jeden Frame, sondern beispielsweise nur nach einer festen Anzahl von Frames, z. B. zu Beginn eines Blocks aus j Frames F1, F2, Fj (j beispielsweise 1, 8, vorzugsweise 16, 32, 64 usw.) benutzt werden. Erst wenn diese Präambel einmal erkannt wurde, stellen sich interne Zähler im Empfänger so ein, dass genau bekannt ist, wann ein Frame und auch ein Block beginnt. Am Beginn der Blockpräambel BP ist ein Bitwechsel zu vermeiden, um eine exakte Einsynchronisation zu gewährleisten. Da nach dem ersten Einsynchronisieren bekannt ist, wann ein neuer Frame beginnt, wird die Frame-Präambel FP schon erwartet und kann entsprechend decodiert werden, ohne mit einem Datenwort oder mit einer Kombination von Teilen zweier nacheinander gesendeter Datenworte verwechselt zu werden. Die Frame-Präambel braucht deshalb nicht dem Anspruch zu genügen, nicht im Datenmuster aufzutauchen. Als Frame-Präambel wird deshalb zunächst der folgende Code vorgeschlagen: 101110 und/oder 010001. Dieser Wert sollte genau dann als Präambel gesendet werden, wenn RDS gleich Null ist. Da die obigen Datencodeworte eine gerade Bit-Anzahl (speziell hier 6) haben, kommt mit jeder Übertragung eines Datenworts entweder 0, 2, 4 bzw. 6 zum RDS-Wert dazu oder der RDS-Wert wird um diesen Wert vermindert. Es kann somit maximal der Betragswert 8 (+/–8) auftreten, und der RDS-Wert kann nicht ungerade werden. Weitere Frame-Präambeln geben an, wie der RDS-Wert des Senders vor dem Senden der Präambel war:
Alle Präambeln mit RDS-Information sollten voneinander den Hammingabstand von mindestens 2 haben, um einen Einzelbitfehler in der Präambel erkennen zu können. Das ist notwendig, weil bei der Übermittlung des RDS-Wertes ein Fehler sich auf die nachfolgenden Korrekturen auswirkt. Weiterhin sollte bei RDS = 0 beispielsweise immer ein positives RDS oder 0 folgen, wobei das hier einer willkürlichen Codevorschrift als beispiel zur Eindeutigkeitserzielung entspricht. Daneben können weitere Präambel angewendet werden, wie beispielsweise:
Wenn nun aufgrund der RDS-Information ein RDS-Zähler gestellt wird und in den folgenden Datenworten ein Nicht-Codedatenwort gefunden wird, so kann leicht entsprechend der Codevorschrift bestimmt werden, ob es ein Codewort 1 oder ein Codewort 2 sein muss, d. h. entsprechend Vorschrift 9 ist das least significant bit LSB bestimmt. Alternativ funktioniert dieses natürlich ebenso für Vorschrift 10, so dass dann das most significant bit MSB bestimmt ist. D.h. das anhand Vorschrift 9 dargestellte Verfahren funktioniert natürlich analog für Vorschrift 10 und ist aus Aufwandsgründen nicht nochmals explizit dargestellt.
Bei Erhöhung des zu spendierenden Aufwands kann nun erfindungsgemäß eine weitere Verbesserung erzielt werden, weil z.B. in dem Code der Vorschrift 9 aber nun beispielsweise nicht alle Einzelbitfehler, selbst wenn die genannte Fehlerkorrekturinformationsübermittlung mittels RDS durchgeführt wird, berücksichtigt werden können. Es wird immer Fehlermöglichkeiten geben über den bereits beschriebenen Fall hinaus. So ist z.B. für manche Codewörter ein Fehler nicht erkennbar, wenn zwei Datenworte sich nur in einem Bit unterscheiden, also ein Hammingabstand von 1 auftritt. Das ist z. B. der Fall für eine Veränderung der Bits 1 oder 2. Es ändert sich so z. B. der Datenwert 0 in den Datenwert 2 durch einen Fehler im Bit 2 des Codewortes 1 gemäß Vorschrift 9.
Um eine vollständige Korrekturmöglichkeit zu bieten, müsste dann die Coderedundanz soweit erhöht werden, dass alle Datenworte zueinander mindestens den Hammingabstand 3 besitzen. Dazu wären mehr Codebits bei entsprechend erhöhter Frequenz zu übertragen, um den gleichen Informationsgehalt pro Zeiteinheit zu gewährleisten.
So ist nun im Rahmen einer Weiterentwicklung nach einer Möglichkeit zu suchen, bei nicht erhöhter Coderedundanz eine sichere Erkennung oder auch Korrektur vorzunehmen. Je nach Anwendung kann dabei auch eine Korrektur vorgenommen werden, die nicht eindeutig ist. Bei einer Vielzahl möglicher Korrekturworte sollte nach einer vorgebbaren Strategie entschieden werden, welches der möglichen Codeworte ausgewählt wird, oder ob z. B. auch ein Kompromiss gefunden wird, der keines der möglichen Codeworte auswählt und stattdessen der arithmetische Mittelwert der Werte aller möglichen Codeworte benutzt wird. Eine nicht eindeutige Zuordnung bei der Korrektur muss dabei signalisiert werden, und Bestandteil der Strategie ist auch, dass die Korrektur verhindert werden kann. Das kann durch Wahl einer Option erfolgen oder auch automatisch, wenn zu viele Korrekturen bisher schon vorgenommen wurden.
Damit soll erfindungsgemäß weiterhin die Fehlererkennung im Rahmen zer Weiterentwicklung differenziert gehandhabt werden, und zwar in mehreren Stufen:

(0) Es liegt kein Fehler vor oder ist ist zumindest kein Fehler erkennbar.
(1) Fehlererkennung und Korrektur sind auf einen eindeutigen Wert möglich (gemäß Hamming).
(2) Es liegen mehrere Codeworte vor, die sich um genau 1 Bit von dem empfangenen Bitmuster unterscheiden und gleichzeitig die Bedingungen bezüglich der RDS und den genannten Pegelwechsel erfüllen. In diesem Fall (2) erfolgt die Korrektur nach einer wählbaren Strategie, wie beispielsweise – minimaler Wert der möglichen Codeworte – maximaler Wert der möglichen Codeworte – arithmetisches Mittel aus den möglichen Codeworten (Ergebnis muss nicht zwangsläufig mit dem empfangenen Bitmuster korrelieren) – Interpolation der Datenwerte (Zusammenhang mit vorher bereits empfangenen Werten) – Impulsunterdrückung (Störung im Bitmuster ausblenden, beispielsweise durch Tiefpassfunktion) – Flankenverschiebung für Bitmuster mit jeweils mehr als einem konstanten Bitwert (Ausgleich von Tiefbass- oder Hochbassverhalten der Übertragungsstrecke) – Impulsgenerierung als Ausgleich des Tiefpasscharakters der Übertragungsstrecke – Keine Korrektur, sondern Signalisierung eines Fehlers und Senden eines festen vorgegebenen Datenwertes, beispielsweise 0.
(3) Fehlererkennung ohne Korrekturmöglichkeit, z. B. Mehrfachbitfehler (Signalisierung des Fehlers gegebenenfalls differenziert zu Punkt 2) und Senden eines vorgegebenen Datenwertes (z. B. 0) oder eines Wertes, der dem empfangenen Wert ohne Beachtung des RDS-Wertes bzw. der Pegeländerungsvorschrift nahekommt.

Im Punkt (0) liegt kein Fehler vor oder ein Fehler, z. B. Einzel- oder Mehrfachbitfehler ist nicht erkennbar, weil ein anderes Datencodewort entsteht.
Im Punkt (1) wird ein Fehler erkannt, und es gibt genau ein Codewort, das durch Änderung von einem Bit aus dem empfangenen Wort entsteht (nur ein Codewort innerhalb der Hammingdistanz 1).
Im Punkt (2) gibt es mehrere Datencodeworte, die der Hammingdistanz 1 zu dem empfangenen Wort entsprechen. Aus diesem Satz der möglichen Codeworte wird ein Wert gemäß einer wählbaren Strategie ausgesucht. Zu beachten ist z. B. die Interpolation: Es ist beispielsweise sinnvoll, wenn man die Signaleigenschaften eines Signals kennt und beispielsweise bei Sensorsignalen oder auch Audiosignalen weiß, dass sich nur in einem begrenzten Umfang von Sensorwert zu Sensorwert oder von Abtastwert zu Abtastwert gemäß Grenzfrequenz Änderungen ergeben können.
Dazu ist im Fehlerfall ein Abspeichern der aktuellen Decodierungsbedingungen sinnvoll und eine Nachbehandlung des Wertes, z. B. mittels Interrupt an den Controller gemäß 11 möglich. Auch sollten die Anzahl und Art der Korrekturen gespeichert werden und gegebenenfalls beim Übersteigen einer vorgebbaren Anzahl von solchen Korrekturen keine weitere Korrektur gemäß Punkt (2) durchgeführt werden. Dieser Fehlerspeicher kann ganz oder teilweise gelöscht werden, sobald eine neue RDS-Information übertragen wird, gegebenenfalls auch nur dann, wenn bei dem Vergleich der intern berechneten RDS-Information mit dem neu empfangenen Wert keine oder zumindest keine große Abweichung festgestellt wird. Die Fehlerkorrektur kann damit einen adaptiven Charakter annehmen. Die Änderung der Strategie ist aber auch beliebig anders möglich und jederzeit durch den Anwender beeinflussbar. So kann z. B. auch in einer Lernphase unter realistischen Umgebungsbedingungen die beste Korrekturmöglichkeit selbst ermittelt werden.
Die Strategie sollte insbesondere dann auf Signalisierung eines Fehlers geändert werden, wenn ein oder gar mehrere Mehrfachbitfehler aufgetreten sind. Dann kann man sich auf den im Empfänger berechneten RDS-Wert nicht mehr verlassen. Die Fehlerkorrektur nach Punkt (2) kann dann ausgesetzt werden, eben zumindest bis wieder ein neuer aktueller RDS-Wert empfangen wurde und keine neuen Mehrfachfehler detektiert werden.
Nicht erkannte Einzelbitfehler in den oberen drei Bits bewirken eine Wertänderung von maximal 25% des Wertebereichs. Änderungen des LSB können eine totale Wertänderung von 1 auf F bewirken. Das ist ausgeschlossen, wenn die Zusatzinformation, also RDS zur Decodierung verfügbar ist und die entsprechenden Codierungsbedingungen vorliegen, also Fehlerkorrekturinfomationsübermittlung durch RDS-Übertragung. In Verbindung mit der beschriebenen RDS-Übermittlung kann in manchen Fällen auch entschieden werden, in welche Richtung eine Korrektur erfolgen muss. Damit kann es zu einer eindeutigen Korrektur kommen.
Folgende Einzelbitfehler werden bei Nichtcodedatenworten sicher festgestellt und sind korrigierbar:

– Fehler im Bit 5 (MSB), sofern Bit 4 aktiv ist.
– Fehler im Bit 4 (zweithöchstes Bit), sofern Bit 5 nicht aktiv ist.
– Fehler im Bit 3 (dritthöchstes Bit), sofern Bit 4 nicht aktiv ist.

Aktiv bedeutet hierbei „1" im Codewort 1 und „0" im Codewort 2.
Alle anderen Einzelbitänderungen können nicht entdeckt oder korrigiert werden, wenn man nur ein Codewort betrachtet. Setzt man jedoch voraus, dass die Codegenerierungsvorschrift genau bekannt ist, so kann man auch aus der Information über den Pegelwechsel an der Wortgrenze im Zusammenhang mit der RDS-Information eine Korrektur vornehmen. Dabei muss nach Codevorschrift ein Pegelwechsel nach einem Datenwort D immer dann stattfinden, wenn ein gleichgewichtiges Codewort gesendet wird. Das trifft auch zu, wenn mehrere gleichgewichtige Datenworte nach D aufeinander folgen. Dadurch wird ein Aufsummieren der RDS durch mehrere Datenworte D (mittelbar oder unmittelbar) nacheinander verhindert. Bei allen anderen Datenworten wird der Pegelwechsel durch die RDS-Information geregelt.
Bei RDS = 0 darf durch das Codewort kein negativer Wert für RDS entstehen, sondern ein möglichst minimaler positiver Wert. Trotz der geringen Coderedundanz sind damit weitere Korrekturen oder Hinweise auf Änderungen bei Einzelbitfehlern möglich. Bei jeder Korrektur eines gültigen Codewortes in ein anderes wird zusätzlich eine Fehlerinformation übertragen. Mit einer zusätzlich Option könnten die damit verbundenen Korrekturen verhindert werden. Es wird dann nur die Information auf einen Fehler ausgegeben. Alle Korrekturen haben höchsten 25% Änderung des Wertebereichs des Datenwortes zur Folge.
Bei einem Mehrfachfehler wird z.B. ein fester vorgegebener Wert gesendet (und Interrupt). Bei der Möglichkeit der Entscheidung unter mehreren Datenworten entscheidet die Strategie. Wechsel der Strategie ist durch den Fehlerzähler in 11 möglich. Dann wird ggf. auch eine Korrektur verhindert, also keine Korrektur durchgeführt, sondern ein fester Wert genommen. Der Zähler in 11 wird durch Aktualisierung des RDS Wertes zurückgesetzt. 11 zeigt dazu nochmals den Empfänger 902 mit Decodierer 914 und Übertragungsstrecke 901 in symbolischer Darstellung mit Ablaufvorgang.
Zunächst wird die RDS Information isbesondere aus dem Nicht-Codedatenwort (bzw. Steuerwort) extrahiert. RDS wird über Block 915 und Block 916 (entspricht Block 912 in 9b) mit der ermittelten RDS Information verglichen. Incremet/Decrement wird dabei laufend durchgeführt. Anschließend erfolgt eine periodische Aktualisierung mit Vergleich (Block 916). Ist das Datenwort einschließlich RDS fehlerfrei (Block 917) wird das Datenwort ausgegeben. Ansonsten gelangt man zur Fehlerkorrektur 918 aus der ein korrigiertes Datenwort oder eine festes Datenwort (vgl. auch Tabelle 12) hervorgeht. Im Falle das keine Korrektur möglich ist erfolgt eine Unterbrechung (Interrupt 919) insbesondere mit Signalisierung, dass keine Korrektur möglich und Fehleranzeige. Bei fehlerhaftem Vergleich der RDS wird ebenfalls ein Interrupt generiert, insbesondere mit Fehleranzeige (920). Mittels Fehlerzähler 921 kann dann die besagte Strategievorgabe in Block 922 aus der Anwendung mit Anpassungs- oder Adaptionsmöglichkeit erfolgen. Schließlich wird bei RDS Aktualisierung der Fehlerzähler 921 zurückgesetzt (reset) wie bereits oben beschrieben.
Dazu wird abschließend in Tabelle 12 eine Codekorrekturvorschrift als Beispiel für eine partielle Korrektur bei geringer Coderedundanz beschrieben.
Dabei bedeuten:

MF:: Mehrfachbitfehler gemäss Punkt (3) liegt vor (Fehler erkannt, aber im allgemeinen keine Korrekturmöglichkeit)
OK:: Kein Fehler erkennbar (Punkt (0))
PV:: Pegelwechsel vorgesehen für gleichgewichtiges Codewort (unmittelbar oder mittelbar nach D)
PE:: Pegelwechsel liegt vor: aktuelles LSB ungleich Letzter Bitwert (last bit value)
X.1:: Codewort 1 für Datenwort X (z.B. D.1 für D, C.1 für C, 5.1 für 5 usw)
X.2:: Codewort 2 für Datenwort X ( z.B. F.2 für F, E.2 für E, 6.2 für 6 usw)
n.d.:: kein Datencodewort, also Nicht-Codedatenwort: An Stelle einer Präambel gelten besondere Bedingungen

Bei einigen Bitwerten ist ein Fehler in einem der Werte möglich (Korrektur nach Punkt (2) oder Punkt (1))
Nachfolgend werden die Spalten in Tabelle 12 beschrieben:

1. Spalte: alle Codeworte
2 Spalte: Bedeutung als Datenwort (Codedatenwort) oder Nichtdatenwort (nicht-Codedatenwort)
3. Spalte: Bedingung war hier rds <= 0, für gleichgewichtiges Codewort ist Pegelwechsel vorgeschrieben (PV), es liegt ein Pegelwechsel vor (PE), Korrekturmöglichkeit auf angegebene Codeworte (oder OK, MF)
4. Spalte: Bedingung war hier rds <= 0, für gleichgewichtiges Codewort ist Pegelwechsel vorgeschrieben (PV), es liegt kein Pegelwechsel vor (/PE), Korrekturmöglichkeit auf angegebene Codeworte (oder OK, MF)
5. Spalte: Bedingung war hier rds <= 0, für gleichgewichtiges Codewort ist kein Pegelwechsel vorgeschrieben (/PV), es liegt ein Pegelwechsel vor (PE), Korrekturmöglichkeit auf angegebene Codeworte (oder OK, MF)
6. Spalte: Bedingung war hier rds <= 0, für gleichgewichtiges Codewort ist kein Pegelwechsel vorgeschrieben (/PV), es liegt kein Pegelwechsel vor (/PE), Korrekturmöglichkeit auf angegebene Codeworte (oder OK, MF)
7. Spalte: Bedingung war hier rds > 0, für gleichgewichtiges Codewort ist Pegelwechsel vorgeschrieben (PV), es liegt ein Pegelwechsel vor (PE), Korrekturmöglichkeit auf angegebene Codeworte (oder OK, MF)
8. Spalte: Bedingung war hier rds > 0, für gleichgewichtiges Codewort ist Pegelwechsel vorgeschrieben (PV), es liegt kein Pegelwechsel vor (/PE), Korrekturmöglichkeit auf angegebene Codeworte (oder OK, MF)
9. Spalte: Bedingung war hier rds > 0, für gleichgewichtiges Codewort ist kein Pegelwechsel vorgeschrieben (/PV), es liegt ein Pegelwechsel vor (PE), Korrekturmöglichkeit auf angegebene Codeworte (oder OK, MF)
10. Spalte: Bedingung war hier rds > 0, für gleichgewichtiges Codewort ist kein Pegelwechsel vorgeschrieben (/PV), es liegt kein Pegelwechsel vor (/PE), Korrekturmöglichkeit auf angegebene Codeworte (oder OK, MF)

Claims

Verfahren zur Fehlerbehandlung bei der Übertragung von codierten Daten in Form wenigstens eines Datenwortes über ein Kommunikationssystem, wobei zu dem wenigstens einen Datenwort ein Codedatenwort nach einer vorgebbaren Codiervorschrift ausgewählt wird, wobei die Daten als Bits, die zwei verschiedene Werte, Einsen und Nullen, annehmen können dargestellt werden, dadurch gekennzeichnet, dass wenigstens eine laufende digitale Summe derart gebildet wird, dass eine aufsummierte Differenz der Gesamtzahl der Einsen und der Gesamtzahl der Nullen wenigstens über das Codedatenwort gebildet wird und diese laufende digitale Summe übertragen wird, wobei die laufende digitale Summe zum folgenden Codedatenwort bestimmt und mit der dann übertragenen verglichen wird, wobei bei Abweichung auf Fehler erkannt wird.
Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass neben den codierten Daten auch wenigstens ein Nicht-Codedatenwort zwischen dem ersten Teilnehmer und dem wenigstens zweiten Teilnehmer übertragen wird, welches nicht nach der vorgebbaren Codiervorschrift codiert ist und die laufende digitale Summe wenigstens als Teil des Nicht-Codedatenwortes übertragen wird.
Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass das nach der vorgebbaren Codiervorschrift ausgewählte Codewort jeweils einem ersten oder zweiten Codewort entspricht die zueinander invertierte Codewörter darstellen.
Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass das nach der vorgebbaren Codiervorschrift ausgewählte Codewort aus wenigstens zwei verschiedenen Codewortsätzen entsprechend der Codiervorschrift ausgewählt werden kann.
Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass bei Erkennen auf Fehler ein Fehlersignal des ersten Teilnehmers erzeugt wird, der den Fehler erkannt hat und das Fehlersignal wenigstens zum zweiten Teilnehmer übertragen wird.
Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass bei Erkennen auf Fehler die fehlerhaften Daten verworfen werden und der diese übertragende Teilnehmer ein Anforderungssignal erhält die Daten erneut zu senden.
Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass neben den codierten Daten auch wenigstens ein Nicht-Codedatenwort zwischen dem ersten Teilnehmer und dem wenigstens zweiten Teilnehmer übertragen wird, welches nicht nach der vorgebbaren Codiervorschrift codiert ist und die laufende digitale Summe auch über das Nicht-Codedatenwort gebildet wird.
Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass eine Korrektur des Fehlers vorgenommen wird, indem abhängig von der laufenden digitalen Summe die folgende laufende digitale Summe erneut ermittelt wird und abhängig davon die fehlerhaften Daten ersetzt werden
Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass abhängig von der Anzahl der Fehler eine Strategievorgabe zur Fehlerbehandlung erfolgt.
Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass die Strategie vorsieht unter vorgebbaren Voraussetzungen keine Fehlerkorrektur vorzunehmen.
Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass eine Korrektur des Fehlers vorgenommen wird, indem das fehlerhafte Datenwort durch ein bestimmtes festgelegtes Datenwort ersetzt wird.
Vorrichtung zur Fehlerbehandlung bei der Übertragung von codierten Daten in Form wenigstens eines Datenwortes über ein Kommunikationssystem, wobei zu dem wenigstens einen Datenwort ein Codedatenwort nach einer vorgebbaren Codiervorschrift ausgewählt wird, wobei die Daten als Bits, die zwei verschiedene Werte, Einsen und Nullen, annehmen können dargestellt werden, dadurch gekennzeichnet, dass wenigstens eine laufende digitale Summe derart gebildet wird, dass eine aufsummierte Differenz der Gesamtzahl der Einsen und der Gesamtzahl der Nullen wenigstens über das Codedatenwort gebildet wird und diese laufende digitale Summe übertragen wird, wobei die laufende digitale Summe zum folgenden Codedatenwort bestimmt und mit der dann übertragenen verglichen wird, wobei bei Abweichung auf Fehler erkannt wird.
Teilnehmer mit einer Vorrichtung zur Fehlerbehandlung bei der Übertragung von codierten Daten in Form wenigstens eines Datenwortes über ein Kommunikationssystem, wobei zu dem wenigstens einen Datenwort ein Codedatenwort nach einer vorgebbaren Codiervorschrift ausgewählt wird, wobei die Daten als Bits, die zwei verschiedene Werte, Einsen und Nullen, annehmen können dargestellt werden, dadurch gekennzeichnet, dass wenigstens eine laufende digitale Summe derart gebildet wird, dass eine aufsummierte Differenz der Gesamtzahl der Einsen und der Gesamtzahl der Nullen wenigstens über das Codedatenwort gebildet wird und diese laufende digitale Summe übertragen wird, wobei die laufende digitale Summe zum folgenden Codedatenwort bestimmt und mit der dann übertragenen verglichen wird, wobei bei Abweichung auf Fehler erkannt wird.
Computerprogramm-Produkt mit Programmcode, der auf einem Datenträger gespeichert ist, zur Durchführung des Verfahrens nach einem der Ansprüche 1 bis 10, wenn das Programm in einem computergestützten Kommunikationssystem ausgeführt wird
Computerprogramm mit Programmcode zur Durchführung aller Schritte nach einem der Ansprüche 1 bis 10, wenn das Programm in einem computergestützten Kommunikationssystem ausgeführt wird.