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."
Related
my first android game it's almost done, and I'm on the way to publish it on the play store.
Today I tested it on some friends phone and it worked on all except for a samung a5. On this phone the meshes flicker, apper and disapper and look deformed. This when playing game where I use a lot of frame buffer, in the main menu where there is a simpler animation everything look right.
The game is developed with libGdx and use some custom shader. I've tested it on 8 other different device without no issue (excepect for low frame rate on samsung galaxy tab s4).
I ask yours advise:
1) what should I start to check to find the problem with a5?
2) do you think I should delay the publication until the bug it's solved ora I should publish it excluding A5 ( or maybe all devices with similar GPU) from compatibility list?
My big problem is that at the moment I don't have the device with me (it's the personal phone of a friend of mine...) and probably I will have it for only a limited amount of time, so I want to be preparated to avoid to lock the device for too much time to my friend.
Thanks to all!
First, I'd make sure you don't have any OpenGL errors - add calls to glGetError and validate frame buffers and shader programs, you can do this without the device and adding extra asserts like this is always worthwhile (assuming you don't already have them). Next, try using the tools provided by the GPU manufacturer. In your case the snapdragon profiler. To minimize the time you'll be using your friends device, get the tools installed ahead of time and if you have access to another Qualcomm device, then use that to familiarize yourself with the software. With luck the cause of problem might become immediately obvious. If not, then it's just a binary search of disabling parts of your code until you narrow it down to a particular shader/draw call, then examine/tweak that to figure out what bit is going wrong.
That's a tough call. If it's a driver bug, then it might only occur on particular revisions. Some A5 devices might work if they're on different versions of Android from your friends device. That said, the A5 is relatively recent and Samsung/Qualcomm drivers tend to be pretty solid IME, so it's more likely an error in your code that happens to only be exposed on certain devices. Personally I would delay release unless your release strategy is timing sensitive, from the limited data you have, your game doesn't work on >10% of devices.
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 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.
I am doing a project on android phone and I hope to use the two camera at the same time. According to Is there any API to fetch both rear and front camera view at the same time? , it may be possible to realize it. However, when I tried it on HTC One S, it cannot work -- the second camera cannot be open. So is there anyone who used to do it seccessfully？ If so， please tell me which phone you worked on. Thank you in advance.
While it is possible in theory, in practice Android does not allow it at a firmware level. I'm not sure exactly what happens, but my guess is that one camera blocks some part of the API from the second one, thereby stopping two from working at once.
So for any device to do this, the manufacturer would have to change it at an OS level, and I don't think this has ever been done.
There are currently two phones that do the trick: Samsung Galaxy S4 and LG Optimus G Pro. Neither defines an API to 3rd parties to use this feature in their apps.
[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