I'm using eZ430-RF2560 and collect accelerometer data through Bluetooth.
I see unusual data activity on the accelerometer data.
It is as follows:
received data => ID : 7A:40 x : 1.0 y : 56.0 z : 0.0received data => ID : 7A:40 x : 1.0 y : 56.0 z : 0.0received data => ID : 7A:40 x : 0.0 y : 56.0 z : 2.0received data => ID : 7A:40 x : 1.0 y : 56.0 z : 0.0received data => ID : 7A:40 x : 0.0 y : 56.0 z : 2.0received data => ID : 7A:40 x : 1.0 y : 56.0 z : 0.0received data => ID : 7A:40 x : -128.0 y : 55.0 z : 1.0 <-- X jumpsreceived data => ID : 7A:40 x : -128.0 y : 55.0 z : 1.0 <- x jumpsreceived data => ID : 7A:40 x : -1.0 y : 55.0 z : 1.0received data => ID : 7A:40 x : -1.0 y : 55.0 z : 1.0
received data => ID : 7A:40 x : 1.0 y : 55.0 z : 0.0received data => ID : 7A:40 x : 0.0 y : 55.0 z : 0.0received data => ID : 7A:40 x : 127.0 y : 55.0 z : 1.0 <<- X jumpsreceived data => ID : 7A:40 x : 1.0 y : 55.0 z : 0.0received data => ID : 7A:40 x : 0.0 y : 55.0 z : 0.0received data => ID : 7A:40 x : 0.0 y : 55.0 z : 0.0
while testing this data collection, I did not move the board but had it stabilized on the desk and I see a spike going wild from 0 to 127, and 1 to -128.
I do not understand this behavior of the board. 8bit accelerometer (CMA3000) on-board should generate data between -128 ~ +127.
However, -128, +127 could be 0s in this case. But there's no clear way of explaining it why.
Please explain why this is happening. Thanks in advance...
Won,
I would recommend looking at the CMA3000 Errata. From the application perspective, the accelerometer app is just reading the value straightforward from the CMA3000.
Regards,
Miguel
Miguel,
Thanks for the information. I personally contacted VTI for this particular issue.
It maybe the ADC's issue since it's only a 8-bit accelerometer.
Do you mean the CMA3000 ADCs, right?
Rgds,
Yes, that's what I'm guessing. If on the application itself does not have any issue (I agree with you that it is only just receiving what's coming in), it must be the CMA3000 generating odd numbers.
Also, when i test with the sample keyboard event generator application from TI, the received x and y axis data jumps around.
The result above is after when I reconfigured the function by removing all scaling statements in IAR workbench.
Hi Won-Jae Yi,
Hal_accl.c file reads 8 bit accelerometer (register thorugh i2c) value and then convert into 16 bit value by using halAccRawAdjust function call.
Initially you could comment out this function call and verify the accelerometer raw values. normally + or - 10 could be resolution.
Regards
Hello,
Unfortunately, I don't think you and I are looking at the same sample application. I'm using ez430-accl sample project file given from TI and does not have halAccRawAdjust function in anywhere in this project.
I am aware of the bit conversions and I'm still thinking this is the cause.
However, I adjusted sampling rate of the accelerometer from 400Hz to 100Hz, and the weird value does not appear. (STRANGE!!)
VTI personnel informed me that this device (CMA3000-D01) has an ASIC design bug that if data read is not synchronized with the interrupt signal, which causes I2C bus deliver data corruption.
The odd value is only produced when a axis value is close to 0s. (thus, when the sensor is in stable condition)
The accl app is reading the accl data in polling mode. You will need to change the hal if you need an interrupt-based approach.