Ambient light sensing via LED response

John Watlington wad at
Sat May 2 00:27:14 EDT 2009

The back-bias voltage is a sensitive topic.
If you could guarantee periodic clearing of the integrator,
I could provide up to 10V or so.   Otherwise, it should
probably be limited to +3.3V.


On May 1, 2009, at 11:59 PM, John Watlington wrote:

> On May 1, 2009, at 2:28 PM, C. Scott Ananian wrote:
>> On Tue, Apr 28, 2009 at 8:38 PM, John Watlington <wad at>  
>> wrote:
>> > I don't have time to take a look at this right now,
>> > but we have a A/D input to dedicate to this, if it helps work  
>> around
>> > the patent.
>> >
>> > We can talk to MERL if needed.   I probably still know a handfull
>> > of people around there.
>> Oh, yeah, you should be able to wire the top side of the LED  
>> directly to the LED and measure the photovoltaic current directly;  
>> that's not patented:
>>                   battery voltage
>>               Q1  |
>> ---from EC------|< _____ to A/D
>>                   |
>>              LED  V
>>                   |
>>                  GND
>> The only question is whether the LED can put out enough  
>> photovoltaic current to be reliably measured by the A/D.
> Ahh, therein lies the challenge!
>> Depends on what the input to the A/D looks like, how much  
>> capacitance it sees, etc.
> Thought the KB3700 (EC) A/D datasheet frustratingly doesn't list  
> any such exotic parameter
> as input impedance, I asked ENE and they said that the input was  
> high impedance CMOS
> (think a MOSFET gate, in the wee, wee microamps).   The impedance  
> also does not vary
> (even though the A/D is muxed).
>> An ultralow power versoin of the 339 could fix any problems there,  
>> but then your parts count increases.
> Sorry, no parts count increases allowed except for one LED,  
> resistors, capacitors (basically free), and maybe
> one transistor, diode, or NMOS MOSFET (about a penny).   I will  
> throw in a couple of EC digital outputs, and
> a day of Richard's time in EC code.
>> You don't *have* to reverse-bias the LED; that just enhances  
>> sensitivity, but distinguishing between
>> "outside on a sunny day" and "inside" doesn't exactly require  
>> precision; there's at least an order of
>> magnitude change in illumination, maybe 2 ( 
>> wiki/Lux).
> I haven't read the patent, but the advantage to a digitally  
> controlled time integration A/D has always
> been a high dynamic range by changing the time scale.  I'll let the  
> community suggest this
> circuit/algorithm.   Someone practiced in the arts might suggest  
> measuring the integration of
> the reverse leakage current over time, using a digital output to  
> clear the integrator, allowing
> software to control the time period over which the current is  
> integrated to increase the range.
> In response to earlier mails on this topic:  the microphone/camera  
> LEDs are inviolate.
> ( Ivan got this one right! )   I will not allow software  
> interference with those LEDs.
> The power savings resulting from switching the LEDs was significant  
> in Gen 1 (on the order of
> 50 mW in run/suspend).  Even after adding this feature, it will  
> have to be integrated into Ohm
> and the Control Panel before being useful in power savings.
> By the way, has anyone really thought about this feature ?  I grok  
> the intent, but you have to make
> sure that kids who happen to be in brightly lit rooms (glaring  
> fluourescents aren't uncommon)
> don't loose their backlight, and wonder why ?   The keyboard  
> lighting on my mac is a good idea,
> but they only allow adjusting the amount of light output, not the  
> sensitivity to ambient light.
> And the Mac's light sensor is annoyingly placed where hand movement  
> during typing may occlude it,
> something we should be able to avoid...
> The light pipes for most LEDs, however, are quite large.  I believe  
> that a second LED
> could be positioned next to an output LED, under a light pipe.     
> Perhaps the battery LED is
> the best candidate, since it is usually not lit when operating from  
> the battery.
> Cheers,
> wad

More information about the Devel mailing list