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.

ez430 accelerometer troubles - values always in certain ranges



I am in a bit of a conundrum. I am trying to use the eZ430 accelerometer for 3D gesture recognition, but both 2g and 8g modes have problems.

The 2g mode, when the sensor is at rest in the position it needs to be to be wearable, x is around 250, y is around 50, and z is around 240. This means with any movement, x and z likely exceed 255, and begin to wrap around to lower numbers.

Even rotating the watch in space, I cannot find an orientation that reflects the best possible case of 128 for x, y or z. At rest, It always seems to be somewhere in the range of 240-255 for two dimensions and 40-60 for the other.

Is there some way I can calibrate the sensor, such that...

a) gravity is equalised in a given fixed position or

b) the values are at least around 128, so that I have half of the range of motion each way before the values start to wrap around?

 

In 8g mode, these problems disappear, but the sensor becomes much less accurate and it is difficult to accurately classify gestures, so a 2g solution would be preferable.

  • William,

     

    Are you talking about the EZ430-RF2560? That is the only EZ430 with an accelerometer, AFAIK.

     

    Gustavo

  • Hi Gustavo.

    I'm talking about the ez-430 Chronos.

    http://processors.wiki.ti.com/index.php/EZ430-Chronos

  • The accelerometer values are singed chars.

    So 0G is 0, while -128 or 127 are -+2G.

    The expected values are 0,64,0 for x,y,z  for a resting sensor.

    The 240/250 you get is a slight negative offset (-15,-5 ~ -0.25G, -0.1G). and y is only 0.78 instead of 1G. Looks rather like an orientation problem.
    So it's not as wrong as you think.

    There is no way to calibrate the sensors, however. At lease none I have heard of.

  • Thanks for the response Jens-Michael.

    Is there any way to tell whether a series of measurements (e.g. 240, 242, 15) has arisen from the sensor rolling over from 255 to 0, or just falling by ~200? At the moment I think I am not getting very good gesture recognition with my classifier as a lot of the data tends to skirt the boundary between 240 and 15, where there's not much difference but obviously on paper it's a 200 point different.

  • There is no rolling over from 255 to 0. There is no 255 either. There's only -128 and +127. And the only rollover from +127 to -128 is when the sensor literally rolls over.

    On 2G or more, the sensor will report 127. And on -2G or less, the sensor will report -128. What you see as 255 is in fact -1. And of course -1 rolls to 0 and then to +1.

    As I said, it is a SIGNED char. And the value latches at -128 or +127.

  • Ah, that makes more sense. I'll have to look at my code and work out what's going on.

    Thanks for your help.

  • x: 246 y: 254 z: 31
    x: 248 y: 254 z: 26
    x: 250 y: 4 z: 22
    x: 251 y: 4 z: 22
    x: 252 y: 3 z: 25
    x: 251 y: 2 z: 27
    x: 252 y: 2 z: 27
    x: 253 y: 3 z: 26
    x: 253 y: 1 z: 27
    x: 253 y: 1 z: 25
    x: 254 y: 254 z: 24
    x: 254 y: 250 z: 25
    x: 253 y: 253 z: 26
    x: 253 y: 249 z: 28
    x: 254 y: 244 z: 27
    x: 255 y: 243 z: 26

    This Is what I mean about rollover; notice the y value goes from 255 to 4 and back again extremely quickly; this was as I was rotating ever so slightly. I assume this is to be expected?

  • If you finally start to print out the values as signed values and not as unsigned, you'll see everything much clearer.

    William Judd said:
    notice the y value goes from 255 to 4

    No. It goes from -2 (0xFE) to 4. It's jsut that you erroneously print the -2 as 254. The binary representation is the same. A -2 on a signed char is 0xFE and a 254 on an unsigned char is also 0xFE.

  • Ah. Ahhhh. Thank you, thank you. That's wonderful, thanks!

**Attention** This is a public forum