Why a Compute Module and not a Microcontroller?
Some say a first impression lasts a lifetime. We believe that applies not only to people, but to engineering decisions as well. The core of Atmos being built around a compute module may seem like a strange choice for aviation, but this post explains why it’s one of the most deliberate, and important, decisions we’ve made so far.
Let's start with the obvious question: why not a traditional microcontroller?
Microcontrollers are common in avionics for good reason. They’re inexpensive, widely available, purpose built, and well understood. Pick a chip, write some code, program it, and move on. In many cases that is the right approach.
So why would we choose a compute module for Draco?
The short answer is this: we aren’t designing just Draco, we are planning for the future of Atmos Avionics.
That means we need something that is reliable through repeated iteration. When we design the custom base board (what we often call the “power board”) for Draco, we want to be able to reuse that as much as possible.
If we took the microcontroller route, each new product would likely have:
Different power requirements
Different protection schemes
Different failure modes
Different tool chains and test setups
That means repeating research and development (R&D) over and over again, on both the hardware and software side of things.
Using a compute module lets us standardize that foundation. Every time you change compute platforms, you pay a tax: new power behavior, new toolchain, new test harness, new failure modes. We only want to pay that tax once.
Yes, the upfront cost is higher. Over time though, that decision saves significant development effort, reduces risk, and allows us to bring products to market faster. Ultimately, that efficiency translates into lower costs and better support for the aviators using our equipment.
Now, the tech savvy among you might be thinking:
“Hang on, in what world do you need 4 GB of RAM and 2.4GHz of processing speed to read voltages, frequencies, and I²C data, then send it to a display?”
You are correct, dear tech savvy reader. In short, we don’t.
That extra RAM and processing speed we have leaves space for better functionality like sensor filtering and validation, robust logging and diagnostics (more on that in a future article but its a secret for now), the ability to support a multitude of engine configurations, and ultimately new features without having to redesign hardware.
In embedded systems, especially avionics, painting yourself into a corner can become expensive very quickly. Headroom gives us flexibility without forcing architectural changes later.
Basing our core computing power on the compute module also simplifies customer support in meaningful ways. Draco logs incoming engine data, as well as any system faults and diagnostic information. If a pilot experiences an issue, the process is straightforward: insert a USB drive, apply aircraft power, wait briefly, then remove the drive and send us the files. That visibility allows us to diagnose issues quickly and accurately.
The modular nature of the system also keeps repairs and servicing efficient. Labor stays low, troubleshooting is faster, and fewer problems require hardware replacement. This decision was made with supportability and long-term ownership costs in mind.
So what about reliability?
Isn’t a microcontroller more reliable?
We’re not claiming that a compute module is inherently more reliable than a microcontroller. Reliability is more about the entire system than just its parts. Power behavior, fault handling, visibility, validation, and diagnostics all matter. Having additional processing and memory allows us to build reliability through better tooling and insight. A platform that helps us see problems early, during development and testing, allows us to fix them cleanly before they ever reach an aircraft. In practice, that can be more reliable than a minimal system that’s difficult to introspect.
Maybe that’s a skill issue. Embedded systems are hard enough already, why make them harder than they need to be?
To wrap things up: choosing a compute module sets Atmos up for faster iteration on Draco, smoother expansion into future products, and consistent, transparent support for our customers. By standardizing our core platform early, we reduce long-term R&D effort allowing us to deliver higher-quality products at a lower cost to the aviators who use them.
If you’re curious about how we approach engineering decisions in avionics, we invite you to join the email list. We’ll continue sharing the reasoning behind what we build, and why.
Next time, we’ll take a deeper dive into the hardware decisions behind the power board.
-Dalton Co-Founder/Software Engineer
