Post Go back to editing

External Synchronization with Interpolation producing consecutive repeated samples

Category: Hardware
Product Number: ADXL382

Hi,

we are using the ADXL382 with External Synchronization with Interpolation (without an external clock).

We sample and plot the data, and observe that every ~250 samples, about ~20 samples are repeated (exactly the same).
I will try to provide as many details as possible to hopefully make this clear.


ADXL config:
XYZ channels enabled
range set to 15g
SYNC_MODE to External Synchronization with Interpolation
mode set to HP
DRDY mapped to INT1 pin

(powered with 1.8V - MCU and IO is also at 1.8V)


---------------------------------------------


We drive the input FSYNC pin using PWM from the MCU, creating a 50% duty cycle at 8 kHz.
On each INT1 interrupt, we read STATUS3 and the XYZ DATA registers.

We also measured the traces using the Saleae Logic Analyzer:

Exporting the SPI trace from the analyzer, we can see that the samples repeat (thus we can rule out errors in the storing, transferring, and plotting)

We clocked the FSYNC for exactly 40k pulses (5-second duration).
Each FSYNC pulse has a corresponding DRDY/INT1 pulse, which has 1 SPI transaction to read the values.
Each read of the values has DRDY (from the status3 register) set to 1.

To us, this means that all XYZ values we have read are valid

The plot of raw samples looks like this:

Zooming in on the start of Z:


The exact number of samples that are repeated varies, but is around 20.
The exact number of samples between the repeats also varies, but is around 250.


---------------------------------------------

When not using FSYNC (i.e., ADXL samples on its own), this does not occur (no repeats of significantly long runs).

We then tried with different FSYNC frequencies, and we can see that it is somehow related to the ODR/Bandwidth.

FSYNC FREQ Hz MAX REPEATS
16000 42
  8000 20
  4000   9
  6000   1
14000   2
15580 22
15500
  5
15000
  3
16064
33
  9000
  1

(The max repeats vary by a couple of samples for each test run we did, but are around the values in the table)


It looks like if FSYNC is ODR, ODR/2, ODR/4 (or close to it), this issue is present.
As you move away from those frequencies, the issue goes away.

The repeatability and the consistent spacing of non-repeated and repeated values rule out that this is random.
This happens repeatedly on every test run.

---------------

All in all, very weird.

How should we go about debugging this?
Has anything similar been observed?
Is it possible that we are somehow inducing noise into the accelerometer or something like that?

Any help will be appreciated.
Best regards,
Tjaž Vračko

  • I thought maybe this is a power issue or an issue with our custom PCB.
    So I took an EVAL-ADXL380-1Z and a nrf52840DK, using similar test code.

    Repeats also happen, but there are fewer of them in a row:

    FSYNC 8kHz: ~4 repeats every ~105 samples


    FSYNC 4kHz: ~2 repeats every ~52 samples


    FSYNC 6Khz: no repeats
    FSYNC 9Khz: no repeats

    Note: "Every X samples" means I counted from the start of repeated samples to the start of the next set of repeated samples.

    I could not test with 16kHz because the DK can not service interrupts fast enough.

    ----------------

    The EVK is ADXL380, but on our custom board, we have ADXL382 - so there might be fewer repeats due to the different sensor.
    Or, this is somehow noise/interference related, and I have less interference on the DK.

     
    Also, it looks like the number of repeats and the distance between them scale with the FSYNC frequency (50 at 4kHz, 100 at 8kHz).

    I looked at the original data again, and also see scaling with frequency:
    FSYNC   8khz: ~20 repeats every ~270 samples
    FSYNC 16khz: ~40 repeats every ~540 samples
    FSYNC   4khz: ~9 repeats every ~130 samples



  • Thanks for the comprehensive details, let me circle this with the colleague responsible of this family of products and come back with feedback.

    have a great weekend,

    Mario SM

  • I'm running into the same issue and would like an answer as all.

  • Hi. I am taking a look at this case. Could I get a couple of additional pieces of information from you?

    I would like the readback of the following registers:

    0x33 SPT_CFG1

    0x32 SPT_CFG0

    0x35 SYNC_CFG

    While we're looking further, if you could try something it might help us understand what is going on better. Please write a '0' to bit 7 of 0x33 SPT_CFG1

    This is the SPT_XTRA_SAMP bit. Keep everything else the same as you have and then re-run. I am looking to see if the repeated samples now report as 0's

    Thanks,

    Jacob

  • Hi,

    Thank you for looking into it.

    The register values are:
    SPT_CFG0  0x32: 0x00
    SPT_CFG1  0x33: 0x08
    SYNC_CFG 0x35: 0x20  <-- only this is non-default, since I set SYNC_MODE to "Interpolation"


    The SPT_XTRA_SAMP bit is 0 already.

    I tried setting it to 1 (writing 0x80 to register 0x33), and the result is the same - I get repeated samples.

    -----

    Keep in mind that on every DRDY interrupt, I read the STATUS3 register and the 6 XYZ registers (in one SPI transaction). 
    The DRDY bit in STATUS3 is always set.

    -----
     
    Best regard,
    Tjaž Vračko

  • Here is a dump of all registers after setup. This is the custom PCB with the ADXL382.

    0x00: 0xAD
    0x01: 0x1D
    0x02: 0x17
    0x03: 0xC1
    0x04: 0x4C
    0x05: 0x91
    0x06: 0x70
    0x07: 0x08
    0x08: 0x00
    0x09: 0xAB
    0x0A: 0x00
    0x0B: 0x23
    0x0C: 0x2E
    0x1D: 0x00
    0x1E: 0x00
    0x1F: 0x00
    0x20: 0x97
    0x21: 0x0D
    0x22: 0x00
    0x23: 0x00
    0x24: 0x05
    0x25: 0x00
    0x26: 0x0C
    0x27: 0x70
    0x28: 0x00
    0x29: 0x00
    0x2A: 0x00
    0x2B: 0x80
    0x2C: 0x00
    0x2D: 0x01
    0x2E: 0x00
    0x2F: 0x00
    0x30: 0x00
    0x31: 0x00
    0x32: 0x00
    0x33: 0x00
    0x34: 0x1A
    0x35: 0x20
    0x36: 0x00
    0x37: 0x00
    0x38: 0x00
    0x39: 0x00
    0x3A: 0x00
    0x3B: 0x00
    0x3C: 0x00
    0x3D: 0x00
    0x3E: 0x00
    0x3F: 0x00
    0x40: 0x00
    0x41: 0x00
    0x42: 0x00
    0x43: 0x00
    0x44: 0x00
    0x45: 0x00
    0x46: 0x00
    0x47: 0x00
    0x48: 0x00
    0x49: 0x00
    0x4A: 0x00
    0x4B: 0x00
    0x4C: 0x00
    0x4D: 0x00
    0x4E: 0x00
    0x4F: 0x00
    0x50: 0x00
    0x51: 0x00
    0x52: 0x00
    0x53: 0x00
    0x54: 0x00
    0x55: 0x00
    0x56: 0x00
    0x57: 0x00
    0x58: 0x00
    0x59: 0x00
    0x5A: 0x00
    0x5B: 0x00
    0x5C: 0x00
    0x5D: 0x00
    0x5E: 0x00

    I hope you are able to reproduce this Slight smile

    Best regards,
    Tjaž
  • Was there a followup to this? I'm running into this issue

  • Hi, 

    The problem observed is a known issue that has been corrected in the new PCN version (revB silicon, rev_ID: C3). You can find more details on ADI_PCN_25_0025_Rev_-_Form.pdf. The C3 parts will start to be shipped to customers by May 2026. Prior C1 and C2 samples can show this behaviour. 

    Regards, 

    Elena

Before You Switch


Switching languages will make ADI Explorer unavailable. Resume your session by switching back to English and reopening ADI Explorer.