Login: 
Passwort: 
Neuanmeldung 
Passwort vergessen



Das neue Heft erscheint am 1. Mai
Eindrücke von der AERO 2025
Im Test: uAvionix AV-30 und tailBeaconX
Sky Pointer vs. Ground Pointer
Neue FAA-Regelung für Zertifikatsinhaber
Wartung und Mondpreise
Unfall: Abgelenkt und abgekippt
Engagierter Journalismus aus Sicht des eigenen Cockpits
Engagierter Journalismus aus Sicht des eigenen Cockpits
Sortieren nach:  Datum - neue zuerst |  Datum - alte zuerst |  Bewertung

6. Februar 2024: Von Tobi K. an Markus Stein

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.

6. Februar 2024: Von Lennart Mueller an Tobi K. Bewertung: +4.00 [4]

"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.

6. Februar 2024: Von Markus Stein an Lennart Mueller Bewertung: +1.00 [1]

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.

7. Februar 2024: Von Lennart Mueller an Markus Stein Bewertung: +4.00 [4]

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.

7. Februar 2024: Von Markus Stein an Lennart Mueller

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.

7. Februar 2024: Von Andreas Schlager an Markus Stein Bewertung: +2.00 [2]

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.

7. Februar 2024: Von Wolff E. an Andreas Schlager

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.

7. Februar 2024: Von Markus Stein an Wolff E.

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

7. Februar 2024: Von Wolff E. an Markus Stein Bewertung: +2.00 [2]

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.

7. Februar 2024: Von Sebastian G____ an Wolff E. Bewertung: +4.00 [4]

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...

7. Februar 2024: Von Guido Frey an Wolff E. Bewertung: +2.00 [2]

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.

8. Februar 2024: Von Wolff E. an Guido Frey Bewertung: +1.00 [1]

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.

23. Februar 2025 10:38 Uhr: Von Markus Stein an Markus Stein Bewertung: +1.00 [1]

Das Frühjahr steht nach dem langen Winter kurz vor der Tür und die Thermik Saison beginnt in Kürze. Hier ein interessanter Bericht eines beinahe Zusammenstoßes eines Motorflugzeuges mit einem Gleitschirm. Beide waren mit FLARM ausgestattet.


Hier ein Auszug aus dem Artikel mit meinen Hervorhebungen.

"Kollisionswarngeräte oder Software-Lösungen bzw. Applikationen mit ähnlichem Zweck existieren von verschiedenen Anbietern. Allen gemeinsam ist die Notwendigkeit einer fachmännischen Installation, deren regelmässige Aktualisierung sowie das Aufdatieren allfälliger Datenbanken, das Aktivieren von Optionen oder die Beschaffung nötiger Lizenzen, um die geforderten Funktionalitäten zur Erhöhung der Flugsicherheit zu gewährleisten und sich umgekehrt nicht in einer falschen Sicherheit zu wähnen. Im Rahmen der Untersuchung über die Kollision zwischen dem Motorflugzeug HB-KLB und dem Segelflugzeug HB-3412 vom 12. Juni 2021 westlich des Piz Neir, sprach die SUST daher zu diesem Thema den Sicherheitshinweis Nr. 56 aus (vgl. Schlussbericht Nr.2046)."

Beinahe-Kollision von Motorflugzeug und Gleitschirm

https://www.flieger.news/fastkollision-ueber-dem-gumen-oberhalb-braunwald-gl/


Hier der Link zum weiter oben erwähnten Schlussbericht Nr. 2046 der SUST mit einem Segelflugzeug.

https://www.sust.admin.ch/inhalte/AV-berichte/HB-KLB_HB-3412_SB_D.pdf#page16

24. Februar 2025 09:15 Uhr: Von Michael Söchtig an Markus Stein

Änderung der Update-Politik - FLARM

https://www.flarm.com/de/blog/aenderung-der-update-politik/

Immerhin wird ab jetzt auch ohne Update weiterhin die Anzeige sichergestellt.


14 Beiträge Seite 1 von 1

 

Home
Impressum
© 2004-2025 Airwork Press GmbH. Alle Rechte vorbehalten. Vervielfältigung nur mit Genehmigung der Airwork Press GmbH. Die Nutzung des Pilot und Flugzeug Internet-Forums unterliegt den allgemeinen Nutzungsbedingungen (hier). Es gelten unsere Datenschutzerklärung unsere Allgemeinen Geschäftsbedingungen (hier). Kartendaten: © OpenStreetMap-Mitwirkende, SRTM | Kartendarstellung: © OpenTopoMap (CC-BY-SA) Hub Version 14.28.22
Zur mobilen Ansicht wechseln
Seitenanfang