Inspiration
As a paraglider pilot and someone who works with technical systems, I kept coming back to the same problem: the most important information should not require me to keep looking down at a screen.
Can a compact flight instrument communicate the most important information clearly, calmly, and primarily through sound?
The goal is not to give the pilot more data. It is to reduce distraction and turn complex information into useful awareness: altitude, climb and sink, navigation, traffic, weather, airspace warnings, and abnormal situations. That focus is what makes Horizon different.
Horizon is intended to behave more like a calm co-pilot than another screen demanding attention.
What it does
VIRON Horizon is a compact, audio-first flight-awareness system for paragliding pilots.
The physical instrument is designed around a custom four-layer PCB and combines:
- Precise barometric altitude and vertical-speed measurement
- GNSS position, speed, and flight logging
- Audio-vario feedback and spoken status cues
- A high-visibility landscape display
- Physical controls suitable for gloves and turbulent conditions
- Internal microSD black-box storage
- Bluetooth connectivity to the VIRON companion app
- Dual microphones for experimental airflow and wind research
- Provision for the future Horizon XC traffic-awareness module
The interface prioritises large values, clear warnings, and meaningful audio over dense menus.
The companion application extends this with:
- Live BLE telemetry
- A 3D flight map
- Track and thermal visualisation
- Black-box recording and replay
- Preflight weather, wind, and airspace-awareness architecture
- Simulated Horizon XC traffic warnings
- Emergency/crash workflow simulation
- Voice alerts
- A deterministic Flight Lab digital twin
What existed before Build Week
VIRON Horizon was already an active hardware and firmware project before OpenAI Build Week.
I had previously developed core firmware functions on ESP32 development hardware, including:
- Barometric vario calculations
- GNSS parsing
- Flight-state detection
- Audio feedback
- Bluetooth telemetry
- Sensor integration
- Black-box flight logging
I had also designed the custom VIRON Horizon BetaBoard in KiCad.
The board integrates the ESP32-S3, MS5611 pressure sensor, QMI8658 IMU, GNSS, audio amplifier, digital microphones, battery charging and power control, physical buttons, microSD storage, debugging points, and provision for the Horizon XC traffic module.
During the same development period, the PCB design was completed as a compact four-layer board, and the first five assembled prototype boards were ordered for production.
What I built during OpenAI Build Week
During Build Week, I focused on transforming the existing companion application into a much stronger platform for development, simulation, and safety testing.
Working with Codex and GPT-5.6, I created a deterministic VIRON Flight Lab that acts as a digital twin of the physical Horizon instrument.
A major architectural change was unifying three telemetry sources:
+-----------------------------+
| Shared active telemetry |
| pipeline / source boundary |
+--------------+--------------+
|
v
Dashboard/HUD • 3D Map • Audio/TTS • Track/Thermals
Wind/Flight State • Awareness/Alerts • Logging/Events
The rest of the application does not need to know whether telemetry came from a real instrument, a deterministic simulation, or a recorded flight.
This made it possible to test complex flight behaviour before the new PCB even arrives.
I added deterministic simulated flights for Kobala and Krvavec, including:
- Preflight
- Ground
- Takeoff
- Climb and thermal phases
- Glide and sink
- Approach
- Landing
- Landed state
I also added simulation architecture for:
- Weather and wind awareness
- NOTAM / restriction status
- Missing and stale data handling
- Horizon XC traffic with multiple targets and severity levels
- Strong-sink and GPS-loss scenarios
- Low-battery scenarios
- Suspected crash detection
- Cancellable automatic SOS countdown
- Manual SOS simulation
- Emergency-assistance workflow structure
All safety-critical simulated features are clearly identified as simulations. Flight Lab cannot place real emergency calls, send messages, or activate external emergency services.
How I used Codex and GPT-5.6
Codex and GPT-5.6 were not used simply to generate isolated pieces of code.
They became part of an iterative engineering workflow.
I used GPT-5.6 to reason about system architecture, safety boundaries, telemetry design, user experience, hardware/software interaction, and how to separate simulation from real operational behaviour.
Codex then inspected the existing Flutter project, traced real data flows, implemented changes, ran tests, built APKs, and repeatedly verified that new work did not break existing functionality.
Examples of Build Week work included:
- Diagnosing and repairing a broken Mapbox 3D integration
- Unifying BLE, Flight Lab, and Replay telemetry
- Replacing an isolated demo generator with a true digital-twin pipeline
- Fixing legacy black-box/replay schema incompatibilities
- Creating a versioned canonical telemetry format
- Adding deterministic flight scenarios
- Adding weather/NOTAM awareness abstractions
- Simulating Horizon XC traffic
- Creating emergency and SOS simulation safeguards
- Improving responsive phone layouts
- Adding configurable calm TTS voice handling
- Introducing a provider-neutral map architecture so Mapbox can later be replaced by an offline or alternative map provider
- Adding automated regression and architecture tests
By the end of this work, the Flutter project had passed the full automated test suite and was built successfully as an Android APK.
What impressed me most about working with Codex was that it could understand and work inside an existing, interconnected codebase instead of treating every feature as a separate coding task.
Challenges
One of the biggest challenges is that VIRON Horizon is both a hardware and software product. Decisions made in one area immediately affect several others.
On the hardware side, important challenges included:
- Routing power, audio, SPI, I²C, GNSS, sensor, and RF-related signals on a compact four-layer PCB
- Protecting sensitive pressure-sensor and microphone ports during assembly
- Designing a reliable shared Confirm/Power button
- Finding components that were actually available for PCB assembly
- Verifying footprints, polarity, orientation, and pick-and-place data
- Balancing display readability, enclosure size, battery consumption, and outdoor use
- Designing controls suitable for gloves, vibration, sunlight, and changing weather
On the software side, one of the hardest problems was avoiding separate implementations for real hardware, simulation, and replay.
A simple demo mode would have looked convincing, but would not have tested the real application.
Instead, Flight Lab now injects deterministic telemetry into the same pipeline used by a physical Horizon.
Another major challenge was safety.
Weather, NOTAMs, traffic, crash detection, SOS, and emergency assistance can easily appear more capable than they really are. I deliberately designed strong boundaries between:
- Simulated data
- Cached or stale data
- Unavailable data
- Future live operational data
For example:
UNKNOWN is never silently treated as CLEAR.
What I learned
This project reinforced the idea that building a real product is much more than just connecting components or writing individual features.
Every decision affects something else:
- Firmware affects physical controls
- The display affects the enclosure
- The battery affects the power architecture
- PCB layout affects sensors and RF performance
- The telemetry design affects replay and simulation
- Safety features affect both UX and legal responsibility
- Component availability can force hardware changes very late in development
I also learned how useful a deterministic digital twin can be for hardware development.
Instead of waiting for every hardware revision before testing the complete user experience, I can now simulate flights, sensor states, traffic conflicts, GPS failures, thermals, landings, and emergency conditions through the same software pipeline that will later receive data from the real instrument.
AI-assisted development was most valuable when combined with verification.
Codex accelerated inspection, implementation, refactoring, testing, and documentation, but engineering decisions still had to be checked against the actual code, schematics, datasheets, PCB manufacturing files, and safety constraints.
What comes next
The next major milestone is receiving and bringing up the first five VIRON Horizon BetaBoards that have now been ordered for prototype production.
Hardware testing will focus on:
- Power-up and battery behaviour
- Charging and power-control reliability
- Sensor accuracy and calibration
- Vario response
- Audio quality
- GNSS performance
- Bluetooth communication
- Outdoor display readability
- Microphone and experimental airflow measurements
- Black-box flight logging
- Enclosure and mounting design
- Integration with the companion application
- Real-world flight testing
The Flight Lab will remain an important part of that process because the same scenarios can be used to compare simulated behaviour with real telemetry from the physical instrument.
Future work also includes:
- Live, properly validated weather and airspace data
- Real Horizon XC / FLARM-FANET integration
- Offline mapping
- Post-flight analysis
- Emergency-profile and rescue-information architecture
- Medically reviewed emergency-assistance content
- Validation with pilots and relevant safety professionals
VIRON Horizon is currently an experimental prototype and is not intended to replace certified flight, navigation, traffic, weather, or emergency equipment.
The long-term goal remains simple:
Create a calm, practical flight-awareness system that helps pilots make better decisions while keeping their attention where it belongs — on the sky around them.
Log in or sign up for Devpost to join the conversation.