Increasing accuracy of Puck.light()

[espruino-discuss]

Posted at 2017-03-07 by oesterle

@gfwilliams, Puck.light() is returning lower values than expected after the first call. Probably because I'm lighting up LED1.

Short story: I think this can be fixed by extending the settling time delay in jswrap_puck_light().

I type this in the console, and I get:

>LED1.write(1);
=undefined
>LED1.write(0);
=undefined
>Puck.light()
=0.15357589721
>Puck.light()
=0.55925130844
>

The last 0.559 reading is the most accurate.

Here's my workaround that gives consistent light readings:

var checkLight = function(){
  digitalWrite(LED1,0);
  analogRead(LED1);
  delay(50);
  light = analogRead(LED1) * NRF.getBattery() / (3 * 0.45);
  light = Math.round(light * 100);
  if (light < 20){
    console.log("  Seems pretty dark in here: " + light + "% brightness");
  } else {
    console.log("  Seems light in here: " + light + "% brightness");
  }
};

var delay = function(milliseconds){
  // Always try to use setTimeout or setInterval instead
  // of this function. This function, used for long periods
  // uses battery power!
  
  var timeout = new Date().ms + milliseconds;
  while(new Date().ms < timeout);
};

Like your C code for jswrap_puck_light(), I reset the LED1 pin, take a reading, wait, and take another (better) reading. But I wait 50 milliseconds, rather than 5 milliseconds.

[gfwilliams]

Posted at 2017-03-07 by @gfwilliams

Thanks!

Are you using an up to date firmware though? I just tried here and I don't seem to be able to reproduce it...

>LED1.write(1);
=undefined
>LED1.write(0);
=undefined
>Puck.light()
=0.66570218404
>Puck.light()
=0.64452409744

It's possible that the older firmware is using different code that doesn't have any delay in it at all?

[espruino-discuss]

Posted at 2017-03-07 by oesterle

@gfwilliams, process.version = "1v91".

I'm also doing analogWrite(LED1, xxx) elsewhere in my code, if that makes a difference.

[gfwilliams]

Posted at 2017-03-07 by @gfwilliams

I'm also doing analogWrite(LED1, xxx) elsewhere in my code, if that makes a difference.

Ahh, you didn't mention that bit ;) Just normal analogWrite, or the forced software version?

Did you experiment with different timeouts? I'm not sure how I feel about this - making Puck.light 10 times slower just to deal with the very first reading in the case where someone is using analogWrite and Puck.light may not actually be in most people's best interests :)

[espruino-discuss]

Posted at 2017-03-08 by oesterle

I called it exactly as above, not with the forceSoft option.

I tried different timeouts; 50ms seemed the minimum in my code to get consistency. I'm fine with a 1/20 second reading in my use case. You also mention not taking more than 5 readings/second, so that's a gating factor, anyway.

You could also have a highAccuracy option (or simple Boolean) in Puck.light(), that when present, adds a bit more delay.

I'm using this, BTW, in a kitchen-sink app that exercises all the sensors, incl NFC, and the RGB LEDs. I'll share that here soon.

[gfwilliams]

Posted at 2017-03-08 by @gfwilliams

I guess maybe the thing to do would be to detect of the pin state was af_output, and if so to wait the full 50ms - otherwise just the 5ms should do it.

[espruino-discuss]

Posted at 2017-03-08 by oesterle

That sounds like an elegant solution – especially as it requires no user attention.

[gfwilliams]

Posted at 2017-03-08 by @gfwilliams

I did that today, so it'll be in the 1v92 release :)