24 Accelerometer Datasheets: Selection Evidence

24.1 Start With the Decision

A parcel tag must catch a hard drop but ignore road shake. Range, sample rate, and resolution must fit that event.

24.2 Route Overview

This is part 1 of 2. Continue with Accelerometer Datasheets: Validation Evidence.

24.3 Part Objectives

• Turn an acceleration claim into range and sample needs.
• Convert ADXL345 counts and scale into product meaning.

24.4 Chapter Roadmap

• Start With the Acceleration Claim
• ADXL345 Datasheet Claim Filter
• Convert Rows to Behavior
• Counts Need Product Meaning
• Phoebe’s Field Notes: The Conversions Sitting Between the Spring and the 4 mg/LSB
• In 60 Seconds
• Prerequisites
• What This Chapter Adds
• Case Study, Not Part Advice
• Case Study Brief
• ADXL345 Rows to Selection
• Extract the Critical Rows

24.5 Start With the Acceleration Claim

Turn Each Data Row Into a Bench Check

Picture a parcel tag that must record a hard drop but ignore normal van shake. A maker sheet lists many values. None matters until the team links it to the product claim and a setting it can test.

Begin with the motion event. Name the smallest and largest force, how long it lasts, how often it is sampled, and what false alert is acceptable. Choose a range that can hold the largest event without making small changes too hard to see.

Bandwidth means the span of changes a sensor path can follow. It is not the same as sample rate. Set both from the event. Then check noise, filter delay, scale, and the number of counts expected for a known movement.

Firmware is the built-in software that controls a device. Record the exact range, rate, filter, interrupt, and power settings that firmware writes. Read them back after start and after a low-power wake. A default value is not a reviewed choice.

Build a short table with claim, maker row, chosen setting, expected result, bench method, pass limit, and owner. Keep the sheet version and part marking beside it. A similar part name may have different limits.

Run a quiet test, a known tilt, a normal shake, and the planned drop. Repeat with the final case and mount. Check clipping, missed events, false alerts, time, current, and saved units. Change one setting at a time.

Try a cold unit, low supply, full event store, and restart. The tag must preserve the event meaning and show when it cannot. Reopen the table after a part, mount, case, or code change.

Give the table and test unit to another engineer. Ask them to repeat one result without spoken help. Fix any hidden step before calling the setup ready.

Keep that repeat result with the table.

One bench set cannot copy every real parcel. Practitioner converts the key rows into settings and evidence. Under the Hood follows scale, noise, interrupts, and error limits that a simple maker value can hide.

Imagine a product saying it can detect motion, tilt, impact, or vibration with an accelerometer. The datasheet case study starts by translating that claim into range, resolution, bandwidth, noise, interrupt, interface, power, and calibration evidence. The ADXL345 rows matter because each one must support a real firmware setting or bench check.

24.6 Learning Objectives

By the end of this chapter, you will be able to:

• Extract application-relevant accelerometer specifications from a manufacturer datasheet.
• Translate range, resolution, data rate, power, interface, FIFO, interrupt, package, and environmental rows into design decisions.
• Build a requirement-to-evidence record for an accelerometer selection.
• Identify what the datasheet proves, what firmware must configure, and what bench tests must still verify.
• Avoid common accelerometer mistakes such as range clipping, voltage-domain mismatch, unverified interrupt behavior, and unrecorded calibration assumptions.

24.7 ADXL345 Datasheet Claim Filter

The ADXL345 datasheet is useful when it is read against one product claim at a time. A tilt product cares about gravity, offset, resolution, axis orientation, and calibration. A wake-on-motion tag cares about activity/inactivity thresholds, interrupt mapping, standby and measurement current, host wake behavior, and false wakes. A drop or shock flag cares about range, sampling, saturation, mounting, and what the part can actually observe.

The part gives the design team concrete levers: selectable +/-2 g, +/-4 g, +/-8 g, and +/-16 g ranges; high-resolution measurement up to +/-16 g; 16-bit twos-complement output; SPI or I2C digital access; activity, inactivity, tap, double-tap, free-fall, data-ready, and FIFO-related interrupt behavior; and a 32-level FIFO. None of those features is a release claim until the board and firmware prove the chosen configuration.

Inspect the figure Figure 24.1 before carrying ADXL345 Datasheet Claim Filter forward. Environmental Specifications and Accelerometer Sensor Datasheet identify the evidence boundary implicit in An accelerometer datasheet becomes engineering evidence only after each row is tied to a claim, configured in firmware, and checked on the assembled board.

Read each parameter row across Figure 24.1, keeping its unit beside the minimum, typical, and maximum columns. The rows separate supply, temperature, shock, and ESD limits; each needs a matching application claim and board check.

For the equipment-tag example, the first pass is not “use every ADXL345 feature.” The first pass is to decide which product statements the part must support. Orientation detection needs a gravity reference, axis convention, offset tolerance, and calibration plan. Motion detection needs a data rate, threshold, duration, interrupt route, host wake sequence, and false-positive test. Drop evidence needs a range decision, saturation check, mounting review, and a policy for events outside the measurable envelope. Reading the datasheet through those claims keeps the design from treating an impressive feature list as proof.

• Selection claim: The range, resolution, interface, package, and power modes fit the motion and board constraints.
• Firmware claim: Register settings for data format, bandwidth/rate, power mode, FIFO, and interrupts match the datasheet assumptions.
• Bench claim: Identity read, axis orientation, clipping, current, FIFO behavior, interrupt timing, and calibration are observed on the assembled board.

24.8 Convert Rows to Behavior

Do not stop at “ADXL345 supports interrupts.” Decide which interrupt source is needed and what the host will do with it. Activity/inactivity may support wake-on-motion. Data-ready may support fixed-rate sampling. FIFO watermark may let the MCU sleep between bursts. Free-fall or tap features may be useful for an interaction or handling claim, but only if thresholds, duration settings, interrupt mapping, and false-positive behavior are reviewed.

Make the interface choice explicit. SPI can be attractive when bus traffic, timing, or device addressing makes I2C awkward. I2C can save pins when timing and bus sharing are acceptable. Either way, the design needs sensor supply, I/O supply, pullups or chip-select behavior, logic levels, bus speed, driver support, and a traceable device-ID read. The firmware settings should be saved beside the bench log, not hidden inside a source file.

Turn the rows into a small configuration record before writing the driver. The record should name the selected range, full-resolution mode decision, output data rate, power mode, FIFO mode, interrupt sources, interrupt pins, threshold and duration values, and whether offset registers are used or calibration is applied in host software. It should also name the exact bench observations: DEVID read, DATA_FORMAT and BW_RATE readback, POWER_CTL measurement state, FIFO_CTL behavior, INT_SOURCE transitions, and raw DATAX/DATAY/DATAZ samples under known orientations.

For a battery tag, the practitioner decision is usually a trade between missed events and excess wakeups. A narrow range gives more useful low-motion detail but can clip handling shocks. A high output data rate can catch short events but costs host reads and may fill the FIFO sooner. A low-power mode can reduce current but may change noise and timing behavior. A threshold that works on a desk may fail on a vibrating vehicle or during shipping. Capture those tradeoffs in the release note so the next engineer can retest the exact assumptions.

1. Choose range from the motion envelope. Check orientation, handling, installation, transport, and shock events before picking a narrow range.
2. Choose data rate from the algorithm. Match output data rate and bandwidth to the motion feature, host read budget, FIFO strategy, and aliasing risk.
3. Choose interrupt behavior from the power budget. Verify whether the host wakes on useful events, stays asleep during background vibration, and drains FIFO data without loss.

24.9 Counts Need Product Meaning

Raw accelerometer counts are affected by range, data format, offset, noise, bandwidth, axis orientation, mounting, temperature, host timing, and filtering. A full-resolution setting may preserve scale across ranges, but firmware still needs to parse the data format correctly and prove that the selected range does not clip the real motion. A static gravity check can catch axis sign and orientation errors before those errors become application logic.

The product-level question is usually not “does the chip measure acceleration?” It is whether the assembled product can distinguish useful motion from noise, vibration, transport handling, user interaction, and fault states. That requires board-level traces, current logs, raw-sample captures, threshold sweeps, interrupt waveforms, calibration notes, and field-pilot follow-up when the installation environment is not yet known.

The under-the-hood risk is that several conversions sit between the MEMS structure and the release decision. The sensor produces signed digital samples whose meaning depends on range and resolution settings. The PCB fixes the physical axis orientation, but the enclosure, mounting adhesive, connector direction, and installed pose decide what those axes mean in the product. The host driver chooses burst reads, FIFO draining, interrupt clearing, debounce policy, and filtering. A mistake at any layer can make gravity look inverted, make short shocks disappear, or make normal vibration look like a handling event.

Good bench evidence separates those layers. A six-orientation static test checks sign and scale before dynamic testing. A slow rotation or known tilt fixture checks angle behavior and offset. A bus trace checks that multi-byte reads do not mix old and new samples. A current log checks standby, measurement, and host-wake behavior under the chosen settings. An interrupt trace checks latch, clear, mapping, and host latency. A vibration or transport test checks whether thresholds survive the actual environment. Only after those checks should the release record say what the ADXL345 configuration proves.

• Data path: DATA_FORMAT, BW_RATE, POWER_CTL, FIFO_CTL, INT_ENABLE, INT_MAP, INT_SOURCE, and sample readout behavior.
• Physical path: Package orientation, PCB axis mapping, rail measurement, bus pullups, mechanical mounting, vibration, and temperature exposure.
• Decision path: The exact application behavior accepted, rejected, or deferred because of the accelerometer evidence.

24.10 Prerequisites

You should already be comfortable with:

• Specification Sheet Fundamentals: absolute maximum ratings, recommended operating conditions, timing, and package information.
• Sensor Selection Process: gates, evidence matrices, and selection summaries before this concrete part case study.
• Sensor Specifications: range, resolution, bandwidth, noise, calibration, and drift.
• Simulation-Driven Testing and Validation: evidence layers, model boundaries, and release records.

24.11 What This Chapter Adds

The previous datasheet-reading chapters explain how to read a specification sheet. This chapter walks one sensor through a design decision. We will use ADXL345 as a representative low-power, 3-axis digital accelerometer because its public datasheet includes the sections IoT designers commonly need: measurement range, digital interface, output data rate, FIFO, interrupts, power modes, package, and environmental limits.

The What This Chapter Adds argument uses Figure 24.2 to compare Feasibility. Look next for Overview before accepting Accelerometer evidence should come from the datasheet sections that match the current decision phase instead of from a page-by-page reading habit as a design claim.

Read Figure 24.2 from feasibility through selection, then continue to schematic, layout, firmware, and production. The lists change from broad capabilities to electrical details, implementation instructions, and quality evidence. Choose the datasheet sections that answer the current decision.

24.12 Case Study Brief

Assume an IoT team is designing a battery-powered equipment tag that needs to detect orientation changes, movement events, and possible drops. The device uses a small MCU with a 3.3 V rail and can wake from an interrupt pin.

24.13 ADXL345 Rows to Selection

The ADXL345 datasheet becomes useful when the team reads it against one product behavior at a time. The route below starts with the motion claim, extracts only the relevant rows, turns those rows into board and firmware choices, and then checks the assembled device before release.

Use the evidence route introduced in the overview. Do not read the datasheet as a passive document from front to back. Read it as evidence for the claims your design needs to make.

24.14 Extract the Critical Rows

For the ADXL345 example, the first extraction pass should produce a small selection table, not a copied datasheet.

24.15 Continue to the Next Part

Carry this evidence into Accelerometer Datasheets: Validation Evidence, which begins with Read Test Conditions First.