Puck.light values depend on how often it's called

The subject says it all - I get different light sensor readings depending on how frequently I call Puck.light().

These are measured in constant lighting conditions:

Average light at 0.5 Hz: 0.60877327967
Average light at 1 Hz: 0.61237373737
Average light at 10 Hz: 0.34283262310
Average light at 25 Hz: 0.39304174558
Average light at 100 Hz: 0.46682646780
Average light at 1000 Hz: 0.50218986742

The values seem to be roughly:

• at a maximum when below 1 Hz,
  
• at a minimum at ~10 Hz,
  
• rising (up to some limit) when above 10 Hz.
  
  

Using the following code:

ITER=10;
var experiment = function(dly) {
  var arr = [];
  var f = function(c) {
    arr[c] = Puck.light();
    if (c<ITER) setTimeout(f,dly,c+1);
  };
  setTimeout(()=>console.log("Average light at " + Math.round(100000/dly)/100+ " Hz: "+E.sum(arr)/arr.length),(ITER)*dly+50);
  f(0);
};

experiment(100); // set the argument to number of milliseconds between readings

Any ideas why this is happening?

I think the light sensor on the puck is an LED (http://makezine.com/projects/make-36-boards/how-to-use-leds-to-detect-light/) so maybe the sampling frequency is much lower than a dedicated oscillator style sensor like the TSL2591?

@catmapper Yes, light is detected by the red LED, that's confirmed in documentation.
That still doesn't explain the behaviour though.

I also noticed the readings "lag" behind the actual lighting conditions. If you rapidly reduce/increase light (e.g. turn on/off a lamp), you're gonna see gradually increasing/decreasing readings over several Puck.light calls, not an immediate spike.

I suppose those behaviours (frequency-dependent values and lagging) are somehow related, but my understanding of physical/electronic principles is very limited, so I'm looking for some layman's explanation...

Looking at your other post with the low battery level, I wonder whether this could be related to that.

A higher polling rate will draw much more power from the battery (at 1000Hz you're looking at 4mA probably), which will drop the battery voltage, which will in turn cause the readings from the ADC to change.

If that's correct then a newer battery would make the situation better, but I could also see if I could add some kind of adjustment for battery voltage to the Puck.light() function.

Having said that, reading the light sensor that often is going to drain your battery extremely quickly - so I wouldn't recommend doing it apart from for testing purposes :)

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.

Ultimately Espruino should provide enough of a wrapper around things that the majority of people don't hit these gotchas. Having to worry about flat batteries is a new thing for me (previously everything was regulated to 3.3v so pretty much either everything worked or it didn't).

At some point you're always going to hit low-level issues (you do with PCs too - it's just a lot further down the line!) - hopefully Espruino makes it less painful when you do hit them though... For instance using normal compiled code with the magnetometer you'd have very little idea of whether the whole thing had crashed or whether it was just the magnetometer.

I'll have a quick look at the light issue this morning - hopefully it'll be quite an easy fix.