I’ll be the first to confess that what follows originates purely from my own ignorance. (OK, I suspect more articles than I’d like to admit started there… ) In coming up to speed on MEMS devices early on, I referred to accelerometer data sheets for this or that reason, and I would see a slew of numbers specifying the characteristics of a particular device. The problem was, those numbers really meant nothing to me, since I had no frame of reference for making sense out of them.

Of course, the obvious answer is to look at the text on the datasheet to see what applications that sensor is intended for. Problem is, most datasheets list a whole range of applications – it’s like everyone’s afraid that they might miss something, so best include pretty much every possible application. While this clearly isn’t literally true, my sense was that many accelerometers, regardless of characteristics, were being marketed as suitable for all apps.

I figured I couldn’t be the only one scratching my head. OK, maybe I am, but since folks with electronics backgrounds are now specifying mechanical sensors, and, since these things are going into an increasing number of systems, there may well be folks like me that are getting introduced to the space, with their heads also similarly aspin.

So I queried a number of accelerometer makers to get a sense of how they viewed their own markets and products. I didn’t want to try to replace the work that analysts do – I wasn’t looking for sales numbers or anything; I was more trying to identify app-related buckets and associated critical characteristics. Not all companies I queried participated (and I’m sure there are many companies I didn’t approach simply because I wasn’t aware of them); what follows is what I’ve gleaned from those that did.

One question that came up early (since I was also asking about proof masses, for a separate later discussion) was why I was focusing on accelerometers exclusively. This was a logical question from InvenSense, given their focus on gyroscopes. And the answer was simply because accelerometers have worked their way into many more applications than gyroscopes, or at least so it seems to me. If this exercise turns out to be useful, then it’s straightforward (in principle) to repeat for other devices in the future.

The biggest problem that I found trying to bucketize accelerometer apps is that single buckets won’t work. There are several orthogonal sets of characteristics that have to be considered. Even a market like automotive isn’t enough to provide a bucket: some automotive apps share characteristics with other non-automotive apps more than they do with other automotive apps.

So, for the most part, I was able to narrow the number of considerations to five – plus one I’ve come up with myself to overlay the others. That gives us six axes – or six degrees of freedom, whichever you prefer.

Benjamins

The first axis is obvious: cost. This isn’t so much about the application as it is about the platform. And it really seems like this is a binary bucket: consumer vs. everything else. Not that all consumer-grade devices cost the same, nor that everything non-consumer costs the same. It’s just that, if an app is destined for a smartphone, tablet, TV remote, or gaming widget, then it better be doable on a cheap sensor. Like, 40¢-50¢, according to Analog Devices.

Obviously you’re giving something up with a consumer-grade sensor. “What,” you ask? Well, a bit of pretty much everything. That isn’t necessarily the final word, however, since sensor fusion folks are madly trying to figure out how to do more with less – doing better at correcting for errors or using other sensors to fill in gaps. And, since you’re giving something up, what do you get in return? Well, most simply put, you get a sensor on a platform where you would otherwise not have one. Pretty straightforward tradeoff.

While some companies offer consumer and non-consumer versions, others – Baolab, for example – are targeting their entire process for consumer, period. (To be clear, Baolab is focusing on a magnetometer first, but accelerometers are on their agenda).

G whiz

The second obvious characteristic to look for is the g range – “g” here referring to gravity, not “grams” (which are themselves an artifact of gravity’s acceleration). And earth’s gravity can serve as an interesting benchmark here.

We live with gravity all the time, and mostly it simply holds us in place, so we don’t really experience it as an acceleration. In a conversation with Sensor Platforms’ Kevin Shaw, he made reference to gravity as a large acceleration (and one that can leak), which wasn’t obvious to me – until I pictured myself launching out a window. Now that’s how you can truly experience gravity as a large acceleration!*

So you have low-g applications – anything involving our typical motions and anything subtle. In automotive applications, for example, this might include navigation or devices used in an active suspension. You’ll find accelerometers with fractional g ratings and with single- or double-digit g values.

Above that, you get into the kinds of accelerometers that are used to detect impacts of various kinds. Airbag accelerometers are probably the most familiar example of these. Freescale actually divides this range up, with a mid-range around 100g for use in safety systems and a high-g range of 250-500g for crash detection.

But other companies make yet less-perturbable devices, generally referred to as shock accelerometers. These measure in the range of 10,000gs and above. What might you use this for? I recall reading about one application intended as a bunker-buster against Saddam Hussein (if memory serves). The projectile had to penetrate some specific number (5?) of hardened concrete shells before it entered the chamber where people were. It would be less effective for the device to explode somewhere in the dirt layers above the chamber, so an accelerometer was used to count the number of shocks encountered as the missile pounded through the reinforcing layers, exploding only when it had counted all of them.

Shaddup

Regardless of dynamic range, noise filtering is critical. This is obvious for a sub-1-g device, and I was almost lulled into thinking that it mattered less for 10K-g devices, since, how much multi-thousand-g ambient noise could there possibly be? Get me off that ride! But then you picture this projectile ramming through tons of dirt and rock and concrete: it has to ignore that bit of hardpan or granite to detect only the hardened concrete.

And here’s where we can perhaps introduce the most important caveat of all when it comes to trying to pin this stuff down: “It depends.” Or, “Every application is different.” This applies to pretty much everything about accelerometers, but it’s particularly true of the filtering. That’s because, in many cases, it’s not about drawing a line and saying, “Ignore everything below here.”

Industrial applications, for example, may use accelerometers to help ensure that things are running properly. How do they know that? Because an operating machine has a particular vibrational signature. So it and many other apps involve looking for a pattern of accelerations, not a specific range. API Technologies highlighted helicopters as an example of such a system, with the rotor monitored for a healthy signature.

And even if you want to use range as your filtering criterion, it’s not always the case where you’re filtering out small noise to isolate big signals. In an automobile, you may be doing the reverse: filtering out the large pothole shocks to focus on something more subtle. So noise isn’t really defined as lower-amplitude signals that threaten the meaningful signal; it’s pretty much any signal that isn’t the one we want.

Which blurs into the next bucket, for which I’ve combined accuracy and reliability. Being able to reject noise is a part of that, but this also gets to issues like temperature and aging compensation. If you’re relying on an accelerometer to ensure that your airplane ends up landing at the correct airport – or, heck, at any airport – then you don’t want to hear the flight attendant say that, due to sensor aging, you’ve drifted off course and will be bussed from the local country road where you ended up landing to the airport where you were trying to go.

There are a number of different specs that may relate to this bucket; anything dealing with numerical stability – offset, drift, linearity, and variation with respect to environmental conditions like voltage and temperature. These establish whether the accelerometer readings are likely to be off by a couple ppm, several hundred ppm, or 10%.

It should also be noted that, strictly speaking, precision and reliability don’t have to go together. You might imagine that an airbag sensor would have a moderate range within which it fires – we don’t need six decimal places of precision – but it has to work every time: reliability is key.

This is probably the single best determiner of “consumer” grade vs. anything-else grade. Remember that cost thing? Yeah… You’ll hear the term “navigation grade” sometimes (although Freescale considers that to be just a marketing term); it simply means that, unlike the sensors in your phone, this sensor will lead you in a direction that more accurately approximates where you’re trying to go.

This is also why so many sensor fusion folks are trying to come up with ways to get consumer-grade sensors to work (or work better) in applications that normally would require something more expensive.

Tread lightly

Some applications place severe demands on the size and power consumption of a sensor and its support circuitry. Because these two characteristics tend to go in tandem, I’m going to put them in the same bucket, loosely referred to as the “mobile” bucket.

That’s because by far the biggest area of concern for these characteristics is phones and tablets. Size matters – small is good. And power matters – as low as possible. That said, smartphones and tablets are moving overwhelmingly into combo sensors, so the power and packaging requirement accrues to the combined unit.

But other applications, like accelerometers in remotes or game wands or healthcare and fitness applications will also benefit dramatically from small size and, because they rely on batteries, low power consumption.

Power savings can be explicit – the number on the data sheet – or implicit based on other features. Kionix points out that the use of FIFOs (or LIFOs) helps to optimize the use of the host as it retrieves data; done more efficiently, this can save significant system power.

Flak jacket

Then there’s the bucket relating to the environmental extremes that might be endured by a sensor. This tends to mean automotive, aerospace, and military. But it also includes industrial applications and down-hole sensing – anything that involves high or low temperatures and a rough vibrational ride.

It’s not just about the sensor surviving the temperature; it’s also about knowing that the readings are accurate at the extreme ends of the range. And the vibration thing isn’t just about dealing with the noise; it’s also about the basic physical integrity of the unit. You don’t want things coming unglued or having solder joints or bond wires or the proof mass itself come unhinged and start rattling around untethered.

Do you want numbers with that?

I’m going to use the terms “analog” and “digital” here, but it isn’t what you think. It’s not about whether you’re getting an analog signal or a digital rendition of the original analog signal out of the sensor (you can get analog, but digital is overwhelmingly more common). This is not even about the sensor; it’s about the fundamental nature of the application itself.

What’s the most common use of an accelerometer? Something that gets done millions (billions?) of times every day across the world? It’s the tilt feature on your phone. In fact, it probably feels like it gets done a hundred times on your phone alone on that lazy Saturday morning when you’re lying on your side trying to see who emailed or texted you overnight, going back and forth landscape/portrait, always 90° out of phase with your head.

The tilt detector uses an accelerometer to figure out where “down” is. It doesn’t try to tell you what the actual acceleration value is; it’s merely signaling a state or an orientation-change event. You’re either portrait or landscape, and whether the transition happens at 45°, 60°, or 30° really doesn’t matter.

The same holds for tap detection on a phone. Or crash detection for an airbag sensor. Or the bunker shell counters in that missile application. I refer to these as digital applications because they signal discrete events (sometimes binary, sometimes not).

Analog applications, by contrast, require an actual value, and the desire is that the value be correct. You’re making a measurement. This is important for navigation, motion-controlled gesture recognition, some health and fitness tracking apps, industrial process monitoring, and seismic applications, just to name a few.

Sensors for use in analog applications have to be more accurate, period. Some sensor manufacturers will have sensors for both digital and analog apps; others will focus on analog. API Technologies, for example, doesn’t make its own MEMS device; it incorporates one made by someone else into an overall accelerometer subsystem that’s intended to be precise and allow accurate analytics. You won’t find this in a phone.

Analog Devices also likes to focus on applications that leverage their DSP capabilities. For example, in addition to the digital airbag application, there may be an accompanying black-box app that more accurately tracks the history of various operating parameters for post-event analysis.

Scoring your app

So we have six axes here, and any given application will cross some number of them; I’ve taken a shot at a table of some sample applications here. There are very few rows that match. (And I didn’t hand-pick the examples to prove that point.)

To be clear, this is an over-simplification. But hopefully it helps those of us newer to the club to wade through some of the parameters in search of the right accelerometer.

*In case this isn’t obvious, this is NOT – I repeat NOT – a suggestion that anyone go out and try to experience the thrill of unprotected free fall through auto-defenestration. As further ward against any over-ambitious lawyers out there, let me state it a different way: DON’T DO IT. Duh…

More info on the contributing companies:

Analog Devices

API Technologies

Baolab

Freescale

InvenSense

Kionix

Sensor Platforms