This commit addresses a few issues with the way frequency management was
handled in the specification:
"Sampling frequency" was interchangeably used as a number as well as an
interval ("sampling frequency bounds"), and the latter was not even
properly defined.
The actual bounds were not properly defined, and neither was the clamping
process that used them.
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" 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.
This commit addresses a few issues with the way frequency management was handled in the specification:
Let us start with the changes in the concepts and definitions:
[[frequency]]of the associated Sensor objects. It is therefore a mixture of the previous "sampling frequency" and "requested sampling frequency" definitions.With the above, the actual sampling bounds are defined and checked:
[[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).[[frequency]]values lies within its sampling bounds.The "optimal sampling frequency" and "requested sampling frequency" 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 #463.
Preview | Diff