cancel
Showing results for 
Search instead for 
Did you mean: 

WICED Smart Bluetooth

Anonymous
Not applicable

Hi,

I'm trying to make sense of the data coming from the accelerometer on the wiced sense.  I'm not really getting the values I expect.

For some reason, in the lis3dsh driver included with the wiced sense sdk, the accel values are divided by 16.  Why is that?  I couldn't find any rationale in the datasheet.

What you get from GetAccAxesRaw(AxesRaw_t* buff)  is a 16 bit value (2's complement) for each axis.

You can also set the range +-2g, 4,8 or 16.  To get the actual acceleration, I'm using the formula:

value * range / 32767

32767 is the max 2's complement 16 bit value.  Range is 2, 4, 8, or 16. 

Does that seem right?  I am not getting the values I expect when the device is at rest -- only about 0.5 g instead of 1. And that value changes depending on what range I select.  Any ideas?


Thanks,

Reynald

0 Likes
Reply
1 Solution
Anonymous
Not applicable

Hi reynald,

Sorry for such a late response, but here are a couple things that I found.

1.  yes I believe when they divide by 16 it is a bug in the driver. Someone pointed out other bugs in the driver in another post as well.

2.  Your method for raw data * resolution / 32767 is only valid for resolutions 2 through 8.

On the STM data sheet for the accelerometer, it gives you the conversion, mg/digit.  accelerometer datasheet.PNG

Using this will show why your formula works for resolutions 2 - 8.  Take +- 2 for example. 

2/32767 = 0.000061027 ~= 0.00006.  Which makes sense because they give you mg/digit. 

But when you get down to +- 16, it because 0.73 mg/digit which is not your expected 0.48 mg/digit you would expect based on the other conversion values. 

Hope this helps,

Kevin

View solution in original post

0 Likes
Reply
5 Replies
Employee

Perhaps STM will be in a better position to address your queries and the included driver is from them too.

We have a "WICED Sense" app available from both iOS and Android that we used to complement the actual kit itself. Are you getting your expected readings from here?

0 Likes
Reply
Employee

Did you have a chance to check out the "Wiced Sense" app?

0 Likes
Reply
Anonymous
Not applicable

The Wiced Sense App doesn't calculate physically accurate data, it just scales it for display in the GUI. For many applications, this is enough. The actual acceleration in m/s^2 is not needed for things like orientation; relative measurements for the 3 axes do fine. But if you want to calculate velocity, you do need to do that scaling.  You're right, it is more of a ST driver thing. I just thought someone on this board may have figured it out already.

0 Likes
Reply
Anonymous
Not applicable

Hi reynald,

Sorry for such a late response, but here are a couple things that I found.

1.  yes I believe when they divide by 16 it is a bug in the driver. Someone pointed out other bugs in the driver in another post as well.

2.  Your method for raw data * resolution / 32767 is only valid for resolutions 2 through 8.

On the STM data sheet for the accelerometer, it gives you the conversion, mg/digit.  accelerometer datasheet.PNG

Using this will show why your formula works for resolutions 2 - 8.  Take +- 2 for example. 

2/32767 = 0.000061027 ~= 0.00006.  Which makes sense because they give you mg/digit. 

But when you get down to +- 16, it because 0.73 mg/digit which is not your expected 0.48 mg/digit you would expect based on the other conversion values. 

Hope this helps,

Kevin

View solution in original post

0 Likes
Reply
Anonymous
Not applicable

I was made aware of this thread, after starting a new thread. Sorry for double posting.

I have done some analysis of the accelerometer data and posted it here.

0 Likes
Reply