oac155linyc13936.jpg

Google Will Define “High Fidelity Sensor Support” For Android Devices, Has Extensive Listing Of Performance Needs

Google Will Define “High Fidelity Sensor Support” For Android Devices, Has Extensive Listing Of Performance Needs

  • Android OS
  • Development
  • Marshmallow 6.0
  • News

Ever endured a telephone having a bum gyroscope? Or perhaps a totally irrational pedometer? Google, within the interest of higher counting your steps and figuring out precisely what within the hell your phone does getting around in three-dimensional space has defined a “high fidelity sensor support” flag for Android devices, as with the Android 6. Compatibility Definition Document.

The concept here’s to provide developers just one flag to consider that states “this phone / tablet / whatever isn’t a dumpster fire of awful sensor precision.” Or, possibly, more positively, to simply say a tool has truly good sensors. The sensors targeted with this new flag range from the accelerometer, gyroscope, compass (geomagnetic field), barometer (pressure), and pedometer (step counter). Not just are precision needs defined, but strict power consumption targets are supplied too. In other words, even when your gyroscope is wicked accurate, it cannot be exceeding 1.5mW (milliwatts) of power when it is switched on whether it really wants to entitled to the awesome kids sensor club. This is actually the complete text.

Device implementations supporting some greater quality sensors that may meet all of the needs indexed by this MUST find out the support with the android.hardware.sensor.hifi_sensors feature flag.

A tool declaring android.hardware.sensor.hifi_sensors MUST support the following sensor types meeting the standard needs as below:

SENSOR_TYPE_ACCELEROMETER

  • MUST have a measurement range between at least -8g and +8g
  • MUST have a measurement resolution of at least 1024 LSB/G
  • MUST have a minimum measurement frequency of 12.5 Hz or lower
  • MUST have a maxmium measurement frequency of 200 Hz or higher
  • MUST have a measurement noise not above 400uG/√Hz
  • MUST implement a non-wake-up form of this sensor with a buffering capability of at least 3000 sensor events
  • MUST have a batching power consumption not worse than 3 mW

SENSOR_TYPE_GYROSCOPE

  • MUST have a measurement range between at least -1000 and +1000 dps
  • MUST have a measurement resolution of at least 16 LSB/dps
  • MUST have a minimum measurement frequency of 12.5 Hz or lower
  • MUST have a maxmium measurement frequency of 200 Hz or higher
  • MUST have a measurement noise not above 0.014°/s/√Hz

SENSOR_TYPE_GYROSCOPE_UNCALIBRATED with the same quality requirements as

SENSOR_TYPE_GYROSCOPE

SENSOR_TYPE_GEOMAGNETIC_FIELD

  • MUST have a measurement range between at least -900 and +900 uT
  • MUST have a measurement resolution of at least 5 LSB/uT
  • MUST have a minimum measurement frequency of 5 Hz or lower
  • MUST have a maxmium measurement frequency of 50 Hz or higher
  • MUST have a measurement noise not above 0.5 uT

SENSOR_TYPE_MAGNETIC_FIELD_UNCALIBRATED with the same quality

requirements as SENSOR_TYPE_GEOMAGNETIC_FIELD and in addition:

MUST implement a non-wake-up form of this sensor with a buffering capability of at least 600 sensor events

SENSOR_TYPE_PRESSURE

  • MUST have a measurement range between at least 300 and 1100 hPa
  • MUST have a measurement resolution of at least 80 LSB/hPa
  • MUST have a minimum measurement frequency of 1 Hz or lower
  • MUST have a maximum measurement frequency of 10 Hz or higher
  • MUST have a measurement noise not above 2 Pa/√Hz
  • MUST implement a non-wake-up form of this sensor with a buffering capability of at least 300 sensor events
  • MUST have a batching power consumption not worse than 2 mW

SENSOR_TYPE_ROTATION_VECTOR

  • MUST have a batching power consumption not worse than 4 mW

SENSOR_TYPE_GAME_ROTATION_VECTOR

  • MUST implement a non-wake-up form of this sensor with a buffering capability of at least 300 sensor events

SENSOR_TYPE_SIGNIFICANT_MOTION

  • MUST have a power consumption not worse than 0.5 mW when device is static and 1.5 mW when device is moving

SENSOR_TYPE_STEP_DETECTOR

  • MUST implement a non-wake-up form of this sensor with a buffering capability of at least 100 sensor events
  • MUST have a power consumption not worse than 0.5 mW when device is static and 1.5 mW when device is moving
  • MUST have a batching power consumption not worse than 4 mW

SENSOR_TYPE_STEP_COUNTER

  • MUST have a power consumption not worse than 0.5 mW when device is static and 1.5 mW when device is moving

SENSOR_TILT_DETECTOR

  • MUST have a power consumption not worse than 0.5 mW when device is staticand 1.5 mW when device is moving

Also such a device MUST meet the following sensor subsystem requirements:

  • The event timestamp of the same physical event reported by the Accelerometer, Gyroscope sensor and Magnetometer MUST be within 2.5 milliseconds of each other.
  • The Gyroscope sensor event timestamps MUST be on the same time base as the camera subsystem and within 1 millisconds of error.
  • The latency of delivery of samples to the HAL SHOULD be below 5 milliseconds from the instant the data is available on the physical sensor hardware.
  • The power consumption MUST not be higher than 0.5 mW when device is static and 2.0 mW when device is moving when any combination of the following sensors are enabled:

SENSOR_TYPE_SIGNIFICANT_MOTION,
SENSOR_TYPE_STEP_DETECTOR
SENSOR_TYPE_STEP_COUNTER
SENSOR_TILT_DETECTORS
Note that all power consumption requirements in this section do not include the power consumption of the Application Processor. It is inclusive of the power drawn by the entire sensor chain – the sensor, any supporting circuitry, any dedicated sensor processing system, etc.

The following sensor types MAY also be supported on a device implementation declaring android.hardware.sensor.hifi_sensors, but if these sensor types are present they MUST meet the following minimum buffering capability requirement:

  • SENSOR_TYPE_PROXIMITY: 100 sensor events

Our speculation is this fact group of needs is most likely met through the new Nexus “sensor hub” around the Nexus 5X and 6P (or at best one of these), with individuals phones becoming reference designs for top fidelity sensor support. Again, the concept here’s pretty developer-centric, of course this is really a document directed at manufacturers. If OEMs satisfy the needs, they are able to tick the flag for top fidelity support, that will allow developers to determine precisely how to calibrate their apps and games for any given device or if to show an alert if your given device doesn’t have the amount of hi-fi sensor support for optimal performance or power consumption. Essentially, this really is about standardizing hardware performance for the advantage of consumer experience.

Observe that OEMs aren’t compelled to construct high fidelity sensor support, they just have to satisfy the needs from it when they want their devices to become flagged as hi-fi sensor capable. This is not essential to get the Play Store or anything like this – simply to be obvious. It’s 100% optional.

Leave Reply

August 2016
M T W T F S S
« Jul   Sep »
1234567
891011121314
15161718192021
22232425262728
293031  

Get more stuff like this
in your inbox

Subscribe to our mailing list and get interesting stuff and updates to your email inbox.