How to convert accelerometer data into G with the ADXL345 digital accelerometer

Go To Last Post
71 posts / 0 new

Pages

Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Am totally new to electronics and the datasheet is very confusing to me, so can anyone please guide me through the specification of the accelerometer? So that i can have a better understanding on the accelerometer and to be able to convert the accelerometer data into G.

 

X-axis Y-axis Z-axis -28 -26 218 These are the readings i get from the accelerometer with a +-2g range

 

This is the datasheet for the ADXL345 digital accelerometer [1]: https://www.analog.com/media/en/technical-documentation/data-sheets/ADXL345.pdf

 

import smbus
import time

# Get I2C bus
bus = smbus.SMBus(1)

# ADXL345 address, 0x53(83)
# Select bandwidth rate register, 0x2C(44)
#       0x0A(10)    Normal mode, Output data rate = 100 Hz
bus.write_byte_data(0x53, 0x2C, 0x0A)
# ADXL345 address, 0x53(83)
# Select power control register, 0x2D(45)
#       0x08(08)    Auto Sleep disable
bus.write_byte_data(0x53, 0x2D, 0x08)
# ADXL345 address, 0x53(83)
# Select data format register, 0x31(49)
#       0x08(08)    Self test disabled, 4-wire interface
#                   Full resolution, Range = +/-2g
bus.write_byte_data(0x53, 0x31, 0x08)

time.sleep(0.5)

# ADXL345 address, 0x53(83)
# Read data back from 0x32(50), 2 bytes
# X-Axis LSB, X-Axis MSB
data0 = bus.read_byte_data(0x53, 0x32)
data1 = bus.read_byte_data(0x53, 0x33)

# Convert the data to 10-bits
xAccl = ((data1 & 0x03) * 256) + data0
if xAccl > 511 :
    xAccl -= 1024

# ADXL345 address, 0x53(83)
# Read data back from 0x34(52), 2 bytes
# Y-Axis LSB, Y-Axis MSB
data0 = bus.read_byte_data(0x53, 0x34)
data1 = bus.read_byte_data(0x53, 0x35)

# Convert the data to 10-bits
yAccl = ((data1 & 0x03) * 256) + data0
if yAccl > 511 :
    yAccl -= 1024

# ADXL345 address, 0x53(83)
# Read data back from 0x36(54), 2 bytes
# Z-Axis LSB, Z-Axis MSB
data0 = bus.read_byte_data(0x53, 0x36)
data1 = bus.read_byte_data(0x53, 0x37)

# Convert the data to 10-bits
zAccl = ((data1 & 0x03) * 256) + data0
if zAccl > 511 :
    zAccl -= 1024

# Output data to screen
print ("Acceleration in X-Axis : %d" %xAccl)
print ("Acceleration in Y-Axis : %d" %yAccl)
print ("Acceleration in Z-Axis : %d" %zAccl)

Above are the code used.

This topic has a solution.
Last Edited: Sun. Apr 28, 2019 - 05:51 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Multiply result by 4milli g. Assuming 2g scale, 1g ie:gravity will measure around 256 as a raw value. Times 4 milli g gives around 1g. By moving the sensor around you will get a maximum reading of 1g.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Kartman,

 

First of all, thanks for replying. The above x,y,z axis data was acquired when the accelerometer is stationary and according to the method you provided, 218 * 0.004g = 0.872g. But it isn't close to 1g, am i doing something wrong? Also if i adjust the measurement range to +-4g,+-8g and +-16g do i just simply multiply the data acquire from +-4g,+-8g and +-16g by 0.004 in order to convert them into g?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

how manysamples did you try to get the reading of 218? How do you know the sensor was at the right Angle?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I did acquire the data several times and its ranging from 218-221 almost all the time. Also the data was acquired when the accelerometer is stationary.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Based on a limited experience of acelerometer sensors, they don't tend to be particularly well calibrated 'straight out of the box'.

It looks like the sensor gives a signed 10 bit output, so -512 to +511, call it +/- 512.

If it's configured for 2G full scale, then 1g as Kartman said would be a reading of 256.

So a reading of 220 is 220 / 256 = 0.86g.

 

If it was perfectly level (it proably isn't) and if it was perfectly calibrated (it probably isn't) then you would expect a reading of X = 0, Y=0, Z=1G=256.

Getting around -30 for X and Y (insted of 0) and around 220 (instead of 256) doesn't seem that crazy.

 

As a simple calibration procedure, you could take the average offset values you are geting with it 'level', then subtract those values from each raw reading to give a 'calibrated' result.

 

 

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi, MrKendo,

 

First of all, thank you for replying.

Shouldn't 10 bit output (0-1023) how come -512 and +512 why do we have to divide it by 2, can you briefly explain on this? Also, "the average offset values you are getting with it 'level'" which means the above data i acquired?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0


Because the sensor is specified as having a range of plus 2g to minus 2g.

 

Ross McKenzie ValuSoft Melbourne Australia

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi, valusoft,

 

First of all, thank you. 

Ah now i get it. Also if i set the measurement range to +-4g then i need to divide the 1024 by 4 only right?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

I have some experience in this area. I sell acceleration loggers ( http://www.ORElectronics.net ) The ones I use are from STMicro but the technology is very similar to that used by Analog Devices, Bosch, and others.

 

For all of these, the full scale sensitivity is not very precise. Its not only NOT very precise, but there can also be a lot of difference between axes and a lot of variation with temperature. Also, there tends to be a lot of zero offset. About the best that you can do is orient the sensor so that one of the axes is parallel to the gravity vector, take a reading or readings, then turn it over and take a bunch more readings. Average each set to make one "reading" for each. Then you can say that the difference between the two readings is 2.0g and the average of the two is 0g. 

 

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ckkkkk wrote:
Shouldn't 10 bit output (0-1023) how come -512 and +512

a 10 bit unsigned number covers the range 0 to 1023, but based on the code you posted

 

# Convert the data to 10-bits
xAccl = ((data1 & 0x03) * 256) + data0
if xAccl > 511 :
    xAccl -= 1024

 

it looks like it is easier to think of as a signed number, so it covers the range -512 to +511.

For simplicity I'm just calling it +/- 512.

A difference of 1 doesn't make much difference.

 

ckkkkk wrote:
Ah now i get it. Also if i set the measurement range to +-4g then i need to divide the 1024 by 4 only right?

I would think of it as, if full scale range was 4G then

 

-4G would give -512

+4G would give +512 (actually +511)

So  4G = 512

So 1G = 512 / 4 = 128.

 

ckkkkk wrote:
Also, "the average offset values you are getting with it 'level'" which means the above data i acquired

Yes.

Almost certainly the sensor will not read exactly 0 when in a field of 0G, there will be some offset, which will be different for each sensor due to manufacturing tolerances etc.

(Plus the other sources of error ka7ehk mentioned above).

So if you require more accurate readings, the sensor needs to be calibrated in some way.

Unlike ka7ehk I am not familar with the best ways to perform a calibration.

I was thinking of the most basic method which is to place it on a (reasonably) level surface and take X,Y Z readings to get the offsets.

Not optimal but it might be good enough.

 

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Jim,

Thank for replying and i will try to follow the method you provided to average out the values.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

MrKendo wrote:

I would think of it as, if full scale range was 4G then

 

-4G would give -512

+4G would give +512 (actually +511)

So  4G = 512

So 1G = 512 / 4 = 128.

 

 

Oh i just realized that with +-4g measurement range it will be in 11bit resolution but still 2048/4 = 512 and 512/4 = 128 which is still 128 per g.

 

 

MrKendo wrote:
Yes.

Almost certainly the sensor will not read exactly 0 when in a field of 0G, there will be some offset, which will be different for each sensor due to manufacturing tolerances etc.

(Plus the other sources of error ka7ehk mentioned above).

So if you require more accurate readings, the sensor needs to be calibrated in some way.

Unlike ka7ehk I am not familar with the best ways to perform a calibration.

I was thinking of the most basic method which is to place it on a (reasonably) level surface and take X,Y Z readings to get the offsets.

Not optimal but it might be good enough.

 

But all the data was acquired when the accelerometer is stationary and placed on the table, with the method you mentioned wouldn't this makes the data acquired to become the offset? Or the data i acquired is actually offset instead of acceleration data?

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello ckkkkk -

 

Please be aware that each axis will have a different full-scale calibration constant and a different zero offset. One axis is usually pretty easy - the axis that is normal to the mounting plane (e.g. circuit board). With some care, you can lay the board on a flat surface for one reading and turn it over for the opposite one. The other two are much harder unless you mount the board in some fixture that will hold it vertical on the four edges.

 

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ckkkkk wrote:

Oh i just realized that with +-4g measurement range it will be in 11bit resolution but still 2048/4 = 512 and 512/4 = 128 which is still 128 per g.

You got me hooked now so I had to go and take a look at the datasheet :)

It depends on the FULL_RES Bit.

If that bit is set then +/-4g range wil use 11 bit, in which case you have 1G = 256 still. If that bit is clear then it uses 10bit mode and 1G = 128.

 

ckkkkk wrote:
But all the data was acquired when the accelerometer is stationary and placed on the table, with the method you mentioned wouldn't this makes the data acquired to become the offset? Or the data i acquired is actually offset instead of acceleration data?

There is a good explanation in the datsheet under OFFSET CALIBRATION.

Basically with this simple method, you assume that X and Y should be in 0g field, so the reading you get is the offset.

You assume that Z should be 1G. You then have to assume that the correct value for 1G is 256 (or whatever). This may not be correct, and is what ka7ehk's method would improve on (I think). But anyway, if you assume that 1G should be 256, but you read 220, then you can say your Zoffset is (220 - 256) = -36.

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ka7ehk wrote:

Hello ckkkkk -

 

Please be aware that each axis will have a different full-scale calibration constant and a different zero offset. One axis is usually pretty easy - the axis that is normal to the mounting plane (e.g. circuit board). With some care, you can lay the board on a flat surface for one reading and turn it over for the opposite one. The other two are much harder unless you mount the board in some fixture that will hold it vertical on the four edges.

 

Jim

 

I'll try my best to get all the reading in orientation, but first i think i need to find a nice shaped wooden block and once again thank you for the advice.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

MrKendo wrote:

You got me hooked now so I had to go and take a look at the datasheet :)

It depends on the FULL_RES Bit.

If that bit is set then +/-4g range wil use 11 bit, in which case you have 1G = 256 still. If that bit is clear then it uses 10bit mode and 1G = 128.

 

Once again thank you for all the effort you spent, really appreciate it.

 

MrKendo wrote:

There is a good explanation in the datsheet under OFFSET CALIBRATION.

Basically with this simple method, you assume that X and Y should be in 0g field, so the reading you get is the offset.

You assume that Z should be 1G. You then have to assume that the correct value for 1G is 256 (or whatever). This may not be correct, and is what ka7ehk's method would improve on (I think). But anyway, if you assume that 1G should be 256, but you read 220, then you can say your Zoffset is (220 - 256) = -36.

Oh so that every of the reading i get next time on all these 3 axis needed to +28,+26 and +36 on x,y and z-axis.

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ckkkkk wrote:

Oh so that every of the reading i get next time on all these 3 axis needed to +28,+26 and +36 on x,y and z-axis.

Correct.

You can either think of it as

Xcalibrated = Xraw + Xoffset

or

Xcalibrated = Xraw - Xoffset

depending on which way round you choose to calculate offset (ie. you could think of Xoffset as either +28 or -28).

You just need to get the signs the right way round.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Question
Can i know what is the differences between the Sensitivity at XOUT, YOUT, ZOUT and Scale Factor at XOUT, YOUT, ZOUT under the SENSITIVITY section on page 4 of the datasheet? After i did some searching, this is one of things that i get

"Sensitivity of the accelerometer, sometimes referred to as the scale factor of the accelerometer, is the ratio of the sensor’s electrical output to mechanical input"

I also noticed that the value of the Sensitivity at XOUT, YOUT, ZOUT are same as the calculations that we did above. For example, 256 lsb/g for +-2g range, 128 lsb/g for +-4g range. Also, why do we need to include the sensitivity values to the calculation we need to perform above and can we use the scale factor value instead to replace the sensitivity value to perform the conversion?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ckkkkk wrote:
Can i know what is the differences between the Sensitivity at XOUT, YOUT, ZOUT and Scale Factor at XOUT, YOUT, ZOUT under the SENSITIVITY section on page 4 of the datasheet?

It's simply 2 different ways of saying the same thing. One is the inverse of the other (but with a factor of 1000 because of conversion fro g to mg)

 

sensitivity = 256 LSB/g

scale_factor = 1 / 256 g/LSB = 1000 / 256 mg/LSB

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

MrKendo wrote:

It's simply 2 different ways of saying the same thing. One is the inverse of the other (but with a factor of 1000 because of conversion fro g to mg)

 

sensitivity = 256 LSB/g

scale_factor = 1 / 256 g/LSB = 1000 / 256 mg/LSB

Noted, so 2 are with the same meaning with different implementation. 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Agree.

 

If you do the "calibration" that I suggested, then you do not need to know anything about the spec'd full scale value or the spec'd offset.

 

Please understand that the specifications provide a "typical" value and "limits" for each axis. That typical value is the ideal one. In the best of all worlds, that is how every device would behave. The limits are a recognition that individual devices are not ideal. The limits specify how far from the ideal any individual device can be. These numbers are basically irrelevant when you are doing your own calibration. YOU are determining what the ACTUAL full scale values and the ACTUAL offsets are so that, in the future, you can use those values to convert from the raw reading into something that is close to the true physical value.

 

Hope this helps

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I now have gain access back to the accelerometer and i have took 10 measurement readings from it while it's laying flat on the table. It seems that the z - axis readings are from 216,217 and 220 so which 1 do i use to determine the offset value?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well, you need to do a second step: turn it over and take 3 more measurements. Then, average the first set together, Then average the second set together. One set should have a positive value and the other should have a negative value. 

 

The number of counts for 1g is then the sum of the absolute values of two averages, divided by 2. Call this ZF  (Z full scale)

 

The number of counts for the zero offset is the sum of the values of the two averages, divided by 2. Call this Z0

 

Then, for a future measurement, Z, the g value is simply g = (Z - Z0)/ZF. Even better, take several readings, average them, and use that for Z. 

 

Direct parallel on any other axes.

 

Jim

 

 

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You need to flip the accelerometer over the other way and get the negative readings. Say you get +100 and -100. The offset is 0. If you get +110 and -90 then the offset is -10.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kartman wrote:
You need to flip the accelerometer over the other way and get the negative readings. Say you get +100 and -100. The offset is 0. If you get +110 and -90 then the offset is -10.

 

Hi Kartman,

I get the accelerometer data by looping it 10 times. Do i need to average the z-axis value then only find the offset? Also +110 and -90 shouldn't the offset = -20 why is it -10 only?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Why -10? 110-10 = 100. -90-10 = -100. We haven't hit trigonometry yet, so you best be revisiting your high school math books.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ka7ehk wrote:

Well, you need to do a second step: turn it over and take 3 more measurements. Then, average the first set together, Then average the second set together. One set should have a positive value and the other should have a negative value. 

I am not sure if i fully understand this but below is what i get from the accelerometer laying flat on a wooden block and the data was acquired using a 10 times loop.

Acceleration in X-Axis : -6
Acceleration in Y-Axis : 6
Acceleration in Z-Axis : 222
Acceleration in X-Axis : -6
Acceleration in Y-Axis : 6
Acceleration in Z-Axis : 222
Acceleration in X-Axis : -7
Acceleration in Y-Axis : 6
Acceleration in Z-Axis : 219
Acceleration in X-Axis : -7
Acceleration in Y-Axis : 6
Acceleration in Z-Axis : 219
Acceleration in X-Axis : -7
Acceleration in Y-Axis : 5
Acceleration in Z-Axis : 218
Acceleration in X-Axis : -7
Acceleration in Y-Axis : 5
Acceleration in Z-Axis : 218
Acceleration in X-Axis : -9
Acceleration in Y-Axis : 6
Acceleration in Z-Axis : 218
Acceleration in X-Axis : -9
Acceleration in Y-Axis : 6
Acceleration in Z-Axis : 218
Acceleration in X-Axis : -12
Acceleration in Y-Axis : 4
Acceleration in Z-Axis : 218
Acceleration in X-Axis : -12
Acceleration in Y-Axis : 4
Acceleration in Z-Axis : 218

 

And these are the data acquired from the accelerometer when it's upside down.

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kartman wrote:

Why -10? 110-10 = 100. -90-10 = -100. We haven't hit trigonometry yet, so you best be revisiting your high school math books.

Ok i get it now. 

 

Kartman wrote:
You need to flip the accelerometer over the other way and get the negative readings. Say you get +100 and -100. The offset is 0. If you get +110 and -90 then the offset is -10.

I have averaged up all the readings and get 219 and for upside down it is -263.8. But its +256 and -256, so it be 37 and -7.8 offset?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I am not sure if i fully understand this 

OK now flip it over in all 3 dimensions and re-read. For example if I look at just the X from your first readings I see:

Acceleration in X-Axis : -6
Acceleration in X-Axis : -6
Acceleration in X-Axis : -7
Acceleration in X-Axis : -7
Acceleration in X-Axis : -7
Acceleration in X-Axis : -7
Acceleration in X-Axis : -9
Acceleration in X-Axis : -9
Acceleration in X-Axis : -12
Acceleration in X-Axis : -12

So the average of those is -8.2 (add them all up, divide by 10). Now flip over. Take 10 readings, perhaps the average of those is +6.7 ? So the "mid point" is half way between -8.2 and +6.7 which would be -1.5

Last Edited: Fri. Apr 26, 2019 - 10:29 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Your Z readings appear to be:

Acceleration in Z-Axis : 222
Acceleration in Z-Axis : 222
Acceleration in Z-Axis : 219
Acceleration in Z-Axis : 219
Acceleration in Z-Axis : 218
Acceleration in Z-Axis : 218
Acceleration in Z-Axis : 218
Acceleration in Z-Axis : 218
Acceleration in Z-Axis : 218
Acceleration in Z-Axis : 218

-262
-262
-263
-263
-265
-265
-265
-265
-264
-264

The +ve average is then +219 and the -ve is +263.8. So the midpoint is +44.8

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:

Your Z readings appear to be:

Acceleration in Z-Axis : 222
Acceleration in Z-Axis : 222
Acceleration in Z-Axis : 219
Acceleration in Z-Axis : 219
Acceleration in Z-Axis : 218
Acceleration in Z-Axis : 218
Acceleration in Z-Axis : 218
Acceleration in Z-Axis : 218
Acceleration in Z-Axis : 218
Acceleration in Z-Axis : 218

-262
-262
-263
-263
-265
-265
-265
-265
-264
-264

The +ve average is then +219 and the -ve is +263.8. So the midpoint is +44.8

 

According to all these then y reading would be

6
6
6
6
5
5
6
6
4
4

 

1
1
0
0
-3
-3
1
1
2
2

+ve = 54 / 10 = 5.4 and -ve = 2 / 10 = 0.2 and the "midpoint" or offset would be 53.8?

 

Last Edited: Fri. Apr 26, 2019 - 10:50 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

How do you get 53.8 from that? Halfway between 5.4 and 0.2 is 2.8

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ckkkkk wrote:
I have averaged up all the readings and get 219 and for upside down it is -263.8. But its +256 and -256, so it be 37 and -7.8 offset?

 

The difference is +44.8. Divide this by two. 22.4. Thus: 219 + 22.4 = 241.4 , -263.8 + 22.4 = -241.4. Both side balance. The scale would be 250/241.4 = 1.0356. Uncalibrated the scale is off by around 3%. Does this line up with the datasheet? 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
Uncalibrated the scale is off by around 3%

Hi clawson,

My bad, i mistook the value 54 instead the 5.4.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kartman wrote:

ckkkkk wrote:
I have averaged up all the readings and get 219 and for upside down it is -263.8. But its +256 and -256, so it be 37 and -7.8 offset?

 

The difference is +44.8. Divide this by two. 22.4. Thus: 219 + 22.4 = 241.4 , -263.8 + 22.4 = -241.4. Both side balance. The scale would be 250/241.4 = 1.0356. Uncalibrated the scale is off by around 3%. Does this line up with the datasheet? 

Shouldn't it be 256/241.4 = 0.9415 as 256 represents 1G? But what i am going to do is strap the accelerometer on wrist and the accelerometer will likely be on the same direction for most of the time and based on the method you guys provided, it takes both +- z-axis data in order to calculate the offset and to convert the value in G. Is there any other way that i can get the offset that would be usable for both the +ve and -ve of z-axis?

Last Edited: Fri. Apr 26, 2019 - 12:05 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ckkkkk wrote:
Shouldn't it be 256/241.4 = 0.9415 as 256 represents 1G?

 

Is your calculator dyslexic? I had a read of the datasheet and , yes, the full scale value is noted to be 256 or 3.9mG/lsb. Thus the scale factor would be 256/241.4 = 1.06

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kartman wrote:

ckkkkk wrote:
Shouldn't it be 256/241.4 = 0.9415 as 256 represents 1G?

 

Is your calculator dyslexic? I had a read of the datasheet and , yes, the full scale value is noted to be 256 or 3.9mG/lsb. Thus the scale factor would be 256/241.4 = 1.06

 

 

Oh ya something wrong with that calculator. But still

 

ckkkkk wrote:
But what i am going to do is strap the accelerometer on wrist and the accelerometer will likely be on the same direction for most of the time and based on the method you guys provided, it takes both +- z-axis data in order to calculate the offset and to convert the value in G. Is there any other way that i can get the offset that would be usable for both the +ve and -ve of z-axis?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It's called ‘calibration’ - you do it once and store the offset and scale values usually in eeprom. For a one off, you might hard code these values into your code. Whilst the calibration drifts with temperature, it is only small. The datasheet says around 0.01% per degreeC.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Besides, why are you concerned with scale and offset? If you want to measure movement and basic orientation, the errors are probably insignificant.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kartman wrote:
Besides, why are you concerned with scale and offset? If you want to measure movement and basic orientation, the errors are probably insignificant.

 

I am doing a fall detection system with raspberry pi and the prototype will eventually place on the wrist. Thus, the acceleration is important for me to determine whether or not the fall event happened.

Last Edited: Fri. Apr 26, 2019 - 01:51 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Wrong answer. For fall detection you are more interested in the change rather than the absolute values. So again, why do you need to scale and offset? The errors are probably insignificant. I would understand if you were making an inclinometer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kartman wrote:
Wrong answer. For fall detection you are more interested in the change rather than the absolute values. So again, why do you need to scale and offset? The errors are probably insignificant. I would understand if you were making an inclinometer.

I did quite a lot of research before this and many suggest that it is best to get 1G on the z-axis and 0G on both the x,y-axis. 

Acceleration in Z-Axis : 222
Acceleration in Z-Axis : 222
Acceleration in Z-Axis : 219
Acceleration in Z-Axis : 219
Acceleration in Z-Axis : 218
Acceleration in Z-Axis : 218
Acceleration in Z-Axis : 218
Acceleration in Z-Axis : 218
Acceleration in Z-Axis : 218
Acceleration in Z-Axis : 218

So again if i just take 1 of the value above, lets say 222 for example then i need to multiply 222 with 3.9mg to convert it into G which makes 222*0.0039 = 0.8658 G. Which is not even close to 1G. Thus, i need to know the offset so that i can make the z-axis reading closer to 1G. Or is it just using 1G - 0.8658G = 0.1342G / 256 - 222 = 34 to find the offset for the z-axis?

Last Edited: Fri. Apr 26, 2019 - 03:35 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

We seem to be going around in circles. We’ve shown you how to calculate the offset and scale. For a given sensor you do this once and make note of the values. You then use these values in subsequent readings. The calculation becomes:
Real value = (raw value - offset) * scale

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Getting 0 on the other axes results in chasing your tail. You cannot know what zero on any axis is until you calibrate that axis. Calibrating any axis requires zero on the other two.

 

And round, and round again. OR, you can iterate through this set of measurements several times to get arbitrarily close.

 

Because it is a cosine function, the error on the gravity axis due to the other axes NOT being zero is small, as long as those other axes are CLOSE to zero. So, get close and accept it. 

 

In the end, you really don't have a precision sensor to start with, so why all the agony over precision calibration? Even if you do the calibration precisely, you only have 1 part in +/-256 resolution!

 

Jim

 

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

Last Edited: Fri. Apr 26, 2019 - 10:50 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Wait i am quite lost now, where exactly are these again?

Kartman wrote:
We’ve shown you how to calculate the offset and scale. For a given sensor you do this once and make note of the values. You then use these values in subsequent readings. The calculation becomes: Real value = (raw value - offset) * scale

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ka7ehk wrote:

Because it is a cosine function, the error on the gravity axis due to the other axes NOT being zero is small, as long as those other axes are CLOSE to zero. So, get close and accept it. 

 

Jim

 

 

Alright.

 

ka7ehk wrote:
In the end, you really don't have a precision sensor to start with, so why all the agony over precision calibration? Even if you do the calibration precisely, you only have 1 part in +/-256 resolution!

Jim

 

Ok i think i got it now, what i am doing right now is just going to perfect the 3 axis readings from 1 side to be perfect but there are other sides...So is there a universal value that can used by all the other sides to calibrate?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

No you haven’t! There’s no magic values - you must perform the calibration procedure to obtain the values. If you don’t want to do the calibration then tolerate the +/-10% error.
Realise that this is not a perfect sensor - it has noise, offsets, scaling and temperature sensitivity.the datasheet outlines these. You need to understand these parameters and determine if they are suitable for your application. Personally, for a fall detector, precision isn’t paramount as there’s a big difference between someone standing up and when they’ve fallen down. You don’t need degree resolution to measure this.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kartman wrote:
No you haven’t! There’s no magic values - you must perform the calibration procedure to obtain the values. If you don’t want to do the calibration then tolerate the +/-10% error.

Which means all the above calculations discussed are all for only 1 direction like this?

 

Kartman wrote:
Realise that this is not a perfect sensor - it has noise, offsets, scaling and temperature sensitivity.the datasheet outlines these. You need to understand these parameters and determine if they are suitable for your application. Personally, for a fall detector, precision isn’t paramount as there’s a big difference between someone standing up and when they’ve fallen down. You don’t need degree resolution to measure this.

So, it is better to just bear with the 10% errors and move on with the data i get?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

For each axis you need to measure gravity in the positive and negative direction. From these values we obtain the offset and scale values.

Only you know what method you are using to determine a fall, so it is up to you to decide what accuracy you require.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kartman wrote:
For each axis you need to measure gravity in the positive and negative direction. From these values we obtain the offset and scale values. Only you know what method you are using to determine a fall, so it is up to you to decide what accuracy you require.

Based on the data i provided above it is only able to find the offset for the z-axis right? Because only z-axis is experiencing the G force. Am i correct? 

Pages