adcmxl3021 velocity drift

Hi,

we are evaluating the use of adcmxl3021 and faced some issues with MTC (Manual Time Capture) with velocity calculation enabled. 
No FIR filter is applied and AVG_CNT=4 is used.
The sensor is not moving, standing on the table, but its calculated velocity is drifting, as you can see below (the 5 "fins" correspond to 5 different acquisitions (4096 samples each).

Performing the same acquisition with acceleration instead of velocity, the signal on the same axis is floating around 0 as expected:

Why is it behaving like this? Is there some error in our setup?
I've been trying to replicate the same measurement using the ADCMXL Evaluation Software but it seems to me that only acceleration time captures are possibile, not velocity ones. Can you please confirm this?

Sorry for the bad quality pics. I hope my point is clear, if not please do ask more details.

Thanks in advance

Lorenzo

Top Replies

  • 0
    •  Analog Employees 
    •  Super User 
    on May 3, 2021 2:02 AM

    Hi,

    Moving this to MEMS Intertial Sensor so they can further assist you. 

    Regards,

    Andrei

  • Hi Lorenzo,

    Can you please describe how did you configure the device in MTC mode in a step by step manner ?

    I want to know whether sync/RTS pulse is required for each capture event or it is issued once only ?

    what is the status of busy line during this process ?

    Thanks

    Malik

  • Hi Malik, 

    thanks for your reply.
    Here's a list of peformed operations:
    - adx_init (reset, check PROD_ID, perform self-test)
    - set AVG_CNT to 0x0004 (we are using SR0)
    - (set filters to FILT_CTRL when needed)
    - start acquisition by writing 0x0122 to REC_CTRL
    - wait for the busy line to go high
    - when busy line goes high, read DIAG_STAT to verify data is ready (and alarms have been triggered, if set)
    - if data is ready, get samples (reset BUF_PNTR to 0x0000, read X_BUF 4096 times (exploiting BUF_PNTR automatic increment), reset BUF_PNTR, and repeat for Y_BUF and Z_BUF. Between every read of X_BUF, Y_BUF or Z_BUF, a 30 us (microseconds) delay seems to be required. [Can you please confirm that? The datasheet is mentioning a minimum of 16 us for t_stall, but which is the recommended delay?]
    - as soon as the whole reading operation is completed, start over another acquisition.

    Busy line is low during sensor acquisition (it takes around 300 ms with AVG_CNT = 4).

    By the way, can you confirm that it is not possible to read the user data buffers while the sensor is acquiring data (busy line low)? In a scenario when "continuous" data stream is needed, reading the data of the previous acquisition while the sensor is performing the next acquisition would allow to virtually have no loss of samples.

    Waiting for your kind reply. Please feel free to move this discussion private if more code details are needed.

    Thanks and best regards

    Lorenzo

  • 0
    •  Analog Employees 
    on Jun 13, 2021 1:06 AM

    Hi Lorenzo,

    Thank you for posting your question in this forum.  I would guess that this relates to the bias error, in the accelerometers. 

    v(t) = a(t) dt, so

    if a(t) = b + noise, where b is the bias on the accelerometer measurement

    then 

    v(t) = noise(t) dt + b x t

    If you have not already tried this, can you execute an auto-null command, by setting GLOB_CMD[0] = 1, then see if this reduces the ramp?  Another approach could be to enable one of the high-pass filter options or design your own high-pass response, in the FIR filters.  

    I hope that this helps. 

    NevadaMark