Why an IMU reads wrong once it's in the enclosure

An accelerometer or IMU works on the bench. It sits flat on a dev board, the numbers look clean, the tilt angle is right. Then it goes into the product, next to a screw boss, a motor or a battery, and the offset has moved, the noise has tripled, or the reading wanders when the case is tapped. Nothing in the schematic changed. What changed is everything the datasheet’s typical-application circuit does not draw.

Four things cause most of this: stress from the board, vibration that the sample rate cannot represent, a range that clips, and an offset that nobody calibrated. Each has a check that costs an afternoon, not a respin.

The board bends, and the sensor notices

A MEMS sensor is a tiny mechanical structure inside a package. When the board flexes, that flex reaches the sensor through its anchors. ST’s PCB guideline note for MEMS sensors says that board deformation shifts parameters such as offset, sensitivity and self-test response. Analog Devices makes the same point from the assembly side: its soldering guidelines for MEMS inertial sensors describe these parts as sensitive to PCB design and to reflow, and say that following good practice in layout and processing avoids the stress.

What that means at the layout stage:

• Keep the part away from where the board is forced. ST’s surface-mount note for QFPN-package MEMS sensors advises staying clear of pushbuttons, screws and anchor points, because those places can put mechanical stress on the sensor (ST TN0019). The distance you actually need is in your part’s own guideline, for your package. Do not copy a number from a different family.
• Read the land pattern and keepout notes for your exact package. The vendors give specific advice on copper under the part, pad symmetry and vias, and it differs by package. That advice belongs to the vendor’s library convention, and your assembler also has their own paste and placement requirements. Check both.
• Think about the enclosure as part of the board. A board that is flat on the bench and then clamped by four screws into a slightly warped housing is a different mechanical object. Test it assembled, with the screws torqued the way production will do it.
• Keep heat sources away. A regulator or charger IC next to the sensor changes its temperature, and temperature moves offset. ST’s own staff suggest checking for nearby heat sources when a sensor behaves oddly.

If you cannot move the part, a stiffer region of the board near a mounting point is better than the middle of a long unsupported span. That is a judgment call, and a thin flex or thin rigid board is a reason to test early.

Vibration that the output rate cannot represent

The most common firmware mistake is choosing an output data rate that matches the question (“I want tilt at 10 Hz”) instead of the environment. Vibration above the sampling rate does not disappear. NovAtel’s application guidance for inertial systems says it folds down into low frequencies or appears as a bias. A motor, a fan, a pump or a vehicle can turn into a slow, believable-looking drift in your tilt estimate.

The remedy is a chain, not a single setting:

1. Use the sensor’s internal filtering. Most modern inertial modules sample internally at a higher rate and low-pass filter before they hand you data at the rate you chose. Read the datasheet section on bandwidth and filters for your part. The bandwidth is often tied to the output rate and to a filter mode you must select.
2. Filter again in firmware for the rate you actually need. If you read at a high rate and decimate, decimate with a proper low-pass filter first. Dropping samples without filtering reintroduces the aliasing you just removed.
3. Deal with the source mechanically. NovAtel’s note is blunt that vibration is best reduced in the mechanical domain: choose the mounting location, use rigid and dimensionally stable mounts, add isolation where needed, and avoid adding resonances. A soft foam pad that isolates a motor can also give the sensor a resonance of its own.

If you cannot predict the vibration, measure it. Log the raw output at the sensor’s highest rate with the product running, and look at the spectrum. Peaks you did not expect tell you what the filtering has to handle.

Clipping and the range you picked

Full-scale range is a trade: a smaller range gives finer resolution, a larger one survives hits. A drop, a latch slamming or a motor starting can exceed the smaller range for a few milliseconds. When the sensor clips, a filter downstream averages the flat top as if it were real data, and the result can be a bias that lingers.

NovAtel lists clipping and errors near the range limit as separate vibration error sources, and advises selecting a range that avoids clipping under the combination of vibration, dynamics and gravity. Add gravity explicitly. An axis that sees 1 g at rest has less headroom than the range label suggests.

Check it the same way: log raw data through the worst event the product will see, then confirm the peaks stay inside the range.

Offset: factory calibration is not installed calibration

Many sensor makers calibrate offset and sensitivity at the factory. That calibration was done on an unstressed part before it was soldered to your board and screwed into your case. The shift described above happens after it.

So there are two things to do:

• Calibrate in the product. For a tilt or orientation product, record the resting reading in a known position and store a correction. For a motion product, log a quiet period at power-up and subtract it. Many parts have user offset registers for this. ST’s staff point to the three offset registers on the LSM6DSO family for fine-tuning a residual offset after the sensor is mounted flat, and they advise confirming the setup is planar first. Other vendors have equivalents, so read the register map of your part.
• Decide where calibration happens. A bench calibration of one unit does not describe the next unit. If the product’s accuracy matters, put the calibration step on the production line and store the result per unit. That is a fixture task. We wrote about the software side of that in writing the software for a production test fixture. It also needs a way to hold the unit still and level, and a place to write the result, which is a layout question: see what test points and programming pads a board needs.

If you enable a high-pass filter on the sensor to remove gravity or offset, calibrate first. ST’s staff have pointed out in the same community threads that filter settling at very low output rates can be long, so do not judge the first readings after a mode change.

Two cautions on integration. If you integrate acceleration to get velocity or position, a small constant bias grows without limit, so do not promise distance from an accelerometer alone. And a gyroscope has its own bias, which also changes with temperature, so a heading from gyro integration drifts unless something else corrects it.

A short pre-release checklist

1. The sensor is placed away from screws, buttons and heat, per the vendor’s note for your package.
2. The land pattern and keepouts follow the part’s own guideline, and the assembler has seen it.
3. Raw data was logged at the highest rate, with the product running, and the spectrum was reviewed.
4. The range survives the worst logged event with gravity included.
5. Filtering is documented from sensor bandwidth to final output, and nothing is decimated without a low-pass.
6. Offset is calibrated in the assembled product, and the result is stored per unit.
7. The test was repeated after an enclosure with production screw torque and after a temperature change.

Items 3 to 7 are firmware and test work, not hardware changes, which is why they are cheap to do before release and expensive to do after.

How we approach it

We start from the sensor’s own documents, place the part for the enclosure rather than for the routing, and build the logging and calibration step into the firmware and fixture from the first prototype. If you have a board where an IMU misbehaves, send the schematic, the layout files, a photo of how it mounts, and a raw log from the product running.