Linear Accelerometer

I've been looking for some time now and reading posts but I still cannot find a simple LINEAR accelerometer that will give me acceleration in 1 direction (3 is fine but I won't use them). I have no need for rotation whatsoever and I only need to sense a couple of gees and not shock but smooth acceleration. Basically, in no way is this a phone application. It's to measure car acceleration. Does anybody know of a chip that will do this, that will work easily with Arduino? I guess even if it doesn't work easily I'll have to make it work because I can't find anything that'll do the job. I must be doing something wrong because I refuse to believe there's no chip on the market to measure acceleration in a straight line... anyway thanks for the advice.

In terms of simplicity, it's probably better to acquire a 3-axis IMU and use only the one appropriate for your application. Many have a range of +/- 2, 4, 8, and 16 G. They also have supporting libraries and example code.

That was initially also my opinion. I already have a 9DOF IMU... P/N starts with GY-something.

After doing a lot of reading about it, it seemed inappropriate for linear acceleration because it had only rotational accelerometer functions and used the onboard magnetometer and gyro sensors for the other functions. I would much prefer using a sensor that was designed specifically to measure linear forces and displacements rather than trying to interpolate rotational data from an IMU. Considering how jittery the output always looked on various youtube videos I doubt I'd get anything of value from it while driving a car. I need something where I can focus on 1 output that is only calibrated to return readings from 1 direction, so I can mount it on my dash, hit the gas and dump the values into Excel to produce a curve that isn't plagued with noise.

With a 9-DOF then three are linear, acceleration in X, Y, and Z. Just select one of those three, probably X, and orient it aiming forward in the vehicle. You're correct though that the low level output drifts and is noisy and may not be suitable for your application. I would first try it and see what you get. You can orient it horizontal and check for zero drift and noise then rotate so it sees gravity. That should tell you whether that class of device is suitable. It may turn out that a single axis device of suitable quality is not available or more likely, too costly.

Keep us informed if you find one as others may also be interested.

Ok I'll give it a try. First I have to learn how to use the library, as there is apparently some sort of calibration mode it has to go through on power-on to null everything out.

Most libraries have a folder of examples. Just select one and watch the X/Y/Z accel values and note the drift. Then rotate the sensor to the other two orientations and note the value of G. Calibration is essentially finding the readout values when the value should be 0 G and 1 G. The raw data for these two values can be mapped to the appropriate G values.

What is the full part number for your device? I'd like to find the library and look at the examples.

I think it’s the GY-85 9DOF IMU

Here's a link to the GY-85 library. It contains a nice example that prints out all values on 500msec intervals. Look at the .H and .CPP files for other available functions.

Be sure to add pullup resistors to the I2C lines. A value of 4K7 is sufficient.

I will try it but there's something still nagging me that I just can't drop until I wrap my head around it.

I looked up linear accelerometer before and searched through tons of irrelevant garbage until I finally found the ADXL335 as the best match. Just now I read that the ADXL345 on the GY-85 is basically a digital version of the same sensor. I don't understand how this is possible. You can't have a linear and a rotational accelerometer in the same sensor.

You rotate a chip about it's CoG and it detects angular motion and reports that as a number


you maintain the chip's attitude and simply push it in 1 direction, thus translating it with no rotation... completely different thing. I've seen a ton of youtube videos where the GY-85 is used on a glove or the breakout board is simply rotated around in the user's hand and some software on a computer screen rotates a cube to mimic the motion --> rotational sensor clearly.

I have never seen the same sensor used to detect linear motion. How could it? Rotating an object produces a net zero force in any axis. You'd need a different sort of sensor to measure the force differential at some fixed distance from the rot center.

Bottom line, if I try to detect linear motion using a sensor which is clearly capable of rotational sensing, how do I interpret the data? What would the numbers mean? How would the sensor know the difference between a rotation about the X-axis occurring at rest or the same rotation happening in an accelerating vehicle? The physics of rotation and translation are simply not the same so i have no idea how to read and interpret the values from the chip I have. Also, something on the internet is wrong since it keeps saying the 335 and 345 are older and newer (digital) versions of the same thing yet the former is actually labelled as a linear accelerometer and the later has been shown time and again to measure rotation.

I don't get it. I've used linear accelerometers at work (don't remember the part number though). They should be extremely common. Why can't I find any?

I see your point and not knowing the internal design of a 6-DOF, I would have to assume that the device contains both linear and rotational elements and each are sensitive to only it's intended motion. I found this document that shows the internals of a MEMS chip. Perhaps the drawings will show how each works and why it is sensitive in only the intended fashion.

I found this device from Sparkfun. It's range is obviously not what you want but perhaps the manufacturer of the ADXL family of devices might have something more suitable.

Your GY-85 board is just a combination of the ADXL345, IDG3205, and HMC5833L. These three chips all speak I2C so they all play together well on the same board. If you look closely at the three black chips you should be able to see which is which.

If you're wondering why the board is called a "GY-85"... no reason. It's just a very popular, mass-produced board that was given its own name. That same kind of phenomenon can be seen with the "ESP12", for example.

YTWally: That looks like precisely the sort of chip I would need but indeed it has too large a range. Meantime I will simply load a sample sketch for my IMU and see what happens when I translate the board or when I just sit it on the table. If it has any linear elements whatsoever it should detect gravity you would think.

The example code shows print statements for three axes in accel, gyro, and magnetic, or 9-DOF. You will need only X-accel but note the stability and range of the other two accel axes in the three possible orientations. This will give you a clue as to what needs to be calibrated.

The module contains three independent sensors but you will only need to be talking to the ADXL345 through the library functions.

Well… the results were a bit unexpected, anti-climatic and I’m starting to wonder how many people have actually used these modules.

Soldered the headers on, loaded up the example sketch and looked at the terminal output while holding the sensor in my hand. All 3 accelerometer readings were fairly stable without any tinkering or calibration of w/e. Rotating the board in all 3 axes caused the value of 128 to change from x to y to z predictably while the others were close to 0. I didn’t expect this sort of stability out of the box, especially after seeing so many videos with horribly noisy and bogus data. I guess some people just don’t know what they’re doing or they’re using the wrong software or… who knows.

Anyway it appears the ADXL345 is a linear accelerometer after all and the gyro handles the rotational stuff. My next test is to take my laptop into my car and record the accelerometer values to the EEPROM during a WOT run. We’ll see what the graph looks like.

Print the data to the serial monitor. When each test is done, copy from the monitor window and paste into a text file in Notepad. After several tests, copy text file to the HD. Later, you can import to a spreadsheet or plot in something like SciDAVis.

I have written a sketch to save all the values of the Y sensor only to EEPROM for 15 seconds of driving. Here’s the sketch:

#include "GY_85.h"
#include <Wire.h>
#include <EEPROM.h>

GY_85 GY85;     //create the object

void setup()
    pinMode(13, OUTPUT);
    digitalWrite(13, LOW);
//    Serial.begin(9600);
//    delay(10);
    digitalWrite(13, HIGH);

void loop()
  int i = 0;
//    int ax = GY85.accelerometer_x( GY85.readFromAccelerometer() );
    int ay = GY85.accelerometer_y( GY85.readFromAccelerometer() );
//    int az = GY85.accelerometer_z( GY85.readFromAccelerometer() );
//    int cx = GY85.compass_x( GY85.readFromCompass() );
//    int cy = GY85.compass_y( GY85.readFromCompass() );
//    int cz = GY85.compass_z( GY85.readFromCompass() );

//    float gx = GY85.gyro_x( GY85.readGyro() );
//    float gy = GY85.gyro_y( GY85.readGyro() );
//    float gz = GY85.gyro_z( GY85.readGyro() );
//    float gt = GY85.temp  ( GY85.readGyro() );
//    Serial.print  ( "accelerometer" );
//    Serial.print  ( " x:" );
//    Serial.print  ( ax );
//    Serial.print  ( " y:" );
//    Serial.print  ( ay );
//    Serial.print  ( " z:" );
//   Serial.print  ( az );
 //   Serial.print  ( "  compass" );
 //   Serial.print  ( " x:" );
 //   Serial.print  ( cx );
 //   Serial.print  ( " y:" );
 //   Serial.print  ( cy );
 //   Serial.print  (" z:");
 //   Serial.print  ( cz );
 //   Serial.print  ( "  gyro" );
 //   Serial.print  ( " x:" );
 //   Serial.print  ( gx );
 //   Serial.print  ( " y:" );
 //   Serial.print  ( gy );
 //   Serial.print  ( " z:" );
 //   Serial.print  ( gz );
 //   Serial.print  ( " gyro temp:" );
 //   Serial.println( gt );
    delay(14);             // only read every 0,5 seconds, 10ms for 100Hz, 20ms for 50Hz
    EEPROM.write(i, ay);
  digitalWrite(13, LOW);

The problem is, I’m using the GY-85 library, not the ADXL library so I don’t know how to access the functions of the ADXL. Specifically I noted that the values when the sensor was at rest are about 128. This is not using the full resolution. I want to:

Increase resolution from 10 bit to 13 bit, per the chip specs
Decrease the Gee range to +/- 2 Gees
Increase sensor refresh rate to 100Hz

How can I do that using the existing GY-85 library?

Best way to find functions that are not used in an example is to read both the .H and .CPP files.

If the at rest readout is 128 then it looks like you're in 8-bit mode. Check the Z-axis with the board normal then inverted. You will probably see values of ~64 and ~192 or +/- 1 G if on the +/- 2 G scale.

If the three sensor chips have their I2C pins wired in parallel then you should be able to use the Adafruit ADXL345 library and talk to the the chip directly. There are many functions in that library.

I just took a quick look at both files and .H has a list of all the functions. The .CPP file mentions 10-bit resolution.

Found the ADXL345 data sheet here. It appears that the sensor is +/- 16G with 13-bit resolution. For lower range values, they just throw away MS bits. Therefore, the +/- 2G range is 10-bit. That's what I remember when I used the Adafruit breakout several years ago. If the GY-85 library is using 8-bit then they're throwing away more bits and scaling the range down even further. Try the Adafruit library as it has four examples.

Really? They reduce the range by throwing away precision? Lame.

Thanks, will investigate.