Auf planecheck.com wird gerade ein (schlecht beschriebener) GTX330ES für 1.900€ angeboten.

Das Problem der Flarmupdates scheint gelöst: https://www.aerokurier.de/praxis/neues-protokoll-flarm-warnung-trotz-alter-firmware/

Danke Malte für den Hinweis!!!

Bliebt zu hoffen, dass auch wirklich ALLE Flarm Geräte auf die aktuelle Software umgerüstet werden.

Kollision trotz FLARM an Bord – solche Sätze in Unfallanalysen waren regelmäßig Auslöser für hitzige Diskussionen vor allem in der Segelflugszene. So kochten auch angesichts eines jüngst von der BFU behandelten Falls, in dem eine DG-300 und eine LS4 zusammengestoßen waren, die Emotionen hoch. Der Hauptkritikpunkt dabei: Nur mit aktueller Firmware in allen beteiligten Geräten ist das Warnsystem bisher in der Lage, Piloten auf gefährliche Annäherungen hinzuweisen. Und in einem der beiden Flugzeuge war die Software veraltet.

Neues Kommunikationsprotokoll
Diese entscheidende Schwachstelle von FLARM soll voraussichtlich ab Mitte 2024 der Vergangenheit angehören. Möglich wird das durch eine grundlegende Neuerung im Kommunikationsprotokoll. "Mit der neuen Firmware werden die Geräte zusätzlich zu den Positions- und Bewegungsdaten noch eine Information zu ihrem eigenen Firmware-Status mit aussenden, sodass zwischen FLARMs in der Umgebung eine Verständigung über das Protokoll, das sie verarbeiten können, möglich wird", sagt Urban Mäder, einer der Segelflieger, die FLARM vor 20 Jahren aus der Taufe hoben. "Begegnet ein mit aktueller Firmware bestücktes Gerät einem nicht aktualisierten, wechselt es situativ auf ein älteres Protokoll, abhängig etwa von Abstand oder Gefährlichkeit des anderen Luftfahrzeugs." Der Vorteil: Die Kollisionswarnung erfolge trotz unterschiedlicher Firmware. Allerdings könne es sein, dass durch die älteren Protokollversionen bestimmte Zusatzfunktionen dann nicht zur Verfügung stehen, so Mäder.

Link zum einfacheren verlinken. ;-)

https://www.aerokurier.de/praxis/neues-protokoll-flarm-warnung-trotz-alter-firmware/

Rein technisch müsste das nichtmal notwendig sein. Die "aktuellen" Geräte erkennen ja, dass ein nicht aktualisiertes Gerät keine Protokoll-Version sendet und muss dann ggf. mehrere ältere Protokoll-Versionen "durchprobieren", bis die Daten Sinn ergeben (das kann man z.B. anhand einer Checksumme, die FLARM hoffentlich hat, festmachen). Mit ein wenig Hirnschmalz und Wille ist das m.E. kein Thema. Mich wundert, dass die Entwickler jetzt erst auf die Idee kommen.

"Die "aktuellen" Geräte erkennen ja, dass ein nicht aktualisiertes Gerät keine Protokoll-Version sendet und muss dann ggf. mehrere ältere Protokoll-Versionen "durchprobieren", bis die Daten Sinn ergeben (das kann man z.B. anhand einer Checksumme, die FLARM hoffentlich hat, festmachen)."

"Vernünftige" Protokollspezifikationen sehen am Anfang einer Nachricht einen Protocol Discriminator (2-4 bits) vor. Dann braucht man nichts durchprobieren, sondern schickt die Nachricht anhand des Discriminators durch den einen oder anderen Nachrichtendecoder.

Wäre sogar mit den im Flarm verbauten Kaffeemaschinen-Microcontrollern à la Atmega 8 seit Ewigkeiten möglich gewesen, wenn man die Rechenzeit statt in sinnloser Verschlüsselung (mit geänderten Schlüsseln je Firmwareupdate) lieber in Kompatibilität zwischen Firmware-Releases gesteckt hätte. Insofern hat der "Shitstorm" nach derartigen Unfällen durchaus seine Berechtigung, denn bisher wurde völlig eindeutig der Fokus auf Marktabschottung ohne jegliche Interoperabilität gesetzt.

Traurig, dass erst jetzt, nachdem tödliche Unfälle geschehen sind, eine Lösung erdacht wird.

Schon sehr traurig, da haben viele in eine Scheinsicherheit investiert und sich letztlich sicher gefühlt. Das traurige daran, dass durch die Bastelbude tote zu beklagen sind und jetzt das längst überfällige Software Update auch noch als Innovation verkauft wird. Einfach nur beschämend.

Ja, das ganze noch als Innovation zu verkaufen, ist schon ziemlich dreist. Auch die Formulierungen im verlinkten Artikel sind ziemlich an den Haaren herbeigezogen:

Den Aufwand, ein Protokoll zu entwickeln, mit dem alle Generationen von Geräten sicher miteinander kommunizieren können, beschreibt Mäder mit dem Versuch, einen C64 mit einem modernen Laptop zu vernetzen.

Mein Siemens P1 wurde gerade dann auf den Markt geworfen, als die letzten C64 vom Band liefen. Entgegen der Logik von Herrn Mäder kann ich mit besagtem Telefon immer noch mobil telefonieren - und ein brandneues Smartphone im gleichen GSM-Netz/Zelle anrufen und von diesem angerufen werden. Das Gerät hat seit Verlassen der Fabrik exakt null Firmwareupdates bekommen. Funktioniert deshalb, weil das Radioprotokoll auf Erweiterbarkeit ausgelegt wurde und die Aktualisierungen nicht die Kompatibilität brachen.

"Die Arbeiten daran laufen seit gut drei Jahren, das war alles andere als trivial." Die Komplexität der Aufgabe in Verbindung mit der Tatsache, dass Updates für FLARM kostenfrei und damit kein Geschäft sind, ließen den Hersteller viele Jahre vor diesem Schritt zurückschrecken.

Wenn man den Gerätekäufern Updates aufzwingt, weil sonst ihre Geräte nicht mehr funktionieren, sollte man sich nicht über die grausam hohen Entwicklungskosten für Updates beschweren (die m.M.n. nur vorgeschoben sind, schließlich haben Einzelpersonen das komplette Protokoll nachentwickelt und auf allerlei Plattformen implementiert [SoftRF]).

Wenn diese Firma dafür drei Jahre braucht, hat man entweder intern keine Zeit für Softwareentwicklung eingeplant, oder nicht die nötige Expertise für ein solches Produkt. Letzterenfalls sollte man sich vielleicht lieber auf die Entwicklung von einfachen Smartphone-(Spiele-)Apps beschränken und die Finger von Safety-Devices lassen.

PS: Mich ärgert, dass im BFU-Bericht diese Problematik überhaupt nicht angesprochen wurde.

Volle Zustimmung. Bleibt nur zu hoffen, dass die angekündigte Software mit den alten Geräte-Versionen auch wirklich kompatibel ist und ausreichend genug getestet wurde, damit endlich Schluss ist mit so einer gefährlichen Firmen Politik.

Genau das ist der Grund, weshalb man endlich auf einen gemeinsamen Nenner kommen sollte!

Es gibt z.B. von uAvionix LP-ADSB (low-power ADS-B) Geräte, welche Flarm komplett ersetzen könnten. Das Zeug ist nicht sündhaft teuer, braucht auch nicht viel Strom, kann sogar von Gleitschirmpiloten am Körper getragen werden.

Es müsste "nur" noch die entsprechenden Anpassungen in den EASA Regulatorien geben, dann wäre das in meinen Augen eine win-win Situation für alle.

Die Technik ist da.

Wäre schön, wenn in diesem Zusammenhang auch mal programmiert wird, dass bei Speed kleiner 10 km/h innerhalb 1 Minute kein FLARM Signal mehr ausgesendet wird, um zu vermeideen, das man von am Boden liegenden mit FLARM ausgerüsteten Segelflugzeugen oder am Rollhalteort stehende Flugzeuge im Final gewarnt wird, weil die eher Null Gefahr bedeuten.

Gleitschirme bei Gegenwind stehen annähernd in der Luft und können unter die Schwelle fallen. Vermutlich ist das der Grund. ;-)

Dann sollte man halt statt einer Minute zwei Minuten nehmen und statt 10 km/h 5 km/h. Kann ja programmtechnisch eher nicht schwer sein. Würde die Akzeptanz bestimmt deutlich erhören bzw. die Ablenkung im Final. Ich hatte immer das FLARM in der Platzrunde "stumm" geschaltet, weil es "nervt". Mein TAS ist dagegen recht ruhig und meckert meist nur, wenn wirklich was "doof" nah kommt. Man könnte das ggf auch als Feature im Setup aufführen.

programmiert wird, dass bei Speed kleiner 10 km/h innerhalb 1 Minute kein FLARM Signal mehr ausgesendet wird

Wenn denke ich ist das eher eine Frage des Empfängers wie dort die Warnungen konfiguriert werden. Den Sender abschalten halte ich für keine so gute Idee. Siehe ADS-B. Alle haben solche schicken Transponder mit automatischem GND Modus und nun hat ATC aber Radar, um die Bodenbewegungen zu kontrollieren und schreibt in die AIP man solle den Transponder doch bitte unbedingt an machen...

Mein Konzept zu Verkehrswarnungen ist dass alle Daten immer fließen und dann erst das Endgerät intelligent entscheidet was es damit macht.

Wenn man an der Empfängerseite ansetzt könnte man für die Warnung z.B. unterschiedliche Geschwindigkeitschwellen je nach LFZ Typ programmieren. z.B. bei Flugzeugen nur oberhalb 20 kt warnen aber bei Glietschirmen schon ab 5kt etc...

Ein reiner Filter nach Geschwindigkeit würde dann auch z. B. mit Flarm ausgerüstete Drohnen im Hoverflug und Windräder (da gibt es auch welche mit Flarm) unterdrücken.

Deswegen 2 Minuten keiner /gleich 2 km/h Speed->Sender aus und mit dem Feature "TX-out-2 km/h yes/no" und alle sind glücklich.

Auf planecheck.com wird gerade ein (schlecht beschriebener) GTX330ES für 1.900€ angeboten.

Hat hier jemand neulich so einen verkauft oder gekauft? Bei einem Projekt könnte einer übrig bleiben.und ich wollte mal klären, was ein GTX330ES mit neuen Papieren eigentlich real wert wäre.

Ich habe einen in den USA gekauft, $1300 ohne Tray etc., denke das war günstig. Den Wert mit Tray und Papieren in Europa würde ich bei €1.500 - €2.000 sehen.

ich habe kürzlich einen für 1800 gekauft, überprüfung und Form 1 in Straubing ca. 180.

Kürzlich €1950 für einen GTX330ES mit Tray und Form 1 bezahlt

Falls jemand einen braucht und ein wenig Importformalitäten nicht scheut: Bei Beechtalk gerade für $1400 inkl. Tray, Backplate, Connectors. Form 1 wie erwähnt bei Straubing oder anderem Avionikbetrieb.

1800€ oder 1400$ plus tax würde ich akuell auch sehen.

"Leider" brauch das GTX330ES ein TSO zertifiziertes GPS, da es nicht kleiner wie SIL1 gestellt werden kann.
Da suche ich gerade noch nach einer schönen Lösung.