Does anybody own an LG Optimus S and seen a value for Sensor.accuracy that wasn't 0 (Sensor.SENSOR_STATUS_UNRELIABLE)? We apparently need to test accuracy of the sensor events we are getting, but on my phone the accuracy is always 0 and wanted to see if it was a phone wide issue or if mine is busted or something.
Thanks.
If you look to part lists of your phone, you will find that accelerometers built in are far away from reliable - so there is always a lot of noise and little accuracy. Chips used in HTC Hero provide deliver 8 bit value for +/- 8G
(hope this helps, even it is not LG specific)
Related
I am currently working with Android Sensor API and accelerometer data.
Though the internal components should support high acceleration (even +-16g), I tried some recent smartphone and found that the maximum range of exposed data is usually +-2g (e.g. Nexus 5) and sometimes +-4g (e.g. Nexus 4).
Is there any way to set the full scale of the sensor? (I didn't manage to find a public API for this)
Alternatively, is there any flagship smartphone that support higher range from stock? (e.g. +-8g, +-16g).
I'm facing the same problem as yours.
DISCLAIMER: I just discovered what I'm writing, so I haven't tested it at all... but I think it's in the right direction.
Checking what range is functional is quite simple: Sensor.getMaximumRange()
http://developer.android.com/reference/android/hardware/Sensor.html#getMaximumRange%28%29
Now, as you know, setting the appropriate value is a much more involved thing. I believe it has to do with Android's so-called "Hardware Abstraction Layer"
https://source.android.com/devices/reference/files.html
I've found this document by STMicroelectronics, who are the manufacturers of the accelerometers embedded in Samsung Galaxy SIII and S4 http://www.st.com/st-web-ui/static/active/en/resource/technical/document/application_note/DM00063297.pdf
If I'm getting it right, you need to #define ACCEL_MAX_RANGE in configuration.h (page 5 of the document) as 8 or 16*GRAVITY_EARTH. There are plenty of instructions following, which I'm still trying to understand, but I think one would need to root the smartphone and compile Android from its source.
Hope this helps! If you manage to solve it, please let me know so that we can help each other.
Regards
Sorry that this is an answer and not a comment, but I don't have the rep yet. I've got a Moto X 2nd Gen, and the accelerometer has a 16-g range(+/-).
Here's the datasheet for the sensor. It's an MPU6515 from Invensense.
As ignzz stated in his/her initial post, it does not seem to be a problem from the sensor hardware, which in his/her case can also record +/-16g in principle. I believe it has to do with the settings of the operating system.
However, I haven't had time to give a try to what I described above. Has someone tried?
I used to extract accelerometer data by android SDK on Samsung Galaxy S4,
and I encounter a strange problem when I change platform to HTC One M8.
Here is the statement about the experiment:
Once I move the device from place A to place B straight(negative direction of device), I will read the accelerometer data and compute the displacement between A and B.
The curve of acceleromter data on S4 is correct.
It contains two pick with different sign and the shape like 'S' lie on the floor.
But when I use M8, it give me the curve which is wrong obviously. it looks like 'W'
P.S. The motion and program of two are totally the same.
Can anyone give me some reason to the difference?
Is the g-sensor on M8 is the problem?
I'm really stuck on it.
thanks.
From what I understand from trying to use the Moves app, this is due to lack of support of the accelerometer when the device's display is off.
I am looking for a way to change that now and if I find something I will update here.
update:
It seems this could just be due to new hardware not being supported yet. This quote leads me to believe that "...are the low-powered, always listening "Smart Sensors." Accelerometers are nothing new, but HTC's can be used by apps all day long without significant drain on the the battery (as they don't fire up the processor etc). As HTC's opened up the API for these -- dubbed HTC's Smart Sensor Hub -- app developers will be able to hook into this information directly."
I've been looking for a way to detect the finger orientation together with a simplification of the touch area in the form of an ellipse, when using a mobile touch device. I choose Android rather than iOS since I found three usefull methods (getTouchMajor(), getTouchMinor(), and getOrientation()) in the Android reference for the MotionEvent class.
But I've tried to implement these three methods in my app, and sadly they does not return the wanted values. The orientation stays at 0, no matter what, while the getTouchMajor and getTouchMinor is exactly the same each time.
So my question is: Am I doing somethign wrong or is these methods just not implemented yet?
(I've tried the functions on several different devices including: Nexus 5, Nexus 7, and HTC One)
As we work together I know you know this answer, but I just wanted to put it up such that fellow users of Stackoverflow can have it as well.
We have found suggestive comments that maybe the touch screen drivers for most devices do not provide this data to the system.
We originally tested: Samsung Galaxy S2, HTC One, Nexus 5 (by LG) and Nexus 7 (by Asus), Samsung Galaxy Tap 3.
As opposed to the others the Samsung Galaxy Tap 3, gave different values for getTouchMajor() and getTouchMinor(), but this relationship was seen getTouchMajor() = getTouchMinor() * 3, and getOrientation() was always 0, as with all the other devices.
About 2 months later we discovered that the Google Nexus 10 can show an ellipse with a direction line, when you activate Input: Pointer Location under developer settings.
The initial conclusion was that most devices do not support, getTouchMajor(), getTouchMinor(). or getOrientation(), Which could be a limitation of the capacitative touch screens.
But seeing the Nexus 10, and the tracking of the ellipse and orientation gives hope for new interaction design.
It indicates to me that some devices do deliver on getTouchMinor and getTouchMajor as well as orientation. (or historical versions of the same functions).
I have not had the chance to code anything for the device myself but it seems plausible.
I'm trying to create an app that utilizes the proximity sensor in most Android phones. But, since I can't really emulate getting my face close to an emulator, I'm debugging on my Nexus 7. Unfortunately, nothing is happening in regards to the proximity sensor.
So, I guess my question can be answered pretty easily, but, does the Nexus 7 even have a proximity sensor? If it does I'll post some code, but I have a feeling that may be my problem...
Thanks!
According to the specs, the Nexus 7 doesn't have a proximity sensor. And it makes sense to not have one, as you're never going to talk on it.
Felix is right, there is no proximity sensor like on the nexus 4.
There is a magnetic sensor Between the z and mic button on the standard keyboard when in upright portrait mode. It behaves like a shmitt trigger hall effect sensor.
Finally, I have noticed that touches can be sensed on the capacitive touchscreen even without physical contact. Experimentation may yield interesting and innovative results. Or a loss of hair.
Best of luck.
I have got a small application that uses compass readings on my device (Xperia Neo V). When testing it, I got very satisfying results while pointing the desired direction. But I tested it on a Samsung Galaxy S3, and I run the same application on my neo V at the same time, the two devices did not show exactly the same direction. There was a drift about 10 degrees.
So, as an electronical engineer I know that different digital compass sensors may give different values due to design, but I coulnd't find an efficient solution to that yet. Any Ideas?
I would try some experiments using rotations in different direction on both devices in the same environment to find any correlation on the results. Possibly there's an offset that should be removed. A real pure compass device could help to estimate the noise level.