Post Go back to editing

ADXL355 Unstable Axis, Offset and One-Way Axes

Category: Software
Product Number: ADXL355
Software Version: N/A

Solution: This was user error, solution here.

Background

I am reading data from an ADXL355 accelerometer via SPI on a RPI Zero W and seem to have gotten stable g values after conversion, but the data I am getting seem to have a few problems.

Link to datasheet: www.analog.com/.../adxl354_355.pdf

1) Offset from expected value

Even though the accelerometer is sat on a static table, the data from it do not read 1g. There are settings for changing the offset of readings, but it strikes me as strange that the offset would be set to several g's, around 3g in a +-8g range. This offset is present in the x-axis and y-axis (the z-axis seems to be way out of order), these are shown in the following image.

2) Axes movement in same direction

I tested the accelerometer axes by changing the orientation of the board as per the following image.

This gives the following readout from the accelerometer:

The y-axis being displaced in the same direction at each extreme of the rotation is what surprises me, given that the endpoints of the rotation are 180 degrees opposed.

3) Coupling of axes

As seen in the accelerometer testing results image above, the axes seem to move together, this is something else that confuses me, as I am barely moving the x axis. Could it be that it is being rotated through space as though it was attached to an arm?

4) Z-Axis Irregularities

Any ideas as to why the z-axis is all over the place would also be greatly appreciated. The axis are all fed through the same conversion from the data read directly from the accelerometer to give g values.



Added solution note
[edited by: ComteCristo at 12:34 PM (GMT -4) on 1 Aug 2022]
  • Hi  , 

    I have not seen this issue before. Can you please share the sensor configurations and the raw acceleration data? (values read from 0x08 to 0x10 registers). This will help me understand the where the issue might be and check if there is any potential data conversion error. 

    Thanks, 

    Pablo. 

  • Hi,

    Sorry for the late reply, it seems some error has been introduced over the weekend and I am having trouble getting the accelerometer to give anything other than very noisy results.

    I'm a little unsure of exactly what you mean by the sensor configurations? The registers I write to on startup?

    Also, how would you like the accelerometer data? Pasting over 1000 values into an answer here seems a bit heavy handed.

    My current code interprets the three data registers for each of x, y, and z as one large 20-bit two's complement number that needs combining and casting to a signed integer, before conversion to the g value, if that helps explain anything.

    Regards, Daniel.

  • Hi Daniel, 

    yes, the registers you write on startup is what I would like to check. 

    Regarding the data, you can attach a text file or .zip file in this forum as well. 

    I have one question: how many parts shown this behavior so far? The large offset and axis moving in the same direction is something we have not seen in this product ever. 

    Thanks, 

    Pablo. 

  • Hi Pablo,

    Update and solution ----------------------------------------------------------------------------------

    It turns out that this error was due solely to my misunderstanding of multibyte reads using SPI, and is now resolved. I received an explanatory answer to this effect right after replying to you (which is still included below).

    The issue was that I was essentially combining the wrong registers unknowingly. More information is available in this stack exchange link.

    Regardless, I greatly appreciate the help offered here.

    Regards, Daniel.

    My original answer ------------------------------------------------------------------------------------

    Registers written on startup

    On startup I write 0b11 to Range (0x2C), 0x07 to Filter (0x28), 0x00 to Power_Ctl.

    To retrieve data I read the data registers, then bit shift to concatenate them, and check if the 20th bit is a one, in which case I pad the data with leading ones to ensure it remains in proper two’s complement format. I then assign it to an 32-bit integer value that uses two’s complement to signify negative numbers. Then I multiply by the scale factor for the given range value, giving the data output.

    Number of units

    The offset and movement together of the axes was only experienced on the one unit we had for testing. After I posted this question I switched to testing another model of accelerometer briefly, until we received a few more ADXL355 units for testing in case of module error.

    Upon coming back to the ADXL355 code, I find that the accelerometer seems to loop through its full range of values and then overflow, then repeating, so have been unable to progress. This new issue has so far come up with three units, so it is likely that I am interfacing with them incorrectly, but I and my colleagues have not been able to figure out what or where the error is.

    Below I have added pictures of how the accelerometer moves under this testing, and the output data in a graph.

    Regarding attached files

    The excel files in the zip are named as per the graphs below.

    Graph_Eyes - The data from the original post, with the z axis in gold included:

    Graph_On_Table - The other data in the original post; the first triple graph set:

    Graph_Overflow - The data showing the overflow issue I seem to be facing now:

    Excel Data.zip

    Regards, Daniel.

  • Hi Daniel, 

    thank you for letting me know and I am glad the sensor is working properly now for you. 

    Regards, 

    Pablo.