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.
Related
I am creating a thermometer app in android when I test on Galaxy S3 it shows that
TYPE_AMBIENT_TEMPERATURE NOT Available
TYPE_TEMPERATURE NOT Available
I want to know that Galaxy S3 has above sensors or not? or How I can solve this issue to get temperature ?
As Yohannes said in the comment you can only calculate standard atmospheric temperature which is not useful to for daily use mostly used in aviation.
Here is the temperature estimation vs barometric height. http://home.anadolu.edu.tr/~mcavcar/common/ISAweb.pdf (page 2).
It seems only way to use an external temperature sensor with bluetooth or similar stuff and require this sensor in your app promotion.
This is really cool one:
http://www.bee-wi.com/bbw200,us,4,BBW200-A1.cfm
An easy way to check if a sensor exists on a specific target phone is to install an app like AndroSensor. This will list all the available sensors.
I doubt if the underlying sensor is missing you'll be able to do much. You can use a weather service to get the current temperature of the device's location but that won't help with a thermometer.
Not sure if this also applies to the Galaxy S3, but you can try to look for sensors with a type value above TYPE_DEVICE_PRIVATE_BASE. Many phones (for example Nexus 5x and Pixel 3) have one or even multiple sensors that exhibit a temperature reading through this and you usually can tell by the name of the sensor (for example "BMI160 Temperature" or "BMP380 Temperature", both on a Pixel 3).
These "vendor defined sensors" are usually from sensors that require a temperature reading for compensation/calibration (BMI160 is the IMU and BMP380 the barometer of the Pixel 3). Especially barometers are very likely to have a temperature channel.
However, there is a good reason that the manufacturer does not offer these temperature readings through the official TYPE_AMBIENT_TEMPERATURE type:
Placing a thermometer inside an enclosed device that heats itself from the inside is not a good method to measure the ambient temperature. Especially if the temperature reading is only meant to compensate temperature drift of the sensor, you will not get anything useful as you mostly measure the temperature of the inside of your phone. Even if a phone officially measures ambient temperature, the results will not be very precise for the same reasons.
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.
In my project, I want to detect if a user is moving or not by using either wifi rssi or accelerometer sensor.
What I should do to achieve that?
It actually all depends on what kind of movement you want to detect.
WiFi RSSIs : From a starting position and scan results (initial RSSIs for newly discovered access points), you can check through time their evolution in term of signal quality. A short displacement of the user will not be easy to find as RSSI values are tweaked by a large amount of parameters (orientation, obstacles, setup of the room, atmospheric conditions, people around). Thus you would need averaged values (scans must then be performed quickly to have enough data) and leaving an access point perimeter would make you lose the information.
Accelerometer : Depends on what quality of sensor you are using. If you're using embedded sensors within smartphones, it will be tough. Their accuracy is bad, and as you'll need to integrate its values (m/s² to get m/s) the error will grow subsequently. Plus it might be hard to discern real user movement from the device's tilt if you're using a mobile phone or tablet.
Without really knowing the details of your projet, I believe that RSSIs should be easier to use if you actually need to detect not so tiny motion. If you want something more precise, you'll need some way bigger research work.
See Android accelerometer accuracy (Inertial navigation) for RSSI-based indoor localization.
I am trying to do an analysis which involves interpreting the results from the various sensors of the Android device. Right now I'm analyzing the magnetic field sensor which should tell me (according to this documentation page) the values of the ambient magnetic field in uT (micro Tesla). Everything is clear so far but on the 2 devices that I tested on (Galaxy S, Galaxy Gio) the results are different. And by different I mean very different.
For example having the same orientation on a table here's what those devices show (just one example):
S2: -2,12, 60 (approximate values on x,y,z accordingly)
Gio: -2,12,-36 (approximate values on x,y,z accordingly)
Even if I switch positions the results are the same. I also read on this page about the intensity of the magnetic field and I believe that I should have around 50uT given my geographical latitude.
Can someone explain what those sensors mean?
Does someone know how to explain this behavior?
Thank you,
Iulian
I just can confirm the problem.
As the author of the steady compass application, I have done many tests of magnetic field sensors with different devices. I have found that one of the devices reported an absolute value of mf about 2x the amount reported by other different device under the same conditions.
I have done a lot of test after phone calibration, and I even put the devices in "airplane mode" trying to minimize electromagnetic interferences coming from the own device. Another comment is that plugging the USB cable on some devices can create important magnetic field variations.
The worst results that I have seen on a given device (after calibration, airplane mode and USB disconnected) is this: Using a compass application with the device on horizontal plane, I take a reading, rotate phone 90 deg in the horizontal plane and take a new compass reading. Both readings differ in more than 15 degrees!
Fortunately, not all devices include such a bad sensors. Best devices have errors of about 2-3 degrees after a 90 degrees rotation.
The conclusion: Unless you are very confident on your magnetic field sensor because you have tested and certified a good behavior, you should give a limited reliability to the readings reported by such sensor.
I have also experienced these problems with the sensors. I believe the phones will give different sensor readings based on the hardware used by the manufacturer.
Try reading the accuracy of the sensor for SENSOR_STATUS_UNRELIABLE. You may have to recalibrate the magnetometer.
Reading here: Android Sensors - Which of them get direct input? ,
I am wondering if anyone has experience or a technically detailed link about the accuracy of the linear acceleration versus just manual processing of the acceleration raw data. E.g., do the new phones have dedicated hardware chips for filtering out gravity, or are most devices just going to filter the same raw source?
Update, proposed answer for someone to confirm if they have such a device (Xoom,Nexus S,?):
"If the device has gyro, or possibly multiple accelerometers, then the returned values for gravity (G) versus external linear acceleration (L) can be fundamentally more accurate than any processing on accelerometer data alone. Without extra sensors, e.g. as on most phones, one could in principle post-process the Acceleration (A) to attempt separation as accurately as what the device is returning for A = G+L"
It seems, the gravity/lin. acceleration can be calculated by a low-pass-filter - just as described in the Android-Documentation.
However only filtering the last value will not do it. I get acceptable results by averaging the accelerometer values of ca. 200ms (for moderate movement, this will still screw up, e.g. when you flip your phone fast between your fingers).
Your proposed answer is most likely correct.
You can check the statistics of several smartphone models on Android fragmentation.
For many models the power consumption of the lin. acceleration and gravity sensor is just the sum of accelerometer, gyroscope and magnetometer.
The gyroscope lets you recognize fast angular movement and it can be used to improve the gravity value, which is not possible with just the low-pass-filter. For the magnetometer im not sure if it really gets you more information.
On my phone (HTC One S) the gravity sensor uses just as much power as the accelerometer, but is still better than my simple filter. So either it is another hardware sensor or probably they use different weights on it. I tried to weight acc-data stronger, if their absolute value is closer to gravity, which is nice but was still not as good as the actual gravity sensor.
For compatibility reasons I would suggest to use a low-pass-filter for gravity if possible, as still not every smartphone has a gyroscope or mentioned sensors.