Arduino sketches demonstrating operation of ST's LIS2DW12 low-power accelerometer. More discussion here.
The DataReady sketch shows how to configure the accelerometer power modes, full scale range, ODR and bandwidth. The sketch performs the self test, calculates the offset biases, and initializes the sensor for data measurement. The sketch sets up the data ready interrupt and reads the accelerometer data when the interrupt is triggered. Finally, the sketch outputs the data to the serial monitor when the RTC alarm is triggered (every second). The main loop is entirely interrupt based such that when no interrupt is being handled the STM32L432 MCU waits in a low-power (SLEEP or STOP) state.
The SleepWake sketch configures the two interrupts for wake and sleep detection. INT1 is chosen to be the wake interrupt and is configured to trigger when motion on one or any axis exceeds a user-programmable threshold (62 mg in the sketch) for a user programmable time (0.16s in the sketch). When the wake interrupt is triggered, the sketch checks the status register to determine what kind of wake event has occurred. The sketch uses the 32-sample FIFO to capture the acceleration data prior to and during the wake event for further diagnosis. If the accelerometer motion falls below the wake threshold for a user-programmable time (20s in the sketch), the sensor enters sleep mode. In sleep mode, the sensor runs at a fixed 12.5 Hz in the low-power state selected by the user. When entering sleep mode, an interrupt is triggered on INT2 and the FIFO is restarted.
Using this Sleep/Wake toggling the application can run at a high rate when in motion and automatically return to a low-power sleep state when the motion has stopped. Similarly, the application can sit in a low-power (as low as 1 uA) state while waiting for motion and then analyze the waking motion captured by the FIFO.
In LPMode2 (14-bit data) I measured ~6.3 uA when the LIS2DW12 is awake at 25 Hz, ~4.8 uA when it is asleep at 12.5 Hz and the Ladybug uses ~2.2 uA in STOP mode. So the LIS2DW12 is using ~4.1 uA (@3V3) when awake at 25 Hz compared to the 3 uA (@1V8) expected from Table 10 of the data sheet and ~2.6 uA (@3V3) when asleep at 12.5 Hz instead of the 1.6 uA (@1V8) from the data sheet. So there is a ~1 uA greater current usage than expected.
In LPMode1 (12-bit data) I measured 4.8 uA with FIFO active and 4.5 uA without (so there is a cost to use the FIFO) in wake mode at 25 Hz and 3.8 uA in sleep mode (3.7 uA w/o FIFO). So in the most likely (LPMode1) mode for wake-on-motion/sleep-on-no-motion functionality, the LIS2DW12 uses ~1.5 uA (@3V3, supposed to be 1 uA @1V8) in sleep mode. Compare with the 850 nA (@1V8) used in sleep mode by the BMA400 and the 0.3 uA (@3V3) I measured for the MC3635 in "sniff" mode. The sizes of all three sensors are the same, their cost is not. BMA400 (if you can find it, now out of production) is ~$3, LIS2DW12 is ~$1, and the MC3635 is ~$1.50 each for quantity 100.
The StationaryDetect sketch takes advantage of the built-in Android stationary mode. In this case, the same inactivity/activity detection is used as in the SleepWake sketch except by setting the stationary mode bit to 1 the power mode and ODR don't change when entering sleep mode. The sketch runs the sensor in lowest power mode LPMode1 at 1.6 Hz, which doesn't change whether awake or asleep. However, when the acceleration on any axis exceeds a user-set threshold (62 mg as in the SleepWake sketch) an interrupt is routed to INT1 as a wake event and when the acceleration remains below this threshold for longer than a user-specified time (10s in the sketch) an interrupt is routed to INT2 as a sleep (or for Android, a stationary) event. This allows the sensor to run at its lowest power state all of the time but still inform the host about motion and no-motion state changes, which is the functionality we want for wake-on-motion/sleep-on-no-motion applications.
In LPMode1 at 1.6 Hz with the low noise feature disabled and the FIFO in bypass (lowest power state) I measured 2.9 uA in either wake or sleep states. When I changed the RTC alarm rate to once per minute to provide a cleaner measurement of accelerometer power usage, the average current dropped to 2.75 uA, which is a more accurate measure IMHO. All of the numbers from the SleepWake sketch measurements are likely overestimates by 0.1-0.2 uA. So the wake-on-motion/sleep-on-no-motion functionality costs ~0.55 uA (@3V3) compared to the 0.38 uA (@1V8) from the data sheet. Close enough for government work.
The Stationary mode has the advantage over the SleepWake mode in that the power usage is minimal when the sensor is awake as well. The stationary mode is best when only the wake/sleep detect functionality is required. Otherwise, when the LIS2DW12 is being used to measure acceleration while awake, i.e, detect free fall or tap, etc the wake power mode and ODR would likely have to be different from stationary mode LPMode1 and 1.6 Hz.
The Tap_OrientationDetect sketch configures the sensor for embedded single- and double-tap detection and for 6D orientation change detection functions. The data ready interrupt is routed to INT2 so that the accelerometer data can be output every second on RTC alarm just like in the DataReady sketch. INT1 has routed to it the single- and double- tap and 6D-orientation-change interrupts. Upon triggering of INT1, the type of interrupt (i.e., orientation change, single or doubletap, etc) is printed to the serial monitor as well as the source of the interrupt (single tap on positive y-axis, orientation change to XH orientation, etc.) The latency between taps, the acceleration threshold and timing of the tap "shock" and quiet time after the tap "shock" are all configurable allowing the user to tailor the interaction to the specific application. The data sheet recommends using 400 Hz ODR for reliable single-/double-tap detection so this is not a low-power embedded function. For lower-power "single-tap" detection, I recommend the SleepWake sketch since a "tap" can be registered if the motion threshold and wake time are chosen small enough.
LIS2DW12 data sheet.
LIS2DW12 application note.
Sketches were developed using an STM32L432 Ladybug development board available on Tindie.
LIS2DW12 breakout board available in the OSH Park shared space here.