I have noticed that by shaking or tapping the phone (an SE Xperia x10 mini) several times recalibrates the magnetometer. Is there any way of doing this software-wise in a more controlled way?
I don't think so. It seems some sort of "hardware reset": when the magnetometer has been confused by a magnetic field (a loudspeaker is usually enough) it requires physical movement in order to return to a "plain state".
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."
First of all, sorry for my english. I'm programming an Augmented Reality Browser for Android following the steps in Raghav Sood's book. Its title is Pro Android Augmented Reality. The thing is that when i launch the example of chapter 9 (named Pro Android AR 9 and located in https://github.com/RaghavSood/ProAndroidAugmentedReality) in my devices, it works fine or not depending on the kind of device.
In my Sony Ericsson Xperia Arc with Android 4.0.4 the browser implemented by Raghav works really fine. When i test the augmented-reality browser in Asus Eee Pad Transformer or in Samsung Galaxy Tab, both of them with Android 4.0.3, the readings from the sensors seem to be wrong. Holding the tablets in landscape mode in front of me, if i focus over one spot (wikipedia, twitter or local markers) and turn over myself to the right, the spots goes down. If i turn to the left, the spots goes up. If i want the spots to move to the left, i have to tilt the devices making their screens look to the ground. In the same order, if i turn the devices making the screens look up to the air, the spots will move to the right.
Seems like the program is confusing sensor readings. Anyone knows how to solve the problem??? Thanks in advance.
i made it. I don't know if it is a good solution but seems to work fine on tablets.
Changing the axis to:
SensorManager.remapCoordinateSystem(temp, SensorManager.AXIS_X, SensorManager.AXIS_Y, rotation)
in SensorActivity seems to fix the axis malfunction. Other problem was that the text asociated with each POI appeared turned in tablets using landscape mode. To avoid this, i used a conditional rotation modification in set method of PaintablePosition class:
if(drawObj.toString().toLowerCase().contains("paintableboxedtext")) rotation=rotation+270;
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.
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)