- From: Nick Doty via GitHub <sysbot+gh@w3.org>
- Date: Mon, 13 Jan 2020 22:36:17 +0000
- To: public-device-apis-log@w3.org
From my read of the paper, the authors suggest two mitigations that they seem to identify as resolving the issue altogether: 1. adding random noise of -0.5-to-0.5 to each value and then rounding to the resolution of the sensor (16 bits, in the case of the iOS devices in question) 2. rounding the output to the nearest multiple of the nominal gain of the sensor (61 or 70 millidegrees per second, in the case of the iOS devices in question) Those mitigations do seem to be hardware specific (per @reillyeon), so we might not be able to include hard numbers in the spec, but could still provide a normative indication that sensors should be rounded using the provided algorithm, based on their hardware details. If nominal sensor gain and sensor resolution are known for each device (*and* accessible to the browser from the underlying operating system), then those mitigation algorithms could be implemented by all browser implementers. I’m not entirely clear on this yet, but it also seems possible that we could do a survey of the accelerometers and gyroscopes currently in use by most mobile devices and then require no more precision than slightly below the typical or lowest precision sensor in the survey. Would that be a huge detriment to functionality? I’m not sure, but if I’m reading it correctly that the iOS devices measure a range of 4000 degrees per second with a resolution (and nominal gain) of 0.061, then we’d be talking about an extra error of 0.1 / 4000 = 0.0025%. That certainly sounds small, though I’m sure it depends on the particular use cases. -- GitHub Notification of comment by npdoty Please view or discuss this issue at https://github.com/w3c/deviceorientation/issues/85#issuecomment-573905808 using your GitHub account
Received on Monday, 13 January 2020 22:36:19 UTC