incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jesse MacFadyen <purplecabb...@gmail.com>
Subject Re: Normalization of acceleration values
Date Fri, 16 Mar 2012 18:29:47 GMT
Perfect!

Cheers,
  Jesse

Sent from my iPhone5

On 2012-03-16, at 11:28 AM, Filip Maj <fil@adobe.com> wrote:

> Yeh that's what I meant Jesse :)
>
> On 3/16/12 11:04 AM, "Jesse MacFadyen" <purplecabbage@gmail.com> wrote:
>
>> Given the goal of uniformity in js, doesn't it make more sense to
>> simply modify the native side?
>>
>> Cheers,
>> Jesse
>>
>> Sent from my iPhone5
>>
>> On 2012-03-16, at 10:59 AM, Filip Maj <fil@adobe.com> wrote:
>>
>>> Solid. Can we drop a constant of value 100 in there somewhere, divide
>>> the
>>> values and use those in the success callback to accel in BB to line it
>>> up
>>> with Android + iOS?
>>>
>>> On 3/16/12 10:54 AM, "Drew Walters" <deedubbu@gmail.com> wrote:
>>>
>>>> FYI, my experience with BlackBerry is that it appears to be based on
>>>> gravity multiplied by 100.  So at rest my Torch 9800 (OS 6) reads
>>>>
>>>> x=27(noise), y=4(noise), z=988
>>>>
>>>> On Fri, Mar 16, 2012 at 12:08 PM, Filip Maj <fil@adobe.com> wrote:
>>>>> Laying devices flat on a table, with the screen pointed up, values
>>>>> were:
>>>>>
>>>>> Android 4.0.2 (Galaxy Nexus): x=0, y=0, z=9.8
>>>>> iPod 5.0.1: x=0, y=0.5 (wtf?), z=-1
>>>>>
>>>>> As a result, in my cordova-js integration branch for iOS, I've added
a
>>>>> "g"
>>>>> constant at -9.81 and multiplied the return values from native by
>>>>> that.
>>>>> This lines up Android and iOS.
>>>>>
>>>>> Not sure what to make of the "at rest" value for y in the iPod,
>>>>> though...
>>>>>
>>>>> On 3/15/12 7:58 PM, "Dan Silivestru" <dan.silivestru@gmail.com>
wrote:
>>>>>
>>>>>> +1 as well.
>>>>>>
>>>>>> I'll look into the values returned for the BlackBerry. At first
>>>>>> glance
>>>>>> they
>>>>>> seem to be 2 orders of magnitude greater then g. I'll post back to
>>>>>> the
>>>>>> group once I have the answer.
>>>>>>
>>>>>> On Thu, Mar 15, 2012 at 10:47 PM, Joe Bowser <bowserj@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> +1
>>>>>>> On Mar 15, 2012 7:42 PM, "Bryce Curtis" <curtis.bryce@gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> +1
>>>>>>>>
>>>>>>>> On Thu, Mar 15, 2012 at 6:43 PM, Filip Maj <fil@adobe.com>
wrote:
>>>>>>>>
>>>>>>>>> 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" <b@brian.io>
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
>>>>>>>>>> <simon.macdonald@gmail.com> 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 <fil@adobe.com>
>>>>>>> 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"
<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
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Dan Silivestru
>>>>>> +1 (519) 589-3624
>>>>>
>>>
>

Mime
View raw message