Yeah, I guess I was looking at one-off pricing. Drops pretty steep at 25 or so pieces…
Here is a plot of what happens to the LED color of a 3200K 6W MR16 bulb as it heats up. The plots are of each color channel reading divided by the sum of the RED, GREEN, and BLUE channels multiplied by 100.0 to get a percentage. Note that the RED band barely changes, BLUE increases, and GREEN decreases. The white plot is the WHITE channel tracks the lux sensor rather well.
Nope, it turned out to be an aliasing problem due to undersampling the pulsed PWM signal on the current sensor. A filter on the current sensor output cured all the problems.
I put my Tek clamp-on current probes on the signals and saw no problems with the signals. Then I put a scope on the signals and saw the pulsed 8 kHz PWM signal that was being sampled at 1 kHz. Next I substituted a signal generator for the current sensor and was able to duplicate the problem by tweaking the signal generator frequency.
I’ve been playing more with the color sensor. It does look like it will be able to estimate color temperature. I ran a couple dozen different lights on it and the ratio between the red and blue channels looks promising. Actually, just the red channel alone correlates pretty well. I need to write some code and slice and dice the numbers to see what works best. One problem is knowing what the color temperature of the lights that I have actually is. And it would be nice to have some lights in the 8000K-20000K range to test the high end.
Woo hoo!!! It measures color temperature! And seems to do it quite well. I am taking the ratio of the red and blue channels from the color sensor and processing it into a color temperature. The conversion is done by interpolating between the readings produced by some “known” color temperature lights. The results seem to be quite realistic and repeatable.
Here is a plot of a warm white Bridgelux array:
What is rather interesting is how the light output increases right after the LED is powered on. This is the only LED that I have seen that does it. It is driven by a fixed voltage (14V) ballasted by a power resistor. The light change is apparently not due to current shifts as the resistor heats since the current plot does not follow the LED output. Ignore this LED Vf / current / efficiency numbers since those sensors were not connected.
Again, the “ref” values are those at the center line of the plot area. The values shown in the line below the “Cursor time” line are those where “X” marks the spot in the plots.
That is awesome texaspyro! Gotta love the progress!
Can I ask what light source you are using and what the light temperature is supposed to be?
That example was a warm white Bridgelux BXRA-W0802 array. They spec it at 2850K-3700K, 3000K typical. This one seems on the low end of that range. It is rather warm color compared to some 3000K lights that I have.
One problem with coming up with some decent calibration sources is the HUGE range that LED makers specify for their possible color temperature. Come on now… 2850K-3700K… give me a break.
For now, my calibration table uses about eight different lights. I am assuming that their color temps are the “typical” values in the data sheet. I also have the sun in there. I am going to order some LEDs in the 7000K…20000K range to fill out the high end. I even have a long wave UV light in there, but don’t know what color temp it is supposed to be. It’s in there as a upper range test case. I think that I said it is 40000K
Wow! I knew some serious effort would go into this but apparently my imagination came up short when it came to all those nitty gritty details. Thank you for explaining this ;-)
I’ve been playing some more with the idea of using just the color sensor chip for doing lux/lumen measurements. I really like that Rohm lux sensor chip, but it is a 3 volt only part and interfacing it to a 5V micro is inelegant. Also it is in a itsy bitsy teeny weenie package that is a royal PITA to solder.
The problem with the color sensor chip is that its sensors saturate at a light level that is a lot less than the Rohm chip so that limits how bright a light you can use. So far, the only light that I have that saturates it is the Old-Lumens Luminus Light Lobber From Lucifer. The good news is that Taos has a version of the color sensor chip that can handle about three times as much light as the one that I am using now.
Another thing about the color sensor chip is that the color filters pass some near-infrared light. Not an issue working with visible light LEDs (they don’t put out any IR), but if you wanted to measure incandescent bulbs (they spew IR light with gay abandon) you would need to add an IR cutoff filter in front of the sensor.
I cut a 4” hole in that 16” sphere that I got from Barnards. It takes up most of the flat spot at the top of one half of the sphere. Then I removed the sheen from the inside of the spheres using 400 grit sandpaper and installed a lux sensor and small baffle. It works VERY well for smearing the light around. Even with the flat spot on the other half of the sphere, the lux reading varies well under than 1% no matter where you shine the light in the sphere or place it in the hole.
Unfortunately, it works too well! My old box arrangement was giving around 1 lux per lumen. The sphere gives around 52 lux/lumen!! That causes the Taos color sensor to saturate with even fairly dim lights (a few hundred lumens). A neutral density filter might be needed.
I’m not sure where the Rohm lux sensor saturates, but I suspect that three thousand lumens would probably max it out. They spec it to 65536 lux max, but it has a low res mode that may be able to double that. Or not.
I’m also seeing some funky numbers with dim (< 50 lux) lights. For instance, a Quark Mini123 S2 spec’d at 8/43/135 lumens is measuring out at 3/28/133 lumens.
I tried reducing the sensitivity of the light sensor chip by changing the timing register. That helps a bunch. Still running it in high-res mode I was able to monitor a Bridgelux BXRA-C8000 array running at 64 watts/5900 lumens. The light chip also has a low-res mode that may be able to extend the range even more.
Another thing that I tried was mounting the light sensor to the outside of the sphere, using the sphere wall has a filter. That yielded a max range in excess of 100,000 lumens using the original timing register value.
In this run, the color sensor was mounted to the outside of the sphere. Even then, the clear channel was saturating… it’s very sensitive. That middle column of numbers is some testing of alternate ways of calculating color temperature.
Here is a plot of the 6000 lumen test. Note that the temperature reading is wrong. The cooling fan on the Bridgelux heatsink seems to mess up the thermocouple. Same thing happens with those 10 W Philips MR16 bulbs with the built in cooling fan… bummer. Also note the built in calendar routines have an extensive list of common and not so common holidays and special occasions.
^You misspelled yom kippur, it has a u not an e.
it’s the Northern English version of that Jewish holiday, often served with chips/ fries 
It now spells Kippur correctly… Oy, vey! The Jewish calendar is a nightmare. But, at least you know when things are in advance. The Islamic calendar can only be determined after the fact… it is based upon when the crescent moon is actually observed.
I added a filter cap across the thermocouple leads. That got rid of the fan noise issues.
I learn something every day - never knew that about the Islamic calendar. We already have Gregorian, Jewish and Chinese calendars, adding another one would be crazy!
Druid, 6 types of Aztec and Mayan calandars, Persian, Indian, and a half dozen more are supported…
wow! I might need to buy one just for the calendar function 
The code for the Windows control program is based up “Lady Heather’s GPS Disciplined Oscillator Control Prorgam”. It is used to control and optimize the operation of Trimble GPSDOs such as the Thunderbolt. These use the GPS satellites to steer the frequency of very precision oscillators that produce VERY precise 10 MHz signals (accurate to better than 1 part per trillion) a 1 pulse-per-second signals (accurate to 1 nanosecond). There are many very advanced and several trivial/stupid features built in.
One neat feature is the ability to access the device from anywhere in the world via the interwebs. You can download the program from Lady Heather's Disciplined Oscillator Control Program John Miles keeps a publicly accessible Thunderbolt online at most times.
The program is over 30,000 lines long and used by thousands of people worldwide. It’s way cool, if I do say so myself. 
You should consider Kickstarter for this if funding the fixed costs is an issue.
While playing with some home lighting replacement LED bulbs I noticed that quite a few of them had a noticeable wave superimposed on the lumen plots. A little poking around showed that it is actually due to 60/120 Hz flicker on the light output. Typically its amplitude runs around 3-10% of the total light output. The way the light sensor sensor converts the incoming light to a digital value winds up aliasing this flicker frequency down to a lower frequency which shows up very well in the lumen plots.
Here is a bulb with a particularly good example of flicker (which is not noticeable at all to the naked eye). The actual flicker level is around 6% of total light output.:
