W3C home > Mailing lists > Public > public-device-apis-log@w3.org > June 2017

Re: [sensors] Should the API allow setting both samplingFrequency and reportingFrequency?

From: Alexander Shalamov via GitHub <sysbot+gh@w3.org>
Date: Fri, 02 Jun 2017 05:10:35 +0000
To: public-device-apis-log@w3.org
Message-ID: <issue_comment.created-305691107-1496380234-sysbot+gh@w3.org>
@rwaldron +1 completely agree with you and I tried to explain that `'samplingFrequency'` cannot be reliably guaranteed neither on platform, nor on HW level.

@rwaldron There are use-cases when effective output rate of the sensor might need to be higher than 'reportingFrequency'. For example data is updated at 240Hz, while VR or game content is rendered at 60Hz. This will reduce latency for data provided by inertial sensors. What do you think about simplifying that concept for web developers by providing `'low latency'` flag? Spec can demand minimum oversampling rate.

> Basically, what I'm saying is I've never heard this terminology used in the context of MEMS sensors. That's why I don't think it's a good fit.

@tobie There should be [publications](http://www.nxp.com/assets/documents/data/en/application-notes/AN4075.pdf) / [papers](https://link.springer.com/chapter/10.1007/978-3-642-31494-0_14) and many inertial sensors actually work that way. I agree that we should avoid increasing cognitive load and simplify that concept for web developers, thus, I think 'low-latency' flag might be a good start.

GitHub Notification of comment by alexshalamov
Please view or discuss this issue at https://github.com/w3c/sensors/issues/209#issuecomment-305691107 using your GitHub account
Received on Friday, 2 June 2017 05:10:41 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 12:18:53 UTC