forked from w3c/sensors
-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Overhaul frequency management in the specification
This commit addresses a few issues with the way frequency management was handled in the specification: 1. "Sampling frequency" was interchangeably used as a number as well as an interval ("sampling frequency bounds"), and the latter was not even properly defined. 2. The actual bounds were not properly defined, and neither was the clamping process that used them. 3. There were too many frequency-related terms in use. Let us start with the changes in the concepts and definitions: - A platform sensor has a sampling frequency, a positive number or null. It represents the frequency at which the platform sensor attempts to retrieve data from the device sensor and it is calculated in an implementation-defined manner based on the `[[frequency]]` of the associated Sensor objects. It is therefore a mixture of the previous "sampling frequency" and "requested sampling frequency" definitions. . How the sampling process works is implementation-defined: it could be polling, or requesting updates at this interval, or something else entirely. - A device sensor has a sampling frequency. It is similar to the above, but operating system or hardware dependent and opaque to this specification. . As such, the device sensor may choose a sampling frequency that differs from the platform sensor's sampling frequency and we have no control over it. - A device sensor MAY report lower and/or upper sampling frequency bounds. With the above, the actual sampling bounds are defined and checked: - A sensor type MUST have lower and upper sampling frequency bounds. The lower bound is "max(implementation-defined value, optional spec-defined value)", and the upper bound is "min(implementation-defined value, optional spec-defined value)". - A new algorithm returns a platform sensor's lower and upper sampling bounds as a tuple "(max(optional device sensor lower bound, sensor type lower bound), min(optional device sensor upper bound, sensor type upper bound))". - A Sensor's `[[frequency]]` is always set to a value within a platform sensor's sampling bounds in "Connect to a sensor" (before that it might not have an associated platform sensor and should be in the "activated" state). - "Set sensor settings" requires that the platform sensor sampling value calculated based on its associated sensors' `[[frequency]]` values lies within its sampling bounds. The "optimal sampling frequency" and "requested sampling frequency" <dfn>s have been removed, and so has the "Find the reporting frequency of a sensor object" algorithm, which addresses point (3). The "Automation" section has only received enough changes to avoid Bikeshed errors and warnings, as the entire section is being rewritten. Related to w3c#463.
- Loading branch information
Raphael Kubo da Costa
committed
Aug 1, 2023
1 parent
95b84e5
commit 89662c8
Showing
1 changed file
with
109 additions
and
89 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters