Accelerometer

An accelerometer is built into the XO-1.75 and XO-4. 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 Open Firmware 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 Open Firmware 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.

(To test the test by forcing a fail, short the G_SENSOR_SDA signal to ground. See a photograph for locating the bus test points on an XO-1.75. The device is within an inch of the SD card slot pinout.)

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 (PDF), 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

• runin-accelerometer script for testing data stream from accelerometer,
• acctest.py a simpler script for reading data from accelerometer
• TurtleBlocks has an accelerometer plugin
• roller command in Open Firmware,
• test /accelerometer command in Open Firmware,
• lis3lv02d.c in kernel source,
• slowing down the data rate as fix for #11041