Re: Sensor API : New draft

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