Re: Sensor API : New draft

if the scaling is not set appropriately by default can't this limit the possible range of meaningful values at the endpoints of the range? 

regards, Frederick

Frederick Hirsch
Nokia



On Nov 23, 2011, at 11:49 AM, ext Philip Gladstone wrote:

> See inline (below) -- I think that the difference is in the scaling that gets applied to base unit. I would prefer to see that all the units are base units (i.e. with no scaling). Otherwise I expect that when new sensors get added, there will be arguments over what the scale factor ought to be (with the probable result that scale factors will vary from implementation to implementation). For example, how about a Carbon Monoxide gas concentration sensor? I think it ought to return the amount of CO in the air as a value from 0 - 1. Otherwise there will be people who want to return parts per million and parts per billion. Gas sensors are also rather slow to respond to changes in gas concentration. They can take many seconds (more than 2 minutes in some cases) to return a reasonable result. I don't know if this sort of lag time needs to be included in the sensor attributes or is this the purpose of minDelay? If so, then a 'short' in microseconds is not large enough to represent these sorts of delays. I also note that the "interval" as part of SensorWatchOptions is in milliseconds (and is a float) while minDelay is microseconds and a short. I think that they ought to (at least) have the same units, if not the same type as well.
> 
> On 11/23/2011 10:43 AM, Tran, Dzung D wrote:
>> Philip,
>> I think the current spec does specify most of the sensor data in its native format in section 7.1 as:
>> 
>> An implementation must set the specific data type of the SensorDataEvent.data attribute in accordance with the following table:
>> Sensor Type 	Data Type 	Units
>> Temperature	double	degree Celsius (ºC)
> No. Should be Kelvin
>> AmbientLight	double	Lux
> Yes.
>> AmbientNoise	double	dbA
> No. Sound pressure is measured in Pascals. I admit that dBA (note the capital B) is more commonly used. Probably ought to specify the reference pressure for 0 dBA.
>> MagneticField	MagneticFieldData	micro-Tesla (uTesla)
> No. The unit is Tesla.
>> Proximity	double	centimetres (cm)
> No. The unit is metre (or meter).
>> AtmPressure	double	kiloPascal (kP)
> No. The unit is Pascal.
>> RelHumidity	double	
> Interesting case. Normally reported as percent (in the range 0 - 100). However, I suspect that it really ought to be reported as the fraction in the range 0 - 1.
>> Accelerometer	AccelerationData	meters/second^2 (m/s2)
> Yes.
>> Gyroscope	RotationData	radians/second
> Yes
>> Orientation	OrientationData	radians
> Yes
> 
> 4 are unscaled SI units, 4 are scaled. 1 (sound) unclear. 1 (humidity) TBD.
> 
> Philip
>> 
>> As for Temperature and RelHumidity, I will need to look at this more in-depth.
>> 
>> Thanks
>> -DT
>> 
>> -----Original Message-----
>> From: Philip Gladstone [mailto:pgladstone@cisco.com]
>> Sent: Tuesday, November 22, 2011 4:44 PM
>> To: public-device-apis@w3.org
>> Subject: Re: Sensor API : New draft
>> 
>> There is also the case of Temperature and RelHumidity. These are often
>> (always?) combined into a single physical sensor -- so I don't know how
>> to set the power consumed by it if I have to represent it as two
>> sensors. In particular, with temp and rel humidity, you can calculate
>> dewpoint.
>> 
>> Also, for the case of units, why are the standard SI units being used
>> for each sensor? For example, magnetic field should be in Tesla,
>> temperature in Kelvin, and atmospheric pressure in Pascals. If there is
>> a simple rule that says that the standard SI unit is used, then it will
>> make guessing the unit much easier and new sensor types will be easier
>> to define
>> 
>> philip
>> 
>> On 11/22/2011 7:00 PM, Tran, Dzung D wrote:
>>> That makes sense. Now, just a matter of how we would represent this in the API? Any suggestion?
>>> Thanks
>>> -DT
>>> 
>>> -----Original Message-----
>>> From: Ben Combee [mailto:ben.combee@gmail.com]
>>> Sent: Tuesday, November 22, 2011 9:14 AM
>>> To: Tran, Dzung D; public-device-apis@w3.org WG
>>> Subject: RE: Sensor API : New draft
>>> 
>>> A GPS sensor has different ranges and units for latitude, longitude, and altitude, for example.
>>> 
>>> From: Tran, Dzung D
>>> Sent: 11/22/2011 5:16 PM
>>> To: Ben Combee; public-device-apis@w3.org WG
>>> Subject: RE: Sensor API : New draft
>>> Hello Ben,
>>> 
>>> We will try to address these.  As for sensor range, we assume it starts at zero which is probably wrong. What do you mean for other sensors you might need a range for each sub-component?
>>> 
>>> Thanks
>>> -DT
>>> 
>>> -----Original Message-----
>>> From: Ben Combee [mailto:ben.combee@gmail.com]
>>> Sent: Wednesday, November 16, 2011 4:21 PM
>>> To: public-device-apis@w3.org WG
>>> Subject: Re: Sensor API : New draft
>>> 
>>> Spotted a couple of minor issues in the new draft hosted at http://dev.w3.org/2009/dap/system-info/Sensors.html
>>> 
>>> In the first example in part 1, the sensor connection instance variable is named "sensorCnx", but later is referred to as "session".
>>> 
>>> In part 5.1, I'm unclear why the range property is described as "short" when most data values are doubles or collections of doubles.
>>> I also an unclear why range is a single value -- for something like a temperature sensor which has units of degrees Celsius, the range of the sensor might not go all the way to absolute 0 so you'd need a minimum and maximum range, and for other sensors you might need a range for each sub-component.
> 
> -- 
> Philip Gladstone
> Distinguished Engineer
> Product Development
> pgladstone@cisco.com
> Phone: +1 978-ZEN-TOAD (+1 978 936 8623)
> Google: +1 978 800 1010
> Ham radio: N1DQ
> 
> 
>

Received on Wednesday, 30 November 2011 14:48:10 UTC