Projekte.DFVetterSchnarr (Struktur)
Datenfunk mit den Transceivermodulen XTR-434L
| Die übergeordnete Zielstellung der Projektarbeit war, mit Hilfe der Transceivermodule XTR-434L eine echtzeitfähige Datenfunkverbindung zwischen einem Master (Rechner) und mehreren Slaves (mobile Roboter) nach dem Zeitscheibenverfahren zu realisieren. Die Projektarbeit sollte sich dabei auf eine Demo-Version mit einem Master und zwei Slaves beschränken, bei der die Transceiver über FPGAs angesteuert werden. Hier auf der Web-Seite sind die aufgetretenen Probleme, die gefundenen Lösungen, die entwickelten Baugruppen und Programme dokumentiert. |
|
Bearbeiter: Johannes Vetter und Christian Schnarr
|
Transceiver XTR-434 -- experimentelle Kontrolle der Datenblattangaben
[Datenblatt] [Foto]
(Untersucht anhand der drei vorliegenden XTR-434 Module.)
Benötigter Strom
Sendebetrieb:Die Werte liegen innerhalb der angegebenen Grenzen zwischen minimal 24 mA und maximal 32 mA.
(26 mA, 28 mA, 30 mA) Empfangsbetrieb:
Alle Module liegen zwischen den typischen 11 mA und den maximalen 12 mA. Module disabled:
Hier liegen alle Module um ein vielfaches (mehr als dem Faktor zehn) über den angegebenen maximal 100 nA.
(1,65 mA, 1,70 mA, 1,74 mA)
Umschaltzeiten
Die Darstellungen im Datenblatt sind hier auf den ersten Blick evtl. etwas verwirrend.Zum Umschalten an sich braucht jedes Modul genau 1 ms.
Bevor danach jedoch Nutzdaten versandt werden können, ist für 1-2 ms ein 50 kHz Rechteck - quasi zum Einschwingen - zu senden.
Bei Sichtkontakt über wenige Meter war bei allen Modulen eine Einschwingzeit von 1 ms ausreichend.
Für eine Übertragung zwischen zwei Räumen oder über mehr als ein paar Meter ist diese Zeit zu erhöhen.
Dabei korrelierte der Strombedarf mit der benötigten Einschwingzeit.
| mA | 26 | 28 | 30 |
| ms | 1 | 1,5 | 2 |
Logikpegel
Auch hier mag das Datenblatt zunächst verwirrend erscheinen. Für die Eingänge sind 0 V und 5 V notwendig.Auch wenn man meinen könnte, daß die 3,3 V des FPGA (Spartan2E) im Rahmen von TTL-Logic noch als high-Pegel angesehen werden, ist dieses vorallem beim Schalten von Rx-enable und Tx-enable nicht verläßlich der Fall. Als Ausgangspegel sind 0,1 V und 3,5 V angegeben.
Damit ist der high-Pegel für den FPGA zu hoch.
Desweiteren können diese Ausgänge nicht direkt belastet werden. Eine Low-Current-Leuchtdiode mit Vorwiderstand am CD (Carrier Detect) würden die Spannung beispielsweise bereits einbrechen lassen.
Antennenbau
Bereits ohne Antenne sind die Module für kurze Distanzen einsatzfähig. Auf Empfängerseite kann dieses sogar von Vorteil sein, da so der Einfluß von leistungsschwachem Rauschen minimiert wird. Die Verwendung zumindest einer einfachen "whip" Antenne ist dennoch ratsam.Auch hierzu sind die Angaben im Datenblatt - vorsichtig ausgedrückt - verwirrend. Es wird ein 16,5 mm langer Draht mit 1 mm Durchmesser in einer Entfernung von mind. 5 cm von anderen Bauteilen empfohlen. Bei der Länge stimmt wohl etwas nicht. Also rechnen wir nach: Ausgehende von der angegebenen Übertragungsfrequenz (f = 433,92 MHz = 433.920.000 1/s) und der Ausbreitungsgeschwindigkeit im Vakuum (c = 299.792.458 m/s) - also Lichtgeschwindigkeit - ergibt sich eine Wellenlänge von:
λ = c / f = (299.792.458 / 433.920.000) m = 69 cm
Für die gewünschte, senkrechte Lambda/4 Stabantenne sind das folglich 17,3 cm (h).
Zum Betrieb bei Resonanz muß diese Länge nun mit 0,96 gewichtet werden und ergibt sich zu 16,58 cm.
Da die Antenne nicht unendlich dünn ist, muß auch dieser Wert nochmals mit einem Verkürzungsfaktor (V), der sich in Abhängigkeit vom Schlankheitsgrad (s=h/d) ergibt, angepaßt werden. s = 16,58 cm / 1 mm = 165,8; V = s / (1 + s) = 0,994
Rechnerisch ergibt sich also eine Antennenlänge von 16,48 cm für den realen Einsatz. Der angegebene Wert im Datenblatt war also korrekt und nur die Maßeinheit falsch. Für ambitioniertere Anwendungen empfiehlt es sich jedoch auf komplexere Antennenkonstruktionen mit ground-plane zurückzugreifen.
(Solch eine passende Antenne von Aurel zum Modul liegt beispielsweise bei etwa zweidrittel des Modulpreises.)
Übertragung von Rechtecksignalen (Melodien)
Motivation
Nachdem wir in ersten Tests mit Signalgenerator und Oszi festgestellt hatten, daß die Transceiver feste Frequenzen im angegebenen Frequenzbereich (10 kHz bis 50 kHz) übertragen können, war der nächste Schritt die Übertragung von Signalen mit Informationsgehalt.In Anlehnung an den vorangegangenen Versuchsaufbau bieten sich hier wechselnde Frequenzen an. Zur einfachen Auswertung beim Empfänger bedeutet dieses die Übertragung von Musik/Melodien.
Grundlagen zum Hören
Das menschliche Gehör kann normalerweise Frequenzen bis max. 22 kHz wahrnehmen.Der Kammerton A liegt bei 440 Hz.
Die Erhöhung eines Tones um eine Oktave erfolgt durch die Multiplikation mit zwei.
Die nächsten Frequenzen für "A" sind folglich 880 Hz und 1,76 kHz.
Zum VHDL-Programm
Wenn btn_2FT gedrückt wird oder sw1 auf eins steht, arbeitet das Programm einen RAM-Speicher der Reihe nach ab, der pro Speicherplatz folgende Informationen enthält:- Legato-Bogen: Wenn das erste Bit Null ist, dann wird vor dem eigentlichen Ton eine kurze Pause (entsprechend der Konstante bogen_zahl) gemacht, so daß sie von der vorherigen Note zu unterscheiden ist.
- Dauer: Mit diesen zwei Bit wird die Notenlänge repräsentiert. Eingestellt ist hier, daß der größte Wert (11) als 1/16tel genau 0,25 Sekunden interpretiert wird (siehe Konstante metrum). Der kleinste Wert (00) steht für 4/16tel also 1 Sekunde.
- Note/Frequenz: Diese letzten vier Bit stehen für die Frequenzteiler der entsprechenden Töne, die in einer LUT (freq) eingetragen sind.
Damit die Notierung im song-RAM einfacher lesbar wird, sind die entsprechenden Notennamen als Konstanten mit hinterlegter Position des zugehörigen Teilerwerts in der LUT definiert.
Da es bei der ersten Variante zu Störgeräuschen kommt (4 Hz und weniger sind zu weit von der Untergrenze von 10 kHz der Übertragungsbandbreite entfernt, so daß das Signal einbricht), bietet sich die zweite Methode an. (Das Programm ist aber so geschrieben, daß song-RAM-Speicher mit beiden Varianten verarbeitet werden.)
Ergebnis
Eine Übertragung um 440 Hz herum ist möglich, hat aber einen starken Rauschanteil.Mit einem Tonspektrum von 1,168 kHz bis 2,623 kHz bekommt man erste brauchbare Ergebnisse.
Um den Einfluß des Transceivers auszuschließen kann man für die ersten Tests auch statt der Aurels ein Kabel benutzen. [Bild] Eine Übertragung vom Labor bis zum Hörsaal ist möglich.
Zum unabhängigen Betrieb eines Empfängers von den Spartan-Versuchsboards kann man die Spannungsversorgungskarte benutzen. (Damit der Transceiver im Empfangsmodus arbeitet, ist am Eingang ein Stecker erforderlich, der TX/NOT_RX auf das entsprechende Potential legt.) [Bild]
VHDL Quellcode
Und hier der VHDL-Code: [sound.vhd]Datenübertragung
Motivation
Nachdem im vorherigen Versuch sichergestellt wurde, daß in rudimentärer Weise einfache Übertragung von informationstragenden Signalen mit den Transceiveren auf den Boards an den FPGAs realisiert werden kann, soll nun mit einer komplexeren Anordnung gearbeitet werden.Als mögliche Anwendung wird hier Roboter-Fußball angenommen, bei dem mehrere mikroprozessorgesteuerte Clients mit einem PC als Master Position und Sensordaten austauschen.
Als einfach Testumgebung können auch zwei PCs beispielsweise mit dem Programm HyperTerminal über diese Module kommunizieren.
Modulare Zerlegung
RS-232 (in) / (out)
Der Empfang über die serielle Schnittstelle erfolgt in Anlehnung an die entsprechende VHDL-Laborübung. Die verwendete Struktur besteht aus einem Start-Bit, 8 Daten-Bits, keiner Parität und mindestens einem Stop-Bit.Mit der Konstante baud von 434 gibt dieser Taktteilerwert in main.vhd eine Übertragungsgeschwindigkeit von 115.200 Bps vor. (Um beispielsweise 9.600 bps einzustellen wäre baud um das zwölffache zu erhöhen.)
Sobald rs232_in ein komplettes Byte empfangen hat, wird dieses auf output gelegt. Mit der Invertierung des out_flag wird das Module speicher_gross veranlaßt dann dieses Byte in den Ringspeicher zu übernehmen.
rs232_out wartet darauf, daß das empty_flag Null ist, also der kleine Ringspeicher nicht leer ist, sprich mindestens ein weiterzuleitendes Byte vorhanden ist. Durch Invertierung von next_flag wird der speicher_klein veranlaßt das nächstaktuelle Byte auf input zu legen. (Während der Übernahme wird bereits das Start-Bit gesendet.) Der Quellcode dieser Module:
[rs232_in.vhd]
[rs232_out.vhd]
Ringspeicher
Hauptaufgabe der Ringspeicher ist die Pufferung der Daten gegenüber der seriellen Schnittstellen. Da mit der momentanen Einstellung die serielle Schnittstelle schneller als die Funkübertragung ist, wird auf der Eingangsseite ein großer Puffer und auf der Ausgangsseite lediglich ein kleiner Puffer benötigt. (Wenn die Baud-Rate verändert wird, sollten daher die Speichergrößen entsprechend angepaßt werden.)Der Quellcode dieser Module:
[speicher_gross.vhd] speicher_gross.vhd
[speicher_klein.vhd] speicher_klein.vhd
Praeambel
Die Praeambel dient zur eindeutigen Identifizierung des Paketbeginnes. Ihre Struktur muß hierzu derart sein, daß sie weder mit dem Rechteck aus dem "Einschwingvorgang" noch mit den Nutzdaten verwechselt werden kann. Nebenher sollte sie mittelwertfrei sein. Hier der Quellcode des Modules zur Überprüfung, ob die auf input anliegende Folge eine Praeambel ist:[is_praeambel.vhd] is_praeambel.vhd
encode / decode
In der vorliegenden Version wird durch den Encoder ein Byte in eine 16-Bit-Manchester-Codierung überführt. Vorteil dieser Codierung ist die garantierte Mittelwertfreiheit (50:50 Verhältnis), die für eine optimale und möglichst störungsresistente Übertragung nötig ist.Laut Datenblatt sind Codierungen bis zu einem 30:70 bzw. 70:30 Verhältnis möglich aber nicht optimal.
In ersten Versionen haben wir daher mit einer "halben" Manchester-Codierung gearbeitet, bei der jedes zweite Bit alleinstehend übertragen wurde und somit nur die Hälfte Manchester-Codiert war. (11011000 wurde hierbei z.B. zu: 10 1 01 1 10 0 01 0) Mit dieser Version einer 8->12 Codierung wären maximal 4 Bits unausgeglichen, was einem Verhältnis von 67:33 entspricht und somit noch in den Grenzen liegt.
Es existieren auch komplexere Verfahren die beispielsweise selbst mit einer 8->10 Codierung - jedoch dann nur über mehrere Bytes hinwegen - Mittelwertfreiheit erreichen. Näher betrachtet ist die Manchester-Codierung eine 1->2 Codierung und unsere "Halbe"-Manchester-Codierung eine 2->3 Codierung. Vor diesem Hintergrund lassen sich dann weitere Codierungen entwickeln. Beispielsweise eine 8->14 Codierung, die sich aus 1->2, 3->5, 1->2, 3->5 zusammensetzt.
Da komplexe Codierung (über mehrere Bytes hinweg - evtl. noch mit fehlerkorregierenden Code, dessen Sinnhaftigkeit bei Funk nebenher nicht ganz trivial zu betrachten ist) den Rahmen dieser Projektarbeit gesprengt hätten und alles Andere als 8->16 bei unseren Versuchen zu instabiler Übertragung führte, sind wir schlußendlich in der abschließenden Version wieder zur einfachen Manchester-Codierung zurückgekehrt. Der Quellcode dieser Module:
[encod.vhd]
[decod.vhd"a]
senden
Dieser Teil wartet darauf, daß im speicher_gross Daten vorliegen. Wenn dem so ist, wird - wenn noch nicht geschehen - der Aurel auf Senden geschaltet und für 2 ms mit einem Rechteck-Signal belegt. Danach folgt die oben beschriebene Praeambel (wobei die Praeambel hier aus der doppelten 16-Bit Praeambel besteht). Das erste Byte wird dann übertragen und als Paketlänge interpretiert. Damit soll sichergestellt werden, daß das nächste Paket wieder mit einer Praeambel starten kann. Es wird also mindestens alle 256 Byte eine Praeambel übertragen. Da die Praeambel in der Übertragung aber eher die Wirkung von Synchronisationspunkten hat und weniger zwingend Paketgrenzen markiert, ist es somit auch nicht zwingend erforderlich, daß das erste Byte eine korrekte Paketlänge angibt, womit das Programm prinzipiell protokolloffen wird.Die Erfahrung hat gezeigt, daß nach dem Senden des letzten Bits, also vor dem Umschalten des Aurels auf Empfangen, noch mind. 1 Bit übertragen werden muß, da sonst das letzte Byte teilweise nicht ankommt. Im vorliegenden Programm wird daher das letzte Bit noch für eine "lead_out"-Zeit gehalten. Dieses Modul befindet sich mit in der:
[main.vhd]
Tiefpass (TP)
Hier werden bis zu einer festgelegten Anzahl von Counts Einsen und Nullen gesammelt und der "Gewinner dieses Rennens" ergibt dann den Ausgabewert.Innerhalb des Programmes wird hiermit das Eingangssignal von einer Abtastung mit 50.000 kbps auf 1.000 kbps heruntergebrochen, was immernoch eine zehnfache Überabtastung darstellt.
Auch hier wäre der Einsatz von komplexeren Filtern denkbar. Da aber die Lauflängenunterschied zwischen Nullen und Einsen - siehe Signalverhalten - hier noch nicht abgefangen werden, wurde auch hier schlußendlich an der einfachen Basisversion festgehalten. Hier der Quellcode dieses Modules:
[TP.vhd]
Takterkennung / -anpassung
Das Tiefpaßgefilterte Signal wird hier auf die eigentlichen 100 kbps heruntergebrochen.Man stelle sich hierbei eine Zeitscheibe mit 10 Fenstern vor, die man versucht synchron zu den Bitgrenzen auf dem Tiefpaßgefilterten Signal abzurollen.
Um nun während des "Einschwingvorgangs" sich einzutakten, wird bei einer Flanke zwischen 5 und 6 - wo also nie eine sein dürfte - angenommen, daß sich der Sendevorgang eigentlich zwischen 10 und 1 befindet; sollte in einem anderen Bereich eine Flanke auftreten (was als Zeichen von Bitgrenzen gilt), wird entsprechend der Position das Betrachtungsfenster angehalten oder zusätzlich weiter gedreht. Damit nicht übermäßig stark auf evtl. unbedeutendes Rauschen reagiert wird, kann nur in jedem zweiten Takt eine Verschiebung des Betrachtungsfensters vorgenommen werden. Die Sprünge beim "no-go" von Flanken in der stabilen Mitte sind von dieser Zeitsperre ausgenommen. Hier der Quellcode dieses Modules:
[Takterkennung.vhd]
Stream/Nutzsignal erkennen
Mit diesem Modul wird nun die von der Takterkennung erzeugte Bit-Folge weiterverarbeitet.Nach der Bit-Grenzen-Erkennung im vorangegangenen Teil, sind hier nun Byte-Grenzen zu finden.
Hierzu wird ein Schieberegister verwendet, das mit jedem neuen Bit ausgewertet wird.
Sofern der vordere Teil als zwei Praeambel erkannt wird und der hintere Teil korrekt zu einem Byte decodiert werden konnte, wird das Byte an den Ringspeicher (klein) weitergegeben und sich dieser Moment als Paket-Anfang gemerkt. Gemäß dieser Annahme wird nach den nächsten 16-Bit wieder überprüft, ob der letzte Teil des Schieberegisters ein korrektes Byte ist, usw.
Da sich das Schieberegister auch nach dem letzten Byte noch weiter langsam mit Bits (aus Rauschen) füllen könnte, die dann mit einer gewissen Wahrscheinlichkeit (im Gegensatz zum ersten Byte des Pakets, das mit 40 Bits gesichert ist, sind es hier nur noch ein Fünftel, also 8 Bits) als Nutzdaten angenommen würden läuft nebenher ein "watch-dog". Dieses Modul befindet sich mit in der:
[main.vhd]
Zusammenfassung aller VHDL-Module
- [main.vhd]
- [main.ucf]
- [main.bit]
- [rs232_in.vhd]
- [rs232_out.vhd]
- [speicher_gross.vhd]
- [speicher_klein.vhd]
- [is_praeambel.vhd]
- [encod.vhd]
- [decod.vhd]
- [TP.vhd]
- [Takterkennung.vhd]
Signalverhalten
Analysen des Signalverhaltens
Auffällig ist, dass beim Senden eines Rechtecksignals konstanter Frequenz und
einem Tastverhältnis von 1:1 die Signale auf 0V ein wenig länger als die
Signale mit 5V ankommen. Dieser Effekt liegt vermutlich am Ausgangsschaltkreis
des Funkmoduls.
In den folgenden Bildern werden die Auffälligkeiten gezeigt.
TP2_DD gibt das Funksignal tiefpassgefiltert wieder.
takt2_z gibt die Länge des vorherigen Signals an.
DD_len gibt die Bitposition im momentanen Byte an.
recv_byte gibt den Wert des zuletzt vollständig empfangenen Bytes an.
CD_OK gibt an, ob der Träger korrekt empfangen wird.
recv gibt an, ob gerade ein Datenpaket bearbeitet wird.
TP2_FLANKE gibt den Start eines neuen Bits bekannt.
TP2_FLANKE gibt den Start eines neuen Bytes bekannt.
Die Pakete in dieser Analyse umfassen alle genau 4 Bytes Nutzdaten und 2 Terminierungsbytes (2x 0x00). Alles danach stellt Rauschen dar. Die Kodierung in dieser Analyse ist
anders als im letztendlich genutzten Programm. Hier wird jedes Bit mit einer
Flanke abgeschlossen; die Länge des Bits gibt an, welchen Wert das Bit hat
(kurz=0=10 Takte, lang=1=16 Takte).
Erstes Beispiel (Nutzdaten=4x 0x00):
Hier kann man die obige Behauptung erkennen, dass die Signale auf 0V Niveau ein wenig länger sind(10-11 Takte) als die auf 5V Niveau (9-10 Takte).
Zweites Beispiel (Nutzdaten=4x 0xFF):
Hier kann man die obige Behauptung erkennen, dass die Signale auf 0V Niveau ein wenig länger sind(überwiegend 16 Takte) als die auf 5V Niveau (überwiegend 14 Takte).
Drittes Beispiel (Nutzdaten=4x 0x0F):
Hier kann man die teilweise extremen Längenschwankungen zusätzlich erkennen. Die langen Signale liegen im Bereich von 14-15 (für Highs) und 16-17 (für Lows). Die kurzen Signale liegen im Bereich von 8-10 (für Highs) und 9-12 (für Lows). Die stärksten Schwankungen treten beim Wechsel zwischen langen und kurzen Signalen auf. Hier handelt es sich vermutlich um Überschwingeffekte, die nicht vom Funkmodul abgefangen bzw. ausgeregelt werden.
Viertes Beispiel (Nutzdaten=4x 0x02):
Die bisherigen Bilder zeigten noch mit unseren Methoden korrekt auswertbare Übertragungen. Nun folgen jedoch einige Bespiele, bei denen es zu Fehlauswertungen kam. Im ersten Bild wird das zweite Byte z.B. als 0x03 interpretiert, da das letzte Bit zu lang übertragen wird.
C-Programm
Sinn und Zweck des Programms
Der Sinn des Programms bestand ausschließlich darin zu prüfen, ob und wie gut die Übertragung Rechner-RS232-FPGA-FUNK-FPGA-RS232-Rechner funktioniert.Paketaufbau
| Offset | Datengröße | Abkürzung | Inhalt |
| 0 | 1 | l | Länge des Pakets |
| 1 | 1 | immer 'M' | |
| 2 | 2 | Absender-ID | |
| 4 | 2 | Empfänger-ID | |
| 6 | l-8 | Nutzdaten | |
| l-3 | 4 | CRC32 über die Nutzdaten |
Testablauf
Alle drei Module wurden jeweils einmal als Sender und Empfänger genutzt. Dadurch kann man modulabhängige Eigenschaften feststellen. Die Paketlänge ist gemäß dem obigen Aufbau Nutzdatenlänge+10Byte. Es wurden zwei Rechner mit jeweils dem selben Programm benutzt. Die beiden Programme wechseln immer ihre Rolle als Sender/Empfänger ab. Der Sender bleibt solange Sender, bis er auf ein Paket eine Antwort bekommt. Dabei ist es egal, ob diese Antwort korrekt ist. Ist dies nicht beim ersten Versuch der Fall, wird jede Wiederholung als Schreibfehler gezählt. Der Sender wiederholt im Fehlerfall alle 2 Sekunden seine Sendeaktion und wartet den Rest auf eine Antwort. Der Empfänger bleibt solange Empfänger bis er ein korrektes Paket empfängt. Ist dies nicht beim ersten Mal der Fall, wird jedes eingehende Datenbündel als Lesefehler gezählt. Wird mehr als 1 Sekunde nichts empfangen, führt dies zu einer Pufferleerung und der Erhöhung der Empfangsfehler. Die FPGAs waren jeweils mit chat_13 programmiert. Diese Version läuft mit Manchestercode.Ergebnisse
Reihe 1 (2.5ms-Modul vs. 3.0ms-Modul)
| Nutzdaten | Versuche | Schreibfehler | Lesefehler | Schreibfehler/Versuche | Lesefehler/Versuche |
| 0 | 2035 | 0 | 2 | 0 | 0.098% |
| 4 | 2033 | 1 | 2 | 0.049% | 0.098% |
| 64 | 1408 | 43 | 2 | 3.054% | 0.142% |
| 240 | 1107 | 73 | 18 | 6.594% | 1.626% |
Reihe 2 (2.5ms-Modul vs. 2.0ms-Modul)
| Nutzdaten | Versuche | Schreibfehler | Lesefehler | Schreibfehler/Versuche | Lesefehler/Versuche |
| 0 | 4041 | 1 | 0 | 0.025% | 0 |
| 4 | 8433 | 1 | 9 | 0.012% | 0.107% |
| 64 | 1013 | 23 | 12 | 2.270% | 1.185% |
| 240 | 352 | 20 | 9 | 5.682% | 2.557% |
Reihe 3 (3.0ms-Modul vs. 2.0ms-Modul)
| Nutzdaten | Versuche | Schreibfehler | Lesefehler | Schreibfehler/Versuche | Lesefehler/Versuche |
| 0 | 659 | 0 | 17 | 0 | 2.580% |
| 4 | 209 | 0 | 11 | 0 | 5.263% |
| 240 | 103 | 2 | 21 | 1.942% | 20.388% |
Paketabhängigkeiten
Für das C-Programm wird die dietlibc und die libowfat benutzt. Die Quellen und Lizenzbedingungen sind auf den verlinkten Seiten zu finden.Quellcode
Der Quellcode des C-Programms befindet sich [hier] und ist mittels bzip2 und tar gepackt.Fazit
Für fehlerarme Übertragungen von konstanten Rechtecksignalen sind die Module sehr gut geeignet und sogar außerhalb angegebenen Grenzen noch einsatzfähig. Bei der Datenübertragungen ist jedoch ein hoher Aufwand nötig.Da wir bei Störungen überwiegend von Büschel-Störungen ausgehen, sind somit auch einfache fehlerkorrigierende Codes nicht ausreichend, da eine größere Codeverschränkung notwendig ist. Bei einer weiteren Bearbeitung sollte eine Längenanpassung in der Empfangssteuerung berücksichtigt werden, die auf die festgestellten Unterschiede zwischen übertragenen Einsen und Nullen eingeht. Zusätzlich würden sich eine weitere Untersuchung und Betrachtung der Empfangssteuerung des Aurel anbieten (z.B. im Bezug auf das Überschwingen). Für spezifische Anwendungen ist auf jeden Fall zu klären, ob eine niedrige Latenz, eine hohe Bandbreite oder eine große Übertragungssicherheit den Vorrang haben. (Abwägung im "magischen Dreieck")
Autor: gkemnitz, Letzte Änderung: 14.04.2011 15:09:59
TU Clausthal 2020 Impressum