• State TI Thinks Resolved
  • Locked Locked
  • Replies 10 replies
  • Answers 1 answer
  • Subscribers 82 subscribers
  • Views 4931 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Translating accelerometer data from bytes to G values

Jesus Mora
Prodigy 50 points

Hi all,

 

I´m already be able to read accelerometer data, but what I read are bytes. Anyone know how to obtain G values from the bytes received? I have tried to do some linear translations but results are not good enough...Actually I think the data read by TI software are not correct.

When the new release with source code?

 

Thanks in advance,

Jesus Mora

 

  • 0
    Guru 17650 points

    Hi Jesus,

    which accelerometer ar you using? Usually such kind of information can be found in the accelerometer users manual, so have a look at it.

    Kind regards
    aBUGSworstnightmare

  • 0 in reply to Joerg Quinten
    Prodigy 50 points

    Hi,

    The accelerometer is the one used by the Chronos sport watch. I´m gonna look at it...

    Thank you so much,

    Jesus Mora

  • 0
    Guru 227245 points

    Jesus Mora said:
    I´m already be able to read accelerometer data, but what I read are bytes

    Well, what do you expext to read? Apples?

    It solely depends on the accelerometer device, how the data is being presented. Some offer internal calibration and linearisation and provide human-readable values, others prvide a simpole voltage reading of the internal sensor and you need to convert the value into something meaningful using a formula or a lookup table. There can be an offset, a linear error or a nonlinear error. It all depends on the device you use. And of course on your math formula. Keep in mind that 10*(x/10) is different to (10*x)/10 due to integer truncation. Unless you use floating point arithmetics (and even then, but to a much lesser extent)

    Also keep in mind that eery accelerometer is exposed to gravity, so if placed parallel to earth it will have an offset of ~9.81 m/s (~1G). But if not 100% parallel, you will read less. And if it is an 2D/3D accelerometer, you'll see an offset on the other axis then.

    With the very limited information you provided, these general hints are all we can give you.

  • 0 in reply to Jens-Michael Gross
    Prodigy 40 points

    I just want to verify few things,

    let's say if  my accelerometer data was 1e (hex), then I converted it to binary which is  0001 1110 and my Bit level description in [mg] for acceleration registers of CMA3000-D01 is:

    B7 = sign bit (since the acceleration data is presented in 2's complement format)

    B6 = 1142;

    B5 = 571;

    B4 = 286;

    B3 = 143;

    B2 = 71;

    B1 = 36;

    B0 =18mg;

    And I converted it to mg by multiplying each bit to it's corresponding level and sum then up i.e => 0*1142+1*571+1*286+1*143+1*71+0*36+0*18 mg = 1101mg.

    Does my conversion looks right here?

    Thanks.

  • 0 in reply to hazmel ilyas
    Guru 227245 points

    hazmel ilyas said:
    Does my conversion looks right here

    No. You're one bit off.

    0x1e is indeed 0001 1110. But you converted 0011 1100.
    The correct G reading for 0x1e is 0.536 G (in one direction). As I explained before, gravitation is an acceleration and it is split across more than one axis if the sensor is not positioned exactly horizontally.

  • 0 in reply to Jens-Michael Gross
    Prodigy 40 points

    Yes you are correct it should be 536mg. However I was just wondering, let's say if we receive the byte E2 (1110 0010) then interpret it as the decimal -30 since it's in 2's complement format. The leftmost bit signifies it is a negative number. After we did the conversion to mg by using the AccelerometerMultiplier values, we get 536mg. Then we have to multiply by -1 since it is -30. Therefore final answer is -536mg.

    Does my calculation here looks correct?

    Thanks.

  • 0 in reply to hazmel ilyas
    Guru 227245 points

    hazmel ilyas said:
    if we receive the byte E2 (1110 0010) then interpret it as the decimal -30

    Yes.

    hazmel ilyas said:
    After we did the conversion to mg by using the AccelerometerMultiplier values, we get 536mg. Then we have to multiply by -1 since it is -30. Therefore final answer is -536mg.

    Hmmm, I'm not really sure about that. It sounds right.
    But without reading the datasheet very carefully, I don't want to say anything definite. I've see so many weird or fuzzy definitions... It may well be that you have to take the lower 7 bits literally and use the MSB as sign indicator. Not a 2's complement, but I've seen this too.

    If you turn the sensor upside down and read 0x1e, then you can be sure :)

  • 0 in reply to Jens-Michael Gross
    Intellectual 260 points

    Hi, I found this post useful but I am still facing some problems when trying to get meaninful data.

    Following http://www.vti.fi/sites/default/files/documents/cma3000-d0x_product_family_specification_8281000a.04.pdf page 14/37.

    Let say the case you receive a value that is all ones, then, if you apply the accelerometer multiplier values, then you get a value that is 2.267mg in the case of a 2g range configuration and 9070mg in the case of 8g range configuration.

    Does this make sense since this values are out of range?

    I think I am missing something!!

    Please help! 

  • 0 in reply to Flor
    Guru 227245 points

    Flor said:
    Let say the case you receive a value that is all ones, then, if you apply the accelerometer multiplier values, then you get a value that is 2.267mg in the case of a 2g range configuration and 9070mg in the case of 8g range configuration.

    The value you get is a signed (!) 8 bit value. So it goes from -128 to 127. all-one is 0xff which is -1. so it is 1/128 of the negative maximum = 2g/128 = 15,6mg in 2g range and 8g/128 = 62mg in 8g range.

    A look into the datasheet confoirms this. The resolution is printed as 18mg/71mg, so the range is actually 2.28g/9g Most likely with saturaiton at the edges (above 2/8g)

    Table 4 on page 14 tells that the values are in 2s complement format. To use the table, you can use the values if the upper bit is 0. If it is 1, you'll have to invert all bits, add 1, and treat the result as negative.

    However, if the value is 0x7f (not all ones, but the MSB being zero), then your calculation is correct. the result is then not outside range, it is outside specified range. It may be 9070mg or even much more. Results above 8g are not guaranteed to be within the specified precision (which means they can be far off)

  • 0 in reply to Jens-Michael Gross
    Intellectual 260 points

    Thank you for the answer.

    Also if you read data from the accelerometer as int8 (2s complement format) you can divide the value by the sensitivity and get the result. 

    - 0x1e = +30 = 30 * 1/56 mg = 536 mg
    - 0xe2 = -30 = -30 * 1/56 mg = -536 mg

    -0x28 = 40 = 40 * 1/56 mg = 714 mg

**Attention** This is a public forum