Math Bridge: Accelerometer range and bits

← Back to Accelerometer Datasheet Case Study
Math BridgeDesign MethodologyStruggle-friendly runway

How can 4 mg/LSB stay fixed while the range grows?

Follow a fixed scale factor into code count, used bits, and the bandwidth boundary attached to output data rate.

Blueprint Bina, the design guideBlueprint Bina guides
The one targetTurn range and scale into required bits.
The chapter case±2, ±4, ±8, ±16 g at 4.00 mg/LSB.
What it buys youA datasheet claim tied to firmware and event bandwidth.

A field team has a real problem to settle: How can 4 mg/LSB stay fixed while the range grows? They must decide what happens before they change full scale on the device. Predict the direction first.

See the relationship first

The figure reads from left to right. The blue card is full scale. The middle card uses this page's rule. The green card is codes per side. Follow the arrows: set the input, use the rule, then read the result and its unit.

The audit later on checks more than one number. Here, the added model uses the baseline named below and holds every other chapter value fixed. That sentence bridges the fixtures, so the numbers do not change without a reason.

Full scale changes codes per side An input card leads through the page rule to the codes per side result. SET INPUT ONE CONTROL USE RULE predict calculate check units READ RESULT
Follow the arrows. Range and scale set how many code buckets are needed; sample rate sets which motion frequencies can be represented.

Derive the baseline in four moves

  1. 1

    Name the input. The chapter baseline for full scale is 16.

  2. 2

    Name the rule. At ±16 g: 16,000/4=4,000 codes per side 8,000 total codes; log₂(8000)=12.97, so 13 bits At ±2/4/8 g the result is 10/11/12 bits ODR=100 Hz gives BW=50.0 Hz

  3. 3

    Put in the chapter value. Set full scale to 16. The page rule gives codes per side as 4000 counts.

  4. 4

    Read the result. Keep counts next to the value. Use it only within the limits on this page.

Predict, then change full scale

Try Predict what happens to codes per side. Move one control, calculate, then check your idea.

16
Chapter baseline
Codes per side

Observe Range and scale set how many code buckets are needed; sample rate sets which motion frequencies can be represented. Reset to 16 and compare codes per side.

Explain Only full scale moves here. The other chapter values stay fixed.

Check yourself

What should you do before you trust the result?
Answer: Predict its direction, use the shown rule, keep the units, and reset to the worked baseline.
What does this small model leave out?
Answer: Only full scale moves. Field effects named in the page limits stay fixed.

Honesty note. This teaching model changes only full scale. It replays the chapter baseline; it is not a field prediction.

1. A code is one fixed-size bucket

At 4 mg/LSB, each count represents four milligravity units. A wider positive-and-negative range needs more buckets. The bucket size stays fixed; the number of addressed buckets grows.

Blueprint Bina: Separate the 16-bit output container from the bits actually needed for a selected range.

2. Name the algebra moves

1

Use both signsTotal span is 2×FS.

2

Count bucketscodes=(2×FS×1000 mg/g)/(4 mg/LSB).

3

Undo powers of twoN=log₂(codes).

4

Round upwardA fraction of a bit still needs the next whole bit.

5

Bind the rateBW=ODR/2 sets the Nyquist ceiling.

3. Reproduce the widest range

At ±16 g: 16,000/4=4,000 codes per side
8,000 total codes; log₂(8000)=12.97, so 13 bits
At ±2/4/8 g the result is 10/11/12 bits
ODR=100 Hz gives BW=50.0 Hz

Every doubled range needs one more bit because doubling a code count adds exactly one to its base-two logarithm.

4. Try the full-scale range

TryMove from ±16 g toward a narrower range while the 4 mg/LSB scale stays fixed.

Full scale
Codes per side
Total codes
Exact bits
Whole bits needed
Nyquist bandwidth

ObserveNarrowing the range reduces code count. The 50 Hz bandwidth stays fixed because this control does not change ODR.

ExplainRange and scale set how many code buckets are needed; sample rate sets which motion frequencies can be represented.

Technical boundaries.

This is a digital-scale ledger, not a complete MEMS model.

Scale
Offset, noise, nonlinearity, calibration, and temperature still change usable accuracy
Bits
A 16-bit register does not guarantee 16 meaningful measurement bits
Bandwidth
Filters and mechanical response also shape the signal before sampling

Verify register settings, orientation, clipping, noise, and real event spectra on the assembled product.

5. Test the motion claim

Use known tilts and controlled impacts at each selected range. Record clipping, code scale, noise, filter delay, and missed high-frequency content.

6. Record the configuration state

Store part revision, DATA_FORMAT, BW_RATE, range, full-resolution mode, ODR, filter, mount orientation, calibration, and raw bench traces.

7. Check yourself

Why does doubling range add one bit?
Answer: It doubles code count, and log₂(2x)=log₂(x)+1.
Does a 16-bit output mean all 16 bits carry range information?
Answer: No. This case needs 10 to 13 bits depending on range.
Does 50 Hz bandwidth prove a drop is captured?
Answer: No. The event spectrum, filters, clipping, and timing need bench evidence.
Honesty boundary.

The 4 mg/LSB and four ranges reproduce the chapter's ADXL345-style teaching case.

4 mg/LSB
Fixed nominal full-resolution scale used by the chapter
10–13 bits
Code capacity, not effective-noise-free resolution
50 Hz
Nyquist ceiling from 100 Hz ODR, not a complete transfer function

Correct, not complete: code arithmetic does not qualify an accelerometer product claim.

Return to Accelerometer Datasheet Case Study with the maths unpacked →