Address questions around exposing high-level, low-level, and uncalibrated sensors

[tobie]

For example, with Barometer, should an Altimeter sensor be exposed as part of the same spec?

Similarly, how do we go about temperature-corrected Barometer data (these are often on the same chip)? Should the spec request both the calibrated compensated data (new BarometerSensor()) and the raw uncompensated data (new UncalibratedBarometerSensor() new UncompensatedBarometerSensor()??) to be exposed?

[pablochacin]

the problem I see with requesting different sensors is how do you correlate them? It's not evident they are the same underlying sensor.

I think the best way is to consider that each sensor offers multiple variables, like "presure", "rawpresure", "altitude". This is the way we have modeled it in our system and works quite well.

[tobie]

@pablochacin so you're suggesting something like:

interface BarometerSensorReading : SensorReading {
  readonly attribute double? pressure;
  readonly attribute double? rawPressure;
  readonly attribute double? altitude;
};

Doesn't that might have some performance cost in some circumstances?

[rwaldron]

Should the spec request both the calibrated data (new BarometerSensor()) and the raw data (new UncalibratedBarometerSensor() ??) to be exposed?

Uncalibrated data is wrong (or at least inaccurate) data. Whatever hardware is responsible for initializing each component to the sensor hub/bus should be responsible for calibration.

the problem I see with requesting different sensors is how do you correlate them? It's not evident they are the same underlying sensor.

Exactly. A Barometer sensor should output a measurement of ambient air pressure in either kPa or hPa. A Temperature sensor should output a measurement of Temperature in (at least) Celsius. These should always be treated as discrete components. Using the output of these particular discrete sensors, user code can compute Altitude from sea level (~1013.25 hPa).

This assumes the host device has both sensors:

readonly attribute double? altitude;

What does this even mean?

readonly attribute double? pressure;
readonly attribute double? rawPressure;

[tobie]

Sorry, I meant "uncompensated" and not "uncalibrated" (please bear with me).

So I was looking at the BMP series of barometer sensors (that are supported in Johnny-Five and which apparently also power the iPhone 6), and it appears that these sensors all have an integrated temperature sensor that is used to compensate the values of the pressure sensor and not (only?) to help calculate the altitude as you seem to indicate in #51 (comment).

So I have a bunch of follow up questions:

• For this particular case, where two sensors on a single sensor are used to provide compensated data to improve the overall quality of the readings, what should be exposed to the Web platform?
  1. the compensated pressure reading only?
  2. the compensated pressure reading and the temperature reading?
  3. the compensated pressure reading, the uncompensated pressure reading and the temperature reading?
  4. the compensated pressure reading and the uncompensated pressure reading?
  5. something different?
  6. leave that up to the implementor?
  7. leave that up to the barometer spec.
• From the barometer data, it seems easy to get elevation data using a bit of math, the temperature(?) and a few constants (mean pressure at sea level, something else?). Should a separate new sensors.Altimeter() be also exposed in that case?

Note, I'm taking Barometer as an example here, but you get the idea.

[pablochacin]

@tobie In our current system, we model sensors as providing "maps" of variables. That is, the event don't have a single sensorReading() method, but a generic getMeasurement(String variable) method. In that way, we don't have to specialize sensor interfaces to access the different variables.

Regarding performance, the higher penalty is for the event meta data (time stamp, location, attributes) and for the connection/transmission overhead, more than for transferring a few more bytes of data.

[rwaldron]

and it appears that these sensors all have an integrated temperature sensor

Yes, and I actually cannot identify a barometric pressure sensor that doesn't come with a temperature. I still think that these need to be treated as discrete sensors.

So I have a bunch of follow up questions:

For this particular case, where two sensors on a single sensor are used to provide compensated data to improve the overall quality of the readings, what should be exposed to the Web platform?

• the compensated pressure reading and the temperature reading?

These are the only useful values that any program will care about. "Uncompensated" air pressure measurements are "wrong" air pressure measurements ;)

From the barometer data, it seems easy to get elevation data using a bit of math, the temperature(?) and a few constants (mean pressure at sea level, something else?). Should a separate new sensors.Altimeter() be also exposed in that case?

This is exactly what I was thinking.

[tobie]

In our current system, we model sensors as providing "maps" of variables.

That's the plan here too. This is more about setting guidelines for concrete sensor implementations as to what to expose and why.

[tobie]

Thanks for the comments, @rwaldron.

Here's a bunch of proposed resolutions that I'd like to include in the extensibility section of the spec:

• Sensor that need to combine the value of different sensors to provide a more precise value should be treated as a discrete sensor.
• only calibrated and compensated (where appropriate) values should be exposed via the API.
• sensors may expose additional values used in order to compensate other values (for example the temperature may be exposed in a barometer sensor).
• certain sensors enable higher level sensors to be built on top of them (for example, a barometer can help built an altimeter). When this is the case, both should be exposed separately (so you'd have an Barometer with eventual temp readings and an Altimeter (with eventual temp and pressure readings?)

@rwaldron: I'd like to get your thoughts on the last point here.

Furthermore, I think it would be useful to have a bunch of definitions in the spec for sensor-related terminology, e.g.: sensor fusion, calibration, compensation, etc. (now tracking in #52) and maybe some high level details as to how sensors are generally implemented (tracking in #53).

[tobie]

I think this is properly addressed in the Extensibility section of the spec. Closing.