Wir wollten ein Boot umbauen.
Es wurde ein Baukasten.

Das Vorhaben: Auf Number Five sollten große Instrumente, Karten, eine gute Musikanlage und ein Sonar zusammenpassen. Die Technik sollte sich nach dem Boot richten: nach dem Platz am Steuerstand, dem zweiten Bedienplatz und dem verfügbaren Budget.

Das Hindernis: Eine Sammlung passender Programme ist noch kein zusammenhängendes Bordsystem. Jedes zusätzliche Gerät brachte eigene Startabläufe, Einstellungen und Vorstellungen davon mit, wer gerade den gültigen Zustand kennt. Beim Einbau kommen Versorgung, Anschlüsse und Wartungszugang dazu.

Die Versuche: Wir begannen mit BBN Marine OS, AvNav und vorhandener Bootstechnik. Statt eine fertige Produktspezifikation abzuarbeiten, begegneten wir immer neuen Abhängigkeiten: Für eine bessere Anzeige brauchten wir Daten; für verlässliche Bedienung bestätigte Befehle; für ein zusätzliches Display gemeinsame Zustände.

Die Entscheidung: Das Projekt wird nach Aufgaben aufgeteilt. Daten erfassen, Musik abspielen und Sonar auswerten gehören in eigenständige Dienste. Anzeigen und Bedienung dürfen davon getrennt auf den Geräten entstehen.

Der Gewinn: Ein Teil lässt sich verändern, ohne jedes andere Teil neu zu bauen. Ein Instrumentendisplay muss nicht gleichzeitig Musikserver sein; ein neuer Bedienplatz braucht keine zweite Musikanlage. Genau darin liegt der Anfang des Baukastens.

Offen bleibt: Aus dieser Grundlage ein dokumentiertes, für andere Boote reproduzierbares Paket zu machen. Die heutigen Quellen sind konkrete Bausteine und Entwicklungsstände, noch kein universelles Installationsimage.

Das Vorhaben: Vorhandene Standards nutzen. Signal K macht Bootsdaten über gemeinsame Schnittstellen zugänglich; NMEA verbindet vorhandene Geber und Geräte. BBN bündelt wichtige Grundlagen, AvNav brachte Navigation und Integrationsmöglichkeiten mit. Diese Arbeit mussten wir nicht neu erfinden.

Das Hindernis: Für unseren Aufbau blieben Lücken zwischen Daten, Gerätestart und einer zusammenhängenden Touch-Bedienung. Ein empfangener Wert erklärt noch nicht, ob er frisch ist. Ein gedrückter Knopf beweist noch nicht, dass der Dienst den Befehl ausgeführt hat.

Die Versuche: Wir haben die vorhandenen Dienste verbunden, Zustände verfolgt und eigene Ansichten aufgebaut. Dabei musste klar werden, welcher Dienst für welchen Wert verantwortlich ist, wie ein Ausfall sichtbar wird und welche Bedienfunktion das angeschlossene System tatsächlich unterstützt.

Die Entscheidung: Ein eigener Gateway vermittelt Daten, Fähigkeiten und bestätigte Zustände. HTTP und WebSocket bleiben die Transportwege im lokalen Netz. Die heutige Darstellung läuft dagegen in nativen Android-Apps. Andere Projekte gehen ebenfalls moderne Wege: KIP beschreibt seine Bedienung ausdrücklich als Touch-orientiert.

Der Gewinn: Anzeigen können dieselbe Grundlage verwenden, ohne dieselbe Oberfläche sein zu müssen. Fehlende Daten werden nicht als Nullwert versteckt. Bedienung kann zwischen angefordertem und bestätigtem Zustand unterscheiden.

Offen bleibt: Jede neue Funktion braucht einen passenden Vertrag und einen realen Test. Home Assistant könnte eine alternative Systembasis werden; eine Migration hat bisher nicht stattgefunden. Die native Darstellung ersetzt auch nicht die Netzwerkdienste.

Das Vorhaben: Ein großes, bezahlbares Android-Display als frei gestaltbarer Bedienplatz. Die 75 Euro für ein Display sind meine Preisangabe. Interessant wird das Gerät durch das, was lokal darauf laufen kann – nicht allein durch seine Bildschirmdiagonale.

Das Hindernis: Das angezeigte Android 14 war auf den untersuchten Geräten tatsächlich Android 10 mit API 29. Zwei äußerlich ähnliche K706-Geräte hatten unterschiedliche OEM-Firmware. Startverhalten, Tasten und Drehknöpfe konnten deshalb nicht einfach als identisch behandelt werden.

Die Versuche: Wir verglichen die reale Hardware, Betriebssystemangaben und Bedienereignisse. GPS-Aufbereitung, Wiederaufnahme und die Zuordnung physischer Regler wurden eigene Arbeitsbereiche. Fehlende Herstellerunterlagen mussten durch nachvollziehbare Untersuchung ersetzt werden.

Die Entscheidung: Geräteprofile statt einer pauschalen Annahme über „das Lumina“. Die Apps berücksichtigen die tatsächliche Plattform. Schnittstellen und Bedienelemente werden gezielt angebunden, statt von einem vollständigen Herstellersupport auszugehen.

Der Gewinn: Günstige Geräte werden als ernsthafte Bedienplätze nutzbar. Gestaltung und Datenzugriff sind unsere Entscheidungen. Ein leistungsfähigeres Gerät kann denselben Ansatz verwenden; wie stark es beschleunigt, muss jeweils gemessen werden.

Offen bleibt: Helligkeit, Ablesbarkeit, Wärme, Feuchtigkeit und Befestigung im tatsächlichen Einbau. Der Kaufpreis ist kein Nachweis für Seetauglichkeit und kein vollständiger Preis eines installierten Systems.

Das Vorhaben: Karten direkt mit den Fingern bedienen und die Darstellung selbst gestalten. Frühe Boston-Studien mit NOAA-Daten zeigten mögliche Stile. Eine hübsche Einzelansicht beantwortete aber noch nicht, wie Laden, Drehen und Wiederaufnahme auf einem günstigen Gerät funktionieren.

Das Hindernis: Kartengeometrie braucht Speicher und einen klaren Lebenszyklus. Ein Renderer kann eine Szene korrekt zeichnen und trotzdem beim Zurückkehren, beim Laden oder unter Speicherdruck scheitern. Auch ein diagnostischer Zellüberblick ist noch keine sauber lesbare Navigationsansicht.

Die Versuche: Wir verglichen Darstellungswege und bauten lokales natives Rendering, Gesten und Arbeitsseiten auf. Auf beiden physischen Luminas wurden im Stand MAP 110 am 26. Oktober 96 Zellen, mehrere Drehwinkel und ein normaler Neustart geprüft. Die Geometriegrenze lag in diesem Versuch bei 512 MiB.

Die Entscheidung: Auf dem Gerät zeichnen und Arbeitsseiten für Routen, Ebenen und Objektinformationen als echte App-Bedienung behandeln. Die vorhandenen Open-Source-Grundlagen bleiben benannt. Leistungsdiagnostik und Bildschirmaufnahme werden getrennt ausgewertet.

Der Gewinn: Die Karte ist Teil unserer eigenen Bedienumgebung. Gestaltung und Geräteauswahl können sich unabhängig von einem einzelnen Plotterhersteller entwickeln. Die vorhandenen Konverter zeigen außerdem konkrete Wege zu Plotterformaten; Lighthouse und Navionics bleiben unvollständig.

Offen bleibt: Der Versuch „Daten löschen und zurückkehren“ scheiterte auf beiden Geräten; die vollständige nautische Darstellung ist nicht abgenommen. Für die aktuelle Südafrika-Karte fehlt uns zudem ein dokumentierter öffentlicher Bildnutzungsnachweis. Deshalb zeigen wir eigene Arbeitsseiten und gekennzeichnete NOAA-Studien, bis eine passende Karten-Vorführung möglich ist.

Das Vorhaben: Musik soll weiterlaufen, wenn sich ein Display ändert. Echos sollen dort sichtbar werden, wo man sie braucht. Beide Aufgaben verlangen eine zuverlässige Quelle und mehrere mögliche Bedien- oder Anzeigeorte.

Das Hindernis: Eine schicke Musiktaste kennt noch keinen echten Wiedergabezustand. Ein empfangenes Sonarpaket ist noch kein brauchbarer Tiefenwert. Beim Fishfinder waren die relevanten Signale zunächst im Gerät verborgen; bei Audio mussten Wiedergabe, Klangverarbeitung und Kanalzuordnung zusammenpassen.

Die Versuche: Für Audio entstanden eigenständige Pi-Dienste mit Spotify Connect, Klangverarbeitung und einer eigenen Oberfläche. Beim untersuchten Venterior erfassen wir Signale mit einem Pico, steuern Pings und werten Echos aus. Die native Sonaransicht zeigt reale Daten des Versuchsaufbaus.

Die Entscheidung: Der zuständige Dienst führt den gültigen Zustand; ein Client sendet einen Auftrag und zeigt die Rückmeldung. Nicht verfügbare Funktionen bleiben erkennbar. Gemeinsamer Zustand ist dabei etwas anderes als bildgenaue oder verzögerungsfreie Synchronisation.

Der Gewinn: Eine Bedienung lässt sich ergänzen, ohne die eigentliche Musikwiedergabe zu duplizieren. Dieselben Sonardaten können zur Darstellung und zur Weitergabe der Tiefe dienen. Im Versuch vom 16. Oktober wurden im besten Fünf-Sekunden-Fenster 19,6 brauchbare Messungen pro Sekunde erreicht; über 600 Sekunden lag der Mittelwert bei 14,17.

Offen bleibt: Der Sonarnachweis gilt für dieses Gerät und diesen Aufbau, abhängig von der Tiefe. Bootsbetrieb und Temperaturkalibrierung sind offen. Für eine neue Audio-Vorführung muss eine verfügbare Quelle einen echten bestätigten Zustand auf zwei Clients liefern; bloß gleich aussehende Bildschirme genügen nicht.

Das Vorhaben: Die nächste Erweiterung soll nicht wieder bei null anfangen. Ein zusätzlicher Sensor soll vorhandene Datenwege nutzen, ein weiterer Bedienplatz vorhandene Dienste, ein neuer Dienst eine klar beschriebene Schnittstelle.

Das Hindernis: Wiederverwendbare Software allein baut kein Boot um. Versorgung, Löten, genaue Anschlussmaße, Gehäuse, Kabelwege und Werkzeugzugang müssen zusammenpassen. In Südafrika wird schon die Beschaffung konkreter Varianten zum eigenen Problem.

Die Versuche: Neben den Apps entstanden Wiederherstellungsrezepte, Elektronikaufbauten und parametrische Gehäuse. Historische Ansichten, aktuelle Druckvorbereitung und offene Passprüfungen gehören zur selben Geschichte. Ein CAD-Bild ersetzt dabei kein gedrucktes und montiertes Teil.

Die Entscheidung: Eigene veröffentlichbare Software, Hardwarequellen und Unterlagen werden mit nachvollziehbarer Herkunft geteilt. KI-Unterstützung ist ausdrücklich Teil der Entwicklung. Änderungen müssen trotzdem verstanden und passend geprüft werden.

Der Gewinn: Mitarbeit kann an der Werkbank beginnen. Eine bessere Halterung, ein lokal lieferbares Teil oder ein sauberer Einbau ist genauso wertvoll wie Code. Wer Fertigung oder Installation anbieten möchte, kann darauf ein eigenes Angebot aufbauen – im Rahmen der jeweiligen Lizenzen.

Offen bleibt: Der reale Einbau und die zusammenhängende Erprobung an Bord. Funkregler, Fernsehen, Funkintegration und Smart Fleet sind mögliche Ausbauwege. Sie benötigen jeweils passende Hardware, Schnittstellen, Rechte und Prüfungen. Das Fundament macht solche Arbeit anschlussfähig; es erledigt sie nicht automatisch.