RE: [sensors] Proximity Events

Any thoughts on: http://dvcs.w3.org/hg/dap/raw-file/tip/proximity/userproximity.html


Or should we keep it in one spec as: http://dvcs.w3.org/hg/dap/raw-file/tip/proximity/Overview.html


The same reason that we want to separate the sensor API into separate specs applies here. We want to make sure that the implementers have the option to implement one but not the other.

Also in this spec that user proximity should ever set to "unknown", why would this you get an event that set this to unknown unless the sensor is faulty? Then what happens? Will you keep getting "unknown". My opinion is that you will only toggle between near and far and vice versa. If the UA can't determine, then you will not get an event.

Thanks
Dzung Tran



-----Original Message-----
From: SULLIVAN, BRYAN L [mailto:bs3131@att.com] 
Sent: Tuesday, May 15, 2012 9:15 PM
To: 'dougt@mozilla.com'; 'w3c@marcosc.com'
Cc: 'anssi.kostiainen@nokia.com'; 'public-device-apis@w3.org'
Subject: Re: [sensors] Proximity Events

Ok. I suggested mm as the minimum will now be 1 cm (~1/3 inch). But that is probably precise enough.
Bryan Sullivan | AT&T 

----- Original Message -----
From: Doug Turner [mailto:dougt@mozilla.com]
Sent: Tuesday, May 15, 2012 03:36 PM
To: Marcos Caceres <w3c@marcosc.com>
Cc: Anssi Kostiainen <anssi.kostiainen@nokia.com>; public-device-apis@w3.org public-device-apis@w3.org <public-device-apis@w3.org>
Subject: Re: [sensors] Proximity Events

Hmm.  Then maybe leave it as cm's for now.  It is consistent with APIs that are exposed to us from handsets and satisfies all of the use cases we discussed (we aren't talking about proximity down to the mm resolution!)

Doug

----- Original Message -----
From: "Marcos Caceres" <w3c@marcosc.com>
To: "Doug Turner" <dougt@mozilla.com>
Cc: "Anssi Kostiainen" <anssi.kostiainen@nokia.com>, "public-device-apis@w3.org public-device-apis@w3.org" <public-device-apis@w3.org>
Sent: Tuesday, May 15, 2012 2:50:54 PM
Subject: Re: [sensors] Proximity Events




On Tuesday, 15 May 2012 at 15:03, Doug Turner wrote:

> Firefox used cm's as that is what every android phone and libhardware returns. We could upgrade to using mm without too much trouble.
>  
> Any objection?
>  

I think that would be good. However, it should be clear in the spec that the number represents the range of the sensor under ideal operational conditions and should not be relied on as an indicator of distance.  

TL;DR… I don't know where to file this, so I'll just write it here as it seems somewhat relevant when we talk about distance…

Doing some rudimentary testing on my Galaxy S using the application "AndroSensor" and on my iPhone4s using the dialler application: with a black metallic surface (a remote control), at a ~45 degree angle, I am able to get within ~5mm to the sensor without triggering the sensor. Using a crumpled metallic round object (a ferrero rocher), I can trigger the sensor at a much larger distance (~5cm). With my hand alone, it only triggers at around 5-4cm. Glass is even more interesting, as it only seems to trigger parallel to the sensor… I can put the glass right on top of the sensor at a slight angle and it does not trigger. A convex metallic object (an ashtray), is also able to successfully deflect the beam at an angle. I'll note that the AndroSensor application is only able to report 0cm, or 5cm, but visually I can see that there is quite a lot of variance in height depending on what object I use. I'll also note that on the iPhone, the only kind of application that can reliably use this sensor appear to be "push up" fitness applications (apart from the dialler).  

If you have not done so, please test various objects yourself. Just hold anything at an angle and you will see how much variance there is. So, under "ideal conditions" (skin/solid non-reflective object parallel to the sensor), this sensors are fairly accurate. Otherwise, their applications are fairly limited with regards to distance.    
  
--  
Marcos Caceres
http://datadriven.com.au

Received on Wednesday, 16 May 2012 05:29:13 UTC