Return-Path: X-Original-To: apmail-incubator-callback-dev-archive@minotaur.apache.org Delivered-To: apmail-incubator-callback-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 66BA991AA for ; Thu, 15 Mar 2012 23:44:32 +0000 (UTC) Received: (qmail 92274 invoked by uid 500); 15 Mar 2012 23:44:32 -0000 Delivered-To: apmail-incubator-callback-dev-archive@incubator.apache.org Received: (qmail 92248 invoked by uid 500); 15 Mar 2012 23:44:32 -0000 Mailing-List: contact callback-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: callback-dev@incubator.apache.org Delivered-To: mailing list callback-dev@incubator.apache.org Received: (qmail 92201 invoked by uid 99); 15 Mar 2012 23:44:30 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 15 Mar 2012 23:44:30 +0000 X-ASF-Spam-Status: No, hits=-1.3 required=5.0 tests=FRT_ADOBE2,RCVD_IN_DNSWL_MED,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of fil@adobe.com designates 64.18.1.23 as permitted sender) Received: from [64.18.1.23] (HELO exprod6og109.obsmtp.com) (64.18.1.23) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 15 Mar 2012 23:44:24 +0000 Received: from outbound-smtp-1.corp.adobe.com ([192.150.11.134]) by exprod6ob109.postini.com ([64.18.5.12]) with SMTP ID DSNKT2J+w2TePRKREPdhmA+U9nk/PB8OnGeb@postini.com; Thu, 15 Mar 2012 16:44:04 PDT Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id q2FNg1J0010179 for ; Thu, 15 Mar 2012 16:42:02 -0700 (PDT) Received: from nahub02.corp.adobe.com (nahub02.corp.adobe.com [10.8.189.98]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id q2FNi3MM000437 for ; Thu, 15 Mar 2012 16:44:03 -0700 (PDT) Received: from nambxv01a.corp.adobe.com ([10.8.189.95]) by nahub02.corp.adobe.com ([10.8.189.98]) with mapi; Thu, 15 Mar 2012 16:44:02 -0700 From: Filip Maj To: "callback-dev@incubator.apache.org" Date: Thu, 15 Mar 2012 16:43:58 -0700 Subject: Re: Normalization of acceleration values Thread-Topic: Normalization of acceleration values Thread-Index: Ac0DBYANAWSbW0G9SOiT8y8XzXPyRQ== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Virus-Checked: Checked by ClamAV on apache.org Hey all, I'm bringing this one back up :) https://issues.apache.org/jira/browse/CB-152 I am leaning towards going with the spec Jesse linked to [1] and having all the platforms roll with units expressed as m/s^2. >From a conversation I just had with Jesse this issue just came up in WP7 as well. I will do some testing on my iPod + android and see what the different return values are currently. I'll try to consolidate. We will have to update docs for this as well! [1] http://dev.w3.org/geo/api/spec-source-orientation.html#devicemotion On 2/8/12 3:54 PM, "Brian LeRoux" wrote: >rather than a vote thread I'm thinking we continue to treat W3C >recommendation 'the right way' to do stuff > >(I realize that in itself is debatable!!!) > >On Tue, Feb 7, 2012 at 7:48 AM, Simon MacDonald > wrote: >> It seems to be on Android that it is returning the value in m/s*s. When >>my >> device is resting on the desk the x and y values are close to 0 while >>the z >> is close to 9.8. Depending on what Android device you have your >> accelerometer may be more accurate or able to go up to a higher level >>of g. >> So, it looks like if we want to standardize on g as the unit to be >>returned >> for the accelerometer I'll need to divide by 9.81. >> >> Also, can someone else run the MobileSpec code and go into Accelerometer >> and do a Start Watch while leaving your phone flat on the desk? I want >>to >> make sure that other devices don't correct for gravity as I only have >> Samsung devices here. >> >> Simon Mac Donald >> http://hi.im/simonmacdonald >> >> >> On Tue, Feb 7, 2012 at 3:36 AM, Filip Maj wrote: >> >>> Let's decide, please. A vote thread? >>> >>> My vote is using what the W3C spec [1] suggests, which, as Jesse points >>> out in the JIRA issue, seems to be m/s^2. >>> >>> My problem looking at this a few weeks ago was figuring out what the >>> reference point/units on the various native platforms was (I.e. What is >>> -10 / +10 on Android? What is -1000 / +1000 on Blackberry? What are >>>those >>> units?). It's not very well documented :s >>> >>> On 12-02-07 3:00 AM, "gtanner@gmail.com" wrote: >>> >>> >Also to note that I think the values on BlackBerry are -1000 to +1000. >>> > >>> >Dan was noticing this last week while working on an app >>> >------Original Message------ >>> >From: Shazron >>> >To: callback-dev@incubator.apache.org >>> >ReplyTo: callback-dev@incubator.apache.org >>> >Subject: Normalization of acceleration values >>> >Sent: Feb 6, 2012 8:57 PM >>> > >>> >https://issues.apache.org/jira/browse/CB-152 >>> > >>> >Should we decide? >>> > >>> >Sent on the TELUS Mobility network with BlackBerry >>> >>>