I'm a little concerned about use of the word "orientation" for these
kinds of events.
WebKit on iPhone already uses the term "orientation" to mean "which
way up is the device", i.e. in portrait or landscape, right-way-up or
upside-down:
<http://developer.apple.com/iphone/library/documentation/AppleApplications/Reference/SafariWebContent/HandlingEvents/HandlingEvents.html#//apple_ref/doc/uid/TP40006511-SW16
>
What you're talking about here is getting data from the accelerometer
to describe arbitrary positions, so I think it would be clearer if
these were called "accelerometer" events, or something else that
distinguishes them from the usage that only applies to the cardinal
angles.
Simon
On Sep 2, 2009, at 2:26 PM, Dave Burke wrote:
On Mon, Aug 31, 2009 at 11:06 PM, Doug Turner
<doug.tur...@gmail.com> wrote:
Thanks Dave for your comments.
I was thinking about update frequency. right now, it is up to the
UA (we are using 50ms).
To give an explicit example, if you want to run a high pass (say to
detect only sudden movements), you might code a simple k-order FIR
filter of the form:
y[n] = b0.x[n] + b1.x[n-1] + ... + bk.x[n-k]
The coefficient values b0 ... bk are a function of the sampling rate
("update frequency") and hence needs to be settable or at least
known to allow code portability.
units -- yes. in g. This is best.
magnetometer -- but in a different API, right? I do not see
directly how you would combined the two.
It's a different API, but (can be) closely related. You can present
magnetometer information either as x, y, z of the magnetic field
vector or as the special case of compass orientation. For example,
Android has the same SensorEvent for both Sensor.TYPE_ACCELEROMETER
and Sensor.TYPE_MAGNETIC_FIELD. Lots of interesting use-cases for
compass ranging from map tile orientation, navigation, augmented
reality, etc.
Also see: http://dougt.org/wordpress/2009/08/orientation-update/ for
some demos.
