> All that to say that the reporting frequency is a function of the sampling frequency and not the opposite. Absolutely agree, and it is reflected in the [abstract operations](https://w3c.github.io/sensors/#abstract-operations). The problem as I see it now (and thanks for pointing it out!) is an unfortunate name and definition of the [Sensor.requestedReportingFrequency](https://w3c.github.io/sensors/#dom-sensor-requestedreportingfrequency-slot) internal slot. Now it might give a wrong impression that it is only to define [reporting frequency](https://w3c.github.io/sensors/#reporting-frequency) , actually this slot stores the `frequency` option and its value is used for these two things: 1) (indirectly) set the [requested sampling frequency](https://w3c.github.io/sensors/#requested-sampling-frequency) for the associated platform sensor. 2) set the [reporting frequency](https://w3c.github.io/sensors/#reporting-frequency) for the given Sensor object (in practice it sets the upper limit because `reporting frequency` is always capped to `sampling frequency`). I will rename the slot to `frequency` (so that it reflects the ctor option name) and provide a better description to avoid this confusion. -- GitHub Notification of comment by pozdnyakov Please view or discuss this issue at https://github.com/w3c/sensors/issues/294#issuecomment-333092609 using your GitHub accountReceived on Friday, 29 September 2017 10:34:34 UTC
This archive was generated by hypermail 2.4.0 : Monday, 4 July 2022 12:47:54 UTC