Post Go back to editing

ADIS16480 Data Inconsistencies

Hi,

We’re using SPI to communicate with an ADIS16480. I'm noticing inconsistencies in some of the values reported by the device:

(1) When reading the yaw Euler angle register (0x6e), the angle changes from the max positive value (180*(2^15-1)/2^15) to 0. At this point, the angle increases at twice the expected rate so that it reaches its max value after 90 degrees of rotation. Next, the reported angle flips to -180 and again increases to 0 after another 90 degrees of rotation.

To summarize, the reported angle appears to be correct from 0 to 180 degrees; however, it does not flip to -180 at the correct point, and it increases at 2x the rate that it should in the negative angle region.

To eliminate magnetic interference as a possible cause, I disabled the magnetometer in the EKF config register.


(2) More generally, it seems that negative values read from all other registers are twice as large as they should be. For example, I enabled body frame measurements (EKF config) and measured the gravity vector along the +Z axis to be 1.0 g. I then flipped the unit over, and observed a value of -2.0 g. I repeated this procedure along the X and Y axes and received the same result.

The problem also occurs when measuring the pitch angle. If I pitch the unit up +90 degrees, the reported value is correct. If I pitch -90 degrees, the reported angle is -180 degrees, which is impossible.

I've also observed the problem when writing negative values to the hard/soft iron calibration registers. When I perform a confirmation read of these registers, I observe that the negative values are all doubled. The positive values are correct.

I've confirmed that these data inconsistencies appear in the raw data read via SPI (it's not due to a conversion factor). I would greatly appreciate assistance troubleshooting these issues.

Many thanks,

-Zach

Parents
  • Hello Zach,

    I am scratching my head on this one.  Using the EVAL-ADIS and the IMU Evaluation software, I set EKF_CFG = 0x0208 on one of my lab units and observed the following response in the upper word registers, for all three accelerometers. Keep in mind, this was a quick, "hand-held" experiment, so we would expect perfect +/-1g responses, but they are pretty close. 

    Register Orientation/Gravity Hexadecimal Value Decimal Value Acceleration
    X_ACCL_OUT +1g 0x04D9 +1241 +0.9928g

    -1g 0xFB2D -1235 -0.9880g
    Y_ACCL_OUT

    +1g

    0x04DD +1245 +0.9960g

    -1g

    0xFB16 -1258 -1.0064g
    Z_ACCL_OUT

    +1g

    0x04FA +1274 +1.0192g

    -1g

    0xFB2D -1235 -0.9880g

    Just to check what is easy, I would also make sure that all of the bias and scale correction registers are equal to zero. The "doubling" in the negative side only of this makes me wonder if there is a bit shift or some other issue that involves the binary to decimal conversion process, in your reads and/or writes. Are you able to read the PROD_ID register correctly? Since this register has a value that does not change, this is a good way to make sure that the read routine is working correctly.  

    I will keep thinking about this, but wanted to share my current thoughts with you.

    Best,
    NevadaMark

Reply
  • Hello Zach,

    I am scratching my head on this one.  Using the EVAL-ADIS and the IMU Evaluation software, I set EKF_CFG = 0x0208 on one of my lab units and observed the following response in the upper word registers, for all three accelerometers. Keep in mind, this was a quick, "hand-held" experiment, so we would expect perfect +/-1g responses, but they are pretty close. 

    Register Orientation/Gravity Hexadecimal Value Decimal Value Acceleration
    X_ACCL_OUT +1g 0x04D9 +1241 +0.9928g

    -1g 0xFB2D -1235 -0.9880g
    Y_ACCL_OUT

    +1g

    0x04DD +1245 +0.9960g

    -1g

    0xFB16 -1258 -1.0064g
    Z_ACCL_OUT

    +1g

    0x04FA +1274 +1.0192g

    -1g

    0xFB2D -1235 -0.9880g

    Just to check what is easy, I would also make sure that all of the bias and scale correction registers are equal to zero. The "doubling" in the negative side only of this makes me wonder if there is a bit shift or some other issue that involves the binary to decimal conversion process, in your reads and/or writes. Are you able to read the PROD_ID register correctly? Since this register has a value that does not change, this is a good way to make sure that the read routine is working correctly.  

    I will keep thinking about this, but wanted to share my current thoughts with you.

    Best,
    NevadaMark

Children
No Data