You have a handheld prototype and want to compare two ways of supporting the electronics inside its case. After a controlled knock or drop, both versions still turn on. Did one protect the board better? An accelerometer can help answer that, but only if the sensor, its mounting and the recording method suit the event.
On our bench we connected a GraftSense H3LIS200DL high-range accelerometer module to a GraftPort-RP2040 board and printed three-axis readings in MicroPython. This note explains what that output shows, and what has to change before the same setup can compare impacts on a prototype.
Start with the part you want to protect
An accelerometer measures acceleration where it is mounted. A sensor on a rigid board support can behave differently from one on a flexible case wall. Before choosing a sensor, decide what the result should represent: the outer enclosure, the internal board, or another part of the assembly.
That also decides whether one measurement point is enough. In a March 2020 Arduino forum discussion, a developer planning repeated product drop tests wanted readings from several positions, synchronized timestamps and saved files for comparison. The thread raised questions about range, timing and synchronization; it did not settle on a finished test system.
For a first comparison, keep the sensor location, orientation and attachment method the same in every run. Record which way the chip axes point relative to the enclosure, plus the prototype revision and the support material used in each trial. Otherwise a difference in the trace may come from moving the sensor rather than from improving the design.
High range comes with a tradeoff
The H3LIS200DL offers selectable ±100 g and ±200 g ranges. Here g is the acceleration unit, not grams. A high range helps avoid clipping a large acceleration, but it does not make the sensor a precise instrument for small movements or gentle tilt.
ST's datasheet specifies 8-bit output, with typical sensitivities of 0.78 g per count at ±100 g and 1.56 g per count at ±200 g. Some module descriptions quote 12-bit resolution and 49 mg steps; those numbers do not describe this device. Printing two decimal places cannot add detail the sensor does not supply.
For an enclosure comparison, ask whether the differences you expect are large enough to see at the chosen range and resolution. Keep three quantities separate: the acceleration the sensor measures, the force on a part, and whether the part was damaged. A high reading alone does not tell you the load on a connector or give the product a drop rating.
Reproduce a simple connection first
We connected the module to the controller's I2C0 port with a four-wire HY2.0 cable: GPIO 4 is SDA and GPIO 5 is SCL. The module takes +5 V at its connector and regulates it to 3.3 V for the sensor, with I2C pull-ups to 3.3 V. Keep the module's input requirement and the bare sensor's supply requirement distinct. An address pad on the module selects the seven-bit I2C address, 0x18 or 0x19.
Run an I2C scan before reading acceleration. Ours found 0x19. If your board answers at 0x18, pass that address to the driver; a driver that silently falls back to its default address will fail in a confusing way.
Get readable axis values before building a recorder
We installed version 1.0.0 of a packaged H3LIS200DL driver, based on Jose D. Montoya's MicroPython_H3LIS200DL library (MIT). The sketch below makes the address, range and output rate explicit and keeps a slow, readable console loop. It is a connection and configuration check, not an impact recorder, and we have not rerun this exact version on hardware.
i2c = I2C(0, sda=Pin(4), scl=Pin(5), freq=400000)
found = i2c.scan()
address = next((a for a in (0x18, 0x19) if a in found), None)
sensor = h3lis200dl.H3LIS200DL(i2c, address=address)
sensor.full_scale_selection = h3lis200dl.SCALE_100G
sensor.data_rate = h3lis200dl.RATE_50HZ
while True:
x, y, z = sensor.acceleration
print("x: {:.2f}g, y: {:.2f}g, z: {:.2f}g".format(x, y, z))
time.sleep(0.5)
The library converts each signed 8-bit axis value into g. Check that the range set in the device agrees with the scale the software uses. If you swap drivers or sensors, revisit the register format and units rather than copying a multiplication factor.
Our terminal showed initialization at 0x19. The first visible line held larger values, followed mostly by zeros on X and Y and either zero or about 0.78 g on Z, which is one count at the ±100 g range. That demonstrates a stream of readings. There was no timestamped drop, known impact condition or reference trace, so the larger first line cannot be called a measured impact peak.
Establish what a number means before using it to judge the mechanics. Raw negative values and the size of each output step are a common source of confusion with high-range parts.
The sensor's output rate is not your recording rate
The loop above pauses half a second after each reading. A brief impact can start and finish inside that pause. Raising the sensor's output rate while leaving the slow print loop alone does not turn the program into a peak recorder.
Think of the work in three stages: the sensor produces measurements, the controller collects them, and the program saves or displays them. Each stage has to keep up with the event. The H3LIS200DL's maximum stated output rate is 1 kHz; whether that is enough depends on the duration and frequency content of your actual impact. It is not a universal drop-test specification.
The library's acceleration property reads X, Y and Z in separate I2C transactions. It does not build a timestamped event buffer or check the data-overrun status for you. An overrun means a newer measurement replaced one before it was read. That matters when you compare peaks or the shape of an event, even if the console output looks reasonable.
For a recorder, separate capture from slow display or file formatting, record actual timing, and check for missed data. Decide how much to keep before and after the event so you can tell the impact from the movement leading up to it. These are development tasks still ahead; the half-second console loop does not demonstrate them.
The chip has interrupt outputs, but on this module INT1 and INT2 are not connected to the four-wire interface. An interrupt-triggered approach means checking the board connections as well as the software. A feature in a chip datasheet is not necessarily reachable through a module's cable.
Make the comparison repeatable
Back to the two enclosure-support designs. Define the event, mounting location, orientation and recording settings before comparing them. Photograph each assembly and give every run an identifier. Examine the whole trace for clipping, missing samples and timing changes before comparing a peak number.
Then inspect what happened to the product: connections, mounting points, and the function that matters to the user. Acceleration data and physical inspection answer different parts of the question. If the capture system cannot resolve the event, or the result has to support a formal requirement, choose a suitable measurement and test setup instead of extrapolating from this demonstration.