We wanted to refit a boat.
It became a building kit.

The intention: Number Five needed large instruments, charts, a good sound system and sonar that worked together. The technology should fit the boat: its helm, a second control position and the available budget.

The obstacle: A collection of suitable programs is not yet a coherent boat system. Every added device brought its own startup sequence, settings and assumptions about who held the current state. Installation adds power, connections and maintenance access.

The attempts: We started with BBN Marine OS, AvNav and existing boat equipment. Rather than executing a finished specification, we kept finding dependencies: better displays needed data, reliable controls needed acknowledged commands, and another display needed shared state.

The decision: Divide the project by responsibility. Acquiring data, playing music and processing sonar belong in independent services. Displays and controls can then develop separately on the devices.

The gain: One part can change without rebuilding every other part. An instrument display does not also need to be the music server; another control position does not need another sound system. That is where the building kit begins.

Still open: Turning this foundation into a documented package that other boats can reproduce. Today’s sources are concrete components and development snapshots, rather than a universal installation image.

The intention: Use existing standards. Signal K exposes boat data through common interfaces; NMEA connects existing sensors and equipment. BBN bundles important foundations, while AvNav provided navigation and integration options. We did not have to invent that work again.

The obstacle: Our setup still had gaps between data, device startup and coherent touch controls. Receiving a value does not tell you whether it is fresh. Pressing a button does not prove that the service executed the command.

The attempts: We connected existing services, traced state and built our own views. That required identifying the authority for each value, making failures visible and checking which controls the connected system actually supported.

The decision: Our gateway exposes data, capabilities and acknowledged state. HTTP and WebSocket remain the transport mechanisms on the local network. Today’s presentation runs in native Android apps. Other projects also take modern approaches: KIP explicitly describes touch-oriented controls.

The gain: Displays can use the same foundation without having to share the same interface. Missing data is not hidden as a zero value. Controls can distinguish a requested state from a confirmed state.

Still open: Every new function needs an appropriate interface contract and a real test. Home Assistant could become an alternative system base; no migration has taken place. Native presentation does not replace the network services.

The intention: An affordable, large Android display as a control position we could design ourselves. The €75 display price is my own purchase report. What makes it interesting is what can run locally on it, beyond its screen size.

The obstacle: The advertised Android 14 was actually Android 10 with API 29 on the devices examined. Two apparently similar K706 units had different OEM firmware. Startup, buttons and knobs could not simply be treated as identical.

The attempts: We compared actual hardware, operating-system properties and control events. GPS handling, resume behaviour and mapping physical controls became separate areas of work. Missing manufacturer documentation had to be replaced with traceable investigation.

The decision: Device profiles rather than a blanket assumption about “the Lumina”. The apps target the actual platform. Interfaces and controls are connected deliberately, rather than relying on complete manufacturer support.

The gain: Inexpensive devices become useful control positions. Presentation and data access are our choices. A more powerful device can use the same approach; the actual performance gain must be measured for each device.

Still open: Brightness, readability, heat, moisture and mounting in the actual installation. Purchase price is not proof of suitability at sea, nor the full price of an installed system.

The intention: Control charts directly with our fingers and shape the presentation ourselves. Early Boston studies using NOAA data explored visual styles. An attractive still image did not yet answer how loading, rotation and resume would work on inexpensive hardware.

The obstacle: Chart geometry needs memory and a clear lifecycle. A renderer can draw one scene correctly yet fail on return, while loading or under memory pressure. A diagnostic overview of chart cells is not yet a readable navigation view.

The attempts: We compared rendering approaches and developed local native rendering, gestures and workspaces. With MAP 110 on 26 October, both physical Luminas were checked with 96 cells, multiple rotation angles and a normal restart. The geometry budget in that trial was 512 MiB.

The decision: Render on the device and treat route, layer and object-information workspaces as real app controls. Existing open-source foundations remain credited. Performance diagnostics and screen recordings are evaluated separately.

The gain: The chart becomes part of our own control environment. Presentation and device choice can develop independently of a single plotter manufacturer. Existing converters also demonstrate concrete routes towards plotter formats; Lighthouse and Navionics remain incomplete.

Still open: The delete-data-and-return trial failed on both devices, and complete nautical portrayal has not been accepted. Today’s chart demonstration uses the existing NOAA Boston test package in the installed app. Dataset revision and capture date are identified separately; earlier style images remain as history.

The intention: Music should keep playing when a display changes. Echoes should be visible wherever they are needed. Both tasks need a reliable source and several possible control or viewing positions.

The obstacle: An attractive music button does not know the real playback state. A received sonar packet is not yet a usable depth measurement. Relevant fishfinder signals were initially hidden inside the device; audio required playback, sound processing and channel routing to work together.

The attempts: Audio gained independent Pi services with Spotify Connect, sound processing and a custom interface. On the Venterior examined, a Pico acquires signals while we control pings and process echoes. The native sonar view displays real data from the test setup.

The decision: The responsible service holds authoritative state; a client sends a request and displays the response. Unavailable functions remain visible as such. Shared state is different from frame-accurate or zero-delay synchronisation.

The gain: Another control can be added without duplicating music playback. The same sonar data can serve the display and depth output. In the 16 October trial, the best five-second window reached 19.6 usable measurements per second; the 600-second average was 14.17.

Still open: The sonar evidence applies to this device and setup and depends on depth. Operation aboard and temperature calibration remain open. The new audio demonstration shows a confirmed volume change from the other Lumina. The receiving client and real DSP show -39 → -40 → -39 dB; this does not establish frame-accurate or zero-delay synchronisation.

The intention: The next addition should not have to start from scratch. Another sensor should use existing data paths, another control position should use existing services, and a new service should expose a clear interface.

The obstacle: Reusable software alone does not refit a boat. Power, soldering, exact connection dimensions, enclosures, cable routes and tool access must fit together. In South Africa, even sourcing specific variants becomes a project of its own.

The attempts: Alongside the apps came recovery recipes, electronics assemblies and parametric enclosures. Historical views, current print preparation and open fit checks belong to the same story. A CAD image is not a substitute for a printed and mounted part.

The decision: Share our publishable software, hardware sources and documentation with traceable origins. AI assistance is an explicit part of development. Changes still need to be understood and appropriately checked.

The gain: Contributions can begin at a workbench. A better mount, a locally available component or a well-executed installation matters as much as code. People offering fabrication or installation can build their own services on these foundations, under the respective licences.

Still open: Physical installation and combined trials aboard. Wireless controls, television, radio integration and Smart Fleet are potential extensions. Each needs suitable hardware, interfaces, permissions and tests. The foundation gives that work somewhere to connect; it does not complete it automatically.