I have a product with 3 ADXL372 accelerometers. With a 390kHz EXT_CLOCK and an ODR of 6400Hz, I've got the accelerometer's in synch at the start, but they lose synch from the second FIFO read:
I counted the SPI clock edges and can confirm that each accelerometer received 3080 clock cycles (8(RegAddress) + 3(XYZ) * 16(2BytesPerValue) * 64(NofReadings) = 3080). Hence I've read exactly the same amount of data from each. I suppose the loss of synch must actually mean the accelerometers are either adding or losing samples.
The alignment problems remain at ODR = 1600, 3200. Yeah the data sheet says "thou shalt only use ODR 6400 for clock > 307kHz", but I thought it was worth a try.
Looking at our external clock signal, from the datasheet we can figure the number of clock cycles per sample as:
=> ClockHz / ODR
=> 614400 / 6400 = 96 clocks per sample
So for 64 samples, 64 * 96 = 6144 clocks. Here's a capture showing the second reading (all INT signals were aligned at the first reading following accelerometer reset):
(Oops - that label "Flash MISO" should say EXT_CLOCK)
The count is showing the number of rising clock edges between the INT signals. In this case, only accelerometer 1 has correctly fired after 6144 clocks, the other two have fired earlier. Hence, the other two have EXTRA samples! And no, having something extra in this case is not a good thing. It's not like an extra pay cheque. It's more like an extra tax bill.
Here's another capture, again at the second reading and this time they've all fired early:
There doesn't seem to be any consistency, so the problem may be related to each accelerometer's internal clock running at a slight different speed, even though we're using the EXT_CLOCK. As evidence, when I set the accelerometers to use their internal clock, they all still get started by us at exactly the same time. But this is what we see from the very first readings:
Accelerometer 1 has collected 64 samples before the other 2. It's internal clock is running faster.
1) Our aim is to have all 3 accelerometers in synch.
2) We have other issues with the EXT_CLOCK line as described here:
https://ez.analog.com/mems/f/q-a/116540/adxl372-ext_clock-spurious-samples
3) We know we can't use EXT_SYNCH because it will miss samples. Are there a set of requirements for using EXT_CLOCK so it will be 100% reliable?
Thanks!
Richard.
tagged
[edited by: JValeriani at 8:30 PM (GMT 0) on 10 Oct 2019]