NMEA Datenströme mit dem MUX vom K6–Team beherrschen,
um LX1600, PDA, Butterfly und den Piloten glücklich zu machen

Der MUX vom K–6 Team kann in der hier verwendeten Version HW4 folgendes:

• Signale von den drei Eingängen (E1, E2, E3) mit unterschiedlichen baud–Raten annehmen
• Tx–Daten von E1–E3 auf dem Weg zum Ausgang evtl. filtern.
• Die verbleibenden Tx–Daten von E1–E3 zusammenfassen und am Ausgang mit einer bestimmten baud–Rate ausgeben.
• Tx–Einganssignale unverändert an einen der anderen Eingänge an der Rx Leitung ausgeben.
• Rückfließende Tx–Signale vom Ausgang zu genau einem der Rx Eingänge weitergeben.

Die Filter können als PASS (nur bestimmte Daten dürfen passieren) oder als BLOCK (nur bestimmte Daten werden geblockt) konfiguriert werden. Das klingt jetzt erstmal nach nicht viel, aber es lassen sich erstaunlich komplexe Datenströme damit handhaben.

Alle Ports können mit den baud–Raten betrieben werden, die die jeweils angeschlossenen Geräte benötigen. Hierbei muß man jedoch darauf achten, das es nicht zu einen Datenstau kommt. Die baud–Rate gibt nur den Takt vor mit der die serielle Schnittstelle tickt. Wie viele Daten übertragen werden, steht in keinem direkten Zusammenhang mit der eingestellten Geschwindigkeit des Ports.

Es ist zwar möglich auf allen drei Eingängen Daten mit 19200 baud entgegen zu nehmen und mit nur 4800baud auszugeben, aber dies geht nur solange gut, wie nur sehr wenig Daten fließen. Übersteigt die gesammelte und gefilterte Datenmenge von E1–E3, dass was die am Ausgang konfigurierte Geschwindigkeit handhaben kann, gehen Daten verloren!!! Zaubern kann der MUX nicht.

Vereinfacht besteht eine Serielle Schnittstelle aus zwei Dräten. Auf dem einen wird aus Sicht des Gerätes gesendet (Tx) und auf dem anderen Empfangen (Rx). Hier liegt auch ein Problem mit den beim MUX verwendeten Bezeichnungen. Denn was für das eine Gerät das gesendete Tx Signal, ist für das gegenüber das empfangene Rx Signal. Es handelt sich dabei aber um den gleichen Draht. Daher ist es ersteinmal recht schwierig die Belegung der Kabel zu verstehen und richtig umzusetzen, da Tx und Rx vom Blickwinkel abhängen. Zum Schluß habe ich mir ein gedrehtes Kabel gemacht und es einfach ausprobiert wie herum es funktioniert.

Für die LS7 wollte ich mit nur einer GPS Quelle (Flarm) sowohl den PDA, als auch das Butterfly und LX1600 versorgen. Die Schwierigkeit besteht dabei darin, dass die unterschiedlichen Geräte unterschiedliche Daten mit verschiedenen Geschwindigkeiten benötigen, zB. ist das LX1600 mit dem vollen Datenstrom des Flarm (GPS, Trafic, Warnung bei 19200baud) überfordert. Dagegen will der PDA alle Daten haben, auch die vom LX1600.

Die Anforderungen sind wie folgt:

• das Butterfly benötigt Trafic und Warnung vom Flarm mit 19200baud
• das LX1600 benötigt GPS vom Flarm mit 4800baud am Eingang
• das LX1600 gibt GPS und LX1600 Einstellungsdaten am Ausgang mit 4800baud aus und erhält über den gleichen Port auch die LX1600 Einstellungsdaten vom PDA
• der PDA benötigt alle Daten von Flarm und LX1600 und gibt seinerseits LX1600 Einstellungsdaten aus. Er ist aber auch der flexibelste was die Einstellung der baud-Raten angeht.

Damit alle Geräte in ihrem vollen Umfang benutzt werden können benötigt man zwei MUX vom K6–Team. Damit läßt sich dieses Problem wirklich elegant aus der Welt schaffen.

Im Nachfolgenden ist die Schaltung genau erklärt:

• MUXeins–Eingang1 19200baud:
  die Flarm Daten werden von E1 nach E2 ohne Veränderung umgeleitet. Die GPS Daten werden auf dem Weg zum Ausgang geblockt (Block $GP), alle anderen vom Flarm generierten Daten können passieren.
• MUXeins–Eingang2 19200baud:
  die unveränderten Flarm Daten werden mit einem gedrehten Kabel zum MUXzwei auf Eingang1 geschickt. Dies könnte man auch mit einem Y–Kabel am Flarm erreichen. Simple RJ45 Kabel zu krimpen ist aber einfacher.
• MUXeins–Eingang3 4800baud:
  Die vom LX1600 erzeugten Daten (GPS, LX) werden ungefiltert zum Ausgang geschickt.
• MUXeins–Ausgang 38400baud:
  alle vom MUXeins gesammelten Daten (Trafic+Warnung von Eingang1 und GPS+LX1600 von Eingang3) werden an den PDA gesendet.

Hier muß man darauf achten das die baud–Rate am Ausgang höher ist als die höchste am Eingang, sonst können keine Daten rückwärts gesendet werden. Alles was der PDA Rückwärts zum Ausgang des MUXeins sendet wird an Eingang3 weitergeleitet (LX1600 Steuerung).

• MUXzwei–Eingang1 19200baud:
  hier liegen die unveränderten Flarm Daten vom MUXeins–Eingang2 kommend an (gedrehtes Kabel). Die Flarm Daten werden von Eingang1 nach Eingang2 ohne Veränderung umgeleitet. Damit stellt man sicher, daß die zwei MUX nicht umkonfiguriert werden müssen, wenn sich die Flarm Datensätze für das Butterfly verändern sollten. Nur die GPS Daten werden auf dem Weg zum Ausgang durchgelassen (PASS $GP)
• MUXzwei–Eingang2 19200baud:
  die unveränderten Flarm Daten gehen an das Butterfly (gedrehtes Kabel)
• MUXzwei–Eingang3 19200baud:
  nicht verwendet
• MUXzwei–Ausgang 4800baud:
  die gesammelten Daten (hier nur GPS von Eingang1) werden an den GPS Eingang des LX1600 gesendet

Der MUXeins hat zudem noch einen manuellen Schalter (eine 'Flug' Position, zwei 'Daten' Positionen) mit dem sich Ausgang und ein Eingang direkt verbinden lassen (bei mir verbinde ich auf beiden 'Daten' Positionen des Schalters den Ausgang mit Eingang1 des MUXeins). Dadurch ist es möglich das Flarm direkt mit dem PDA zu verbinden, wenn man das Flarm auslesen oder eine Deklaration hochladen möchte. Ich benutze auf dem PDA SeeYou und ConnectMe. Hier muß man darauf achten, das man zuerst ConnectMe startet und die richtige Geschwindigkeit einstellt (19200 baud), bevor man den Schalter am MUX umlegt. Ansonsten stellt sich das Flarm auf die Geschwindigkeit von ConnectMe um. Stellt man danach den Schalter wieder auf 'Flug', kommen bei den angeschlossenen Geräten keine Daten an, weil das Flarm zb von 19200baud auf 4800 baud umgestellt wurde.
Passiert es einem doch einmal, ist es aber kein großes Problem. Den Schalter zurück auf 'Flug', bei ConnectMe die richtige Geschwindigkeit einstellen (19200 baud), Schalter auf 'Daten' stellen und schon arbeitet das Flarm wieder mit der richtigen Geschwindigkeit (bis ich dies begriffen hatte, hatte ich das Instrumentenbrett aber einige male ausgebaut, die MUX neu programmiert, auch das Flarm öfters neu eingerichtet und die Hersteller mit vielen Fragen gelöchert).

Durch die Verwendung von Block $GP im MUXeins und Pass $GP im MUXzwei stellt man zusätzlich sicher, das der PDA wirklich alle Daten bekommt die das Flarm erzeugt, selbst wenn sich in einem der nächsten Updates etwas an dem Datenstrom ändern sollte. Zudem stellt man auch sicher, das es zu keinen Kollisionen gleicher Daten kommt, da das was bei dem einen MUX geblockt wird, beim anderen MUX passieren darf. Es darf nämlich nicht sein, das zb von zwei verschiedenen Quellen GPS Daten eingespeist werden. Zwar könnte der MUX damit sogar umgehen (welches Paket zuerst kommt, malt zuerst) aber eine abwechselnde Zuspielung aus unterschiedlichen GPS Quellen ist für ein LX1600 oder die Aufzeichung im PDA sicher nicht das gelbe vom Ei.

Die Schaltung sieht kompliziert aus und ist es auch. Jedoch funktioniert es wirklich klasse. Hier hat man für kleines Geld eine kompakte Komplettanlage die keine Wünsche offen läßt. Nichts ist doppelt vorhanden und durch eine einzige GPS Quelle arbeiten alle Geräte mit den gleichen Daten. Es kann also nicht zu einer Addierung systematischer Fehler kommen.

Diese Addierung war zB der Grund warum ich das mechanische Vario entfernt habe. Ich habe mich dabei beobachtet immer auf das Gerät zu schauen welches in der jeweiligen Situation die besseren Werte lieferte. Also beim Sinken meißt auf die netto Anzeige im Flugcomputer und beim Steigen auf das mechanische Vario. Zentriert habe ich aber nach dem Pips des e–Vario. Dadurch wird der Fehler den man macht aber maximal. Jetzt gibts nur mehr eine einzige Referenz für Steigen/Sinken/Vorfliegen und fertig.

Zudem sind die Geräte heutzutage auch derart zuverlässig, das der Bedarf für Backupgeräte nicht mehr logisch begründet werden kann. Es kommt mir auch so vor, also ob der Ein oder Andere ein völlig mit Instrumenten überladenes Instrumentenbrett einfach ein bischen cooler findet als die minimalistische Variante.