RE: [sensors] Device Proximity (was: Device light and proximity sensor)

You are depending on the OS or proximity sensor device to give you this near/far value, otherwise the UAs need to interpret this near/far base on value, min and max. Are we going to specify in the spec how near/far are interpret. Is <= 50% means near and > 50% means far? 

 Also, some notebooks and desktops are adding proximity sensor for detecting if there is user present. In this case near/far have different range.

Thanks
Dzung Tran

-----Original Message-----
From: Doug Turner [mailto:dougt@mozilla.com] 
Sent: Thursday, May 10, 2012 7:07 AM
To: Claes1 Nilsson
Cc: Marcos Caceres; public-device-apis@w3.org
Subject: Re: [sensors] Device Proximity (was: Device light and proximity sensor)

Claes,

For the use case of "is the user's face on the screen", this near/far API works great.  However, for most other things defining what near and far mean is going to be a troubling issue.

For external distance sensors -- any other approach could be considered (including the silver bullet of Web Intents).  However, I think those kind of use cases should be out of scope.

Doug



----- Original Message -----
From: "Claes1 Nilsson" <Claes1.Nilsson@sonymobile.com>
To: "Marcos Caceres" <w3c@marcosc.com>, public-device-apis@w3.org
Sent: Thursday, May 10, 2012 6:47:56 AM
Subject: RE: [sensors] Device Proximity (was: Device light and proximity   sensor)

It seems as most use cases is about detecting "near" / "far" using a sensor in the user's current device. As far as I know the sensor technology in most devices support this granularity and not a real distance. So a super simple API for this seems as an attractive approach.

External distance sensors, as well as other typically external sensors such as medical sensors, is another thing and discovery has to be addressed so I guess that a Web Intents based approach should be considered. 

Claes

> -----Original Message-----
> From: Marcos Caceres [mailto:w3c@marcosc.com]
> Sent: den 10 maj 2012 11:20
> To: public-device-apis@w3.org
> Subject: Re: [sensors] Device Proximity (was: Device light and
> proximity sensor)
> 
> On Thursday, 10 May 2012 at 06:04, N.V.Balaji wrote:
> > Just reporting the value is a better approach. Even though you may
> trust the
> > people closer to OS, you can't guarantee all implementers agreeing on
> the
> > same values.
> 
> Again, this only comes down to the use case and the variance between
> them. Remember that other things can cause variance in the reading too
> (e.g., transparent plastic in front of the infrared beam, as iPhone
> users learned: http://www.youtube.com/watch?v=3tGqQd7S7d8). For other
> types of proximity sensors, there is also other sources of variance
> simply based on the type of material (this is by design:
> http://www.fargocontrols.com/sensors.html ).
> 
> 
> So, can we please get some agreement on the use case(s) and
> requirements? If the use case is "phone next to ear", then a variance
> of a few centimetres or millimetres won't matter. If the use case is
> more industrial, like "detect when metal gear spoke spinning at 200rpm
> comes into 2mm proximity to the sensor", then current model would be
> better. However, we still need to consider that higher sensitivity
> proximity sensors might be part of an array of sensors (i.e., car
> parking sensors). See this proximity sensor array as an extreme
> example:
> http://www.youtube.com/watch?feature=endscreen&NR=1&v=vzWEgOt3xsM

> 
> See also the following, which also contains good details about
> proximity sensors:
> http://www.omron.com.au/technical_guide/proximity_sensor/index.asp

> 
> 
> 
> 
> --
> Marcos Caceres
> http://datadriven.com.au

> 
> 
>

Received on Thursday, 10 May 2012 15:49:33 UTC