Puck.light values depend on how often it's called #1913
Replies: 5 comments
-
Posted at 2017-01-08 by catmapper 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? |
Beta Was this translation helpful? Give feedback.
-
Posted at 2017-01-08 by Ron @Catmapper Yes, light is detected by the red LED, that's confirmed in documentation. 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... |
Beta Was this translation helpful? Give feedback.
-
Posted at 2017-01-09 by @gfwilliams 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 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 :) |
Beta Was this translation helpful? Give feedback.
-
Posted at 2017-01-09 by Ron 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. 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. |
Beta Was this translation helpful? Give feedback.
-
Posted at 2017-01-10 by @gfwilliams 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. |
Beta Was this translation helpful? Give feedback.
-
Posted at 2017-01-08 by Ron
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:
The values seem to be roughly:
Using the following code:
Any ideas why this is happening?
Beta Was this translation helpful? Give feedback.
All reactions