By Gerald Barrera

For most of the past decade, the conversation about inertial sensing for small satellites has been a conversation about one comparison: MEMS or fiber optic. Which is more accurate, which is lighter, where the crossover sits. I have had that conversation more times than I can count, and I have come to think it is the wrong place to start. The comparison is largely settled, and I will get to that, but the decision which determines whether a constellation program succeeds is no longer a performance decision at all.

When a customer is building one satellite, the sensor question is a performance question. You pick the best figures the mass and power budget will allow and qualify a handful of units. When the same customer is building a hundred satellites, or several hundred, the questions that break programs are different. Can the supplier deliver unit 300 with the same characteristics as unit three? Will lead time hold when the launch manifest moves? Will this part still be built, on this process, when the replenishment order arrives in year four? Those questions rarely appear on the first request for quotation. In my experience they are the ones that decide the program.

Where the crossover actually sits

The comparison deserves a fair hearing before I set it aside. It is not about one technology being better than the other; it depends entirely on the mission. A fiber optic gyro still makes sense when extremely high accuracy is required over long periods without GNSS or other external aiding, and optical technologies remain paramount for deep-space navigation, where drift over years is the whole problem.

For stabilization and orientation in low Earth orbit, though, high-performance MEMS now matches optical devices on the parameters that matter, bias instability and angle random walk among them. That is not a claim the industry would have made with confidence five years ago. What changed was volume. As MEMS inertial sensors went into vehicles, ships, industrial machinery and aircraft in very large numbers, the knowledge base about how they behave in service grew with them, and that knowledge fed back into materials, packaging, sensing elements and drive electronics. In my own company’s case, the understanding behind the sensors now flying in LEO was mostly earned on the ground, in markets that never think about orbit. Production at scale also strengthened the consistency of the manufacturing process itself, which turns out to be the property a constellation cares about most.

So the comparison has narrowed to the point where, for most LEO missions, performance no longer discriminates between viable options. When performance stops discriminating, something else decides.

What “good enough” means at volume

That something else begins with reliability, which is the parameter customers rarely list first and should. A satellite cannot be maintained or repaired. Whatever the platform’s role, the inertial sensor has to work invisibly and consistently in the background for the life of the mission, and a proven performance record is worth more than an incremental improvement on a datasheet.

After reliability come the parameters that a prototype program never has to think about: consistency from unit to unit, lead time, availability and cost. This is the biggest change I see in the market. Customers are no longer asking for a few sensors for a prototype. They need a supplier that can support higher volumes for years and stay with the program through its second and third tranches. A supplier that can support a prototype and a supplier that can support production at unit 400 are different businesses, even when the part number is the same.

The mistake I see most often

The most common error is to start with the sensor instead of the mission. A team arrives with a long specification because they want the best performance available. When the conversation turns to what the satellite actually has to do, the answer is often different, and sometimes cheaper.

The second error follows from the first: reading headline figures without asking how they were achieved. A bias instability number is a statement about a particular test, at a particular temperature, over a particular window. Whether that figure applies to a given program depends on whether the mission ever sees those conditions. The right questions for a supplier are plain ones. How accurate does the system need to be? How many satellites are being built, on what schedule and budget? How long is the mission? What are the size, weight and power limits? There is no benefit in pushing a customer toward more performance or more cost than the mission requires. Sometimes the answer is a higher-end optical solution. On many other occasions MEMS will do the job with margin to spare.

The case for the datasheet

There is a fair objection to all of this, and it deserves a proper hearing. A satellite that misses its pointing budget is a failed satellite no matter how many others are flying beside it. Long-term bias stability is exactly what a five-year LEO mission demands. And datasheets exist precisely because performance is the one thing that cannot be fixed after launch, whereas lead time can be negotiated and cost can be absorbed.

I take that seriously, and two things follow from it. The first is that constellations change what failure means. A 2024 Aerospace Corporation report on constellation acquisition sets out how contracts can specify reliability at the constellation level rather than for each individual satellite. The logic is that a constellation can absorb the loss of one satellite through replenishment. That logic holds only if the supplier can deliver the replacement on the same process, on time. The performance argument, followed to its conclusion, lands back on supply. The second is that the objection assumes the datasheet describes the mission. It often does not, which is the point of starting with the mission in the first place.

This will matter more, not less, as constellations of smaller platforms take on space domain awareness work, because tracking a maneuvering object asks something different of the sensor than routine attitude control does. Holding orientation is a matter of detecting drift and correcting it, which calls for low noise and repeatability. Tracking demands a much higher response rate and wider bandwidth, inputs from star trackers and sun sensors, and a sensitive, low-noise accelerometer to enable fine control of thrust during constant adjustment. A sensor selected for station-keeping was never chosen for that job, and a program that starts from the mission will spot the difference early.

What to ask before the RFQ

For decision-makers, the practical change is in the order of questions. Before comparing figures, define the mission: accuracy actually required, unit count, schedule, duration and SWaP limits. Then ask each supplier how its headline numbers were obtained and under what conditions. Then ask the questions that only matter at volume: unit-to-unit spread across a production lot, how lead time is protected, how long the process will be supported, and what the in-service record shows.

As the industry matures, I expect these questions to harden into standards. Aviation reached that point long ago, with defined benchmarks for reliability and mean time between failures, but commercial LEO still has no industry-wide benchmark of that kind. Whether the industry writes those benchmarks itself or has them written for it, the programs that already buy on reliability, consistency and supply will be the ones least disrupted when it happens.