Accelerometer

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.)

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 (will change for C1) 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 '100\n' or '400\n' to rate,
• the sensor will be powered down about five seconds after last access.

Internals

According to the data sheet, the sensor generates samples at either 100 Hz or 400 Hz (will change for C1). 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.

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.

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 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.

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.

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 includes a thermal sensor.

References

• runin-accelerometer script for testing data stream from accelerometer,
• roller command in OpenFirmware,
• test /accelerometer command in OpenFirmware,
• lis3lv02d.c in kernel source,
• slowing down the data rate as fix for #11041