Many demanding sensor applications for mobile devices, like pedestrian dead reckoning and image stabilization, require good algorithms for sensor fusion and context awareness. These are only possible when there is a robust foundation of sensor drivers to provide the sensor data.
The most distinguishing feature of a sensor driver is the framework it uses to communicate back to user space services and applications. A consumer-grade sensor driver interface should provide the following features:
- A control interface to query and set hardware capabilities and configurations:
- enable/disable the sensor,
- available output rates and measurement ranges,
- precision (quantization) and resolution (noise),
- device name with hardware and firmware versions,
- unit conversion and axis alignment,
- power modes (deep sleep, low power idle, full),
- power usage and wake/sleep latencies for different modes,
- special capabilities: e.g. an accelerometer that can detect taps;
- isochronous data events: regular samples with accurate timestamp available at various rates from 10Hz-250Hz (nominal 50Hz), e.g. acceleration in x, y, and z;
- asynchronous data events: triggered events, e.g. proximity detect, free-fall detect; and
- FIFO data buffering.
The commonly used frameworks, Input Event (also known as evdev), Industrial I/O (IIO), and HID Sensor all work for today’s sensor applications, but none of them encompass all the above features.
Input Event was designed for devices like mouse, keyboard, and joystick. It is a mature standard which can be used to quickly bring up a polled driver. It has an easy command-line interface and supports bi-directional communication between the system processor and sensor. Together with the uinput framework, user space applications such as virtual sensors can produce events in the same form as hardware devices.
Some downsides to the Input Event framework are that there is no provision for hardware timestamps and its control interface is limited. There is not even a simple way to indicate multi-sensor data is sampled simultaneously.
Industrial I/O, or IIO, was introduced more recently to enable efficient high data throughput (e.g. sample rates greater than 500Hz) and has been adopted by Google in the recent Android Jelly Bean release. It includes facilities to publish sensor metadata, such as measurement scale factor. Data is exposed as sysfs giving a simple text interface to control the devices.
The main criticism of IIO is that it is over-engineered. Eventhough a version has been upstreamed since the later 2.6 kernel series, no standard userland interfaces are yet developed. Permission management in Android is moved outside of the stock udev interface into a dynamically generated one.
HID sensor is an extension of the human-interface device framework and adopted by Microsoft in Windows 8. It is a transport interface similar to I2C or SPI and can be wrapped in any standard driver framework such as input event or IIO. However, on Windows 8, the framework is proprietary and leads to difficulty in debugging and possible latency due to overhead.
Other frameworks exist, such as ALSA for high data-rate sound or hwmon for low-level sensors such as fan temperature. Pressure, temperature, and relative humidity sensors often use these frameworks, but they are less widely adopted for inertial sensors. Sometimes, a simple interface is implemented which has direct readings over a device node or sysfs.
It is important to stress that, no matter which driver framework is used, it can be made compatible with the list of features mentioned here. It is beneficial as a community, however, to move towards a complete non-proprietary sensor driver standard across platforms in order to increase the integration of sensor solutions across sub-systems. Multiple working groups are attempting to do just that from various angles. We at Sensor Platforms, being power-users of sensors, contribute to these initiatives to ensure they are compatible with the many possible use cases without over-engineering.