Y axis, 800Hz ODR
-5
0
1
2
-3
-1
1
0
2
2
0
2
2
0
2
1
1022
-14
-16
-11
-17
-14
-19
-12
-11
-14
-14
-11
-14
-11
-14
-14
-13
-11
-13
-13
-10
-13
-11
-15
-11
-11
-9
ADXL372
Recommended for New Designs
The ADXL372 is an ultralow power, 3-axis, ±200 g MEMS accelerometer that consumes 22 µA at a 3200 Hz output data rate (ODR). The ADXL372 does not power...
Datasheet
ADXL372 on Analog.com
LTC6906
Production
The LTC6906 is a precision programmable oscillator that is versatile, compact and easy-to-use. Micropower operation benefits portable and battery-powered...
Datasheet
LTC6906 on Analog.com
Hi jwang,
The problem is very, very hard to pin down. On my dev board the accelerometers are failing instantly, yet on production boards they _seem_ to be working. However we are in the process of adding debugging to our production boards because we can't see the signals so they may be failing and recovering without us knowing. Sorry for being so vague!
However, you asked for a schematic and here it is:
And for a waveform capture (but this is the SiT1569). Note this capture has "persistence" turned on which is why it looks so fat:
Yes I did try at 3200Hz and lower ones too. None helped.
As you may know I've another open ticket https://ez.analog.com/mems/f/q-a/116556/adxl372-ext_clock-at-above-307-2khz-seems-to-cause-extra-readings/347849 sort-of related to this issue and our current thinking is to switch all three accelerometers to use their internal clocks. But this means they won't be synchronised so could prove to be a problem for our product. To understand if this is the right thing to do, we really just need to know if EXT_CLOCK _may_ be known to sometimes be unreliable and if INT_CLOCK is the only way to be sure of never getting a spurious trigger or missed sample.
Thanks for your help!
The internal clock shift from part to part which can be more than 10% difference among multiple parts. So it's not suggested to use the internal clock for synchronization. We haven't seen the "spurious acceleration" before as you mentioned to the max g, from your reading, it's 1024 which is close to half of the max g range. So let's talk about the LTC6906 first, are you able to provide the waveform as well? I'm still speculating this is caused by the input clock signal. And when you enable 3 axes at the same time, does this also happen every 10 seconds? Can you send me the raw data from 3 axes as well? I'd like to check if any data misalignment happens at any chance.
The internal clock shift from part to part which can be more than 10% difference among multiple parts. So it's not suggested to use the internal clock for synchronization. We haven't seen the "spurious acceleration" before as you mentioned to the max g, from your reading, it's 1024 which is close to half of the max g range. So let's talk about the LTC6906 first, are you able to provide the waveform as well? I'm still speculating this is caused by the input clock signal. And when you enable 3 axes at the same time, does this also happen every 10 seconds? Can you send me the raw data from 3 axes as well? I'd like to check if any data misalignment happens at any chance.