Light Sensor

A light sensor is built into the XO-1.75. It measures the amount of light reaching the laptop from outside.

XO-1.75 C1 has the sensor is next to the storage indicator. Any use of the wireless activity indicator or the panel backlight affects the readings. The storage indicator is turned off briefly during each sample capture.

XO-1.75 B1 has a restricted form of the feature, in that the wireless activity indicator is affected by the sensor, and any use of the storage indicator will affect the reading.

XO-1.75 A3 has a restricted form of the feature, in that the sensor is affected by the battery and power LED.

The sensor is managed by the embedded controller, and is averaged and updated at a rate that depends on the brightness of the light. Reading the averaged value can be done up to 213 times per second, but there is no great advantage to reading that quickly.

Testing

In OpenFirmware at the Ok prompt, type

ok als@ .d (cr  d# 200 ms  many

and press enter. The sensor readings will be displayed continuously, until you press a key.

(If you always get the same reading, please report the defect, and also type

ok test /leds

and observe the flashing pattern. Normal pattern on a B1 is wireless indicator bright, storage indicator bright, wireless indicator dim.)

Programming

The OLS kernel driver makes readings available two ways. All sysfs nodes mentioned here are under /sys/devices/platform/olpc-ols.0/.

• Brightness/Darkness state can be reported to user programs via a virtual switch input device. The name of the device is "OLPC OLS notify". The "low_lim" and "high_lim" sysfs nodes determine the bright and dark hysteresis points for this "switch". When OLS readings go lower than "low_lim", the "switch" closes. When the light goes away, causing readings to go higher than "high_lim", the "switch" opens.

• The current OLS reading is reported by the "level" sysfs node. Polling this node will give a stream of integer values, with lower values for brighter light. The readings returned are the actual time taken, in milliseconds, for the reverse-biased diode to discharge (see below). Readings may take many seconds when there is very little light. Readings are rate limited to no more than two per second. It's advantageous to limit the amount of time spent reading the light sensor, because time spent reading is time during which the storage LED can't blink (since it interferes with the reading). To keep readings short normally, but allow for full use of the sensor on demand, the longest reading the sensor driver will take is the maximum of "high_lim" and "ceiling". "high_lim" is the high hysteresis limit, currently set by powerd to 80, and "ceiling" is set by default to 0. Therefore, by default the highest reading returned by "level" will be 80 (actually, 81). If you want longer readings, e.g., if TurtleArt wants to get the full range of readings possible, TA needs to write a value to "ceiling". The absolute maximum value that can be written is 10000. Dark room readings are something like 5000.

The "power_state" sysfs node is identical to "level", and is deprecated.

Internals

The sensor is a reverse biased LED. The EC charges the LED as if it is a capacitor, and then times how long it takes to discharge. The discharge time is mostly related to the ambient light, and slightly related to operating temperature of the embedded controller.

XO-1.75 C1 Restriction

The sensor is adjacent to the storage indicator. The EC disables the storage indicator while taking a sample. The wireless indicator, if it is used, and the screen backlight, will affect the sample.

XO-1.75 B1 Restriction

The sensor is adjacent to the wireless indicator. The EC disables the wireless indicator while taking a sample. The storage indicator, if it is used, and the screen backlight, may affect the sample.

XO-1.75 A3 Restriction

The sensor is adjacent to the battery indicator, and as a result generates distorted samples when the laptop is connected to a DC power cable.

References

• runin-light-sensor script for testing data stream from sensor,
• kernel implementation first included in os40,
• embedded controller implementation,
• OpenFirmware implementation.