I own a samsung galaxy tab 10.1 4g lte-- and am starting to play with the sensors onboard. I looked up the mems gyro on board and found that (you can see for yourself on pg 9) that there are 4 different condition settings to change the sensitivity of the gyro from 250 degrees per second to up to like 2500 degrees per second. I am pretty sure that the lower setting will allow for a finer resolution of reading, while the higher settings can account for larger amounts of motions ( the reading at highest resolution (250) would probably max out at 250). Does anyone know what the default setting is and how to change it? If i had to guess I would bet the setting is on +-500 or +-1000 by default.
Thanks for the help in advance.
On registering your listener, you can specify the rate at which the events should be received.
registerListener (SensorEventListener listener, Sensor sensor, int rate)
You can choose from a variety of rates enumerated by SensorManager class:
SENSOR_DELAY_NORMAL, SENSOR_DELAY_UI, SENSOR_DELAY_GAME, or SENSOR_DELAY_FASTEST
Moreover, even the rate values are just a hint for the system, it's not necessarily receiving events at your specified rate.
Related
I'm reading out the accelerometer sensor on a Sony Smartwatch 3. Since the Android Wear 1.5 update the sampling rate won't drop below about 60hz, regardless weather I use SENSOR_DELAY_NORMAL, SENSOR_DELAY_UI or SENSOR_DELAY_GAME. Before the update SENSOR_DELAY_NORMAL resulted in a sampling rate of about 18 samples/seconds.
accelerometer.getMaxDelay()still returns 62500, which would be 16 samples/sec. I also tried setting the desired delay directly, when registering the sensor with sensorManager.registerSensor(this, accelerometer, 62500) but this doesn't work either.
Has anybody any idea of how I can reduce the sampling rate? It's very important for my app to be energy efficient, thats why the low sampling rate is important.
Docs say next about samplingPeriodUs:
This is only a hint to the system. Events may be received faster or
slower than the specified rate. Usually events are received faster.
So, IMHO you should just ignore some amount of sensor events, as was proposed by Alex. Dry run for sensor event (i.e. without actual processing shouldn't be very power consuming).
How could it have been different: Not the Android update changed the behavior, it was my misunderstanding.
For everyone who might have problems with sensor batching or sampling rates:
The sampling rate might be different, when the display is on or off. In my case it was 60hz when on and 18hz when off.
Sensor batching might not be working, when the device is connected to a power source. For me I head to unplug the USB-cable. Bluetooth debugging might be helpful in that case.
I have seen this app, but how can I test the driver of the pressure sensor on Android ?
Depending on the resolution of your sensor you might see changes depending on the hight of meters above sea level. Try to put it on your desk and the floor, you should see small changes (or go some floors up in your building).
My experience with pressure sensors is, that they are quite inaccurate to measure the hight of the gadget in a small resolution.
To read the values of your sensor, you can also try to read the values from sysfs, if you have shell access.
I am needing to implement a shake recognizer, and I am using the accelerometer on the device to that. However, when I check the values I get from the sensor, it appears that they vary wildly from device to device. For instance, I get a value range of 0-8 as force (after some calculations) on one device, and on the other 0 - 4.
So it looks like they have very different ranges.
Is there anything I can do to make these ranges equal. Or are there some variables that I can use to somehow calculate what a fairly hard shake would be?
According to specification accelerometer should return Measures the acceleration force in m/s2. So it should be calibrated. One thing you could check however is the Sensor class's getMaximumRange() and getResolution()
The physical placement of the chip on the pcb and the securing of the pcb within the device and the construction of the device could all lead to different damping effects in responce to your shaking input force.
You don't say how your processing the sensor data there may well be effects related to sampleing and filtering performed at the driver level.
You clearly need to be flexible in your code with the range of values you expect and test on a good range of devices.
The sensor should be calibrated.
Apparently it isn't. If the gain in the different directions (that is x, y, z) is not significantly different then it is enough to look for sudden changes in the length^2 of the accelerometer vector: x^2+y^2+z^2.
If the gains are also significantly different then you have no choice but to write an app for accelerometer calibration...
By the way, you are not the first one to report gross inaccuracies, see for example Android: the range of z-value in the accelerometer sensor are different on different devices.
I write a simple app to read accelerometer data and I found that sampling rate is too low(even one sample 5 seconds) when I put phone on the table and keep quiet. I set sampling rate as FASTEST it's sampling rate always is high.
I want to know why and how does Android do this? I guess jni or hardware always read data but it discard data when it find there is no change between two sample.
As you can see from the documentation of the sensor listener the procedure onSensorChanged is called when the sensor changed. This means that if you hold the device still the sensor values won't change.
I have to admit that most phones add noise to sensor values and these values are always changing; you should be 'proud' of your phone - it doesn't add a lot of noise.
I am working on a project using HTC magic which requires the data from the electronic compass, including both the accelerometer and magnetic sensor. But I find that there is a significant latency between the move of the phone and the trigger of the sensorChanged event. In other word, the acceleration and magnetic data obtained from sensor are updated about half of a second after my motion. And I have several questions about the problem as follow.
Are the orientation data computed by the acceleration and magnetic data? Or are there a physical sensor for orientation?
Does the latency result from the android API (using the event) or the physical limitation of the electronic compass?
It is said that the model of the electronic compass is AK8976A from Asahi Kasei. Does anybody have the datasheet or know the frequency of the sampling?
Any idea to improve the real-time experience?
Thank you in advance!
When you register the SensorEventListener what rate are you using? You should be using SENSOR_DELAY_GAME to get the best balance between frequent updates and not overdriving the update queue which can actually cause updated to be slower if SENSOR_DELAY_FASTEST.
As to your other questions I think they're kind of moot. Whether the update delay you're seeing is due to the API, or the actual compass itself you can't change it.
I did figure this out. Turns out that in 2.2 you can't use sensor rates other than the standard SENSOR_DELAY_UI, SENSOR_DELAY_NORMAL, etc. The documentation claims you can also specify the number of microseconds between notifications, but they are lying.
Once I used the standard constants it started working on 2.2