W3C home > Mailing lists > Public > public-device-apis@w3.org > November 2011

RE: Sensor API : New draft

From: Tran, Dzung D <dzung.d.tran@intel.com>
Date: Wed, 23 Nov 2011 15:43:58 +0000
To: Philip Gladstone <pgladstone@cisco.com>, "public-device-apis@w3.org" <public-device-apis@w3.org>
Message-ID: <84BCA539DD96614691177EDA3CE4FF0516F2A1F7@ORSMSX101.amr.corp.intel.com>
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)
AmbientLight	double	Lux
AmbientNoise	double	dbA
MagneticField	MagneticFieldData	micro-Tesla (uTesla)
Proximity	double	centimetres (cm)
AtmPressure	double	kiloPascal (kP)
RelHumidity	double	
Accelerometer	AccelerationData	meters/second^2 (m/s2)
Gyroscope	RotationData	radians/second
Orientation	OrientationData	radians

As for Temperature and RelHumidity, I will need to look at this more in-depth.


-----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 

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


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
Phone: +1 978-ZEN-TOAD (+1 978 936 8623)
Google: +1 978 800 1010
Ham radio: N1DQ

Received on Wednesday, 23 November 2011 15:44:32 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:32:32 UTC