cancel
Showing results for 
Search instead for 
Did you mean: 

IIS328DQ Z axis wild numbers

RLee.4
Associate III

I'm using a IIS328DQ on I2C buss (400KHz). I've got it set up at +-4g 100Hz sampling

It looks like it's doing it's thing correctly BUT for the z axis value. After the interrupt for data, I'm reading the XYZ outputs (MSB first order) and getting

00 50 FE 90 21 10

With the thing sitting mostly flat. X and Y are plausible but Z is 0x2110 meaning that it's like numbers in the 8464 range or 15 bits FS. The datasheet isn't all that clear about how many bits this is, but I'm thinking this is supposed to be +- 11 bits (12 bits signed) FS.

This number doesn't agree with the datasheet whereas the X and Y numbers are showing FS to be 11 bits (2048) at 1.05mg/bit correctly...

What could this possibly be? Id' expect a solding problem to give me warped X and Y maybe but not Z at 4X what full scale is supposed to be....

1 ACCEPTED SOLUTION

Accepted Solutions
Eleon BORLINI
ST Employee

Hi @RLee.4​ ,

>> Or maybe this data is 12 bit LEFT justified?

That's the point, indeed.

The 12 bit representation means that only the first 12 MSb (from the MSB i.e. the OUT_X_H (28h)).

After concatenating OUT_X_H (28h) with OUT_X_L (28h), you have to take only the first (from MSb) 12 bits, or all the 16bits and divide by 16 as in the afore-mentioned driver.

I can state with you that it is probably not very clear, but should work.

-Eleon

View solution in original post

5 REPLIES 5
Eleon BORLINI
ST Employee

Hi @RLee.4​ ,

Please note that all ST accelerometer sensor, if placed "flat" (i.e. with the z axis pointing out of the plane), senses the "1g" earth acceleration,

Consider than the LSB to milli-g conversion formula in the +-4g FS case (you can find it on Github C driver repository iis328dq_reg.c:(

float_t iis328dq_from_fs4_to_mg(int16_t lsb)
{
  return ((float_t)lsb * 1.95f / 16.0f);
}

In your case, z-axis LSB are 2110h --> 8464d --> 1.031mg (according to the formula above, where the 12bit shift is implemented dividing by 16).

This is close to 1g, i.e. the earth gravity acceleration, being the typical zero-g level offset accuracy about 30mg (in case of 0g).

As a side note, if you want to compensate this residual stationary offset; you can characterize it at the beginning of your acquisition and then substract it to your running data via software.

If my reply answered your question, please click on Select as Best at the bottom of this post. This will help other users with the same issue to find the answer faster. 

-Eleon

RLee.4
Associate III

I get that I should be seeing something close to -1 in Z axis (+Z is up according to the diagram in the datasheet so gravity should be showing as a negative number the way I've got this mounted). What I'm missing here is the number of bits this is sending back.

How many bits is this sending me? 12? 16?

According to the datasheet (rev 3 page 9) we should have 1.95mg/bit at +-4g setting which would give us 16g at this number. So is the datasheet wrong and this should be .12mg/bit? I'm plenty confused as to how to read this datasheet then...

Or maybe this data is 12 bit LEFT justified?

Eleon BORLINI
ST Employee

Hi @RLee.4​ ,

>> Or maybe this data is 12 bit LEFT justified?

That's the point, indeed.

The 12 bit representation means that only the first 12 MSb (from the MSB i.e. the OUT_X_H (28h)).

After concatenating OUT_X_H (28h) with OUT_X_L (28h), you have to take only the first (from MSb) 12 bits, or all the 16bits and divide by 16 as in the afore-mentioned driver.

I can state with you that it is probably not very clear, but should work.

-Eleon

RLee.4
Associate III

Ah. Thanx.

Might want to pass on to the tech writing staff that nowhere in the datasheet for this part (DocID027250 Rev 3) does it mention this is left justified data.....

Eleon BORLINI
ST Employee

Ya, I'll report it internally

Best,

-Eleon