Understanding accelerometer data

Sun Nov 1 15:04:39 CET 2009

On Sun, Nov 1, 2009 at 3:27 AM, Neil Jerram <neiljerram at googlemail.com> wrote:
> 2009年11月1日 Nelson Castillo <arhuaco at freaks-unidos.net>:
>>>> Here I print a direction vector (ignoring Z).
>> It goes from 0 to 100 (instead of 0.0 to 1.0) to avoid floating point.
>> It updates rather fast.
>>>> http://svn.arhuaco.org/svn/src/openmoko/accelerometers/dir.c
>>>> If I only care about this vector I think I'll use a thread to keep
>> reading from the accels.
>> Fine, but have you measured what the CPU cost of that is?

No. I wouldn't care much about reading 1600bytes/second in the FR from
kernel buffers in a C program.
read_all uses blocking reads anyway. I mean: no busy waiting here and
if I use threads I don't need to use locking for the accel data.
>> I tried something (very fast, not polished) in Python but i feel the
>> program lags reading the accels.
>> Does Python's read have any internal buffering (by default)?  In Guile
> (which does) that was the cause of the lag that I saw; and when I
> added a call to set the buffer size to just sizeof(struct
> input_event), the lag disappeared.

I remember that some time ago I wrote a module to check this and
Python attempted a read of 32K in my PC! No matter how many bytes I
was trying to read. This could be the cause if you are already
experienced this.
In this weblog post I just read that we have to use non-blocking I/O
to avoid this problem.
http://bec-systems.com/site/259/how-to-optimize-python-reads-for-general-data