Post Go back to editing

ADXL372 extremely high noise and low sensitivity to accelerations

Greetings.

We are trying to test an ADXL372 breadboard before spinning tiny accelerometer modules to measure various parts of a vehicle and extract power spectral densities at these locations. 

The datasheet says we should see about +/-1.5g peak to peak on all axes maximum when the high pass filter is enabled, but we have 10 to 20 times this which is purely unacceptable. Even shaking the breadboard until the wires fall off barely shows a consistent pattern on the plots of the axes time history. 

What's happening? We do have a LTC4332 SPI extender dev board in between the accelerometer and the microcontroller, but it seems to work fine looking at the waveforms on the oscilloscope and it has been validated on the setup phase of the code.

The code is attached. It can be used as-is on the EVAL-ADXL372-ARD shield. Note that in the code the CS is set to pin 8 and the INT1 to pin 3.  

arduino_ADXL372_test.zip

Thanks in advance for your help. 



.
[edited by: gmrdx at 1:24 AM (GMT -5) on 10 Mar 2022]
Parents
  • I do not know what happened, but when I tried to take captures without the extender, and with (both changing the USING_EXTENDER flag and not changing it), I was not able to replicate the issue. It could have been that the microcontroller was not properly programmed with the flag set when I used the extender, although in this case I don't explain why the data looked right once decoded on the scope. Perhaps the data has been shifted somehow? 

    Thanks for your help in identifying this had something to do with the extender in the end.

    This leaves me with sorting out how to manage to read the accel reliably WITHOUT the INT1 pin, because our current architecture does not support 7 wires to each accel, only 6. There does not seem to be a register that shows the number of samples in the FIFO, and yet the datasheet says we have to leave at least a sample in the FIFO at all times (since we're measuring 3 axes). I did not fully understand why though. I am not sure this is as simple as setting the scheduling such that half the FIFO size is pulled from the accel every X microseconds where X is the time it takes to fill half the FIFO: there will be drift due to unmatched clocks until the FIFO is either overflowed, or empty...  Should I create another question or can anyone answer this?

  • Hi, 

    I am glad you were able to find the issue. 

    The FIFO_ENTRIES and FIFO_ENTRIES2 registers (registers 0x06 and 0x07) contain the information of number of samples currently on the FIFO memory. 

    Regards, 

    Pablo. 

  • Thanks Pablo, Obviously I missed it when scanning the datasheet... Thanks, problem solved then!

Reply Children
No Data