accelerometers. Furthermore the format of the acquired datastream is explained

accelerometers. Furthermore the format of the acquired datastream is explained

−

in detail. This document does not cover the physical basics of acceleration or

+

in detail.

+

+

This document does not cover the physical basics of acceleration or

the mathematical details on this subject.

the mathematical details on this subject.

+

Consult the hardware specs at the STMsite for the [http://www.st.com/stonline/products/literature/ds/12726/lis302dl.htm LIS392DL]. It contains an interesting read how this unit functions.

==Axis orientation==

==Axis orientation==

Line 22:

Line 25:

To explain the axis orientation I have created some images for easier

To explain the axis orientation I have created some images for easier

−

understanding.

+

understanding. Note that X and Y are in the same plane as the screen, while the Z arrow is pointing "into the screen", i.e. behind the Neo. The device for the first sensor is ''/dev/input/event2''.

[[Image:Accelerometer_orientation1.png|Axis orientation of the first accelerometer]]

[[Image:Accelerometer_orientation1.png|Axis orientation of the first accelerometer]]

−

===Orientation of the second sensor===

===Orientation of the second sensor===

In contrast to the first sensor the second one is turned 45 degrees around the

In contrast to the first sensor the second one is turned 45 degrees around the

−

Z axis. See the attached image to get a clue about its orientation.

+

Z axis. See the attached image to get a clue about its orientation. Note that X and Y are in the same plane as the screen, while the Z arrow is pointing "into the screen", i.e. behind the Neo. The device for the second sensor is ''/dev/input/event3''.

[[Image:Accelerometer_orientation2.png|Axis orientation of the second accelerometer]]

[[Image:Accelerometer_orientation2.png|Axis orientation of the second accelerometer]]

Line 39:

Line 41:

different input event based file mappings. These device nodes can be found at

different input event based file mappings. These device nodes can be found at

These device nodes can be opened by the default filesystems calls for reading

These device nodes can be opened by the default filesystems calls for reading

files. The data can be read from the stream as soon as the sensor measures it. Note that since the data is exported as normal files you can easily e.g. use netcat to stream the accelerometer data over bluetooth to your laptop to a control a game running on your laptop.

files. The data can be read from the stream as soon as the sensor measures it. Note that since the data is exported as normal files you can easily e.g. use netcat to stream the accelerometer data over bluetooth to your laptop to a control a game running on your laptop.

−

==Data structure==

==Data structure==

Line 283:

Line 292:

}

}

}

}

+

+

</pre>

+

+

A PHP absolute version

+

+

<pre>

+

<?php

+

+

$x = 0;

+

$y = 0;

+

$z = 0;

+

+

$secondsensorfile = "/dev/input/event3";

+

#open file in binary mode

+

$dfeed2 = fopen($secondsensorfile, "rb");

+

+

while (!feof($dfeed2)) {

+

$contents = fread($dfeed2, 16);

+

$arr = unpack("s4time/S1data/S1code/l1value",$contents);

+

if ($arr[data]=3){

+

if ($arr[code]==0) $x=$arr[value];

+

if ($arr[code]==1) $y=$arr[value];

+

if ($arr[code]==2) $z=$arr[value];

+

}

+

print "x= $x, y= $y, z=$z \n";

+

}

+

fclose($handle);

+

?>

</pre>

</pre>

Line 378:

Line 415:

return 0;

return 0;

}

}

+

</pre>

+

+

And in Guile Scheme. (This one is a complete autorotation program.)

+

+

<pre>

+

;; Open device file for the second accelerometer (whose axes are

+

;; aligned with the screen). Must make Guile's internal buffer small

+

;; (16), otherwise it reads too far ahead and this program gets mostly

+

;; out of date data.

+

(define e (open-file "/dev/input/event3"

+

"r0"))

+

(setvbuf e _IOFBF 16)

+

+

;; Uniform vector for reading data from device file. Must match

+

;; sizeof(struct input_event), otherwise the read can get an 'invalid

+

;; argument' error.

+

(define v (make-u16vector 8))

+

+

(define (current-acceleration)

+

(let loop ((x #f) (y #f) (z #f))

+

(uniform-vector-read! v e)

+

(let ((code (u16vector-ref v 4))

+

(axis (u16vector-ref v 5))

+

(meas (+ (u16vector-ref v 6)

+

(* 65536 (u16vector-ref v 7)))))

+

(if (>= meas (expt 2 31))

+

(set! meas (- meas (expt 2 32))))

+

(case code

+

((2 3)

+

(case axis

+

((0) (loop meas y z))

+

((1) (loop x meas z))

+

((2) (loop x y meas))

+

(else (loop x y z))))

+

(else

+

(if (and x y z)

+

(list x y z)

+

(loop x y z)))))))

+

+

(define (orientation x y z)

+

(cond ((and (< y -200)

+

(> (- y) x y))

+

0)

+

((and (> x 200)

+

(< (- x) y x))

+

1)

+

((and (> y 200)

+

(< (- y) x y))

+

2)

+

((and (< x -200)

+

(> (- x) y x))

+

3)

+

(else #f)))

+

+

(define (main)

+

(let loop ((ori #f))

+

(let ((new-ori

+

(apply orientation

+

(current-acceleration))))

+

(and ori

+

new-ori

+

(not (= ori new-ori))

+

(system* "xrandr"

+

"-o"

+

(number->string new-ori)))

+

(sleep 1)

+

(loop (or new-ori ori)))))

+

+

(main)

</pre>

</pre>

Line 402:

Line 508:

The other one is ''lis302dl.2''. See [[GTA02 sysfs#Accelerometers]] for the other options.

The other one is ''lis302dl.2''. See [[GTA02 sysfs#Accelerometers]] for the other options.

+

+

+

'''NOTE''' : --[[User:Garthps|Garthps]] 15:38, 14 December 2010 (UTC) : the interface has changed in newer kernels. Now it is in :

+

+

/sys/devices/platform/spi_s3c24xx_gpio.0/spi3.0/

+

+

and

+

+

/sys/devices/platform/spi_s3c24xx_gpio.0/spi3.1/

+

+

'''NOTE2''' : --[[User:Boudewijn|Boudewijn]] 10:42, 11 August 2011 (UTC): It might have changed once more; I could not find it using om-gta02 2.6.37.6 #1 Fri Jun 10 18:09:48 CEST 2011 armv4tl, but found it in:

+

/sys/class/i2c-adapter/i2c-0/0-0073/lis302dl.1/sample_rate

+

(following the path suggested by [[GTA02_sysfs#new:_.2Fsys.2Fclass.2Fi2c-adapter.2Fi2c-0.2F0-0073.2Fspi_s3c24xx_gpio.0.2Fspi3..7B0.7C1.7D.2F|sysfs for 2.6.28]])

* [http://www.st.com/stonline/products/literature/ds/12726/lis302dl.htm] The interesting hardware spec of the accellerometer built into the gta02, where you can learn how this device is actually functioning on the low-level side.

To understand the values provided by the accelerometers it is crucial to
understand how the sensors are oriented. In the following I will refer to the
sensors as first and second sensor. The way to access the data sources of
these two will be described later on in this document.

To explain the axis orientation I have created some images for easier
understanding. Note that X and Y are in the same plane as the screen, while the Z arrow is pointing "into the screen", i.e. behind the Neo. The device for the first sensor is /dev/input/event2.

In contrast to the first sensor the second one is turned 45 degrees around the
Z axis. See the attached image to get a clue about its orientation. Note that X and Y are in the same plane as the screen, while the Z arrow is pointing "into the screen", i.e. behind the Neo. The device for the second sensor is /dev/input/event3.

These device nodes can be opened by the default filesystems calls for reading
files. The data can be read from the stream as soon as the sensor measures it. Note that since the data is exported as normal files you can easily e.g. use netcat to stream the accelerometer data over bluetooth to your laptop to a control a game running on your laptop.

To be able to use the measured data it is important to understand the format
in which the data is provided.
The structure of the given data is based on the kernel input event message
system which exports the following data structure:

The types categorize the incoming messages. All possible types can be found in
the kernel sources or include files in INCLUDEDIR/linux/input.h
During the tests with the accelerometers I observed the fact that only two
different message types are used.

0x00

According to linux/input.h this event is called EV_SYN. It signals the wish to syncronize. Normally this event is used in combination with code 0x00 to mark the send data complete and therefore applyable.

0x02

This event is called EV_REL and signals relative movement. It is used to transmit the acceleration the sensors encounter.

The definition should not be taken too seriously in this context, because the
data values provided by the accelerometer always represent the absolute
acceleration measured at the given time. So, in newer kernels, the proper
absolute movement notification is used instead :

0x03

This event is called EV_ABS and signals absolute movement. It replaces the EV_REL notifications in newer kernels, but

The synchronization event may use quite a lot of codes, as linux/input.h
shows. However the only used one seems to be the 0x00 code.

0x00

This code is referred to as SYN_REPORT. It means that the last dataset was completely transmitted. Therefore the before transmitted set of data values can be considered complete. This means if this message is received you may process the given data further.

Although the information is the same as before, the absolute interface differs from the relative one by the fact that
only changed values are reported. So if the phone was completely idle, experiencing exactly the same acceleration from
one sample to the next, you will read only synchronization events (this will not happen due to noise, though).

So when you miss the value for an axis between two synchronization events, just assume the previous value still holds.

Views

Personal tools

Scope

This document describes a way to access the data provided by the
accelerometers. Furthermore the format of the acquired datastream is explained
in detail. This document does not cover the physical basics of acceleration or
the mathematical details on this subject.

Axis orientation

To understand the values provided by the accelerometers it is crucial to
understand how the sensors are oriented. In the following I will refer to the
sensors as first and second sensor. The way to access the data sources of
these two will be described later on in this document.

Orientation of the first sensor

To explain the axis orientation I have created some images for easier
understanding.

Orientation of the second sensor

In contrast to the first sensor the second one is turned 45 degrees around the
Z axis. See the attached image to get a clue about its orientation.

Data acquisition

The information from both of the accelerometers is exported through two
different input event based file mappings. These device nodes can be found at
/dev/input/event2 and /dev/input/event3.

The sensor I am refering to as the first one is event2. Therefore the second
one is accessible through the event3 device.

These device nodes can be opened by the default filesystems calls for reading
files. The data can be read from the stream as soon as the sensor measures it. Note that since the data is exported as normal files you can easily e.g. use netcat to stream the accelerometer data over bluetooth to your laptop to a control a game running on your laptop.

Data structure

To be able to use the measured data it is important to understand the format
in which the data is provided.
The structure of the given data is based on the kernel input event message
system which exports the following data structure:

I think the time structure does not need further explanation. A lot more
interesting is the type, code and value part of every message. Lets take a
closer look at these parts.

Event types

The types categorize the incoming messages. All possible types can be found in
the kernel sources or include files in INCLUDEDIR/linux/input.h
During the tests with the accelerometers I observed the fact that only two
different message types are used.

0x00

According to linux/input.h this event is called EV_SYN. It signals the wish to syncronize. Normally this event is used in combination with code 0x00 to mark the send data complete and therefore applyable.

0x02

This event is called EV_REL and signals relative movement. It is used to transmit the acceleration the sensors encounter.

The definition should not be taken too seriously in this context, because the
data values provided by the accelerometer always represent the absolute
acceleration measured at the given time. So, in newer kernels, the proper
absolute movement notification is used instead :

0x03

This event is called EV_ABS and signals absolute movement. It replaces the EV_REL notifications in newer kernels, but

the information (the event codes) is the same.

Event codes

Both types of event may supply different codes. These codes can be understood
as some kind of further specification about the specified data values

Synchronization event codes

The synchronization event may use quite a lot of codes, as linux/input.h
shows. However the only used one seems to be the 0x00 code.

0x00

This code is referred to as SYN_REPORT. It means that the last dataset was completely transmitted. Therefore the before transmitted set of data values can be considered complete. This means if this message is received you may process the given data further.

Relative movement event codes

The amount of possible codes for this event type is quite big. The only used
ones are the following ones.

0x00

REL_X - Acceleration in x direction

0x01

REL_Y - Acceleration in y direction

0x02

REL_Z - Acceleration in z direction

The X, Y and Z axis are to be understand as defined in the chapter about Axis orientation.

A typical message block

A typical message block consists of 3 messages containing the acceleration
data for every of the three axis followed by a syncronization message to
signal the end of the block.

The following example is such a message block with detailed explanation of its
different messages and data sections.

Absolute movement event codes

Although the information is the same as before, the absolute interface differs from the relative one by the fact that
only changed values are reported. So if the phone was completely idle, experiencing exactly the same acceleration from
one sample to the next, you will read only synchronization events (this will not happen due to noise, though).

So when you miss the value for an axis between two synchronization events, just assume the previous value still holds.