Post Go back to editing

ADXL372 EXT_SYNC : how to keep 3 accelerometers in sync?

Our product is using 3 * ADXL372 accelerometers.  It's important that all 3 accelerometers be synchronised.  To achieve this we have been focused on using the EXT_SYNC feature.  We are also trying to save power, so have been using the FIFO to buffer 68 XYZ samples and using the INT FULL signal from one of the accelerometers as a CPU trigger to read 64 samples (making sure we leave some samples in the FIFO as the datasheet suggests).

We have connected the CS signals from the 3 accelerometers to the same CPU port so all 3 lines can switch at exactly the same time when we send initialisation commands to them.
The first issue we found was each accelerometer would begin buffer to its FIFO at different times.

INT0 is routed to the CPU, INT1 & INT2 we're just monitoring on the logic analyser.  This is the first trigger after measurement start.  As you can see, each ADXL372 signals FIFO_FULL at different times.  In the left trace the FILTER_SETTLING time is 370ms, but in the right trace it's 10ms.  So the right trace is much better, but still not perfect.

Our solution is to do this:

  • Initialise (FIFO mode, INT source, etc).  Set FIFO threshold to 3 * 32 samples.
  • Start sampling & await INT
  • On INT, stop the EXT_SYNC clock
  • For each chip, read the number of samples in the FIFO and read out all except the last sample triplet (so there's one XYZ triplet left in each FIFO)
  • Adjust the FIFO threshold up to 3 * 68 samples and resume the EXT_SYNC clock

This is what the signal now looks like (the bottom 3 signals are the FIFO FULL INT lines):

So, that's the background.  We now seem to have all three accelerometers in synch.  However our problem is that a few 10s of seconds after this, it looks like an accelerometer misses samples:

On the left all INT lines activate at the same time meaning all FIFO's have reached the threshold at the same time - perfect!  However, 64 samples later we see INT1 & INT2 both activate in unison, but INT0 takes an extra 4 sample clocks.  So ADXL372 # 0 is now behind and the FIFOs are now out of synch - NG!

In this trace, the EXT_SYNC is 1024Hz.  The TIMING.ODR field is set to 6400Hz.

Are we doing something wrong?

What must we do to ensure all accelerometers remain in synch?

Parents
  • Thanks for the question. Regarding the first issue on initialization, the turn-on time may vary from part to part. So the software fix you implement should work. Regarding the second issue, we haven't seen missing samples in the past using external sync, so is this always happening on a specific ADXL372? Does INT0 always take extra 4 sample clocks? If so, can you change to different External Sync speed, e.g. 400Hz and see if it makes any difference? 

  • Hi jwang,

    Thanks for your reply.

    As requested, here's another trace, this result was the same at an EXT_SYNC of 1024Hz & 512Hz.

    In this case it looks like Accelerometer#1 missed samples this time, as it's INT line stopped firing (INT0 kicked off the read and we'd read #1 before it reached threshold).

    Running at 512Hz though it took much longer before the error occurred.

    I also note this forum post that seem to imply EXT_SYNC will miss traces sometimes:
    ez.analog.com/.../adxl372-external-synchronization

  • Thanks for the update. It looks like the issue is not repeatable on a single sensor, the reason I asked to change sync speed is to see if there's any correlation between the delayed samples and the speed you use. Can you double the sync speed and check if the issue still there? Apart from that, is the driving capability of the External Sync to drive multiple sensors at the same time?

    The Ezone reply you referred to does indicate the possibility of missing one sample due to the asynchronous nature of the internal clock and external sync. We have not characterized it on the bench but this should not happen oftentimes. 

    Another two suggestions here: you can pull all the samples out from the FIFO since the rule of left one in the FIFO only applies to when the entire FIFO(512 samples) is filled. Secondly, I found you left your External Sync signal running during the read of the second and third sensor, can you try enabling the External Sync after you finish reading the third sensor, similar to what you did in the fix for initialization? On the waveform you attached, it seems the first sensor starts refilling new data before old data being read out in the third sensor. 

    Please let me know if it helps.

Reply
  • Thanks for the update. It looks like the issue is not repeatable on a single sensor, the reason I asked to change sync speed is to see if there's any correlation between the delayed samples and the speed you use. Can you double the sync speed and check if the issue still there? Apart from that, is the driving capability of the External Sync to drive multiple sensors at the same time?

    The Ezone reply you referred to does indicate the possibility of missing one sample due to the asynchronous nature of the internal clock and external sync. We have not characterized it on the bench but this should not happen oftentimes. 

    Another two suggestions here: you can pull all the samples out from the FIFO since the rule of left one in the FIFO only applies to when the entire FIFO(512 samples) is filled. Secondly, I found you left your External Sync signal running during the read of the second and third sensor, can you try enabling the External Sync after you finish reading the third sensor, similar to what you did in the fix for initialization? On the waveform you attached, it seems the first sensor starts refilling new data before old data being read out in the third sensor. 

    Please let me know if it helps.

Children
  • Hi jwang,
    Thanks for your reply.

    1) I'd like to focus on your answer when you say:
    ".. missing one sample .. external sync .. should not happen oftentimes"

    To be clear, does this mean it can happen?  And does this mean what I am seeing in the traces where a sample seems to have not been done is expected behaviour.  Yes, it may not happen often, but it will happen sometimes?

    2) The driving capacity seems fine - my scope is old so here's a photo of the EXT_SYNC waveform:

    3) For speed and simplicity I do not query each accelerometer for how many samples are in it's FIFO.  I just wait for accelerometer 0 to signal FIFO_FULL then read 64 from all accelerometers.  I rely on the FIFO to be a FIFO and keep buffering.

    So I also do not want to stop the EXT_SYNC while I read as this would impact the sample timing and introduce artificial frequencies in the dataset.

    I could adjust the threshold to 64, but sometimes the CPU may be delayed in reading from the FIFO and another sample may be buffered before it gets to read the FIFO.

    Anyway, my main focus is understanding if the ADXL372 is sometimes going to not take a sample.  Please clarify if this can happen.

  • Per datasheets states that this could happen. I need to check back with the team and see if there's any way we can minimize the effect. May look into the digital simulation as well. Will get back to you once I have more information. 

  • Hi jwang,

    Thanks for helping.

    I posted this picture yesterday but the forum seems to have lost it, so I'll repost.  In this capture, I have included more data from the analyser, specifically a count of clock edges that clarifies the problem.

  • Analog Devices reported EXT_SYNC may indeed miss samples.  So if you need to be sure of having a contiguous sequence of samples, stay away from EXT_SYNC.  Either use EXT_CLOCK or let the ADXL372 use it's internal clock.