Accelerometer Data

Iain B. FIndleton ifindleton at
Tue Mar 24 14:33:48 CET 2009

The location of the control interfaces for the accelerometers in the 
2.6.28 build has moved to :


After reading the code for the driver version on the git tree, I 
discovered that the settings for sample_rate and full_scale are limited 
to 2 values only, and the units of the threshold value are determined by 
the full_scale settings.

As to the time intervals between reports, to my view, they are still 
pretty erratic, although at least the time codes on the reports are at 
least always increasing in time.

The code read so far appears to indicate that the overrun values are not 
reported. Is there an easy way to get the exact, current source for the 
driver that is used in the 2.6.28 release? Even although I have been 
reading diff files since the 1970s they still cause my brain to dissolve 
an leak out of my ears.....

What I am wondering is whether the devices themselves report according 
to spec and setup? It pretty hard to make use of the data for much if 
you can't determine the time interval that the acceleration value refers to.

As to keeping up with the device, I can envisage code that would be too 
slow as a possibility, but a 500 MHz processor should easily manage a 10 
ms device, one would think. I have not personally seen a timing issue 
for a device on a modern CPU since the 1980s.

Neil Brown wrote:
> On Monday March 23, ifindleton at 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
>  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
> _______________________________________________
> Openmoko community mailing list
> community at

More information about the community mailing list