17 Accelerometer Datasheet Case Study
Turning ADXL345 Specifications Into Design Evidence
17.1 Start With the Acceleration Claim
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.
17.2 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.
17.3 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.
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.
17.4 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.
- Choose range from the motion envelope. Check orientation, handling, installation, transport, and shock events before picking a narrow range.
- Choose data rate from the algorithm. Match output data rate and bandwidth to the motion feature, host read budget, FIFO strategy, and aliasing risk.
- 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.
17.5 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.
Phoebe’s Why
This chapter says several conversions sit between the MEMS structure and the release decision without naming the first one: the mechanical-to-electrical step inside the package itself. A MEMS accelerometer is a tiny proof mass held by springs etched into silicon. Acceleration pushes the mass, the springs push back, and the mass settles at a displacement proportional to acceleration – Hooke’s law doing the sensing. That displacement is far too small to wire out directly, so the mass itself forms one plate of a capacitor whose gap changes as it moves; a differential pair of capacitors on either side turns a tiny displacement into a measurable capacitance imbalance, which the chip’s own electronics convert to a digital count. The reason full-resolution mode can hold a constant 4 mg per LSB across every selectable range is that this same physical structure and the same capacitance-to-digital chain runs underneath all four ranges – only how many of the 16 output bits get used actually changes.
The Derivation
Spring-mass displacement under acceleration (Hooke’s law, Newton’s second law):
\[F = ma = kx \quad\Longrightarrow\quad x = \frac{ma}{k}\]
Parallel-plate capacitance and its sensitivity to gap, the basis of differential capacitive sensing:
\[C = \frac{\varepsilon_0\varepsilon_r A}{d} \quad\Longrightarrow\quad \frac{\Delta C}{C_0} \approx \frac{2\Delta d}{d_0}\ \text{(differential pair)}\]
Bits needed to represent a full-scale range at a fixed LSB weight:
\[N_{bits} = \log_2\!\left(\frac{2\times\text{full-scale}}{\mathrm{LSB}}\right)\]
Internal antialiasing bandwidth tracks the selected output data rate:
\[\mathrm{BW} = \frac{\mathrm{ODR}}{2}, \qquad \text{Nyquist ceiling: content above BW folds back}\]
Worked Numbers: This Chapter’s Own 4 mg/LSB Across Its Four Ranges
Using this chapter’s own stated full-resolution scale factor of \(4.00\) mg/LSB:
| Range (this chapter’s own) | Full scale | Codes needed | Bits used |
|---|---|---|---|
| \(\pm2\) g | \(2000\) mg | \(2000/4.00 = 500\)/side, \(1000\) total | \(\log_2(1000)=9.97\to10\) |
| \(\pm4\) g | \(4000\) mg | \(1000\)/side, \(2000\) total | \(10.97\to11\) |
| \(\pm8\) g | \(8000\) mg | \(2000\)/side, \(4000\) total | \(11.97\to12\) |
| \(\pm16\) g | \(16{,}000\) mg | \(4000\)/side, \(8000\) total | \(12.97\to13\) |
The bit count climbs by exactly one for each doubled range while the 4 mg/LSB weight stays fixed – the arithmetic behind “full-resolution mode preserves scale across ranges,” and it uses only 10-13 of the part’s 16 output bits depending on range, never all 16 at once.
Aliasing risk, worked: selecting an output data rate of \(100\) Hz gives an internal antialiasing bandwidth of \(\mathrm{BW}=100/2=50.0\) Hz. A handling knock or drop event with real spectral content above \(50.0\) Hz will fold back into the passband instead of vanishing – exactly this chapter’s own warning to match “output data rate and bandwidth to the motion feature… and aliasing risk,” now with the Nyquist ceiling that phrase was pointing at made explicit.
17.6 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.
17.7 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.
Start from use
The important rows depend on the application: tilt, step detection, asset motion, shock flag, or low-power wake.
Read only what matters
Range, resolution, data rate, interface voltage, current mode, FIFO, interrupt, and package rows become decision inputs.
Map rows to firmware
Register settings must reflect the datasheet assumptions: range, full-resolution mode, data rate, power state, FIFO mode, and interrupts.
Datasheet is not release
Bench checks still need to prove board wiring, host timing, current draw, interrupt behavior, and calibration for your build.
ADXL345 is used here because the public documentation is clear and familiar. A real product still needs a current availability check, lifecycle review, package review, regulatory context, mechanical fit, firmware support review, and bench qualification.
17.8 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.
17.9 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.
17.10 Extract the Critical Rows
For the ADXL345 example, the first extraction pass should produce a small selection table, not a copied datasheet.
A typical current, data rate, offset, or timing value only applies under stated test conditions. A release record should name the datasheet section, the operating condition assumed, and the bench evidence used to confirm the board behaves acceptably.
17.11 Range and Resolution
Accelerometer range selection starts with clipping risk. Resolution only matters after the sensor can survive and represent the acceleration range the product will see.
Small motion
Gravity-dominated orientation use cases often prefer a low range, provided installation shocks and transport events are handled separately.
Human activity
Movement detection needs enough range for normal events and enough data-rate margin for the chosen algorithm.
Transient events
Drop or impact claims need a range and sampling plan that can capture the event without saturating the output.
Bench before release
Shake, orient, rotate, and tap the assembled board while logging raw samples so range and axis assumptions are visible.
In ADXL345 full-resolution mode, the scale factor remains about 4 mg per LSB while the selected range changes the full-scale limit. That means range choice is mainly about avoiding clipping and matching expected acceleration, while the firmware must also confirm the resolution mode used.
17.12 Interface, Voltage, and Host Fit
A common datasheet failure is checking the sensor supply but missing the I/O voltage and bus timing. The ADXL345 separates sensor supply and I/O supply. Your schematic review must show both are valid for the selected host and bus.
17.13 Firmware Settings Become Evidence
The firmware configuration is where the datasheet becomes behavior. Record the register choices as part of the design, not as hidden implementation detail.
accelerometer selection note:
part: ADXL345
application claim: wake the equipment tag on movement and record orientation
bus: selected host bus and voltage domain
range setting: selected g range and clipping rationale
data format: full-resolution or fixed-resolution mode
data rate: selected output data rate and bandwidth rationale
power mode: measurement, standby, and low-power behavior
interrupt plan: activity, inactivity, data-ready, or FIFO watermark
FIFO plan: mode, watermark, host read policy
calibration: offset method and temperature assumptions
bench evidence: rail, bus trace, sample log, interrupt log, current logIf a release record cannot say which range, data format, output data rate, FIFO mode, interrupt mapping, and power mode are configured, the datasheet review is incomplete. Defaults may be useful for first communication, but release behavior should be explicit.
17.14 Power, FIFO, and Interrupt Strategy
Low-power accelerometer design is not only about the sensor current. It is about how often the sensor wakes the host, how much data the host must read, and whether the firmware can distinguish useful motion from background movement.
17.15 Range, Noise, and Release Decision
The release decision should not say “ADXL345 supports motion detection.” It should say something like:
The selected ADXL345 range did not clip during the representative movement bench test, the configured output data rate produced enough samples for the firmware algorithm, FIFO watermark interrupts woke the host as expected, and the residual risk is untested installation vibration in the first pilot batch.
17.16 Bench Validation Summary
The bench summary turns datasheet interpretation into reviewable evidence.
17.17 Incremental Examples
17.17.1 Confirm Communication and Axes
A first bench pass can use an Arduino, Raspberry Pi Pico, or ESP32 board with an ADXL345 breakout over I2C. The firmware reads the device ID register, configures a low output data rate, logs raw X/Y/Z counts, and checks the board in six known orientations. A Saleae Logic, Bus Pirate, or sigrok/PulseView capture can confirm the I2C address, register reads, and pullup voltage. This evidence proves communication and axis mapping; it does not yet prove wake-on-motion, battery life, or field vibration behavior.
17.17.3 Validate Drop and Orientation
A field-ready product should repeat the selection check across board revision, enclosure orientation, firmware hash, and installation profile. The team logs burst samples from the FIFO during handling and drop-surrogate tests, compares clipping against the selected +/-g range, verifies SPI or I2C burst-read timing, records package orientation in the assembly drawing, and stores calibration assumptions beside the test logs. If the enclosure changes axis orientation or damping, the accelerometer decision must be rerun instead of copied from an earlier prototype.
17.18 Try It Now
Write a five-line ADXL345 selection note for a battery-powered asset tag:
| Field | Your answer |
|---|---|
| Motion claim | Orientation, movement, shock, or wake behavior being supported. |
| Datasheet rows | Range, output data rate, interface, power, FIFO, interrupt, package, or environment rows used. |
| Firmware settings | Register choices that make the datasheet rows real in the product. |
| Bench evidence | Bus trace, raw-sample log, current log, interrupt waveform, axis check, or calibration note. |
| Residual risk | The installation, temperature, vibration, enclosure, or field behavior still not proven. |
17.19 Choose ADXL345 Evidence
For each claim, choose one datasheet row and one bench check:
- The tag wakes only on meaningful movement during warehouse handling.
- The device can detect tilt changes without clipping during installation.
- The MCU can sleep while the accelerometer buffers samples.
17.20 Practice Checks
17.21 Common Pitfalls
“Supports FIFO” or “supports interrupts” is not enough. The review must show how the firmware configures the feature and how bench evidence proves it works on the board.
Range selection should come from expected acceleration, installation, shipping, handling, and field events. A low range can produce clean-looking data until the first real event clips.
Checking only the sensor supply can miss an incompatible pullup rail or host logic level. Record both sensor supply and I/O supply assumptions.
The package drawing and PCB orientation decide how X, Y, and Z map to the enclosure. Record polarity and orientation before writing release logic.
Raw accelerometer output includes offset and variation. A release record should state whether the product uses factory trim, board-level calibration, field calibration, software compensation, or no compensation.
17.22 Summary
An accelerometer datasheet becomes useful when it is connected to a design claim. In this case study, ADXL345 rows for range, resolution, supply, I/O, interface, power modes, FIFO, interrupts, package, and environment become a selection note. The strongest workflow is to extract the relevant rows, configure firmware explicitly, verify board behavior on the bench, and record residual risk. The datasheet supports the decision, but the assembled product still needs evidence.
17.23 References
- Analog Devices ADXL345 Product Page - official product overview, feature summary, documentation links, and part information.
- ADXL345 Data Sheet - official data sheet for electrical, timing, register, package, and operating specifications.
- AN-1077: ADXL345 Quick Start Guide - official application note for initial configuration and self-test orientation.
- AN-1025: Utilization of the FIFO Buffer in ADI Digital Accelerometers - official application note for FIFO modes and host interaction.
- AN-1057: Using an Accelerometer for Inclination Sensing - official application note for tilt and inclination measurement concepts.
- Best Engineering Practices When Using ADXL Accelerometers - Analog Devices engineering guidance for ADXL accelerometer use.
17.24 See Also
- Specification Sheet Fundamentals: review how limits, typical values, and test conditions should be read before copying a datasheet row.
- Sensor Selection Process: compare this ADXL345 case study with a broader sensor shortlist and scoring workflow.
- Testing and Validation: turn the selected accelerometer settings into release-gate tests.
- Simulation-Driven Testing and Validation: decide where simulation, bench evidence, and field pilots each belong.
17.25 What’s Next
| If you want to… | Read this |
|---|---|
| Review datasheet vocabulary and limits | Specification Sheet Fundamentals |
| Compare sensor parameters beyond accelerometers | Sensor Selection Process |
| Connect datasheet choices to automotive constraints | Automotive Applications |
| Turn selected parts into release tests | Testing and Validation |
| Review simulation and bench evidence together | Simulation-Driven Testing and Validation |
| Previous | Current | Next |
|---|---|---|
| Simulation-Driven Testing and Validation | Accelerometer Datasheet Case Study | Automotive Applications |
17.26 Key Takeaway
The accelerometer case study shows why part selection depends on range, noise, bandwidth, power, interface, and calibration needs. The best component is the one whose real limits fit the application.