Post Go back to editing

ADXL372 EXT_CLOCK: spurious samples

Our product has 3 ADXL372 accelerometers and for the last few months we've had them connected to a development board, configured to use the EXT_CLOCK that is being generated at 307.2kHz from a CPU pin.  This has been working well.  Using the EXT_CLOCK pin allows us to keep all three accelerometers synchronised.  (We know EXT_SYNC is unreliable, hence avoid it, see https://ez.analog.com/mems/f/q-a/110729/adxl372-ext_sync-how-to-keep-3-accelerometers-in-sync )
 
Our first real prototype used a LTC6906 with a set resistor to adjust the clock to 307kHz.  In this configuration we would see a spurious acceleration of almost maximum g, usually just on one channel but sometimes on more.  This would usually occur every 10 seconds, more or less.  Eg, here's a one channel example (this is the raw reading from the accelerometer):
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
 
We had some other problems with the first prototype, so have quickly moved on to version 2, this time using a SiT1569 at 390kHz.  As this is above the 307.2kHz default, we have set the accelerometers to run at 6400Hz ODR to permit an EXT_CLOCK of max 614kHz.
 
However, we get immediate bad readings.  Either constant zeros, spurious signals or FIFO misalignment.  If we switch the accelerometer to use it's internal clock the problem readings immediately go away, although I did see some FIFO misalignment.
 
I should finally add that we have been unable to detect any obvious difference in signal quality of the EXT_CLOCK between the working dev board the 2 prototype boards.  The clock signals look nice and square, rail to rail.  But maybe our oscilloscope isn't showing the whole story.
 
So we would like to know how to get the ADXL372 to use the EXT_CLOCK signal reliably.  Is there any optimum settings, sample rate, signal conditioning or anything else that will make it robust?  Or is the EXT_CLOCK known to sometimes be problematic?
Thanks!
Parents
  • Hi Richard,

    Sorry for the late replay. I think this is a separate issue than the misalignment issue we talked on another thread.

    So did you say the external clock mode works fine with the clock derived from the uC but not the LTC6906 chip? Can you share the partial schematic and the clock waveform when using the LTC6906. 

    Apart from this, when using the SiT1569, can you switch the ODR to 3200Hz and see if the issue still happens, though it's 30% higher than the 307.2kHz clock. Extra care may need to be taken when running an external clock at a lower percentage of the default clock speed.

    Please let me know if this works for you.

Reply
  • Hi Richard,

    Sorry for the late replay. I think this is a separate issue than the misalignment issue we talked on another thread.

    So did you say the external clock mode works fine with the clock derived from the uC but not the LTC6906 chip? Can you share the partial schematic and the clock waveform when using the LTC6906. 

    Apart from this, when using the SiT1569, can you switch the ODR to 3200Hz and see if the issue still happens, though it's 30% higher than the 307.2kHz clock. Extra care may need to be taken when running an external clock at a lower percentage of the default clock speed.

    Please let me know if this works for you.

Children
No Data