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

RE: Quantative device orientation data collection and analysis

From: Mandyam, Giridhar <mandyam@quicinc.com>
Date: Wed, 13 Aug 2014 13:54:09 +0000
To: Rich Tibbett <richt@opera.com>, public-geolocation <public-geolocation@w3.org>
Message-ID: <CAC8DBE4E9704C41BCB290C2F3CC921A23E45FD5@NASANEXD02E.na.qualcomm.com>
Hello All,
This was sent over a month ago, with no response on the public list as of yet.  Please take a look and try to provide feedback to the list before August 23.  In particular, I will call your attention to two questions that have impact to the DeviceOrientation specification:

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

> Q: Should we define a consistent rate for deviceorientation and devicemotion events to fire at? What should that rate be?

-Giri

-----Original Message-----
From: Rich Tibbett [mailto:richt@opera.com] 
Sent: Monday, July 07, 2014 2:48 AM
To: public-geolocation
Subject: Quantative device orientation data collection and analysis

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 Wednesday, 13 August 2014 13:54:44 UTC

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