incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Drew Walters <deedu...@gmail.com>
Subject Re: Normalization of acceleration values
Date Fri, 16 Mar 2012 18:10:55 GMT
After finding the right document [1], apparently on BlackBerry 1000 =
G force.  Apparently my desk is in a slow constant fall to the center
of the earth.

I'll just do some math on native side to conform the values.  Maybe
not today though.

[1] http://www.blackberry.com/developers/docs/5.0.0api/net/rim/device/api/system/AccelerometerSensor.html

On Fri, Mar 16, 2012 at 1:04 PM, 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