There are some very fast ones… S2829
that have their rise/fall times specified. They’re not horrendously expensive either. They’re designed for infrared, but they absolutely do pick up visible light well enough for this type of application (only looking for relative change)
Well, DC’ish… There’s always a bit of ripple, and that’s what I was wondering if your circuit was fast/sensitive enough to pick-up…
Seriously awesome project. Looks like you’ve cobbled a ton of functionality into this thing.
The Hammamatsu device has a 5 microsecond rise+fall time -> 200 kHz max freq. Thats probably on the high side of typical for a phototransistor. Also, it has zero sensitivity below 700 nm (where most visible LEDs have very little output). I need to do some spec searching for fast visible light phototransistors.
I tried replacing the LM741 op-amp with a much faster OP27. Then I tested it with that PT4415 based driver that I used on my desklamp retrofit (Nichia 219 Desk Lamp Retrofit) As I dimmed the driver, I could see a 112 kHz pwm rate.
Also, the phosphors used in white LEDs have some persistence. That could also limit the max PWM rate that one can see. I want to try driving a red LED (no phosphor) with a signal generator and see just how fast it can go.
I tried the red 5mm LED with the signal generator. I could get it to read up to 225 kHz, but one had to be really picky about the LED location and drive level. If you lost the signal at that freq you had to drop the freq back down to around 100 kHz for it to re-acquire. I figure the circuit is good to around 100 kHz, but probably 50 kHz is more realistic/robust with the phototransistor that I am using.
I hung a scope of the op-amp output. The limiting factor does not appear to be the photo-transistor but is the op-amp. I was seeing the signal way past 500 kHz, but it was not swinging above the counter-timer input threshold. Looks like a comparator (like the LM311) could improve things. They can handle of several MHz and not break a sweat.
I cobbled an LM311 comparator onto the circuit board. Works to 3 MHz if you futz with the LED drive. Pretty solid at 2 MHz. I am driving the 5mm red LED with a signal generator. The light is coupled to the phototransistor with a soda straw.
I also tried a white 5mm LED. It was good to around 2 MHz.
God, you’re right. I guess this explains why I shouldn’t post at 3am with one eye open. I read that 2+3us as ns instead of us….
I know they’ve got FAST ones… That’s just the wrong part number that I quoted… And actually, now that I really give it thought, I think their REALLY fast ones are Photodiodes, not Phototransistors… I’ll have to look at the schematic for photodetectors that I did a few years back tomorrow when I’m at the office - It’s been so long, I don’t even remember what was on it…
Yeah, PIN diodes are the way to go if you want fast (I’ve seen them used at 20+ GHZ). APD’s if you want sorta fast and sensitive. The biggest problem with photodiodes is the signal processing needed to get usable signals out of them. The biggest problems with phototransistors is that they are not very fast.
There is a little issue with the comparator version. If you shine a bright, DC driven light at it you can see some bogus frequency readings. The comparator is so sensitive that it starts reading noise on he phototransistor output. Maybe a little hysteresis feedback around the comparator will help with that? I’m out of high ohm resistors at the moment…
What about another RC filter on the ‘instant’ line similar to the ‘averaged’ line? Obviously much faster RC constant, but still, just a TINY bit of filtering might prevent the glitches….
I tried that and all it seemed to do was kill the max freq one could measure.
The problem with reading the PWM of a light that does not have any PWM is that the instant value and the average value are essentially the same. The comparator amplifies any noise on those lines and produces a false frequency value. I expected the problem from day one and was very pleasantly surprised (and a bit mystified) when I was not seeing it with the op-amp.
I also tried a divider on the average voltage to put some separation between the average and the instant. It worked to a point, but reduced the sensitivity and maximum freq response. And, with enough light, still made false readings.
I then added a 10 megohm feedback resistor from the comparator output to the “+” input to add some hysteresis. Volia! A SkyRay King on full blast was no problem. Max readable freq was still over 2 MHz.
I checked several single AA lights that have boost converters. I can see the driver switching freq (all were between 64 and 130 kHz. My Sipik clone was the only one that did not have a detectable switching freq. I did have to get the light rather close up and personal to the sensor (a few inches) to detect the signal… all these lights were less than 30 lumens.
With the PT4115E driver that I used in my desk lamp I hooked a scope across the LED. The waveform is a rather ragged sawtooth wave with spikes. At some dimming levels (those had a lot of noise on the LED waveform) the optically measured switching rate looked like it was 1.5 times the LED voltage waveform.
When I put a scope on the comparator output with the Sipik clone, I could carefully futz with the light position and see an 8 MHz waveform (too fast and low amplitude for the counter to count). I seriously doubt that the driver was switching anywhere near that fast… most likely it was threshold noise.
I found a problem on the PWM sensor board that I kludged together that was causing a lot of the noise issues and things like that 8 MHz waveform and ragged comparator output waveforms. The power supply bypass caps on the comparator were not soldered properly. One end was open circuit… no bypass at all. After I re-soldered it, a whole lot of crap went away.
Also, I don’t have to get the sensor as close to the light to measure the boost driver switching freqs. The readings are rock solid and flake free. I can measure a 10 lumen Fenix E01 from around a foot away (starts at 61 kHz and increases as the cell drains).
Bypass Caps… We don’t need to stinking bypass caps
I’m kind of a bad boy when it comes to schematic creation… I always put down the fundamentals and then go back and add the bypass caps, bulk storage caps, decoupling caps, etc later… I went on vacation one time, and someone decided to ‘help’ me by laying out the schematic I had been working on… Boards released to fab and all…
I get back, Look at board and think to myself… Wonder what that paper-weight cost… there isn’t a single bypass cap on it… Oh well, it was only 12 layers
Glad to hear you’ve got it working. That’s a pretty awesome thing to be able to measure without touching the circuit - no parasitics from scope probes or anything so you’re not changing things by measuring them…
Actually a quick question for ye - Could we use this system, or set it up in some fashion, that would allow us to accurately test battery voltages, lumens, temperature etc all at the same time? This would be handy for showing how a light performs over a period of time (normally cell voltage being the underlying factor) without having to repeat tests several times. I would have a very good reason to use this over the coming months so I'm super keen to get my hands on one...
Yeah, that’s measuring a boost driver switching freq.
It can measure the 2500 Hz PWM on a 10 lumen light around 3 feet away… and that’s in a room with 10,000 lumens of overhead lighting. Granted, each of those PWM pulses peaks at 150 lumens.
Anyway, it works a whole lot better than it has any right to…
I would be interesting to try it on something with a really high switching freq. My switchiest light is running at 132 KHz.
I’d also like to know why my Sipik clone has no measurable driver freq. I can’t believe that the Chinese would put a filter cap on a $5 (shipped) light.
I’m beginning to REALLY dislike whoever did the IIC interface to those Melexis MLX90614 IR thermometer chips. I hope his batteries run down in the middle of a SuperStorm of the Century Hurricane of Soggy New Englanders.
I was originally using a bit-banged IIC bus interface since the ATMEGA328 idiot designers (I hate you, too) put the hardware IIC interface on the same pins as two of the the ADC inputs. When I decided to use the ATMEGA1284, it has the IIC hardware interface on its own pins. Hooray, I’ll mod the code to use the hardware IIC interface.
Turns out the bastard MLX90614 likes to lock up the AVR hardware IIC interface. At the end of some random reading, it leaves the SDA data line pulled low. Voila, no more IIC communications. After a week of futzing with it, I finally got it to work reliably (hopefully) by turning off and back on the AVR IIC interface after each stop condition.
Oh, yeah… I also REALLY hate the bastards that designed the Corky toilet fill valve.
I finally figured out why the IR thermometer was locking up the IIC bus… When you read the temperature from the chip it gives you two bytes of data and a CRC error check byte. The IIC/SMBus spec (and some of their example code) says you can terminate a transmission early by NACKing the last byte you want and sending a STOP. Nope, that drives the little bugger insane and it freaks out. Since I wasn’t using the CRC byte, I didn’t waste time reading it. Now I read the CRC and all is well. Well, as well can be with a chip with a schitzo interface.
I also got in some new phototransistors to try with the PWM sensor. Those puppies can read out past past 4 MHz! They also seem to be a bit more sensitive. That does seem to make measuring buck/boost driver switching freqs a bit more fiddly. The optimum light position is more critical (you can’t just jam the light up against the sensor). But for 10 cents a pop, one can’t complain too much…
Question: How well would this device work if hooke dup to an integrating sphere? Could we permamently attach the light sensor to the sphere to get lumen/lux/PWM readings? Or does the light need to be shone directly at the sensor/s for most features to work?
