Android Sensor.TYPE_LINEAR_ACCELERATION reporting wrong values on Galaxy S5

879 views Asked by At

I am developing an app that needs to be able to recognize if the phone is lying somewhere (without moving). To do so, i used the Sensor.TYPE_LINEAR_ACCELERATION which reports the acceleration without the gravity component. On my test device (Nexus 5) it reports something like: x=0,002, y=-0,02, z=-0,005 To detect if the device is lying still, i calculate the average:

avg =sqrt(sqr(x)+sqr(y)+sqr(z))

If the value is below a threshold, i report to the user, that the device is lying still. Works fine on my Nexus 5.

However, the Galaxy S5 reports something like that when lying still: x=-0,761, y=0,167, z=19,923

So the z value is clearly wrong... As I googled for an answer to this problem I found that the sensor values for TYPE_LINEAR_ACCELERATION are calculated as follows:

Sensor.TYPE_LINEAR_ACCELERATION = Sensor.TYPE_ACCELEROMETER - Sensor.TYPE_GRAVITY   

As the accelerometer as well as the gravity sensor should contain the earths gravity (~9,81m/s2) I can only assume, that Samsung made some calculation errors or mountet some sensor reverse on the phone....

Does anybody have the same problem?

Does that happen on other (Samsung) phones?

Is there any fix for this?

1

There are 1 answers

0
msysmilu On BEST ANSWER

=== New answer ===

I have seen that a change the sampling rate of the sensor did the trick in avoiding this error. From the probable SensorManager.SENSOR_DELAY_FASTEST to SensorManager.SENSOR_DELAY_UI

=== Old Answer ===

Given my 2 comments on your question and because of having the same problem on 2 other Galaxy 5S', at the present moment, and with regard to the goal which is detecting the telephone's stillness, I can only suggest 2 workarounds: a peak-to-peak value consideration, and a high pass filter.

  1. Peak-to-peak Value Consideration: just measure the difference between the last 2 readings; if this is bigger than a threshold then a movement event can be triggered.
  2. High Pass Filter: slightly more complicated, but more professional, implement in your code such a filter that will only bring forward rapid changes in the acceleration, while suppressing the constant value of 19.