Herzlichen Dank für den Input! Ich würde das ganze auch lieber simpler halten, habe nur die Befürchtung, damit keinen Fuß in die Tür bei den ATC-Providern zu bekommen. Mein Gedanke war, über die Authentifizierung und Verschlüsselung dort den Wind aus den Segeln zu nehmen. Wenn die einfachere Variante auch akzeptiert wird, freue ich mich sehr!

Ich frage mich, was in diesem Bereich ein gangbarer Weg wird, um vernünftige Lösungen einzuführen? M. E. müsste dies beiden Seiten Vorteile bringen (Vereinfachung von Verfahren auf beiden Seiten). Dann könnte auch das Interesse an einer Einführung steigen. Momentan dringe ich aber bei der DFS überhaupt nicht vor. Ich erhalte noch nichtmal eine Ablehnung...

Korrekt, defacto brauchen wir eine neue (intakte) Seitenruderflosse, um den Aufwand zu reduzieren.

Danke für das Richtigstellen!

Cheers,

Olli

Danke hab mal drauf geschaut. Bezieht sich das auch für Telefonnummern eines Flugplatzes? In diesem Fall ist auf Openaip keine hinterlegt.

Ich würde das Problem mit Authentifizierung komplett weglassen. Seriously. Jeder kann beliebige Flugpläne aufgeben, ein ILS Sender ist extrem einfach zu bauen, gleiches gilt für ADS-B-Störsender, GPS Jamming, Drohnen, die vorprogrammierte Routen abfliegen, etc. Bis hin simply zu fake-Funksprüchen. Wenn man damit anfängt, muß man feststellen, dass die ganze Aviation extrem unsicher ist, aus rein technischer Sicht. Bis auf GPS Jamming ist das in der Praxis aber offenbar kein großes Problem (wahrscheinlich auch, weil man dafür in den Knast geht, wenn einen der Peilsender findet). Ist zwar ehrenwert, dem Problem nicht noch ein weiteres Problem danebenstellen zu wollen, aber über Verschlüsselung nachzudenken hier ist aus meiner Sicht der falsche Weg. PGP ist hier völlig am falschen Platz, insbesondere da GPG/PGP auch ganz andere Schwachstellen hat, die aber alle nicht technischer Natur sind.

Genau wie man mit einer einfachen Web-Registrierung digital Flugpläne aufgeben kann, muß es einfach nur ein simples API geben, über das man nach Registrierung einfach die Daten kriegt und bestätigen kann. Technisch gesehen ziemlich einfach überall zu integrieren. Ob man daraus dann ein Iridium/Starlink/5G/SMS/Telegram/ForeFlight/iOS-App/Autorouter/…-Gateway baut, ist weitestgehend trivial.

KISS. Keep it simple, Stupid.

@Markus: Berichtigungen bezüglich aeronautischer Daten bitte direkt in OpenAIP abgeben (https://www.openaip.net/). Dort kann man oben durch die Suche auf den Platz navigieren und dann auf "Request Change" klicken. Auf diese Art und Weise kommen die Verbesserungen nicht nur Airfield.Directory, sondern auch allen anderen OpenAIP-Nutzern zugute.

@Bernd: Ich kanns dir leider nicht sagen, ich hab mich mal kurz im Web eingeloggt, und deren Anleitung stimmt nicht, da gibts keinen "+ Custom connector" Button, oder ich hab ihn zumindestens nicht gefunden. De Facto mußt Du aber nur die MCP Server URL eingeben, https://airfield.directory/mcp ist korrekt. Ggf noch Streamable HTTP auswählen.

Aha. Dann war es wohl der Seitenflossenholm? Wenn der aus der Befestigung bricht, kann sich das Rumpfheck komplett spalten. Den ganzen Bereich hatte ich bei der RF 5 mal auseinander wegen Schraubentausch-LTA.

Hier eine kleine Rückschau von mehreren Ferry-Flügen, bei denen ich mitwirken durfte: https://www.pilotundflugzeug.de/img/red/issues/pf/2012-12/pdf/PF_Titel_2012-12.pdf

Ich war dort auch nur "fliegender Pilot", habe selbst keine Ferry-Aufträge angenommen oder ausgeführt.

Grundsätzlich gibt es dabei zwei Szenarien:

• Ferry wird zum Festpreis ausgeführt - hohes Risiko für den Ferry-Piloten und überscahubar für den Auftraggeber
  Problem: es wird möglichst kostengünstig geflogen, Wetter wird ggf. ignoriert (Übernachtungen in Grönland $$$) - Ruhezeiten, Rettungsmittel etc. werden minimiert
• Ferry wird zu vorher veranschlagten, aber nach Aufwand abzurechnenden Kosten ausgeführt - die Kalkulation für den Ferry ist unabhängig von Preisschwankungen, ggf. muss auch Mal die ein oder andere Übernachtung mehr mit abgerechnet werden
  Vorteil: der Ferry-Pilot hat nicht die "Pressure" die dritte teure Übernachtung auf eigene Kosten zu übernehmen, obwohl das Wetter auch am nächsten Tag genau so schlecht ist über dem Eiskap, ggf. muss ein Life-Raft als "Dangerous Good" zum Abflug-Flugplatz transportiert werden, wenn diese Kosten mit abgerechnet werden können, wird es wahrscheinlicher auch mitgenommen

Letztlich hängt alles natürlich auch vom Flugzeugmuster, der Strecke und dem Auftraggeber wie Aufragnehmer ab. Die "erfahrenen" Ferry-Leute werden sich da auf viel weniger Kompromisse einlassen, insbesondere wenn sie das Flugzeuge nicht kennen. Natrülich auch die Frage ob es ein Neu- oder nahezu-Neuflugzeug ist oder ein altes Schätzchen, nach dem vierten Avionik-Umbau, mit unzuverlässiger Fuel-Pump.

This looks like a remote custom connector issue with https://airfield.directory/mcp on the macOS desktop app.

Please try these quick checks first:

Confirm the MCP Server URL starts with https:// exactly as entered.
Remove and re-add the connector from a fresh app session.
If the connector uses OAuth or API key auth, re-authenticate after adding it.
If you control the MCP server, validate its MCP responses with the MCP Inspector tool, especially the tools/list JSON-RPC response. Perplexity expects a valid response with an id field and a tools array.

Hat wer geschafft den MCP-Server in Perpelxity zu verbinden?

Mit der SMS-Lösung für die PDC rennst Du bei mir offene Türen ein! Je günstiger, einfacher und etablierter eine Lösung ist, umso lieber ist mir das. Ich glaube nur nicht, damit bei einem ATC-Provider durch die Tür zu kommen. Wenn soetwas auf ATC-Seite akzeptiert würde, wäre ich mehr als zufrieden! Mein Gedanke war ein Standard, auf dem dann weitere Anwendungen aufsetzen können, aber vielleicht läuft das dann auch hierauf hinaus: https://xkcd.com/927/ ...;-))

Danke für die ausführliche Antwort. Ich bin weiterhin der anderen Meinung, dass das kein Problem der bestehenden Standards ist, sondern "nur" ihrer Anwendung. Deswegen finde ich einen weiteren Standard genau der falsche Weg.
Und wenn es nur um die PDC geht, dann ist Handy (vielleicht ganz modernistisch mit SMS/Whatapp ;-)) aus meiner Sicht die beste und bei vorhandenem Willen der DFS heute schon mögliche Lösung.

Aber man muss ja nicht immer einer Meinung sein!

Jepp, Du hast recht! Das waren F-16.

Geile Geschichte, dankeschön! (aber bist du sicher, dass es F-18 waren, nicht F-16? Das wäre für NORAD und diverse Reserveeinheiten reichlich ungewöhnlich bei der Luftraumsicherung. Ist aber natürlich nicht wichtig.)

Besten Dank für all Eure Antworten:

Wir haben bereits ein Angebot vorliegen und das Problem ist nicht, jemanden Wissenden/Könnenden zu finden, sondern schlicht, dass der Neuaufbau leider wirtschaftlich zu aufwändig ist. Man muss eine Helling anfertigen und mehrmals auf-/abrüsten, etc. Das frisst einfach Zeit (und somit Geld).

Daher der Versuch, über einen Bruch/Ersatzteil den Wiederaufbau abzukürzen.

Dennoch werde ich in Erwägung ziehen, bei den geliefertem Kontakten nachzufassen.

Besten Dank,

Oliver

"Ich kann leider immer noch nicht erkennen, welches Problem hier gelöst wird, ausser der Vermeidung von Angriffen durch gefälschte Nachrichten. War mir aber wie gesagt nicht bekannt, dass dies beim heutigen System ein Problem ist."

Bei den bisherigen Systemen besteht das Probem tatsächlich (noch) nicht. Das liegt m. E. an den bisherigen hohen Hürden der erforderlichen spezialisierten Hardware. Etwas anders sieht es z. B. im Bereich FANS aus. Dort werden die Nachrichten im Klartext übermittelt und könnten gezielt angegriffen werden, was m. E. nur noch eine Frage der Zeit ist. Von Seiten der DFS wurde bei Vorschlägen zu günstigeren Methoden immer diese Angreifbarkeit ins Feld geführt. Das wäre m. E. aber mit der vorgeschlagenen Systematik jedoch nicht der Fall.

Das grundsätzliche Ziel meiner Systematik ist, einen Standard zu schaffen, der eine sichere, günstige und authentifizierte Kommunikation zwischen ATC und Flugzeug ermöglicht. Diese sollte frei von Hardware-Beschränkungen sein, so dass einfache "off-the-shelf" Technik verwendet werden kann. Diese muss dann auch nicht mehr fest im Flugzeug verbaut sein. Damit entfällt die Zertifizierung zusammen mit dem Flugzeug. Das bereitet momentan nämlich Probleme: Die Lebensdauer von Flugzeugen übersteigt meistens die Lebensdauer anderer technischer Systeme. Ich kenne einen Operator, der gerade für viel Geld weltweit 3,5-Zoll-Disketten kauft, um seine FMS weiter mit Daten zu versorgen...

Wenn ein sinnvoller Kommunikationsstandard etabliert ist, entwickelt sich daraus evtl. auch ein entsprechendes "Öko-System". So könnten auch z. B, Maintenance-Daten in Echtzeit übermitttelt werden, Voranmeldungen für Handling, Zoll, Einreise etc. während des Fluges verschickt werden, ohne dass eine Authentifizierung für jeden Anwendungszweck erneut erforderlich ist.

Leider scheint der Trend jedoch gerade in die andere Hardware-basierte Richtung zu gehen: https://www.ldacs.com/

"Insbesondere kann ich nicht erkennen, wie das die Beschränkung auf bestimmte Übermittlungswege verbessert.
ATN B1 ist heute schon im Prinzip unabhängig von der Übertragungsschicht definiert. Dass im EASA-Raum praktisch nur VDL Mode 2 unterstütz wird, ist eine Entscheidung der EASA und keine technische Einschränkung.
Auch ATN/IPS ist ja schon stadardisiert - es fehlt "nur noch" an der Zulassungsvorschriften."

Mein klassisches Beispiel ist hier die Pre-Departure-Clearance. Diese kann ich elektronisch momentan nur per ACARS mit entsprechend zertifizierten Geräten abrufen. Die Kosten der Hardware übersteigen dabei den Zeitwert von so manchem GA-Flugzeug und die laufenden Kosten eines ACARS-Abos manches Avgas-Budget...

Hier wäre in meiner Systematik die Nutzung im Prinzip mit einem iPad möglich. Auch wäre es egal, ob die Übermittlung per ACARS, GSM, Starlink, GoGo oder Winktelegraphen erfolgt.

"Schliesslich die Frage der "Software- vs. Hardware-Implementierung".
Grundsätzlich gibt es in den CS-ACNS und erst Recht in den dahinter liegenden Standards wenig, was gegen eine SW-Implementierung sprechen würde."

Wenn diese Möglichkeiten auch genutzt werden, wunderbar! Allerdings scheint mir dies momentan kaum der Fall zu sein.

"Allerdinbgs gibt es einige aus meiner Sicht sehr sinvolle Anforderungen, die zumindest in der zertifizierten Luftfahrt nur mit zertifizierter Hardware lösbar sind.

Zum Beispiel: Was ist denn Deine Position zu der Anforderung aus den AMC zu ACNS.B.DLS

"When CPDLC messages are displayed:

(a) such location should be in the Primary Field of View.

...

(c) messages from the ATS should remain displayed until responded, cleared or the flight crew selects another message.

(d) means should be provided for the flight crew to clear uplinked messages from the display. However, this capability should be protected against inadvertent deletion."

Ist das nicht prizipiell im Sinne der Flugsicherheit sinnvoll? Wenn ja, wie stellt man das mit einer reinen SW-Lösung sicher?
Wie kann eine reine SW-Lösung dafür sorgen, dass das IPad nicht nur an ist, wenn ATC was vom Piloten will, sondern der Pilot auch sicher darauf aufmerksam wird.

Und ich glaube, hier das Kernthema zu erkennen: DLS/CPDLC ist darauf ausgelegt, eine echte Zweiwege-Kommunikation zwischen ATC und der Flightcrew zu sein und damit eine vollwertige Alternative für Sprechfunk. Das setzt voraus, dass nicht nur der Pilot jederzeit ATC kontaktieren kann, sondern auch ATC jederzeit den Piloten.
Dein Vorschlag scheint sehr stark auf das Thema "Der Pilot will was von ATC" fokussiert zu sein...

Diese Anforderungen halte ich grundsätzlich für sinnvoll für genau den Einsatzzweck "Zwei-Wege-Echtzeit-Kommunikation". Das ist allerdings m. E. der allerletzte Einführungsschritt. Ich halte eine Einführung z. B. über die PDC für sinnvoll. Hier kann ich ein solches System gut ohne das Risiko von verbogenem Blech ausprobieren. Wenn eine Nachricht nicht ankommt oder nicht bestätigt wird, wird eine von zwei Seiten aufmerksam. Ein zeitliches Risiko besteht nicht.

Wenn das ganze dann irgendwann Richtung CPDLC gehen sollte, so wäre z. B. auch eine Art AMoC möglich: Die Nachrichten könnten über eine AppleWatch o. ein ähnliches Device per Vibration signalisiert werden. Das erzeugt ebenfalls angemessene Aufmerksamkeit. Auch eine Verbindung zum Headset für ein Signalton für eine hereinkommende Nachricht wäre möglich. Insgesamt halte ich das für ein lösbares Problem, aber eher als einen Schritt für einen weit späteren Zeitpunkt.

Und nochmal: Glaube ich, damit den Stein der Weisen gefunden zu haben? Definitiv nein! Was ich aber sicher weiß: Wenn wir uns als Community keine Gedanken darum machen, was wir in Zukunft für Systeme haben wollen, dann werden es andere, mit evtl. ganz anderen Interessen, tun. Das wird dann für die GA nicht unbedingt günstiger oder besser...

Just my two cents...

Einmal durfte ich einen Ferry von USA nach Deutschland mit durchführen. Möchte ich nicht missen, war ein grandioses Erlebnis!

Aber: Der Moment, an dem die Öldruck-Warnlampe halfway zwischen Goose Bay und Narsasuaq anging, werde ich sicher auch nicht vergessen. War zum Glück aber nur eine Steckvebindung; weiß man halt in der Luft nicht. Zeitdruck war alleine deshalb schon da, weil der Flug im November stattfand und wir zwischen zwei Tiefdruckgebieten die vielleicht einzige Möglichkeit über Wochen genutzt haben. Start in Island morgens um 0735, Landung in Aschaffenburg um 1655 bei 8:45 h Blockzeit, weil noch ein Tankstop bei Andrew in Wick auf dem Plan stand. Dabei im Schneetreiben nachts noch eine Kaltfront überholt. Schönwetter-Fliegerei an die Nordsee-Inseln ist etwas anderes...

Trotzdem ein unheimlich schönes Abenteur! Alleine der Anflug auf Narsasuaq zwischen den Eisbergen, dieses leuchtende Blau des Wassers, Polarlichter zwischen Grönland und Island - das genieße ich auch fast 14 Jahre später noch!

Nachtrag zum Thema Pannen: Schon das erste Leg hatte es in sich, denn der Transponder übertrug nur bei 3.000 ft die Höhe korrekt, ansonsten irgendeinen Quatsch. War ein Avionik-Umbau und es wurde zufällig genau bei 3.000 ft gecheckt. Kann man sich echt nicht ausdenken... Beim Überflug vom Airport in Portland hatten wir real 12.000 ft, wurden aber in irgendwas um die 1.000 ft auf dem Radabildschirm angezeigt. Wie uns dann später von der FAA mitgeteilt wurde, standen zwei F-18 schon am Rollhalt. Hätte teuer und unangenehm werden können. Wie sich heraus stellte, war ein einziger Pin am Stecker vom Transponder verbogen.

Die Geschichte mit den 3 Stunden bei der Bordercontrol weil man meinte, mein Visa könnte falsch sein (was es nicht war) lass' ich mal als Panne weg, denn das hat mit dem Flug nur bedingt etwas zu tun. Obwohl, eigentlich war der Ferry schon der Auslöser des Problems.

Wartet nur bis hubert kommt...er schleppt alles..

... und Feuerstein ist aufgrund der Lage und der ansteigenden/abfallenden Piste ein toller Platz mit netten Piloten und Türmern an dem jeder VFR Pilot mal gewesen sein sollte! Am Rollhalt 1 zu stehen und dann einen Schleppzug am Taxiway starten zu sehen hat definitiv etwas besonderes :-)

Mir ist die Ironie durchaus bewusst. Gleichwohl kurze Zusammenfassung für Besucher, die noch nicht bei uns waren.

Südlich der Piste ist eine SAA/ Kunstflugbox bis 6.000 ft AMSL. Wer die von Süd nach Nord durchqueren möchte, bitte vorher beim Betriebsleiter/ BfLA nachfragen, ob die aktiv ist. (steht leider nicht in der AIP). Oder einfach außen herum.

Anflug Piste 08, Endteil. Hier bitte ab mittlerem bis starker Ostwindkomponente mögliches Lee einkalkulieren. Hier kann sich ein Rotor ausbilden, der einen ca in der ersten Hälfte bzw. Mitte des Endanfluges erst anhebt und kurz danach vor der Hangkante absacken lässt. Die Strasse vor der Piste bitte noch mit 15m Höhe überfliegen. Die Piste ist für die meisten lange genug, man muss da nicht an der Schwelle 08 aufsetzen. (Fränkisch: Wers ko, der derf).

Abflug Piste 26: Bitte alsbald möglich nach dem Abheben ca 30° nach Nordwesten abdrehen. Die Ortschaft in der verlängerten Centerline wg. Lärmschutz bitte meiden (steht in der AIP).

Am Feuerstein starten Schleppzüge (mit Genehmigung) vom Rollweg. Wenn der Betriebsleiter (Von 10:00 bis 18:00 LT ist ein BfLA) darum bittet, nach der Landung auf der Piste oder vor dem Start am Rollhalt 1 zu warten, bitte am Funk keine Diskussionen über Rechte und Pflichten. Die Kollegen im Segelflugzeug haben i.d.R. keinen Ventilator. Danke.

Und PS: Die Piste hat in der Mitte einen ziemlichen Buckel. Dort ist die Halbbahnmarkierung. Die Piste geht dahinter weiter ;)

Ich bin neulich über 2 Folgen in youtube ("on the move") über das gefährliche Dasein von ferry-Piloten gestolpert.

Die beiden Episoden berichten die Storiese beim Transfer von Flugzeugen von schief nach schräg.

Dabei entsteht der Eindruck:

- super gefährlich

- ständig geht alles kaputt und bringt ale beteiligten fast um

- hoher Zeitdruck und Kostendruck.

Dabei entstand der Eindruck, dass die ferry-Piloten die Kosten für inspektionen und außerordentliche reparaturen von den Ferry-Piloten oder deren Firmen getragen werden.

Ist das tatsächlich so?

Es gibt noch einen anderen youtube-kanal "Nomadic Airways". Das läuft ähnlich und ist ein bisschen langweilig. Viel blabla,viele Stunden, hoher zeitdruck und viel Filmen in Hotelzimmern und resturants. Aber eigentlich immer ohne Pannen.

Möglicherweise haben diverse Eingaben bei der EASA und EU Kommission etwas vorteilhaftes im Verhalten bei dem Luftfahrtbundesamt gebracht?!

Wir hatten in der Vergangenheit nicht immer Glück mit Mitarbeitern dieser Behörde, die meinten, dass sie besser wüssten wie Flugsicherheit geht, als z.B. die EASA.

Vielleicht wäre es ja auch eine Chance, einen Präsidenten zu haben, der sich darauf beschränkt, die entsprechenden Vorschriften effizient und bürgerorientiert umzusetzen und sie nicht zu verschlimmbessern.

Ich kann leider immer noch nicht erkennen, welches Problem hier gelöst wird, ausser der Vermeidung von Angriffen durch gefälschte Nachrichten. War mir aber wie gesagt nicht bekannt, dass dies beim heutigen System ein Problem ist.

Insbesondere kann ich nicht erkennen, wie das die Beschränkung auf bestimmte Übermittlungswege verbessert.
ATN B1 ist heute schon im Prinzip unabhängig von der Übertragungsschicht definiert. Dass im EASA-Raum praktisch nur VDL Mode 2 unterstütz wird, ist eine Entscheidung der EASA und keine technische Einschränkung.
Auch ATN/IPS ist ja schon stadardisiert - es fehlt "nur noch" an der Zulassungsvorschriften.

Schliesslich die Frage der "Software- vs. Hardware-Implementierung".
Grundsätzlich gibt es in den CS-ACNS und erst Recht in den dahinter liegenden Standards wenig, was gegen eine SW-Implementierung sprechen würde. Allerdinbgs gibt es einige aus meiner Sicht sehr sinvolle Anforderungen, die zumindest in der zertifizierten Luftfahrt nur mit zertifizierter Hardware lösbar sind.
Zum Beispiel: Was ist denn Deine Position zu der Anforderung aus den AMC zu ACNS.B.DLS

"When CPDLC messages are displayed:

(a) such location should be in the Primary Field of View.

...

(c) messages from the ATS should remain displayed until responded, cleared or the flight crew selects another message.

(d) means should be provided for the flight crew to clear uplinked messages from the display. However, this capability should be protected against inadvertent deletion."

Ist das nicht prizipiell im Sinne der Flugsicherheit sinnvoll? Wenn ja, wie stellt man das mit einer reinen SW-Lösung sicher?
Wie kann eine reine SW-Lösung dafür sorgen, dass das IPad nicht nur an ist, wenn ATC was vom Piloten will, sondern der Pilot auch sicher darauf aufmerksam wird.

Und ich glaube, hier das Kernthema zu erkennen: DLS/CPDLC ist darauf ausgelegt, eine echte Zweiwege-Kommunikation zwischen ATC und der Flightcrew zu sein und damit eine vollwertige Alternative für Sprechfunk. Das setzt voraus, dass nicht nur der Pilot jederzeit ATC kontaktieren kann, sondern auch ATC jederzeit den Piloten.
Dein Vorschlag scheint sehr stark auf das Thema "Der Pilot will was von ATC" fokussiert zu sein...

Ich habe das Whitepaper mal angehängt. Mir ging es darum, bei der Datenkommunikation etwas unabhängiger von proprietärer und zertifizierter Hardware zu werden. Bisher basiert CPDLC hauptsächlich auf einer Authentifzierung per Hardware und einem festgelegten Übermittlungsweg. Alle anderen Wege wurden meist von Seiten ATC mit dem Totschlagargument der Angreifbarkeit der Kommunikation und der nicht erfolgten Zertifizierung belegt. Das nutzt hauptsächlich Hardware-Herstellern, die dann für entsprechende Kleinserien astronomische Preise aufrufen, was die Verbreitung in der GA meist auch gering hält.

Hier war mein Gedanke, eine standardisierte und softwarebasierte Kommunikationsmöglichkeit zu schaffen, die dementsprechend unabhägig von (teurer) Hardware und festgelegten (teuren) Übertragungswegen ist.

Mit Sicherheit ist das nicht der Stein der Weisen, der in jedem Anwendungsfall anderen Techniken überlegen ist. Allerdings hätte ich es interessant gefunden, das mal mit der DFS zu diskutieren, ggfls. zu optimieren oder bei Nichtgefallen wieder in der Tonne verschwinden zu lassen... Aber es wurde bisher noch nicht mal diskutiert.

Zur PDC per App bei VFR/IFR-Wechseln: Klar ist die telefonische Lösung sehr einfach umsetzbar. Dies wird bisher von der DFS nur für die Bundespolizei vorgehalten und für alle anderen auf Grund von Personalmangel abgelehnt. Hier war die Überlegung, dies per App zu optimieren, so dass im Idealfall ein Lotse nur noch auf eine Art "Release-Button" drückt und die Clearance automatisch versandt wird.

Ein weiterer Gedanke war, die Systematik auf weitere Bereiche anzupassen. So könnte z. B. ein tief fliegender VFR-Pilot in einem Tal ohne Radar- und Funk-Abdeckung einen standardisierten Hilferuf über solch ein System per GSM oder Starlink versenden, der direkt beim zuständigen FIS-Lotsen aufschlägt. Ein Frequenz-An- und Abmeldung bei FIS könnte darüber erfolgen.

Da die Übertragungswege nicht festgelegt sind, könnte auch eine Art "Netzwerkrelay" erfolgen: Ein Datenburst, der auf einer frei zugänglichen Frequenz ausgesandt wird, kann von anderen Flugzeugen weitergeleitet werden. Das könnte für den Drohnenbetrieb evtl. hilfreich sein bei kleinen Sendeleistungen.

Ich bin allerdings weder Programmierer noch Lotse. Insofern lasse ich mich da von Praktikern gerne belehren.

Fantastische Erfahrungen gerade wieder mit dem Referat L4 gemacht für den Sprach-Eintrag Englisch. Die hatte ich vor einer Woche versucht, telefonisch morgens um 8:30 Uhr zu erreichen, sie rief mich dann sogar 20 Minuten später zurück mit der Nachfrage, ich hätte angerufen!! Hatte dann doch schon das richtige Formular online rausgesucht, es ging alles innerhalb von einer Woche, neue Lizenz im Briefkasten mit den aktuellen Daten . Perfekter Service und ich habe noch nie in 15 Jahren beim LBA schlechte Erfahrung gemacht, es ging alles sehr rund und schnell z, B. IFR Lizenz, Validierung in die USA, Ummeldungen von Flugzeugen etc. Ich gehöre wohl zu der zufriedenen Fraktion mit dem LBA!

Diskussion zum Nutzen hier: https://www.pilotundflugzeug.de/forum/2026,07,28,12,1955196