Ich habe von einigen Kunden gehört, dass sie erstens nicht sehen können, ob/dass ihre Blitzer blitzen (das ist nachvollziehbar : Pilot zu klein :-), guckt nicht über den DG-Pilz, Blitzer lichtdicht) und dass sie zweitens von den ihnen entgegenkommenden Kollegen keine Bestätigung bekommen, dass ihre Blitzer arbeiten (das ist nicht so beruhigend). Weiter höre ich von diesen Kunden, dass ihre FLARM-Installationen im Zusammenhang mit den Geräten, die die FLARM-Signale verarbeiten (PDA und/oder Flarm-Display), perfekt arbeiten.

Alles zusammen ist eine aus meiner Sicht nicht befriedigende Situation.

Da jeder Rechenknecht bei mir vor Auslieferung geprüft wird, kann das nur daran liegen, dass der Rechenknecht den FLARM-Datenstrom nicht interpretieren kann. Und das, korrekte Verkabelung vorausgesetzt, kann eigentlich nur an einer nicht angepassten Baudrate liegen.

Ich konnte jetzt einen solchen Fall untersuchen und habe ich festgestellt, dass hier das FLARM auf 19.200 bd eingestellt war. Damit wurde mein Verdacht bestätigt.

Der Rechenknecht arbeitet als Splitter und reicht dabei die Signale vom FLARM elektrisch ohne Verarbeitung 1 zu 1 durch. Deshalb funktioniert die FLARM-Installation auch mit jeder gewählten Baudrate. Der Rechenknecht lauscht auf der Leitung nur passiv mit, kann aber das FLARM nur bei 38.400 bd verstehen, nicht bei einer anderen BaudRate. Deshalb muss dein FLARM auf 38.400 bd eingestellt sein. So habe ich das auch in der Einbauanweisung für den Rechenknecht beschrieben.

Bitte überprüfe deine FLARM-Konfiguration daraufhin, ob dein FLARM und alle angeschlossenen Systeme auf 38.400 bd eingestellt sind. Wenn du nach dem Einbau des Rechenknechtes die Konfiguration deines FLARMs nicht verändert hast, ist die Wahrscheinlichkeit groß, dass das FLARM noch auf 19.200 bd oder mit noch geringerer BaudRate arbeitet.

Dieser Wert von 38.400 bd ist in der Rechenknecht-Konstruktion mit Absicht und Bedacht gewählt.

Das FLARM kann sekündlich einen Schwarm von Datensätzen aussenden, darunter für jedes erkannte Flugzeug jeweils einen PFLAA-Datensatz. Wenn du die FLARM-Dokumentation zur Datenschnittstelle (FLARM Data Port Specification) aber im Detail liest, wirst du finden, dass die FLARM-Software bei weniger als 19.200 bd gar keine PFLAA-Datensätze sendet und bei sehr starkem FLARM-Verkehr auch noch bei 19.200 bd nicht sicherstellen kann, dass alle Informationen von allen erfassten Flugzeugen (PFLAA-Datensätze) über die Leitung geschickt werden (im Jargon : port congestion). FLARM kann dann insbesondere nicht sicherstellen, dass die Daten der „wichtigsten“, weil potentiell gefährlichsten, Gegner mit übertragen werden. Das FLARM kann die Daten nicht priorisieren. Höhere Datenraten entspannen dieses Problem. Deshalb habe ich 38.400 bd gewählt.

Da ich aber andererseits gelernt habe, dass nicht alle FLARM-PDA-NAV-Programm-Kombinationen auf 38.400 bd (oder mit noch höherer Datenrate) betrieben werden können, werde ich im Herbst 2015 das Rechenknecht-Programm so umgestalten, dass es sich an Baudraten zwischen 19.200 und 115.200 bd automatisch anpasst. Alle Rechenknecht-Besitzer, die das wünschen, erhalten den Update ohne neue Kosten, wenn sie mir den Rechenknecht zuschicken. 

Ich werde hier bekannt machen, wenn und wann der Update zur Verfügung steht.

Horst 11.08.15

Ich habe auf der Basis der mitgeschnittenen NMEA-Daten meiner Flüge in 2014 und 2015 untersucht, ob irgendwo Datenverluste durch port congestion erkennbar waren.

Selbst bei 32 gleichzeitig beobachteten Flugzeugen waren noch keine Unterdrückungen nachweisbar. Alle Mitschnitte basieren allerdings auf einem FLARM, das auf 38.400 bd konfiguriert war. Höhere Verkehrsaufkommen sind in den Testdaten bisher noch nicht protokolliert worden.

Für den Betrieb bei 19.200 bd liegen zZ nur wenige mitgeschnittene Daten bei geringem Verkehrsaufkommen vor, so dass noch nicht von einem voll repräsentativen Ergebnis ausgegangen werden kann. Bisher waren auch hier noch keine Unter­drückungen nachweisbar. Es wurden immer genügend Daten übertragen, um den Rechenknecht-Betrieb zu gewähr­leisten.

Gegen kurzzeitige Unterbrechungen der PFLAA-Sätze bezüglich eines Flugzeuges (<15 Sekunden) ist der Algorithmus des Rechenknechtes konstruktiv gefeit.

Der oben angekündigte Update ist jetzt verfügbar.

Ich bitte darum, mit mir vor der Zusendung des Rechenknechtes per Mail Kontakt aufzunehmen.

Horst  18.10.15                                            nach oben