An avionics program lives on the picture the crew trusts. The primary flight display, the synthetic-vision terrain, the sensor feed, the moving map: each has to be correct, correlated, and drawn on hardware that has to certify and is not allowed to fail. We build that software, and we have shipped it on real avionics products and real aircraft, not just in the lab.
Glass cockpit and primary flight displays
We wrote a DO-178-style glass-cockpit rendering library for an experimental glass-panel avionics product, Avilution XFS. That means a display you can defend to a certification authority: bounded, predictable behavior, no surprise allocations mid-frame, and a panel that draws what it is told and nothing else. This is the industry-facing side of our safety-critical graphics work.
Synthetic vision
We have ported OpenSceneGraph and osgEarth to embedded aviation hardware so the same terrain engine that runs on a workstation runs in the aircraft, correlated to the real world. For Precog's Skyline we built an iPad-based glass-cockpit augmented-reality device that overlays synthetic-vision terrain on the pilot's view, locked to aircraft pose with a Stratux ADS-B and GPS receiver, part of our mobile work. Synthetic vision is unforgiving: the terrain has to be correct, correlated, and fast enough to trust in the cockpit.
![]()
Sensor and mission displays
The out-the-window view is only half the panel. We build the electro-optical, infrared, and radar sensor views, the moving map, and the tactical picture drawn over them, including MIL-STD-2525 symbology from our Nobori toolkit. When the sensor itself has to make a decision, that is our computer vision work, and when a display has to be validated before it flies, our visual simulation systems test it against synthetic sensors first.
Navigation when GPS is denied
GPS is a single point of failure. Jam it, spoof it, or fly where it does not reach, and an aircraft that trusted it is lost. We build GPS-denied and vision-based navigation: visual odometry, terrain-relative navigation, and inertial sensor fusion that give the platform a position and attitude estimate without a satellite.
Training on the same avionics
The cockpit a crew trains in should match the one they fly. We build correlated visual simulation for crewed and uncrewed platforms: a flight model driving the same out-the-window and sensor views over the same terrain, so the simulator and the aircraft do not disagree.
Certifiable, from the silicon up
Getting graphics onto certifiable hardware often starts below the application, at the driver. We work in that layer, and across the embedded range from low-end single-board computers to NVIDIA Jetson. When the processor itself is bespoke, that is our RISC-V core work.
Who works on it
AlphaPixel is a US-owned small business, founded in 2004, with senior developers who each have 25-plus years in real-time 3D, embedded, and safety-critical work. DLA DD2345 / ITAR registered. We take closed-source defense work and open source alike, and we do not sell a display or an avionics box, so our advice is not a sales pitch for one.
Frequently asked questions
What avionics display software do you build?
We build the software behind the picture the crew trusts: the primary flight display, synthetic-vision terrain, the sensor feed, and the moving map. Each has to be correct, correlated, and drawn on hardware that has to certify and is not allowed to fail. We have shipped this on real avionics products and real aircraft, not just in the lab.
Have you actually shipped avionics software on real aircraft?
Yes. We wrote a DO-178-style glass-cockpit rendering library for an experimental glass-panel avionics product, and we built an iPad-based glass-cockpit augmented-reality device that overlays synthetic-vision terrain on the pilot's view, locked to aircraft pose with an ADS-B and GPS receiver. This is production-facing work, not a demo.
Do you build synthetic vision systems?
Yes. We have ported OpenSceneGraph and osgEarth to embedded aviation hardware so the same terrain engine that runs on a workstation runs in the aircraft, correlated to the real world. Synthetic vision is unforgiving: the terrain has to be correct, correlated, and fast enough to trust in the cockpit.
Can you build sensor and mission displays, including MIL-STD-2525 symbology?
Yes. Beyond the out-the-window view we build the electro-optical, infrared, and radar sensor views, the moving map, and the tactical picture drawn over them, including MIL-STD-2525 symbology from our Nobori toolkit. When the sensor itself has to make a decision, that is our computer vision work.
Can you help with navigation when GPS is denied?
Yes. GPS is a single point of failure: jam it, spoof it, or fly where it does not reach and an aircraft that trusted it is lost. We build GPS-denied and vision-based navigation, including visual odometry, terrain-relative navigation, and inertial sensor fusion that give the platform a position and attitude estimate without a satellite.
Is your avionics software DO-178 certifiable?
We build it to be certifiable: bounded, predictable behavior, no surprise allocations mid-frame, and a panel that draws what it is told and nothing else, so it can be defended to a certification authority. We are not a designated engineering representative and do not sign your certification, we make the software survive the process.
Can you build training and simulation that matches the real avionics?
Yes. The cockpit a crew trains in should match the one they fly, so we build correlated visual simulation for crewed and uncrewed platforms: a flight model driving the same out-the-window and sensor views over the same terrain, so the simulator and the aircraft do not disagree.
How do we engage AlphaPixel for an avionics program?
Tell us the target hardware, the certification basis, and which part of the panel you need, from the driver up to synthetic vision, sensors, and symbology. We are a US-owned small business, DD2345 and ITAR registered, comfortable with closed-source and export-controlled work. Contact us to scope it.