ADXL345 help??

abdeshpande

New Member
Hi! I'm trying to put together a project where a picaxe 08m2 would log data from an adxl345 accelerometer at 100hz or so. I'm using a proto board from the startup kit. I am using an accelerometer based of the adxl345 (basically a breakout) and have soldered it to the board. It is running off 4.5v (three AA batteries) My program just for logging data is below. it doesn't save it or anything; I'm just using it to test live while it's hooked up to my computer. the code is below. the accelerometer is here: http://www.robotmesh.com/grove-3-axis-digital-accelerometer-16g and I used this tutorial: https://www.sparkfun.com/tutorials/240 and I use this datasheet for the accelerometer: https://www.sparkfun.com/datasheets/Sensors/Accelerometer/ADXL345.pdf

So basically, I can get reading from the accelerometer, but I have NO IDEA what im reading. When I perform the calculations which should apparently get me acceleration in Gs, I get numbers that ARE NOT 0, when the accelerometer is still. Sometimes b3 just goes straight from 0 to 255 and back and forth. Does anyone know what im getting from the accelerometer and what I should be doing differently? BTW the data is stored under 2 different byte variables and are combined into word variables so w0 is x, w1 is y, and w2 is z. When I take any of them, and multiply it by 0.0078 (which the tutorial says to do) I DONT get 0. Does anyone know what I should do?

Help please and thanks in advance!

Code:
HI2CSETUP I2CMASTER, 0xA6, i2cfast, i2cbyte

HI2COUT 0x31,(0x01) ;puts into +-4g mode
HI2COUT 0x2D,(0x08) ;puts into measurement mode

main:

HI2CIN 0x32,(b0,b1,b2,b3,b4,b5) ;getting data from adxl345. b0 and b1 are x, b2 and b3 are y, and b4 and b5 are z. They *should* be combined in w0, w1, and w2
debug
pause 10
goto main
 

westaust55

Moderator
Welcome to the PICAXE forum.

Have you tried a search of the PICAXE forum for other threads on the ADXL345 ?

You appear to have the i2c slave address correct.

See if the information in these thread where the users got their ADXL345 working helps:
http://www.picaxeforum.co.uk/showthread.php?24058-I2C-help-ADXL345-3-axis-accelerometer-from-sparkfun
http://www.picaxeforum.co.uk/showthread.php?25635-i2c-code-working-on-14m2-but-not-20x2
http://www.picaxeforum.co.uk/showthread.php?18234-Spark-Fun-IMU-Fusion-board/page2


You have not included the math part of you code/test so hard to say exactly what you are doing wrong.

If you take for example the x axis, w0 = b1:b0 (the same as 256*b1 + b0 automatically) so no math to combine is required.


When I take any of them, and multiply it by 0.0078
How are you multipling?
To achieve a useful value are you doing something like
x-axis = w0 * 78 / 10000
or
x_axis = w0 * 8/1024 or even x_axis = w0 / 128
which will give zero for low G values
you could use say
x_axis = w0 *78 / 100 or x_axis = w0 * 100/128 or even x_axis = w0 *25 / 32
which all will give a value 100 times G, so a value like 0.05 will be seen as 5 rather than 0.
In 4g mode the chip operates at 10 bit so there are 6 upper bits not used.
At a quick glance I could not see how the data signifies a negative G value. Is it just the msb set or are they using 2’s compliment ?
Maybe post more of the PICAXE code you are trying to use.
 
Last edited:

inglewoodpete

Senior Member
I have not used the ADXL345 i2c accelerometer chip. However, I have done quite a lot of work with the 3-axis analogue version - ADXL335.

Firstly, you need to power the ADXL chip with a 3.3v power supply. 3.6v is the absolute maximum. 4.5v will probably damage this chip.

With a 3.3v supply for the ADXL, it is simplest to run the PICAXE from the same power supply to simplify the interfacing between the two chips.

I found the best way to test the chip was to place it flat. Then one axis will give a minimum reading and the other two axes will read at half scale. Turn the chip over and the previous axis that originally gave a min reading will give something like twice the reading of the half scale of the other two. Rotating the chip 90 degrees should give readings of minimum, half scale and full scale, depending on which axis is pointing in which direction.
 

abdeshpande

New Member
Hi! Yeah, I just realized that the voltage was too much. However, I hooked it up to 3.3V and it just didn't work. There was no response coming from the accelerometer. But when I reconnected it to 4.5V I was able to get response. Also, when the chip is flat, I am getting x maxed out, y at around 0, and z at around 120 (these are just raw values without being multiplied or anything.) is that matching your previous experience? Thanks!
 

abdeshpande

New Member
This is a debug picture while the accelerometer is flat on the table. I am just manually multiplying the w values by 0.0078 outside of the program. (should I even be doing that?) I created b7 which should equal w0, but while it's flat it doesn't, but when it's at a random angle it is. w3 is just a byproduct of creating b7. Also, b1, b3, and b5 are all either 0 or 255 at any time; they aren't anything else. is that supposed to happen? Thanks!
debug pic.png
 
Last edited:

inglewoodpete

Senior Member
Hi! Yeah, I just realized that the voltage was too much. However, I hooked it up to 3.3V and it just didn't work. There was no response coming from the accelerometer. But when I reconnected it to 4.5V I was able to get response. Also, when the chip is flat, I am getting x maxed out, y at around 0, and z at around 120 (these are just raw values without being multiplied or anything.) is that matching your previous experience? Thanks!
Sorry if I sound little pedantic here. The magic smoke will escape if you continue to run the ADXL345 chip at 4.5v!

When you say you used 3.3v, did you power BOTH chips at 3.3v at the same time? The i2c will not communicate reliably if the voltage on the two chips is different. 3.3v to 4.5v won't work without a converter interface of some sort.
 

abdeshpande

New Member
Sorry if I sound little pedantic here. The magic smoke will escape if you continue to run the ADXL345 chip at 4.5v!

When you say you used 3.3v, did you power BOTH chips at 3.3v at the same time? The i2c will not communicate reliably if the voltage on the two chips is different. 3.3v to 4.5v won't work without a converter interface of some sort.
Hi! Yeah, before I was running the picaxe on 4.5v and adxl345 at 3.3v. I switched both to running at 3.3v and I was able to get a reading. However, I still have no idea how to get a value in Gs. I have attached a pic of the debug screen while the accelerometer is flat. Thanks!
debug pic 2.png
 
Last edited:

hippy

Technical Support
Staff member
Also, when the chip is flat, I am getting x maxed out, y at around 0, and z at around 120
The data values are two's complement 16-bit word values, LSB first, MSB second, so your DEBUG output shows -

X : $FF $FE = -2
Y : $00 $02 = 2
Z : $00 $77 = 119

Assuming 8mg per bit, that would make Z = 119*8 = 0.928 which is close(ish) to 1g. I am not familiar with the sensor but that would suggest the readings are in the right ball park. Perhaps try it upside down, rotated etc and see what results you get.
 

hippy

Technical Support
Staff member
This (untested) code may prove more useful that the DEBUG you are using ...

Code:
#Picaxe 08M2
#Terminal 4800

HI2cSetup I2CMASTER, 0xA6, I2CFAST, I2CBYTE

HI2cOut 0x31, ( 0x01 )
HI2cOut 0x2D, ( 0x08 )

Do
  HI2cIn 0x32, ( b0,b1, b2,b3, b4,b5 )
  w3 = w0 : b0 = "X" : Gosub ReportAxis
  w3 = w1 : b0 = "Y" : Gosub ReportAxis
  w3 = w2 : b0 = "Z" : Gosub ReportAxis
  Pause 500
Loop

ReportAxis:
  If w3 >= 0x8000 Then
    w3 = -w3
    SerTxd( b0, " = -", #w3 )
  Else
    SerTxd( b0, " = +", #w3 )
  End If
  If b0 = "Z" Then
    SerTxd( CR, LF )
  Else
    SerTxd( 9 )
  End If
  Return
 

abdeshpande

New Member
Assuming 8mg per bit, that would make Z = 119*8 = 0.928 which is close(ish) to 1g. I am not familiar with the sensor but that would suggest the readings are in the right ball park. Perhaps try it upside down, rotated etc and see what results you get.
I might be wrong, but wouldn't 1G mean that it's accelerating at the speed of gravity? So if it's still shouldn't I be seeing 0G? Also, the datasheet says that at +-4g range the data is at either 10 bit or 11 bit (i'm not really sure) So isn't the combined data that you said 16 bit? How would I make it 10 or 11 bit? Thanks!
 

Technical

Technical Support
Staff member
16 bit is simply 10 or 11 bits with some extra 0s at the front.
i2c protocol only uses whole bytes, so you will always get 16 bits.
 

inglewoodpete

Senior Member
I might be wrong, but wouldn't 1G mean that it's accelerating at the speed of gravity? So if it's still shouldn't I be seeing 0G?
If we were in a 0G environment, we would tend to float away! 1G is normal gravity, since G is short for gravitational force at the earth's surface.

Also, the datasheet says that at +-4g range the data is at either 10 bit or 11 bit (i'm not really sure) So isn't the combined data that you said 16 bit? How would I make it 10 or 11 bit?
To add to what Technical has said above, the 16-bit values would have 10- or 11-bit significant bits. Positive values would have the upper bits set to zeros while negative numbers would be 'topped up' with ones. Negative gravity values would be expressed as twos compliments. The data sheet should give more details.
 

abdeshpande

New Member
If we were in a 0G environment, we would tend to float away! 1G is normal gravity, since G is short for gravitational force at the earth's surface.



To add to what Technical has said above, the 16-bit values would have 10- or 11-bit significant bits. Positive values would have the upper bits set to zeros while negative numbers would be 'topped up' with ones. Negative gravity values would be expressed as twos compliments. The data sheet should give more details.
Thanks! I'm building a rig to test the acceleration and measure it against something else. If I encounter any problems I'll post it up here. Thanks for everything!
 
Top