Veränderung der Schaltung durch das LX1600 eProm v2.10

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. Mit dem eProm Update des LX1600 auf version 2.10. gibt es die Schwierigkeit mit den verschiedenen Geschwindigkeiten nicht mehr. Das LX1600 kommt jetzt mit dem Datenstrom des Flarm (GPS, Trafic, Warnung bei 19200baud) zurecht.

Die Anforderungen vereinfachen sich dadurch wie folgt:

• das Butterfly benötigt Trafic und Warnung vom Flarm mit 19200baud
• das LX1600 kann mit dem vollen Datenstrom des Flarm am Eingang umgehen
• das LX1600 gibt alle Flarm Daten und die LX1600 Einstellungsdaten am Ausgang mit 19200baud 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 nunmehr eigentlich gar kein MUX mehr. Jedoch kann der PDA mit der Version 2.15 von ConnectMe in dieser Konfiguration nicht auf das Flarm zugreifen. Das braucht man aber um Deklarationen hochladen und Flüge herrunterladen zu können. Deswegen braucht es doch einen MUX vom K6–Team. Damit läßt sich dieses Problem wieder elegant aus der Welt schaffen.

Im Nachfolgenden ist die Schaltung genau erklärt:

• MUX–Eingang1 19200baud:
  die Flarm Daten werden von E1 nach E2 ohne Veränderung umgeleitet. Die gesamten Flarm-Daten werden auf dem Weg zum Ausgang mit einem leeren 'Pass' Befehl gefiltert (Pass ''), dadurch werden alle Daten geblockt, weil nichts passieren darf.
• MUX–Eingang2 19200baud:
  die unveränderten Flarm Daten werden mit einem gedrehten Kabel zum Y-Kabel geschickt. Ein Anschluß ist für das Butterfly und der andere versorgt das LX1600. Obwohl eigentlich keine Daten von den Geräten geschickt werden, habe ich dennoch mit einem leeren 'Pass' Befehl diesen Port geblockt.
• MUX–Eingang3 19200baud:
  Die vom LX1600 erzeugten Daten (Flarm, LX) werden ungefiltert zum Ausgang geschickt.
• MUX–Ausgang 19200baud:
  alle vom MUXeins gesammelten Daten (Flarm+LX1600 von Eingang3) werden an den PDA gesendet.

Der MUX hat 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 MUX). 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).

Die Schaltung hat sich durch das eProm Update des LX1600 drastisch vereinfacht. Wird irgendwann auch noch das ConnectMe repariert, braucht man gar keinen Mux mehr, sondern verbindet einfach das Flarm mit dem LX1600 und das LX1600 mit dem PDA. Hier hat man dann 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.