A head-up display on smart glasses for light aviation

The context

A manufacturer of instrumentation for microlight aircraft is building a head-up display: flight data — attitude, speed, altitude — projected into smart glasses, so the pilot keeps their eyes outside rather than on the panel.

The hardware existed: a probe producing the flight data, and two models of glasses from different manufacturers. What was missing was the application holding it all together.

The challenge

This project stacked three difficulties you rarely meet together.

Three Bluetooth peripherals, simultaneously. The probe transmits, the glasses receive, and all three must be discovered, paired and reconnected without the pilot having to think about it. Manual pairing before every flight would have been enough to disqualify the product.

No existing library for the display. An artificial horizon — the pilot’s spirit level — does not exist in Flutter. It had to be built from the raw attitude data the probe provides.

A context where bugs are expensive. A frozen display or a wrong reading in flight is not a comfort issue.

What we did

The project began with a genuine framing phase: understanding the hardware, going through the existing documentation, and above all redefining the scope with the client before writing any code. The expected features were reworked together, then with the designers.

Only then:

• An MVVM architecture with reactive state management, chosen because the application is fundamentally a real-time data stream that must be routed to the right peripheral according to the current configuration.
• A technical validation phase before committing. Before building on a Bluetooth library, we developed a working prototype to verify its real compatibility with the probe and both models of glasses. Discovering an incompatibility three months in would have cost the project.
• Automatic discovery and connection of all three peripheral types at launch: the pilot switches on, it connects.
• A custom artificial horizon built from attitude data, since nothing existing was suitable.
• Configurable data routing, with the application deciding which model of glasses receives what, according to the chosen layout.

Alongside the application, we also delivered an API and an over-the-air firmware update server.

The outcome

The application has been under continuous development since 2024 and remains actively evolving.

What made this project possible was the sequence: framing, validation prototype, then development. On a project where the hardware sets the rules, that order is what protects the budget — the first week’s Bluetooth prototype validated a choice everything else depended on.