Accelerometer Data

Neil Brown neilb at suse.de
Mon Mar 23 23:52:05 CET 2009


On Monday March 23, ifindleton at videotron.ca wrote:
> Okay, it looks like the 2.6.28 kernel and modules are an improvement for 
> the accelerometer data, but the report times, while not negative any 
> more, appear somewhat erratic. The type codes appear to be unchanged in 
> this build, with the driver reporting EV_REL and EV_SYN.

The time codes "should" be very reliable, and should be spaced at 10ms
intervals as the device interrupts at 100Hz (by default).

Each open file on the /dev/input/eventXX device has an internal buffer
of 64 entries.  If your application is not able to read fast enough to
keep that buffer from over flowing, then you will occasionally loose
chunks of 64 entries (and so see gaps for 640 ms).

However this is not what I see.  If I measure the time between EV_SYN
reports for 1000 such reports, I get a histogram like
   freq ms
    805 10
    136 20
     34 30
     11 40
      1 41
      4 51
      5 61
      1 71

Which isn't what I expected.  No over-runs are being reported, and
there are no 640ms gaps, so the internal buffer isn't wrapping.

(goes and reads code again...)

Ah.  If none of X, Y, or Z change, then EV_SYN won't be reported
either.  So this presumably shows that there are times when the
accelerometers think the device is completely stable - nothing
changing.

If the device were reporting EV_REL events, then you could only lose
EV_SYN events if all three axes reported 0, which means perfect
free-fall.  That seem unlikely...

I have a patch which I'm in the middle of writing which makes the
'sample_rate' sysfs setting more useful.  Instead of just '100' or
'400' you can have any other (smaller) value, and it samples the
accelerometers at that rates.  So e.g. '10' with give 10 samples per
second, and '0.1' will give one every 10 seconds.  When I get up to
testing that I'll make sure that it delivers properly times events.

You do similar histogram-generation tests yourself by:

 wget http://beagleboard.googlecode.com/files/evtest.c
 cc -o evtest evtest.c
 ./evtest /dev/input/event2   | grep Sync | awk '{print int(($3 - prev)*1000) ; prev = $3}' | sed 1000q | sort  | uniq -c

I would be interested to see what you get using a kernel that
reports EV_REL events.

'evtest' is a very useful program for experimenting with the various
input devices.

NeilBrown




More information about the community mailing list