ADXL367 Accelerometer Overview¶

Introduction¶

The ADXL367 is an ultra-low-power, 3-axis digital MEMS accelerometer from Analog Devices, designed for battery-powered, always-on monitoring, and event wake-up scenarios. While maintaining very low system power consumption, it provides stable 3-axis acceleration sensing for motion detection, posture recognition, activity monitoring, and edge-triggered IoT applications.

Compared with higher-precision but higher-power accelerometers, the ADXL367 emphasizes ultra-low-power, long-duration online operation. It is commonly used in a system architecture of low-power front-end screening plus event-triggered deep acquisition.

Key Features (Summary)¶

• Ultra-low power: typical 0.89 uA at 100 Hz; about 180 nA in motion wake-up mode; about 40 nA in standby
• Selectable measurement ranges: +-2 g, +-4 g, +-8 g
• Digital interfaces: SPI (4-wire) and I2C
• Resolution: 14-bit (with compatible 12-bit / 8-bit output formats)
• Low noise: typical noise density down to about 170 ug/sqrt(Hz)
• Configurable ODR: commonly up to 400 Hz
• Built-in FIFO: 512 samples
• Integrated temperature sensor and activity/inactivity detection capability
• Wide supply range: 1.1 V to 3.6 V
• Suitable for always-on monitoring, event triggering, and battery-powered devices

Typical Applications¶

• Always-on motion monitoring and interrupt wake-up
• Wearables and portable terminals
• Battery-powered IoT nodes
• Posture detection, drop/vibration event detection
• Low-power edge sensing and intelligent triggering

Technical Specifications (Quick Table)¶

Evaluation Board¶

Wiring¶

As shown above, ADXL367 uses I2C wiring in this project, avoiding SPI bus sharing with ADXL355.

The interface mapping is as follows:

Official Driver Reference¶

Driver in this project (node_acc_adxl367)¶

What this block is for¶

The repository ships a dedicated ESP-IDF component that turns the ADXL367 into a node-local accelerometer service: one I2C address, one node_acc_adxl367_dev_t state object, and a consistent API for bring-up, configuration, raw reads, FIFO, interrupts, and on-chip motion detection. It is intended to sit between your application (or the bundled test harness) and the physical sensor.

Where it sits in software¶

All transfers use I2C only. The driver never calls the ESP-IDF I2C API directly; it goes through driver/node_i2c. Register writes, 14-bit packing, and timing-sensitive flows follow Analog’s reference implementation under driver/ref-adxl367 (same ideas as adxl367.c).

flowchart TB
    subgraph application_layer [Application]
        APP[Your firmware]
        TST[node_acc_adxl367_test.c]
    end
    subgraph driver_layer [This component]
        API[node_acc_adxl367.c / .h]
    end
    subgraph bus_layer [Bus abstraction]
        I2C[node_i2c]
    end
    IC[(ADXL367)]
    APP --> API
    TST --> API
    API --> I2C
    I2C --> IC

node_acc_adxl367_dev_t caches the open I2C handle plus the last known range, ODR, power mode, measurement mode (accel/temp mix), and FIFO mode so callers and the implementation stay consistent.

Repository layout¶

Functional map (what you can configure and read)¶

Test phases (what is proven before you integrate)¶

The test source groups behaviour into phases so you can align application design with verified capability.

Pin macros and board-specific GPIO wiring for interrupts live in the test file; align them with the wiring tables earlier in this page.

Structural health monitoring (SHM): how this maps to monitoring tasks¶

SHM pipelines usually separate (a) long idle or low-rate observation from (b) higher-rate capture when the structure is excited or when an anomaly is suspected. The driver exposes hardware that matches that split.

Suggested data-flow for a node (conceptual, not a single API call):

flowchart LR
    A[Configure ODR / range / FIFO or ACT] --> B{Idle sampling or event}
    B -->|Timer or link| C[Read STATUS / drain FIFO]
    C --> D[Feature extraction<br/>RMS, bands, spectrum]
    D --> E[Telemetry or local alarm]

In short: the driver does not implement damage models; it gives you deterministic access to the ADXL367 features that SHM workflows typically need—threshold-based attention, buffered windows for dynamics, and environmental context via temperature—so higher-level SHM logic can stay in application code or on a gateway.