You're right that the battery level affects the readings, but I wouldn't call the situation better, just different. Fresh battery yields:
Average light at 0.5 Hz: 0.61942668876
Average light at 1 Hz: 0.61750315656
Average light at 10 Hz: 0.63999368686
Average light at 25 Hz: 0.69513494318
Average light at 100 Hz: 0.74657709911
The curve is quite different than at low battery, but there still is a curve - a side effect I didn't expect.
The 1 kHz was just an experiment (there's a 200 Hz theoretical maximum anyway).
Anyway, no big deal, just the same realization as in the magnetometer/battery post: the Espruino API is a very thin wrapper around low level calls, and doesn't provide much of a reliability layer.
That is not a problem, just something that perhaps should be acknowledged.
I'm perhaps in the minority, but I'm not too interested in tinkering with low level electronics, but rather using Puck as an HCI device. Use cases in that sphere are somewhat limited by the "unreliable" nature of electronics (unless handled and accounted for).
One example use case: I intended to implement a variable-rate light detection as a power-saving measure for my Proximity module.
Espruino is a JavaScript interpreter for low-power Microcontrollers. This site is both a support community for Espruino and a place to share what you are working on.
You're right that the battery level affects the readings, but I wouldn't call the situation better, just different. Fresh battery yields:
The curve is quite different than at low battery, but there still is a curve - a side effect I didn't expect.
The 1 kHz was just an experiment (there's a 200 Hz theoretical maximum anyway).
Anyway, no big deal, just the same realization as in the magnetometer/battery post: the Espruino API is a very thin wrapper around low level calls, and doesn't provide much of a reliability layer.
That is not a problem, just something that perhaps should be acknowledged.
I'm perhaps in the minority, but I'm not too interested in tinkering with low level electronics, but rather using Puck as an HCI device. Use cases in that sphere are somewhat limited by the "unreliable" nature of electronics (unless handled and accounted for).
One example use case: I intended to implement a variable-rate light detection as a power-saving measure for my Proximity module.