Beiträge von Biting Bee

Bugfix: Altimeter

Der Fehler wurde durch ein falsch interpretiertes Vorzeichen verursacht. Falcon übermittelt die barometrische Höhe aufgrund seiner internen Achsenkonvention als negativen Wert, während unsere Anzeige einen positiven Wert erwartet.

Dadurch wurde die eigentlich korrekte Höhenangabe verworfen und stattdessen ein ungenauer Ersatzwert angezeigt. Der Fix dreht das Vorzeichen nun korrekt um.

Hinweis zur LED-Steuerung

Die LEDs lassen sich entweder im Testbetrieb schalten oder im Produktivbetrieb, wenn du unten das entsprechende Kontrollkästchen „LEDs“ aktivierst.

Neues Feature: MFDs

Die MFDs sind jetzt vollständig implementiert und können per Drag-and-drop frei positioniert sowie über eine Skalierungsfunktion in der Größe angepasst werden. Eine manuelle Eingabe von Koordinaten ist nicht mehr erforderlich.

Wenn du bereits eine einigermaßen aktuelle Version installiert hast, sollte dich die Software automatisch darauf hinweisen, dass ein Update verfügbar ist.

Zusätzlich besitzt die Software jetzt eine eigene Render-Engine. Dadurch sollten sämtliche Anzeigen in Echtzeit mit einem Aktualisierungsintervall von etwa 10 ms dargestellt werden.

Vielen Dank fürs Testen!

Genau solche Rückmeldungen helfen mir wirklich dabei, Fehler zu finden und die Software weiter zu verbessern. 🙂


Nur zur Kenntnisnahme ich habe heute in Dx9 Dx11 sowie in WPF eine Renderengine gebastelt es kam den ganzen Tag zu Fehlern der MFD Laggs und Einbrüchen
Mozilla Firefox war der Auslöser sobald dieser Browser läuft laggt mein Falcon aber lustigerweise nicht immer. Ein Mist so einen Fehler zu finden.
Problem behoben Mozilla beim Fliegen zu und Renderprobleme und Laggs beheb ich jetzt mit Win + STRG + Umschalt + B (Im Livebetrieb de Grafikkartentreiber neu Laden)
Das wirkt Wunder

Die Auffäigkeiten schau ich mir umgehend an!
Ich mach gerade das MFD fertig erste Test liefen super damit hat dieses Config - rumgeschreibe endlich ein Ende.
Meine MFDs haben einen eigenen Renderer da muss man keinen Client mehr starteten nur RTT aktivieren das war es.
Mein Live Monitor starten dann kann man die einfach per Drag and Drop hin und her schieben mit Positionsspeicher natürlich

Besten Dank!

Guten Morgen,

Offiziell nun hier komplett zum Download bereit:
Da es eine ksotenlose Software ist und sich keine Sau ein Zertifikat von Microsoft Leisten kann

Frei einstellbare FPS

Zur Leistungsoptimierung und Anpassung an den jeweiligen Rechner kann zwischen folgenden Bildraten gewählt werden:

• 30 FPS
• 60 FPS
• 80 FPS
• 90 FPS
• 100 FPS
• 120 FPS

Ein kleiner Cockpit-PC kann bewusst mit 30 oder 60 FPS betrieben werden.

Ein leistungsfähiger Rechner mit schnellem Monitor darf dagegen bis zu 120 FPS zeichnen.

Die Einstellung bestimmt das maximale Zeichentempo der kontinuierlichen Instrumente.

Lampen und Statuszustände bleiben ereignisgesteuert.

Eine höhere Bildrate erzeugt allerdings nicht automatisch mehr neue Falcon-Daten. Der zentrale Telemetriedatenweg arbeitet mit rund 100 Hz.

Bei 120 FPS kann die Oberfläche zwar häufiger gezeichnet werden, erhält dadurch jedoch nicht automatisch 120 unterschiedliche Falcon-Datensätze.

Die tatsächliche MFD-Bildrate hängt außerdem vom Falcon-RTT-Export und der Simulatorleistung ab.

Jeder Anwender kann damit zwischen möglichst geringer Systemauslastung und besonders flüssiger Darstellung wählen.

Vorbereitung für physische Cockpithardware

Die Netzwerkarchitektur bildet gleichzeitig die Grundlage für meine physische Cockpithardware:

Ein späterer ESP32 oder Arduino muss dadurch nicht selbst auf das Falcon Shared Memory zugreifen.

Er erhält lediglich die bereits gefilterten und aufbereiteten Signale, die er tatsächlich benötigt.

Die direkte Ausgabe an Mikrocontroller bleibt ein eigenständiges Hardwaremodul.

Server, Netzwerkprotokoll, Modulfilterung und Empfangsclient sind als Grundlage bereits vorhanden.

Ist mein Client schneller als die BMS-Tools?

Ob mein Client grundsätzlich schneller als jedes mit Falcon BMS gelieferte Werkzeug ist, kann ich ohne direkten Vergleichstest nicht seriös behaupten – auch wenn ich dazu neige zu sagen: ja, um Welten!

Die Software wurde jedoch konsequent für meinen Anwendungsfall optimiert:

• Shared Memory wird mit rund 100 Hz gelesen.
• Grafische Anzeigen laufen mit bis zu 120 FPS.
• Der LAN-Datenstrom überträgt maximal 120 Datenbilder pro Sekunde.
• Lampen und Statusanzeigen werden ereignisgesteuert aktualisiert.
• Unsichtbare Anzeigen verursachen keine unnötige Zeichenarbeit.
• Der Produktivmodus kann die lokale Oberfläche gezielt ruhigstellen.
• Nur ausgewählte Netzwerkmodule werden übertragen.
• Alle Anzeigen verwenden eine zentrale Falcon-Verbindung.
• Langsame Empfänger erzeugen keinen Rückstau alter Datenbilder.

Später werden die originalen F-16-Grafiken über die Instrumente gelegt.

Über das Netzwerk müssen keine fertigen Grafiken, sondern nur die reinen Rohwerte übertragen werden – schneller und schlanker geht es kaum.

Der größte Leistungsgewinn ist bereits bewiesen

Ein entscheidender Vorteil steht schon heute fest:

Zitat

Ich benötige auf dem Falcon-PC nicht mehr fünf verschiedene Programme, nur um drei Dinge im Cockpit anzuzeigen.

Für den normalen Betrieb gilt:

Zitat

Einmal Falcon BMS und einmal mein BMS Live Monitor – nicht mehr und nicht weniger.

Der Live Monitor übernimmt zentral das Einlesen der Falcon-Daten, Instrumente, DED, PFL, RWR, MFD, Cockpit-LEDs, Funk- und IVC-Überwachung, Test- und Produktivbetrieb, Netzwerkverteilung sowie Diagnose und Verbindungsüberwachung.

Alle Cockpitdaten werden nur einmal eingelesen, einheitlich verarbeitet und an die benötigten Anzeigen verteilt.

Optionale Display-Clients benötigen keine eigene Verbindung zu Falcon BMS.

Das bedeutet:

• weniger Programme und parallele Prozesse
• weniger Konfigurationsaufwand
• weniger mögliche Fehlerquellen
• eine zentrale und nachvollziehbare Datenkette

Mein bisher bestes Falcon-Projekt

Der BMS Live Monitor ist längst kein einfacher Live Viewer mehr, sondern meine zentrale Verwaltungs-, Anzeige- und Netzwerkplattform für das vollständige F-16-Cockpit.

Diesmal habe ich zuerst geplant, die Architektur durchdacht, Verantwortlichkeiten getrennt und erst danach mit der Umsetzung begonnen.

Genau deshalb ist dieses Projekt für mich hundert Prozent besser als alles, was ich zuvor für Falcon BMS entwickelt habe.

Der Softreset ermöglicht es außerdem, die Daten bei Bedarf auch während des Flugbetriebs mit nur einem Klick neu zu synchronisieren, ohne Falcon verlassen zu müssen.

Notwendig war das bislang zwar noch nicht, aber sicher ist sicher!

Hat jemand Lust, die Software zu testen?

Für den normalen BMS-Nutzer ist der praktische Mehrwert derzeit zwar noch begrenzt:

Man kann sämtliche Daten anzeigen lassen, sie zunächst aber hauptsächlich beobachten und auswerten.

Das Ansteuerungsmodul „Controller-distri“ habe ich bewusst entkoppelt.

Es steht vorerst nur mir zur Verfügung – ohne den dazugehörigen Mikrocontroller würde es euch ohnehin nichts bringen.

Für mich wären vor allem folgende Testergebnisse interessant:

• Single-Version: Stabilität des IVC-Connectors im Onlinebetrieb und Echtzeitdarstellung der Instrumentenbretter – gibt es Verzögerungen oder Ruckler?
• Server-Version: Läuft der Display-Client stabil? Optisch ist er zunächst nur ein Werkzeug zur Darstellung auf einem entfernten Rechner.

Warum ist die Software so umfangreich?

Weil sie nicht nur Falcon BMS unterstützen soll.

Eine getrennte Schnittstelle für DCS ist ebenfalls vorhanden, aber noch nicht fertiggestellt.

Außerdem ist eine Schüler-Lehrer-Übertragung vorgesehen – technisch ist sie bereits vorhanden, konzeptionell muss ich sie jedoch noch zu Ende durchdenken.

Damit könnte ein Ausbilder – schiel zu Bumi – live sehen, was sein Flugschüler gerade im Cockpit treibt.

Aber nun genug dazu!

Vielleicht möchte der eine oder andere einfach einmal einen Blick darauf werfen.

Aktuell habe ich keinen freien Webspace zur Verfügung.

Bei Interesse schreibt mich einfach an; ich stelle die Software dann über OneDrive oder Google Drive bereit.

Die bebilderte Anleitung weicht an einigen Stellen noch leicht von der aktuellen Version ab und wird in den nächsten Tagen angepasst.

Die Einrichtung sollte aber auch ohne Anleitung weitgehend selbsterklärend sein.

Vielen Dank im Voraus für euer Feedback!

Funk und IVC sind direkt integriert

Funk und IVC sind keine geplanten Funktionen, sondern bereits direkt und stabil in den Client eingebaut.

Der BMS Live Monitor verbindet sich mit den von Falcon BMS und IVC bereitgestellten RCC- und RCS-Shared-Memory-Bereichen.

In der Funkgeräte-Ansicht kann ich unter anderem überwachen:

• Funkgerät 1 mit UHF und COM1
• Funkgerät 2 mit VHF und COM2
• aktive UHF- und VHF-Frequenzen
• über ICP und DED gewählte Cockpitfrequenzen
• UHF Guard und Backup-UHF
• Ein-/Ausschaltzustände und PTT
• Empfangslautstärken
• Status des IVC-Clients und der Serververbindung
• mögliche IVC-Verbindungsfehler

Der Client unterscheidet klar zwischen Funkgeräten und IVC.

UHF und VHF liefern die Cockpit- und Funkdaten; IVC übernimmt als separater Sprachclient die Sprachübertragung.

Passwörter und andere sensible IVC-Daten werden bewusst nicht ausgelesen.

Wird Falcon neu gestartet, werden nur dessen Verbindungen zurückgesetzt. Die separat laufende IVC-Verbindung wird nicht unnötig getrennt.

Test- und Produktivmodus

Im Testmodus liefern alle Registerkarten vollständiges optisches Live-Feedback.

Instrumente, Cockpit-LEDs, DED, PFL, RWR, Funkgeräte, CMDS, ECM und Diagnosedaten bleiben sichtbar und aktiv.

Diesen Modus nutze ich für Entwicklung, Skalierung, Datenzuordnung, Fehlersuche sowie Netzwerk- und Clienttests.

Der Testmodus erzeugt keine künstlichen Falcon-Daten, sondern zeigt die tatsächlich vorhandenen Live-Daten mit vollständiger lokaler Oberfläche an.

Im Produktivmodus werden Falcon- und IVC-Daten weiterhin vollständig eingelesen und die ausgewählten Module an den LAN-Server gesendet.

Die aufwendigen lokalen Anzeigen bleiben jedoch standardmäßig ruhig.

Bei Bedarf kann ich einzelne Bereiche gezielt freischalten – etwa das Instrumentenbrett, analoge Instrumente, Cockpit-LEDs, DED/PFL, RWR, Funkgeräte oder ECM.

So arbeitet der Hauptclient im Cockpitbetrieb als schlanke Datenzentrale, während die Instrumente auf den vorgesehenen Netzwerkmonitoren laufen.

Produktiver LAN-Server

Der BMS Live Monitor besitzt einen vollständig integrierten LAN-Server.

Der Hauptrechner dient als zentrale Datenquelle; standardmäßig verwendet der Server Port 43860/TCP.

Die Verbindung arbeitet mit einem dauerhaften TCP-Datenstrom, NoDelay, Keepalive und bis zu 120 Datenbildern pro Sekunde.

Im Netzwerkbereich sehe ich direkt:

• Serverstatus und verwendeten TCP-Port
• lokale IPv4-Adressen
• Anzahl der verbundenen Clients
• gesendete Datenbilder und übertragene Datenmenge
• Zeitpunkt der letzten Übertragung
• mögliche Netzwerkfehler

Mehrere Display-Clients können gleichzeitig verbunden werden.

Für jeden Client wird nur das aktuellste Datenbild vorgehalten. Ein langsamer Empfänger erzeugt daher keinen wachsenden Rückstau aus veralteten Instrumentendaten.

Der Datenstrom ist für mein vertrauenswürdiges Cockpit- und Heimnetz vorgesehen und wird nicht als öffentlicher Internetdienst betrieben.

Gezielte Auswahl der Netzwerkdaten

Direkt im Hauptprogramm kann ich festlegen, welche Datenbereiche übertragen werden:

• Live- und Digitaldaten
• Instrumentenbrett und analoge Instrumente
• Cockpit-LEDs und Systembits
• DED und PFL
• RWR
• Funkgeräte und IVC-Zustände
• CMDS
• ECM

Nur ausgewählte Module werden in das Netzwerkpaket geschrieben.

Ein Instrumentenrechner muss beispielsweise keine Funk-, RWR- oder ECM-Daten erhalten, wenn er sie nicht benötigt.

Die lokale Darstellung bleibt davon unabhängig.

Vollständiger BMS Cockpit Display Client

Neben dem Hauptprogramm existiert ein eigener Display-Client.

Dieser greift nicht selbst auf das Falcon Shared Memory zu, sondern verbindet sich ausschließlich über das LAN mit dem BMS Live Monitor auf dem Falcon-PC.

Dadurch kann ich Anzeigen auf einem zweiten Rechner darstellen, ohne dort Falcon BMS oder zusätzliche Shared-Memory-Werkzeuge installieren zu müssen.

Für jedes auf dem Server freigegebene Datenmodul besitzt der Client eine eigene Registerkarte.

Ein abgeschaltetes Modul wird deutlich als deaktiviert gekennzeichnet. Alle freigegebenen Module laufen unabhängig von der momentan sichtbaren Registerkarte weiter.

Der Display-Client bietet außerdem:

• frei wählbare Serveradresse und TCP-Port
• Testverbindung über 127.0.0.1
• Verbindung zu weiteren Rechnern über die IPv4-Adresse des Falcon-PCs
• automatische Neuverbindung nach einer Unterbrechung
• Anzeige der übertragenen Module
• empfangene Datenbilder, Datenmenge und Paketnummer
• gemessene LAN-Latenz
• skalierbare Fenster
• rahmenloses Vollbild mit F11 und Rückkehr mit Esc

Die Verbindung zwischen Hauptprogramm und Display-Client wurde bereits praktisch mit laufender Daten- und Instrumentenübertragung geprüft.

Mein eigener F-16-Cockpit-Server-Client für Falcon BMS – Teil 1/3

Achtung, viel Text – aber für Cockpitbauer sicherlich ein interessantes Thema!

Eine zentrale Verwaltungs-, Anzeige- und Netzwerkplattform für mein vollständiges F-16-Cockpit

Wer mich schon länger kennt, weiß, dass ich bereits einiges für Falcon BMS entwickelt habe. Dabei sind durchaus interessante Programme entstanden.

Rückblickend waren viele davon jedoch fehleranfällig, nur halb durchdacht oder nie wirklich konsequent zu Ende gebaut.

Oft habe ich einfach mit dem Programmieren begonnen, ohne vorher die vollständige Architektur festzulegen.

Irgendwann hatte ich mich so tief in meinem eigenen Code verlaufen, dass selbst für mich kaum noch nachvollziehbar war, welcher Teil eigentlich wofür verantwortlich war.

Neue Funktionen verursachten an anderer Stelle Probleme, Datenwege waren nicht sauber getrennt und der Code wurde immer schwieriger zu pflegen.

Bei diesem Projekt bin ich bewusst einen anderen Weg gegangen:

Zitat

Erst planen, gründlich durchdenken und anschließend gezielt umsetzen.

Falcon-Telemetrie, Instrumentendarstellung, Funk und IVC, Netzwerkübertragung, Testbetrieb, Produktivbetrieb und die spätere Hardwareausgabe besitzen jeweils einen eigenen, klar definierten Bereich.

Auch Verbindungsabbrüche, Missionswechsel, Falcon-Neustarts, unterschiedliche Aktualisierungswege und langsame Netzwerkempfänger wurden bereits bei der Architektur berücksichtigt.

Das Ergebnis ist für mich persönlich hundert Prozent besser als alles, was ich bisher für Falcon BMS gebaut habe.

Warum ich einen eigenen Server/Client entwicklet habe?

Für Cockpitanzeigen gibt es bereits Lösungen wie Helios.

Helios bietet viele Möglichkeiten, ist für meinen speziellen Anwendungsfall jedoch zu leistungshungrig und beim Aufbau der Profile und Schnittstellen zu komplex.

Mein Cockpit ist ausschließlich auf die F-16 ausgelegt. Ich benötige daher keine Universalplattform für zahlreiche Simulatoren und Flugzeugtypen.

Auch Falcon BMS bringt verschiedene Tools und Exportmöglichkeiten für Instrumente, Displays und Shared-Memory-Daten mit.

Diese lösen jedoch meistens nur einzelne Teilaufgaben: Ein Tool stellt Instrumente dar, ein anderes kümmert sich um Displays und ein weiteres wird für Diagnose oder Datenexport benötigt.

Dadurch müssen mehrere unabhängige Programme gleichzeitig gestartet, konfiguriert und überwacht werden.

Genau dieses Problem löse ich mit meinem eigenen Server/Client.
Alles aus einer Hand

Der eigentliche Kracher ist für mich, dass ich für die komplette Verwaltung meines Cockpits nur noch eine zentrale Anwendung benötige.

Instrumente, Displays, Warnleuchten, Funkgeräte, IVC-Status, Test- und Produktivbetrieb sowie die Netzwerkverteilung werden in einem gemeinsamen System zusammengeführt.

Der zentrale Datenweg lautet:

Der BMS Live Monitor liest die benötigten Daten einmal zentral ein, bereitet sie auf und verteilt sie anschließend an die verschiedenen Anzeigen und Netzwerkempfänger.

Dadurch muss nicht jedes Instrument und nicht jeder angeschlossene Rechner selbst auf das Falcon Shared Memory zugreifen.

Es laufen keine verschiedenen Cockpitprogramme mehr nebeneinander, die dieselben Daten unabhängig voneinander einlesen.

Falcon BMS und der IVC-Sprachclient bleiben natürlich eigenständige Programme.

Für Anzeige, Aufbereitung, Diagnose und Verteilung meiner Cockpitdaten benötige ich jedoch nur noch den BMS Live Monitor.

In einer Anwendung kann ich kontrollieren:

• ob Falcon BMS läuft und ein aktiver 3D-Flug erkannt wurde
• ob Falcon pausiert oder eingefroren ist
• ob IVC läuft und mit dem Server verbunden ist
• welche Funkfrequenzen aktiv sind
• ob Instrumente aktuelle Daten erhalten
• ob der LAN-Server läuft und wie viele Clients verbunden sind
• welche Datenmodule übertragen werden
• wie viele Datenbilder und Bytes gesendet wurden
• wann die letzte Übertragung stattgefunden hat

Direkter Falcon-BMS-Datenweg

Der BMS Live Monitor wurde ausdrücklich für Falcon BMS 4.38 und die F-16 entwickelt.

Die Telemetrie wird direkt aus den Windows-Shared-Memory-Bereichen von Falcon BMS gelesen.

Der zentrale Scanner arbeitet mit rund 100 Hz und kommt ohne normalen WinForms-Timer aus.

Kontinuierliche grafische Anzeigen laufen mit bis zu 120 FPS. Zahlenwerte besitzen einen getrennten Aktualisierungsweg.

Lampen, DED, PFL, RWR und andere Zustände werden ereignisgesteuert aktualisiert. Verändert sich beispielsweise nur eine Kontrollleuchte, muss nicht die gesamte Oberfläche neu aufgebaut werden.

Die Software prüft außerdem, ob tatsächlich ein Falcon-Prozess läuft. Ein veralteter Shared-Memory-Bereich wird nicht fälschlicherweise als aktive Verbindung behandelt.

Wird Falcon beendet oder neu gestartet, gibt der Client die zugehörigen Verbindungen einschließlich der RTT-Textur frei und verbindet sich anschließend frisch mit dem neuen Prozess.

Alte Instrumenten- oder MFD-Daten werden nicht unbemerkt weiterverwendet.

F-16-Instrumente und Anzeigen

Der Client deckt alle für mein F-16-Cockpit relevanten Instrumente, Daten und Kontrollanzeigen ab.

Dazu gehören unter anderem:

• das große F-16-Instrumentenbrett
• ADI, HSI, Höhenmesser, Fahrtmesser, Variometer und AOA
• Triebwerks- und Kraftstoffinstrumente
• Fuel Flow, Fuel Total, RPM, FTIT und Nozzle Position
• Öl- und Hydraulikdruck, EPU-Kraftstoff und Kabinendruck
• Kompass und Speedbrake
• das rechte MFD über den RTT-Textur-Export
• DED und PFL mit jeweils fünf vollständigen Zeilen
• positionsgenau invertierte DED- und PFL-Zeichen
• RWR-Rundanzeige mit bis zu 40 Kontakten
• Peilungen, Bedrohungsstufen, Missile Activity und Missile Launch
• Threat Warning Prime Panel und ALR-56M-Selbsttest
• AOA-Indexer, AR/NWS-Indexer und Caution Panel
• 93 grafische Cockpit-Statusfelder
• Fahrwerksstatus und einzelne Fahrwerksverriegelungen
• CMDS/EWS mit Chaff, Flare, Betriebsarten und Statusanzeigen
• fünf ECM-Programme und ECM-Betriebszustand
• Power-, Blink-, Misc- und Betty-Bitfelder
• Diagnosewerte wie Leserate, Lesezeit und UI-Latenz

Geometrie, Beschriftung, Skalierung, Zustände und Datenquellen sind ausdrücklich auf die F-16 zugeschnitten.

Herauslösbares Instrumentenfenster

Das große Instrumentenbrett kann aus dem Hauptfenster herausgelöst, frei verschoben, skaliert und auf einem beliebigen Cockpit-Monitor platziert werden.

Es bleibt auch dann aktiv, wenn ich im Hauptprogramm die Registerkarte wechsle.

Mit F11 lässt es sich auf dem aktuellen Bildschirm rahmenlos im Vollbild darstellen. Mit Esc geht es zurück in den Fenstermodus.

Das herausgelöste Fenster benötigt keine zweite Verbindung zu Falcon BMS, sondern wird weiterhin von derselben zentralen Datenquelle versorgt.

Zusätzlich kann der LAN-Display-Client auf weiteren Bildschirmen oder Rechnern ausgeführt werden.

Ich denke schon, dass ich damit ein paar Platzrunden drehen werde. 😄

Ein Verkauf steht für mich allerdings nicht zur Debatte.
Wenn ich die investierte Zeit, Kraft, Nerven, Arbeitsleistung und natürlich auch die finanziellen Aufwendungen und Fehlkäufe, Testprodukte und ständigen Probierkäufe von Materialien, Maschinen und alles zusammenrechne, liegt der tatsächliche Wert inzwischen weit über 20.000 Euro. Für einen Käufer würde das in keinem vernünftigen Verhältnis stehen – und diesen Betrag würde vermutlich ohnehin niemand bezahlen. So etwas baut man nur einmal im Leben und das für sich selbst. Damit sollte die Frage beantwortet sein.

Hallo, meine lieben Freunde! 😄

Das berühmte vor (ca. 3 Seiten schon erwähnt) Sommerloch neigt sich langsam dem Ende zu – und damit wird es auch hier bald wieder mit dem Bau weitergehen!

Eigentlich befinde ich mich bereits in der Endphase: Das Glareshield muss noch geschliffen und lackiert werden, anschließend werden die Panels für die linke Konsole gefräst, die Kippschalter eingebaut und das USB-Board in Betrieb genommen und natürlich die Verkabelung der Mittelkonsole.

Mitte bis Ende September werde ich wieder richtig loslegen und das Projekt Schritt für Schritt finalisieren! 😊

Aktuell fahre ich bewusst einen Gang runter und konzentriere mich voll auf den Aufbau eines Master-Slave-Systems.

Auf der rechten Cockpit-Seite ist mittlerweile eine ordentliche Menge an Hardware zusammengekommen:

Engine Cluster (4 Motoren)

Fuel Gauge (2 Motoren)

Hyd Pressure 1 (1 Motor)

Hyd Pressure 2 (1 Motor)

Cabin Pressure (1 Motor)

EPU Fuel (1 Motor)

Fuel Flow (1 Display)

Pilot Fault (1 Display)

Macht insgesamt: 9 Motoren und 2 Displays.

Die bisherige Lösung mit vielen einzelnen USB-Anschlüssen ist auf Dauer einfach unpraktisch und schwer wartbar.

Deshalb gehe ich jetzt den Schritt, alles über ein zentrales System zu bündeln.

Die Idee dahinter:

Ein ESP32 übernimmt die Rolle als Master, empfängt die Daten (z. B. aus BMS) und verteilt sie gezielt an mehrere Slave-Controller, die jeweils ihre eigenen Instrumente ansteuern.

Der aktuelle Testaufbau läuft mit 1 Master und 1 Slave – und das bereits stabil.

Besonders spannend: Die Kommunikation funktioniert im 1-Wire-Betrieb, also tatsächlich über nur eine einzige Datenleitung. Dass die Master-/Slave-Kommunikation so sauber mit nur einem Kabel läuft, hätte ich so ehrlich gesagt nicht erwartet.

Nächster Schritt:

Bis zum Wochenende plane ich eine Platine mit 1 Master und 4 Slaves, komplett aufgebaut und sauber verdrahtet.

Der große Vorteil liegt klar auf der Hand:

Der komplette Motor- und Display-Block kann künftig über einen einzigen USB-Anschluss betrieben werden – deutlich aufgeräumter, skalierbarer und wartungsfreundlicher.

Sobald die Verdrahtung steht, geht es an die Software:

Dann schreibe ich den finalen Programmcode und muss im Prinzip nur noch die Treiberplatinen der Motoren an die jeweiligen ESP32-Slaves rechts anschließen.

Wenn alles so läuft wie geplant, ist damit nicht nur die Verkabelung rechts der Schalter und Taster erledigt, sondern auch die komplette Motor- und Displayansteuerung sauber integriert.

Für die Kompakte Umsetzung habe ich das Instrumentenbrett vorn rechts schon umgebaut in eine Sandwitch-Bausweise mit 2 Etagen.

Nervlich am Ende…

Das Panel- und Kabelmanagement hat mich echt an meine Grenzen gebracht.

Die rechte Seite ist jetzt aber endlich komplett fertig – inklusive aller Panels, Platinen und dem gesamten Anschlusssystem. Ich habe dabei den Rat von Bumerang umgesetzt und jedes Panel einzeln mit einem eigenen Stecker versehen. Normalerweise wollte ich die GX Serie als Stecker nehmen allerdings hätte mich das finanziell ruiniert so habe ich mich für eine SUB Steckervariante entschieden / DB9, DB15 und DB25. Dafür habe ich dann ein Gehäuse entworfen und in den Drucker geworfen. Somit hat ein Stecker nun nur noch knapp 25 Cent gekostet von hinten habe ich die Stecker mit Heißklebepistolensaft verschlossen.

Im Nachhinein absolut die richtige Entscheidung – dafür nochmal ein großes Dankeschön!

Projekt-Update:

Die linke und rechte Seite MIP ist soweit abgeschlossen:

Das IFF Case, das Left Eyebrow sowie das Master Caution Case sind fertig – inklusive LED und Druckfunktion.

Beim Right Eyebrow ist mir heute leider ein Druckfehler aufgefallen. Das Teil hatte ich schon vor ein paar Wochen als „fertig“ abgelegt, daher ist es erst jetzt aufgefallen – musste also neu gedruckt werden.

Morgen kommen endlich die 500 m farbcodierten Kabel, dann startet die erste große Verkabelungsrunde.

Der CDU-Centerbereich ist ebenfalls fertig gefräst, lackiert und gelasert – und ich muss sagen: gefällt mir!

Das CDU mittelteil Frintblende oberhalb der Rotarys muss noch lackiert werden und ein Drehschalter muss noch verbaut werden.

Gute Nacht

Neuer Status – ein paar Tage später

Nach einer etwas nervigen Reparatur am Threat Warning Prime Panel gibt es wieder ein Update!!!

Nach dem Eingießen mit Harz hatte sich offenbar irgendwo ein Kontaktproblem auf der Platine eingeschlichen – am Ende blieb mir nichts anderes übrig, als das Panel komplett neu aufzubauen.

In dem Zuge habe ich direkt ein Transistor-Board entworfen, mit dem ich die Schaltung invertiere. Der große Vorteil:

Ich kann jetzt jede einzelne LED im Threat Warning Prime Panel separat ansteuern – genau so, wie ich es ursprünglich haben wollte.

Für die erste Platine habe ich noch 2–3 Tage gebraucht (Fräsen, Löten, Eingießen, Kabel sortieren etc.).

Die zweite Platine war dann dank sauberer Vorbereitung und Dokumentation in ein paar Stunden erledigt.

Das bestätigt wieder:
👉 Alles sauber dokumentieren und Dateien final abspeichern lohnt sich.

Ich habe in der Vergangenheit zu oft kleine Änderungen gemacht und nicht gespeichert – und genau diese haben mir später gefehlt.

CDU Block 70 – erste Tests. Das CDU habe ich testweise mit einem Printtaster ausgestattet, um das Haptikgefühl zu prüfen – und ich muss sagen: wirklich überzeugend.

Das bedeutet für mich:
👉 Ich werde rundum alle 26 Printtaster verbauen.

Wie ich die Belegung am Ende umsetze, hängt stark von Helios ab – und da stehe ich aktuell ehrlich gesagt noch etwas auf Kriegsfuß 😅

Ziel ist es, die Taster so einzubinden, dass ich damit z. B. Seiten umschalten kann.

Geplant ist aktuell:

Primäranzeige: Center Pedestal Style wie in der F-16 Fighting Falcon

Später (optional): Kneeboard + weitere Inhalte

Aber das ist aktuell noch Zukunftsmusik.

Weitere CDU-Features

Das CDU hat inzwischen auch:

die untere Blende für Heading & Course

einen Toggle für Tank Select (NORM / WING FIRST)

sowie einen Rotary für die Fuel Gauge

(Test, Norm, RSVR, Int. Wing, Ext. Wing, Ext. CTR)

Heute steht an:

👉 Lackieren und Lasern, dann ist das Panel mechanisch im Prinzip fertig.

Ein kleines Problem gibt es noch:

Der Rotary ist minimal zu groß und kollidiert mit der 6 mm MDF-Platte unter dem CDU – das wird noch angepasst.

Das Sunshield

Das Sunshield fürs CDU ist ebenfalls fertig – und ich bin ehrlich gesagt ziemlich zufrieden, das Teil sieht richtig gut aus.

Das Einpassen war allerdings etwas tricky:

hier und da mit der Feile nachgearbeitet

Material war ca. 1 mm zu dick, wodurch es seitlich an die MFD-Rahmen gedrückt hat

Konnte ich aber nach etwas Tüftelei sauber korrigieren – und man sieht es jetzt nicht mehr.

Ein Bild habe ich angehängt
(alles noch vormontiert, nichts final auch ist das Glareshield noch nicht geschlieffen oder lackiert und liegt nur Roh auf dem Pit)

Parallel dazu laufen aktuell die 3D-Druckjobs für das Master Caution Case, das IFF Case sowie das Left Eyebrow Case.

Sobald die Teile fertig sind, geht es an die finale Montage – also Bestücken und sauberes Verkabeln von Left & Right Eyebrow, Master Caution und IFF Case.

Anschließend wird noch das kleine Light-Plättchen (Activity / STBY) im Misc Panel eingeklebt.

Damit wäre der Center-Bereich dann endlich abgeschlossen.

Danach wartet „nur noch“ der linke Bereich auf mich – und der hat es bekanntlich ordentlich in sich.

Das UHF-Radio ist zum Glück bereits fertig.

Wenn ich allerdings an das ECM, CMDS oder das Pitch Panel (hier werde ich defenitiv OLED Displays 0.96 Zoll verbauen) da wird mir jetzt schon etwas anders… aber soweit sind wir ja noch nicht 😅

Heute war praktisch der letzte große Schritt beim Threat Warning Prime Panel.

Eine Kleinigkeit fehlt noch: Mir fehlt aktuell noch eine 3-mm-LED. Zum Testen habe ich deshalb vorübergehend eine 5-mm-LED eingesetzt. Der Nachteil dabei ist allerdings, dass der Taster in diesem Slot nicht mehr funktioniert, da die 5-mm-LED schlicht zu groß ist.

Das Gehäuse ist inzwischen final lackiert, die Taster sind gefertigt und auch die Tasthauben wurden passgenau gefräst. Das gesamte Panel ist so konstruiert, dass man es komplett zerlegen und bei Bedarf warten kann.

Das Einschleifen der Tasthauben war ehrlich gesagt echte Feinarbeit. Am Ende hat aber alles perfekt gepasst – der Aufwand hat sich definitiv gelohnt.

Ich erwarte in den nächsten Tagen eine neue LED-Lieferung, und sobald die da ist, kann das Panel endgültig eingebaut werden.

Etwas Respekt habe ich noch vor dem Lasern der Beschriftung auf den Tasthauben. Ich bin mir momentan noch nicht ganz sicher, ob mein Laser so kleine Schriftarten und Symbole wirklich sauber und klar darstellen kann.

Ein paar Bilder (wie immer) vom aktuellen Stand habe ich unten als kleine Impression angehängt.

Der Taster - Rohling oben

Der Taster - Rohling unten

Die Tasthaube

Die Platine in 2k Epoxid eingegossen

Das Threat Panel Gehäuse lackiert

Threat Panel Gehäuse + Tasten

Damit man mal eine Größenvorstellung bekommt

Der Urlaub ist nun vorbei – und auf den Bildern sieht man ganz gut, was in der Zeit tatsächlich entstanden ist. 😁

Ganz so viel wie ursprünglich geplant habe ich am Ende zwar nicht geschafft, aber ein paar wichtige Schritte konnten trotzdem erledigt werden.

Aktueller Stand:

Threat Warn. Prime ca. 90 % fertig

Hyd Pressure 1: fertig

Hyd Pressure 2: fertig

Fuel Gauge: fertig

Misc Panel: fertig

RWR Frame: fertig

Attitude Indicator Frame: fertig

Right Eyebrow: etwa 75 % fertig

Ich habe mir inzwischen vorgenommen, zukünftige Urlaubsphasen lieber nicht mehr zu detailliert im Voraus zu planen. Eigentlich war mein Ziel, das komplette Glare- und Sunshield fertigzustellen – aber am Ende merkt man doch wieder, dass selbst im Urlaub die Zeit irgendwie begrenzt ist.

Trotzdem bin ich insgesamt zufrieden mit dem Fortschritt. Schritt für Schritt wächst das Cockpit weiter

Nach sehr viel Tüftelei, einigen Rückschlägen und ehrlich gesagt auch ein paar Momenten kurz vor dem Nervenzusammenbruch ist es nun endlich geschafft.

Das Design steht, die Zeichnungen passen, die Platine wurde gefertigt und bestückt. Alle Bauteile sitzen dort, wo sie hingehören – die LEDs sind verlötet und auch die Drucktaster haben ihren Platz auf der Platine gefunden.

Beim Löten musste ich teilweise tatsächlich mit der Lupe arbeiten, weil ich die feinen Lötstellen kaum noch erkennen konnte. Früher ging das deutlich einfacher… aber das Alter macht sich eben bemerkbar – die Augen werden leider leider nicht besser.

Anschließend habe ich eine Backplate bzw. eine Art Gussformhalter gefertigt, um auf der Rückseite des Panels sämtliche herausführenden Kabel zu fixieren. Normalerweise würde ich so etwas niemals auf diese Weise bauen. Doch aufgrund des extrem begrenzten Platzes – verursacht durch den Minimonitor für das RWR – hatte ich hinter dem Panel gerade einmal einen einzigen Zentimeter zur Verfügung, um alles unterzubringen und gleichzeitig rund 20 Leitungen (6x2 für Leds + GND sowie 6x1 + GND für die Taster) sauber herauszuführen.

Um dieses Platzproblem zu lösen, habe ich das Threat Warning Prime Panel etwa 18 mm nach vorne herausgesetzt, wodurch ich auf der Rückseite wieder die Materialstärke des MIP (ebenfalls etwa 18 mm) einsparen konnte. Dadurch steht das Panel nun leicht erhaben vor dem MIP. Im Original scheint es – soweit ich das anhand von Bildern beurteilen kann – nahezu bündig mit dem MIP zu sein.

Am Ende blieb mir nichts anderes übrig, als das Threat Warning Prime Panel komplett zu versiegeln.

Ich hoffe einfach nur, dass es niemals kaputt geht.

Der Fortschritt geht aktuell etwas schleppend voran und deutlich langsamer, als ich ursprünglich gehofft hatte.

Inzwischen sind jedoch die Rahmen und Blenden für das RWR (Radar Warning Receiver) eingebaut. Für die Darstellung werde ich hier eine Displaylösung verwenden, da mir aktuell keine sinnvollere Alternative einfällt.

Das Right Eyebrow Panel ist ebenfalls bereits gedruckt, geschliffen und lackiert. Die Blenden sind fertig gelasert, hier fehlt lediglich noch der Zusammenbau und die Verkabelung.

Ebenso ist bereits der Attitude Indicator inklusive Rahmen und Blende montiert (aktuell noch unlackiert). Auch hier plane ich eine Displaylösung über DisplayLink via USB, ähnlich wie beim RWR.

Das Threat Warning Prime Panel bringt mich momentan allerdings fast zur Verzweiflung.

Ich hatte mir die Umsetzung deutlich einfacher vorgestellt. Besonders die Kombination aus Tastern und LEDs ist problematisch, da im Inneren der Taster extrem wenig Platz vorhanden ist. Man fragt sich teilweise wirklich, wie dort überhaupt noch zusätzliche Komponenten untergebracht werden sollen, ohne dass am Ende die mechanische Funktion des Tasters beeinträchtigt wird.

Mittlerweile bin ich hier jedoch auf einem guten Weg.

Die Platine für das Threat Warning Prime Panel habe ich bereits selbst gefräst. Aufgrund der sehr geringen Einbautiefe – es bleiben weniger als 1 cm Platz hinter dem Panel – kann ich diese jedoch nur für die Taster und LEDs nutzen.

Die Vorwiderstände muss ich an anderer Stelle unterbringen, da dafür hinter dem Panel schlicht kein Platz mehr vorhanden ist.

Der Grund dafür ist, dass das RWR-Display bündig an der Rückseite des MIP anliegen muss, wodurch der verfügbare Bauraum zusätzlich stark eingeschränkt wird.

Gott was eine Arbeit ...

Heute sind endlich die letzten 57 Kippschalter aus dem tiefsten China angekommen – yeah! 🎉

Gestern hatte ich allerdings einen kleinen Hänger im Projekt. Daher habe ich den FuelFlow Indicator fertig gestellt und ein bisschen am Glareshield weitergebaut, allerdings nichts wirklich Weltbewegendes. Dafür habe ich mich noch einmal intensiv an meine Software gesetzt – und dabei mein komplettes Konzept über den Haufen geworfen und eine neue Lösung entwickelt.

Auslöser für den Umbau der Software war mein DED Display was total abgespackt hatte.

[Am Ende war es nur ein falscher Treiber vom Display]

Was mich bisher gestört hat:
Wenn man die Controller einmal umsteckt oder der COM-Port sich ändert, musste man in der Software alles wieder neu konfigurieren. Gerade bei mehreren Geräten war das ziemlich nervig.

Deshalb habe ich das Ganze jetzt grundlegend anders aufgebaut. Die Software arbeitet nun gerätebasiert statt COM-port-basiert. Beim Start oder bei einem Gerätescan fragt die Software alle verfügbaren COM-Ports ab. Jedes angeschlossene Gerät antwortet dabei mit einem Gerätenamen und einer eindeutigen Geräte-ID.

Beispiel:

F-16 LED | LED001

DED Display | DED001

Fuel Gauge | FG001

Dadurch kann die Software das Gerät immer eindeutig identifizieren, egal auf welchem COM-Port es gerade hängt.

Vorteile des neuen Systems - Automatische Geräteerkennung:
Die Software erkennt Geräte automatisch anhand ihrer ID – ein erneutes Setup ist nicht mehr nötig.

Unabhängig vom COM-Port´. Selbst wenn Windows den COM-Port ändert oder man ein Gerät umsteckt, wird es weiterhin korrekt erkannt.

Modularer Aufbau:
Neue Geräte lassen sich sehr einfach hinzufügen. Die Software ist jetzt so aufgebaut, dass jedes Gerät als eigenes Modul behandelt wird.

Geräteverwaltung:
In der Software kann man Geräte nun:

- hinzufügen

- deaktivieren

- neu scannen

- einzeln testen

Testfunktionen:
Für jedes Gerät gibt es eine eigene Testfunktion, mit der man sofort prüfen kann, ob alles korrekt verbunden ist.

Ergebnis:

Das Ganze macht das System jetzt deutlich robuster und flexibler – vor allem wenn später noch mehr Panels und Controller dazu kommen.

Im Prinzip kann ich jetzt beliebig viele Geräte anschließen, sie automatisch erkennen lassen und direkt in die Software integrieren.

Das war zwar etwas mehr Arbeit als geplant, aber ich denke, dass sich diese Architektur später im Cockpit-Projekt definitiv auszahlen wird.

Bauschschmerzen:
Macht mir der Attitude Indicator - ich habe keine Ahnung wie ich den bitte bauen soll!
Würde am liebsten ein Display dort verbauen genauso wie bei RWR aber bisher habe ich noch keine so kleinen Displays im Netz gefunden.
Vielleicht hat ja jemand von Euch eine Idee oder Shop für so kleine Displays

Für den Attitude Indicator brauche ich quasi max 80x80 mm oder 60x60 mm DIsplay
Für das RWR 85x85mm - keine Ahnung wie andere das gelöst haben!

So weiter gehts mit den nächsten Schritten


P.S. THE BIG HIGHTLIGHT
__________________________________________________________________________________________

Ich habe soeben geschaut, wann ich mit dem Cockpit gestartet bin.
Am 24.07.2025 habe ich den Bau meiner Fräse abgeschlossen und das MIP als erstes Teil gefräst!
Das bedeutet, das ist nur 251 Tage her - 8 Monate und 7 Tage

Mit etwas Spucke und sinkenden Hardwarepreisen für Computer könnte ich noch dieses Jahr im Cockpit sitzen mit einem neuen Computer

Status Update – 27.03.2026

Morgen beginnt mein Urlaub – und passend dazu ist die rechte Konsole endlich fertig.

Das alles hat länger gedauert als gedacht, aber jetzt ist sie komplett.

Ein bunt gemischtes AliExpress-Paket aus China ist aktuell auf dem Weg zu mir.

Darin sind alle fehlenden Kippschalter und Elektronikteile, damit ich endlich mit der linken Konsole weitermachen kann.

Perfektes Timing für den Urlaub. 🙂

Plan für die nächsten 11 Tage:

- Throttle: etwa 22 Kabel verlängern – danach ist der Throttle komplett fertig

- Linke Konsole: Panels bis zum Landing Gear Panel bauen

- Glareshield: schleifen und neu lackieren

- CDU: alle Buttons drucken und einsetzen

Wenn alles gut läuft, sollten danach nur noch ein paar Bereiche übrig bleiben:

Bereich um das Gear Panel, Misc Panel und die Eyebrows

Dann ist das Cockpit wieder ein großes Stück weiter - das Beste kommt aber erst weil ...

Der beste Teil beim Bau eines Cockpits sind nicht die Schalter, die Kabel oder die Panels – sondern der Moment, in dem alles zum Leben erwacht und der erste Flug beginnt.

Zitat von cuca

Der, ich glaube, FWD Fuselage Tank ist bei den Zweisitzern kleiner als bei den Einsitzern - weil da ja der Platz fürs hintere Cockpit benötigt wird.

Dementsprechend ist bei den Zweisitzern die "FR"-Nadel im Normalbetrieb links von der "AL"-Nadel, genau andersherum als bei den Einsitzern.

In Folge dessen sind auch die "Überlapppungsfähnchen" an der "FR"-Nadelbasis andersherum gestaltet, weil Grenzwerte für Fuel Imbalance anders - und auch andersherum - sind.

Krasser Gedankengang!

Okay, ich habs zusammen - läuft nun alles!
Alles läuft synchron und es sind nr zwei Werte die mit der Drehschalter immer wieder überschriebenw erden AFT /FWD und Total bringt nur die Gesamtwerte mit.

Danke euch für die Infos und das Bild mit dem "Fuel System" sehr hilfreich um das bildlich auch mal zu sehen, wie das Zusammenspiel funktioniert.
Schon geil zu sehen wie das Instrument synchron läuft ... ich freue mich wie ein Honigkuchenpferd.

Nebenbei viel mir auf das die F-16 CM-52 eine differenzierte Anzeige hat wie die F16 DM-52

(wobei beides die selbe Maschinen sein sollen nur die DM ist halt der TwoSeater) optisch wirken die Instrumente erstmal gleich aber der Nadeltyp ist komplett anders bei der DM dort ist AL mit roten Marker / Zeiger was in der CM nicht der Fall zu sein scheint. Ebenso viel mir dabei auf das die CM detailierter als die DM Maschine ist. (4.38)



Besten Gruß
Bee