Accelerometer: Difference between revisions

From OLPC
Jump to navigation Jump to search
No edit summary
No edit summary
Line 1: Line 1:
An accelerometer is built into the XO-1.75. It measures acceleration due to gravity, the learner, and other forces.
An accelerometer is built into the XO-1.75. It measures acceleration due to gravity, the learner, and other forces.


(XO-1.75 A2 and A3 were the first prototypes with accelerometers. XO-1.75 B1 has a restricted form of the feature, where the speed is limited. XO-1.75 C1 has a different accelerometer.)
(XO-1.75 A2 and A3 were the first prototypes with accelerometers. XO-1.75 B1 has a restricted form of the feature, where the speed is limited. XO-1.75 C1 has a different accelerometer with higher speed and resolution.)


== Testing ==
== Testing ==
Line 11: Line 11:
== Programming ==
== Programming ==


* your program must read /sys/devices/platform/lis3lv02d/position <font color="red">(will change for C1)</font> and parse the (x,y,z) result,
* your program must read ''/sys/devices/platform/lis3lv02d/position'' and parse the (x,y,z) result,
* your program should avoid reading ''position'' at a rate more than the sample rate the sensor is configured for, unless you don't mind receiving the same sample again,
* your program should avoid reading ''position'' at a rate more than the sample rate the sensor is configured for, unless you don't mind receiving the same sample again,
* your program will not be told of an overrun or underrun condition,
* your program will not be told of an overrun or underrun condition,
* to change the sample rate, write '100\n' or '400\n' to ''rate'',
* to change the sample rate, write one of the defined rates to ''/sys/devices/platform/lis3lv02d/rate'',
* the sensor will be powered down about five seconds after last access.
* the sensor will be powered down about five seconds after last access.


== Internals ==
== Internals ==


According to the data sheet, the sensor generates samples at either 100 Hz or 400 Hz <font color="red">(will change for C1)</font>. The samples are moved into the registers. The driver we are using will read the registers at any frequency, above or below the sample frequency.
According to the data sheet, the sensor generates samples at the selected sample rate:


* for XO-1.75 C1, the available sample rates are 1, 10, 25, 50, 100, 200, 400, 1600, and 5000 Hz,
⚫
If we read at a frequency below the sample frequency, then there will be an occasional harmless and undetected overrun condition and we'll get a new sample each time.
* for XO-1.75 B1, the available sample rates are 100, and 400 Hz.


The samples are moved into the device registers. The driver we are using will read the registers at about 25 Hz, which may be above or below the sample frequency.
⚫
If we read at a frequency above the sample frequency, then we get consecutive samples; a series of samples of the same value. Because the new sample has not yet arrived.


⚫
If we read at a frequency below the sample frequency, then there will be an occasional harmless and undetected overrun condition and we'll get a new sample each time. This will result in data loss.
We've checked for consecutive identical samples using a Python script. On an XO-1.75 A3, with the sensor configured for the default 100 Hz sample rate, we get roughly five or six consecutive samples before a change. At 400 Hz sample rate, we usually get a different sample each time, but half the time get a repeat.


⚫
If we read at a frequency above the sample frequency, then we get consecutive samples; a series of samples of the same value. Because the new sample has not yet arrived.
We've checked how fast a Python script can fetch samples, despite the underrun. On an idle XO-1.75 A3 the rate is about 970 samples per second. Hence the five or six consecutive samples before a change at 100 Hz sample rate.


The Linux driver we are using pays no attention to, and does not expose, the status register in the sensor. If it did, then we could defer a read of sysfs position until the next sample is available. This timing information may become important later.
(The Linux driver we are using pays no attention to, and does not expose, the status register in the sensor. If it did, then we could defer a read of sysfs position until the next sample is available. This timing information may become important later.)


== XO-1.75 B1 Restriction ==
== XO-1.75 B1 Restriction ==
Line 39: Line 40:
The missing pullup resistors were added, and the accelerometer device changed for a different model.
The missing pullup resistors were added, and the accelerometer device changed for a different model.


The new accelerometer includes a thermal sensor.
The new accelerometer is faster, has a greater resolution, and includes a thermal sensor.


== References ==
== References ==

Revision as of 00:42, 1 November 2011

An accelerometer is built into the XO-1.75. It measures acceleration due to gravity, the learner, and other forces.

(XO-1.75 A2 and A3 were the first prototypes with accelerometers. XO-1.75 B1 has a restricted form of the feature, where the speed is limited. XO-1.75 C1 has a different accelerometer with higher speed and resolution.)

Testing

In OpenFirmware at the Ok prompt, type roller and press enter. A ball will appear on screen, and the ball will fall according to the tilt experienced by the sensor. Press any key to exit.

In OpenFirmware at the Ok prompt, type test /accelerometer and press enter. This uses the sensor's self test function to apply an internal force, and checks that the result is not beyond a reasonable value.

Programming

  • your program must read /sys/devices/platform/lis3lv02d/position and parse the (x,y,z) result,
  • your program should avoid reading position at a rate more than the sample rate the sensor is configured for, unless you don't mind receiving the same sample again,
  • your program will not be told of an overrun or underrun condition,
  • to change the sample rate, write one of the defined rates to /sys/devices/platform/lis3lv02d/rate,
  • the sensor will be powered down about five seconds after last access.

Internals

According to the data sheet, the sensor generates samples at the selected sample rate:

  • for XO-1.75 C1, the available sample rates are 1, 10, 25, 50, 100, 200, 400, 1600, and 5000 Hz,
  • for XO-1.75 B1, the available sample rates are 100, and 400 Hz.

The samples are moved into the device registers. The driver we are using will read the registers at about 25 Hz, which may be above or below the sample frequency.

If we read at a frequency below the sample frequency, then there will be an occasional harmless and undetected overrun condition and we'll get a new sample each time. This will result in data loss.

If we read at a frequency above the sample frequency, then we get consecutive samples; a series of samples of the same value. Because the new sample has not yet arrived.

(The Linux driver we are using pays no attention to, and does not expose, the status register in the sensor. If it did, then we could defer a read of sysfs position until the next sample is available. This timing information may become important later.)

XO-1.75 B1 Restriction

Due to missing pullup resistor <trac>11041</trac>, on an XO-1.75 B1 the data rate between the sensor and the CPU has been constrained by kernel driver to about 30 samples per second. This directly affects the read rate from sysfs. Therefore undetected overrun always occurs, and there is no advantage to increasing the sensor sample rate to 400. This is expected to be fixed in a later hardware revision.

XO-1.75 C1 Changes

The missing pullup resistors were added, and the accelerometer device changed for a different model.

The new accelerometer is faster, has a greater resolution, and includes a thermal sensor.

References

Retrieved from "http://wiki.laptop.org/mediawiki/index.php?title=Accelerometer&oldid=262213"