W3C home > Mailing lists > Public > public-geolocation@w3.org > July 2014

Quantative device orientation data collection and analysis

From: Rich Tibbett <richt@opera.com>
Date: Mon, 7 Jul 2014 11:47:33 +0200
Message-ID: <CAAsrAZB=Gy6Jykw6i_yt5E-ifRCqQs688rPHQOPV8i+i4-CYQQ@mail.gmail.com>
To: public-geolocation <public-geolocation@w3.org>
Last week I published http://sensortest.org; a new research tool that
allows us to capture, store and analyze sensor data returned from
deviceorientation and devicemotion events across different browser,
platform and device implementations.

In the data collection process, SensorTest.org captures device
orientation and motion sensor data as a user rotates their current
device around in physical space. The SensorTest.org data sampler
isolates current gravity components from accelerometer data observed
from a devicemotion event listener to create a consistent data
reference frame and then stores these gravity components against
deviceorientation beta and gamma data readings observed through a
deviceorientation event listener.

The tool then provides visualizations of captured orientation/motion
data that can be used to compare and analyze different
implementations.

SensorTest.org does not attempt to define 'correct' conventions or
visualizations at this point. Ideally that is the subject of further
discussion and justification on this list, mathematical or otherwise,
that can be presented for any of the implementation conventions we can
observe on SensorTest.org.

We can initially conclude a number of things from the event data
currently collected:

---

1. There are no consistent data conventions between any browser
engines that have been currently tested. Each implementation should
produce identical visualizations to each other. Right now few data
commonalities can be observed across current browser engine
implementations.

    - Example iOS capture: http://sensortest.org/?show=e317a6211156485f
    - Example FF capture: http://sensortest.org/?show=ec51fc2114f81de2
    - Example Chromium capture: http://sensortest.org/?show=7cd2982114454212

Q: Are there any compelling justifications for any one of these
calibrations to be codified in the DeviceOrientation Events
specification?

2. A number of implementations introduce or perpetuate significant
sensor noise in their output. This is likely due to software-based
sensor data translation in implementations (e.g. using low/high-pass
filters to filter devicemotion data introducing lag between
devicemotion and deviceorientation readings that can be observed).

    - Example of high sensor noise: http://sensortest.org/?show=35c6582114c98156
    - Example of low sensor noise: http://sensortest.org/?show=415ef021148ebfe1

Q: Can we improve the signal-to-noise ratio between devicemotion and
deviceorientation event data?

3. While iOS Safari produces the least intra sensor noise, the device
orientation beta range is set as [-90, 90) while gamma is [-180, 180).
This is not conformant to the data range conventions described in the
current specification where beta should be in the range [-180, 180)
and gamma should be [-90, 90).

    - Example of the data ranges used in iOS implementations:
http://sensortest.org/?show=28d554211055962d

Q: Will this be addressed in future updates to iOS or do we need to
plan around this as implementers and web developers?

4. The interval between firing of deviceorientation and devicemotion
events is different across implementations. While e.g. Chrome and
Safari are deliberated rate-limited to return every 50ms, other
implementations fire a new event as quickly as every 16ms that results
in data 'streaking'. Do we want to

    - Example of data 'streaking': http://sensortest.org/?show=18177e2113e576a6

Q: Should we define a consistent rate for deviceorientation and
devicemotion events to fire at? What should that rate be? (FWIW, I've
been told that 50ms can be too slow for creating immersive VR
experiences like e.g. Google Cardboard).

---

There is likely to be a lot more useful information to be observed
hiding within the data collected at SensorTest.org. If you notice
anything significant it would be good if you could share those
observations on this mailing list.

SensorTest.org is open-source and MIT licensed. Any improvements to
the data sampling process and/or visualization process are very
welcome at https://github.com/richtr/sensortest.org/.

- Rich
Received on Monday, 7 July 2014 09:48:00 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:51:08 UTC