Post Go back to editing

ADXL372 EXT_CLOCK at above 307.2kHz seems to cause extra readings.

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]
Parents
  • I've had the opportunity to test some more of our boards and have stumbled across an interesting coincidence.  It seems a board we have hand soldered is giving this synchronisation problem, but another board that has been reflow soldered does not (it does, but far far more infrequently).  The schematic is identical and tracking is pretty much too, but the faulty board is FR4 whilst the working one is flex.

    I admit this is an unreliable assessment as I've only been able to test a few boards but seeing as most MEMS application notes say you shouldn't place parts under strain or route tracks under them, I wanted to ask if the problem behaviour I've outlined in this ticket is possibly influenced by how the accelerometers have been soldered?

Reply
  • I've had the opportunity to test some more of our boards and have stumbled across an interesting coincidence.  It seems a board we have hand soldered is giving this synchronisation problem, but another board that has been reflow soldered does not (it does, but far far more infrequently).  The schematic is identical and tracking is pretty much too, but the faulty board is FR4 whilst the working one is flex.

    I admit this is an unreliable assessment as I've only been able to test a few boards but seeing as most MEMS application notes say you shouldn't place parts under strain or route tracks under them, I wanted to ask if the problem behaviour I've outlined in this ticket is possibly influenced by how the accelerometers have been soldered?

Children