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!
Hi jwang,
We're under pressure to deliver reliable readings so are currently working on a driver that will synchronise the accelerometers when they're using their internal clocks as we presume the external clock will continue to have issues. One outcome of the incomplete driver is this rather unscientific observation:
After leaving my Dev board in active mode for a while, here are the error totals (where an error is a flatline (accelerometer axis typically goes to 0) or FIFO misalignment (bit 1 incorrect for an axis):
Acc1Errors = 223
Acc2Errors = 124
Acc0Errors = 56
This is using the 390kHz External Clock with ODR set to 800Hz.
What's interesting, is the speed of each accelerometer's internal clock (I measure this when I switch to the internal clock, same board, same accelerometers):
ACC:1 Freq=840.776
ACC:2 Freq=818.043
ACC:0 Freq=777.172
Is it a coincidence that the faster the internal clock is, the more errors it has?
And FWIW, after 4 hours running on their internal clocks, I've had no errors from any of the accelerometers. This isn't an exhaustive test, but so far it's looking promising.
Hi jwang,
We're under pressure to deliver reliable readings so are currently working on a driver that will synchronise the accelerometers when they're using their internal clocks as we presume the external clock will continue to have issues. One outcome of the incomplete driver is this rather unscientific observation:
After leaving my Dev board in active mode for a while, here are the error totals (where an error is a flatline (accelerometer axis typically goes to 0) or FIFO misalignment (bit 1 incorrect for an axis):
Acc1Errors = 223
Acc2Errors = 124
Acc0Errors = 56
This is using the 390kHz External Clock with ODR set to 800Hz.
What's interesting, is the speed of each accelerometer's internal clock (I measure this when I switch to the internal clock, same board, same accelerometers):
ACC:1 Freq=840.776
ACC:2 Freq=818.043
ACC:0 Freq=777.172
Is it a coincidence that the faster the internal clock is, the more errors it has?
And FWIW, after 4 hours running on their internal clocks, I've had no errors from any of the accelerometers. This isn't an exhaustive test, but so far it's looking promising.
Thanks for the update, and it's good to hear so far so good by using the internal clock. We don't have enough characterization data yet to show the correlation between the internal clock speed and the number of errors that might occur but this is an interesting point to look into. The product line is currently working on the issue and will definitely take this into consideration.