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?
Related
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 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.
[Edit: Removed all mention of Android version - the issue is present on all versions of android]
Background: When the screen is off, many Android phones do not provide updates to applications of Accelerometer readings by calling onSensorChanged() when the screen is off. This behavior is discussed on S.O. and is further documented here
http://code.google.com/p/android/issues/detail?id=3708
On some phones (Nexus S, Droid X2, ...) accelerometer values are only provided when there is a significant change in value. Sitting still on a table, for example, there might be one or zero updates per minute
In order to produce code that is robust across phone models, how am I to distinguish between a lack of update events per screen off, vs. lack of updates per non-movement? Should I maintain a database of phone models?
This will be hard to detect. Android's API provides a way to control the Wake Lock. But manufacturers have done a TERRIBLE job of implementing this into the OS on their side. Just TERRIBLE. You would need to grab a PARTIAL_WAKE_LOCK to keep the phones CPU running when the screen is turned off.
However not all devices use this and will not respond - some half/half respond - and some respond great.
After reading the comments above I can tell you the majority of devices with 2.3+ I have used still do not implement the partial wake lock still.
I personally would not rely on something the manufacturer controls because the market is SO fragmented. I would try to find a way to get the functionality I'm looking for with a different solution.
Hope this helps.
I've been looking for a solution for this problem for two days now. But still didn't find anything useful.
At this post here, by Bruno Albuquerque there's something that could help with motorola phones but it's not generic.
I believe #jjNford is right about manufactures have a finger on that, can you post any info about that?
Here is a bug report about that dated from 2009
I have an app that I have written that works fine on the Samsung Galaxy S series (I have a captivate). However, the app apparently doesn't work on the Droid's as Motorola has laid out the file structure differently.
I'm looking for a way to detect the manufacturer so that I can switch out program behavior.
Does anyone know an easy way to do this?
android.os.Build.MANUFACTURER is probably what you want.
Bear in mind that the file structure is likely to vary on other devices as well, as that's not part of the public SDK.
This what you need in addition to manufacturer:
android.os.Build.MODEL;
I have a G1 and an HTC Hero handset. All the applications that I've written were tested only on these devices; come new SDK and Android handsets with (support for) different screen resolutions, densities and capabilities I have been asked to estimate the efforts required to port some of the application to new Android handsets such as Droid, Nexus One etc.
I know that making such an estimation would depend a lot on the application that is being ported, what device capabilities it uses and assumes and the way it is written.
This question is an effort to highlight all the things that a developer needs to consider(in general) when making such estimates. Please help.
Thanks.
In general, you're going to want to consider the following issues:
Resolution - different resolutions will cause your UI to look different than the original.
Input methods - not all phones have keyboards, some might be missing some other keys, etc. Think about the different possible configurations and how the user would interact with your application in each of them.
Performance - on some devices you might have performance issues that you do not see on the G1.
Device specific bugs/issues - this isn't really something you can "estimate", but it's definitely something to consider.
Of course, some of these may not be relevant for your application or the devices you intend to target, or you may decide that they aren't important enough to change.
EDIT: Another thing I forgot - if you're using native code in your application (don't remember what it was called, NDK?) it may not run on all devices.