Re: Sensor API : New draft

In all the cases that I saw, the values for these sensor readings were 
'float'. This gives plenty of resolution over a wide range of values. I 
agree that you want scaled values if you report as an integer value. 
However, if you use an integer, then you may have problems in the future 
if the resolution (or range) of the sensor increases.

Since all numbesr in Javascript are actually 64-bit floats, there is a 
huge range of over 600 orders of magnitude with at least 14 digits of 
precision. The volume of the universe in cubic planck lengths is under 
10^200 so there is plenty of range.

Philip


On 11/30/2011 9:47 AM, Frederick.Hirsch@nokia.com wrote:
> 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
>>
>>
>>
>

-- 
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
Blog: http://wwwin-blogs.cisco.com/pgladsto/

Cisco.com - http://www.cisco.com

This email may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message.

For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html