ADXL372 EXT_CLOCK: spurious samples

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,

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.

I can't find any remaining boards with the LTC6906, I'll have another search but we did have a long hard look at the signal from that part on a CRO and didn't see anything unusual.  It just looked like a reasonable rail to rail square wave.

The behaviour and rate at which errors are occurring varies wildly.  My comment about "every 10 seconds" was just on one board that we since modified to try to isolate this issue.

I will try to let the FIFO fill with 170 samples instead of 68 and report.  But there is a chance the CPU will not service the in time FIFO causing it to overflow.

Note however we have now decided our next design will remove the EXT_CLOCK and revert to using the ADXL372 internal clock in the hope we don't get spurious triggers, flatlines & missing samples.  We will try to compensate for the lack of synchronisation by timestamping the time at which the FIFO Watermark interrupt occurs from each accelerometer.  Please let us know if there are any known problems using the internal clock before we commit to the new design.

As a side note, we are currently trying to overcome the errors caused by the delay in sampling each axis - the ADXL372 internal MUX switching time means each axis is not synchronised hence our calculations incur errors.  I'll quickly ask if you know what the switching time is (we think it's linked to the ODR, so switching time varies as the ODR is varied).

Hi Richard,

There shouldn't be spurious triggers using the internal clock, though I have to say that I still recommend setting the FIFO Sample size to greater than 500 @ 3200/6400Hz ODR to avoid the chances of missing samples. We're investigating the issues at the moment together with the external clock/sync issue, will let you know once we have an update.

Regarding the delay in sampling each axis, it's about 104us in between two consecutive access.

I hope this helps.

Hi JWang,

I'd like to try your recommendation, so can I asked specifically what I should do?

I'm reading triplets (XYZ), currently my watermark is set to 68 * 3 = 204.  When the FIFO WM interrupt occurs I read 64 * 3 = 192 bytes.

If you believe the FIFO should fill to 500 bytes, then shall I set the FIFO WM to 167 * 3 = 501 and do I still read 64 * 3 = 192 bytes or do I read 166 * 3 = 498 bytes?  (I say 166 because we're supposed to leave at least 1 triplet in the FIFO to avoid misalignment).

Thanks!

Hi JWang,

BTW, thanks very much for citing the switching time - it's very very helpful for us to know this to compensate for errors when calculating direction of sudden impacts.  And If I can hijack this thread with one more related question --- what's the sampling order?  We're not exactly sure, but we think it's Y->X->Z, could you please confirm?

Thanks!

Say you have FIFO Watermark set to 501, as soon as interrupt triggers, you can pull all the 501 samples out at once, which are 167 sets of samples in total. You don't have to leave one sample sets unless you are using the full FIFO sample size, 510 when 3 axes are enabled in this case. I hope this helps.

The sensor samples in the order of X-> Y-> Z. Can you inform why you think it would be Y-> X -> Z? 

One more info to add, it takes about 50us between the finish of Z-axis data conversion, to the trigger of Data Ready interrupt. This may be also useful to your application.

Hi jwang,

Ah, the sampling order was an educated guess from our math boffin, but based on your answer he's changed his mind and agrees with you .  Thank you very much for these details, it really is a big 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.