cancel
Showing results for 
Search instead for 
Did you mean: 

LSM303AH -1G/1G Unexpected Output, Less than 90 degrees

wb346
Associate II

Hello,

I am having issues with my acceleration data being output from my LSM303AHTR. I have configured it for 2G Full scale making the "sensitivity" 0.061mg/lsb.

I have tested two LSM303AH chips on two of our custom PCBs. I am getting similar results on both chips, but I am not getting the same exact values on both chips.

I evaluated all axis at +Gravity, -Gravity, and 0 Gravity. All of the expected 0 Gravity values are being seen, however, I am getting less than 90 degrees for positive and negative 1G positions.

My method for obtaining degrees from counts follows. I believe it is correct because it works for other projects' accelerometers:

Register Value * Sensitivity = mg
G = mg*1000
arcsin(G)

We can abstract out my method for obtaining degrees and just focus on counts. The issue still remains. When I am reading an axis that has full gravity exposure, I should be getting +/- 16,383 counts.

For X +1G I am getting -16,900 counts, which converts to 90 degrees, but this is slightly off scale.
For X -1G I am getting -15,750 counts, which converts to -75 degrees.
For Y +1G I am getting 15,750 counts, which converts to 75 degrees (just like X -1G).
For Y -1G I am getting -16,080 counts, which converts to -75 degrees.
For Z +1G I am getting 16,550 counts, which converts to 90 degrees, but this is slightly off scale.
For Z -1G I am getting -17,000+ counts which is greatly off scale.

Regarding my code, it is very specific and wouldn't make sense to anyone. I am shifting the MSB 8 bits and OR'ring it with LSB and stuffing that into a Signed Int. Again, we can talk about the conversion process, but all that really matters are the Counts I'm reading, which are not what is expected.

It's worth noting that I am very familiar with how this chip works because I am accustomed to using LIS2DS12 which is essentially the same as LSM303 except it doesn't have a magnetometer built in. 

Any help is appreciated.
Thank you.


1 ACCEPTED SOLUTION

Accepted Solutions

Hi @wb346 ,

I'm not sure I can see the issue:
I see data that is only slightly off spec: the offset accuracy is 30 mg, and applying the sensitivity to your data I see
X: -16,900, -15,750 (I imagine that one of those is with a +) -->   -1030,  -970  [mg]
Y: 15,750 -16,080  --> 970, -980 [mg]
Z: 16,550 -17,000  -->  1009, -1037 [mg]

just focusing on the counts, as you suggested, I see no problem in the data (not a problem as big as a 15 degrees error), so I think that the problem is in the algorithm for angle calculation.
I would try to use the formula used by the design tip and check if the problem is there

View solution in original post

10 REPLIES 10
Federica Bossi
ST Employee

Hi @wb346 ,

Have you already tried to compute this following the guidelines reported in our design tip here?

If this helps you, please mark my answer as "Best Answer" by clicking on the "Accept as Solution" button, this can be helpful for Community users to find this solution faster.

In order to give better visibility on the answered topics, please click on 'Accept as Solution' on the reply which solved your issue or answered your question.

@Federica Bossi Thanks for the reply. I have that document bookmarked, but I haven't read it in a while and I have not computed tilt using those formulas.
This is the reason however, that I emphasized the counts. 

The conversion from counts to degrees is irrelevant. I only mentioned the conversion so we could all use a metric that is widely understood (degrees).

The problem remains that the counts coming out of the chip are not expected values. I'm also going to reflow the chip on both of my boards and see if that helps anything.

Ciao @wb346 ,

Ok, can you please share your full configuration?

In order to give better visibility on the answered topics, please click on 'Accept as Solution' on the reply which solved your issue or answered your question.

Hi Federica,

I have the following config:
CNTRL_1_A = 0x11  0001 - 14 bit High Resolution 0001 - BDU bit set (block data update)
CNTRL_2_A = 0x04  00000100 - Rolling Read Enabled

The last three registers are 0x00 (default).

I have this same configuration when using the LIS2DS12 with no issues.
I also wanted to add that I have tried this with three separate LSM303s that I hand soldered and one LSM303 that came factory assembled on an EVAL Board. I have confirmed using a logic analyzer that the counts being populated into my int16 variables / structs are in fact being sent to my MCU and stored correctly.

I appreciate the help.
Tom

Hi @wb346 ,

I'm not sure I can see the issue:
I see data that is only slightly off spec: the offset accuracy is 30 mg, and applying the sensitivity to your data I see
X: -16,900, -15,750 (I imagine that one of those is with a +) -->   -1030,  -970  [mg]
Y: 15,750 -16,080  --> 970, -980 [mg]
Z: 16,550 -17,000  -->  1009, -1037 [mg]

just focusing on the counts, as you suggested, I see no problem in the data (not a problem as big as a 15 degrees error), so I think that the problem is in the algorithm for angle calculation.
I would try to use the formula used by the design tip and check if the problem is there

Hey Niccolo.

Thanks for looking into this. You know, I was aware of the 30mg error, but I am just realizing that that 30mg accounts for the last 15 degrees. As insane as this is, technically, the readings are within spec. My algorithm is solid. What you are saying with the 30mg is correct, and that explains my 75 degree readings. I confirmed this result using an LIS2DS12 also (this is basically the same as LSM303).

I am disappointed in the results, however. As a professional IIot company, we need to be able to rely on these sensors to tell us when something is experiencing full gravity.

Is there another sensor that can deliver these results?

Thank you for your insight. I definitely had a 'forest through the trees' moment there. I had the answer the whole time, I just couldn't zoom out and see all the pieces.

don't worry, it happens to everyone a moment like that =)
anyway, I'm using an LSM6DSV16X to perform a similar task, and with a zero-g level offset accuracy of 12 mg I have an accuracy of +-0.2 degrees, so I think that even with LSM303AH you can do it.
the only difference is the more complicated algorithm that I use

Niccolò

Thank you. Are you getting the huge degree error towards 90 degrees though?

The problem is the logarithmic nature of how I'm deriving degrees. I am taking arcsin of g to get radians, and then multiplying by 180/pi ( 57.3 ). After 75 degrees, the output becomes more dramatic, and every mg of error heavily impacts the accuracy of the reading:

wb346_0-1689008682461.png

 



I will look into this 12mg error part, but even at 90 degrees, we are now talking about a potential error of 8-9 degrees:

wb346_1-1689008732050.png


Furthermore, you are saying your margin of error on your 12mg part is 0.2 degrees, but according to the math we are using, your error should be +/-  0.7 degrees:

wb346_2-1689009035013.png

Could I trouble you to point me in the direction of how to better calculate ANGLE using the readings? I have the eCompass document referenced above, but I don't think that applies to my application. I am just looking to get degrees from a reading. We are not making drones or anything like that. We are just interested in getting an angle at time of reading.

You mentioned a more complicated algorithm, which is okay for us, but I don't see how we can get around this 8 degree error of your 12mg error Sensor.

I'm sure your answer can benefit others as well.
Thank you for your help.

the idea is to rely on the other axis when one is too close to the 90 degree limit.
my solution is in fact the direct development of the design tip shared by Federica, so you can use that as a reference

hope this helps =)
Niccolò