3 Channel Driver

Remember that three watt led module I built a while back? Well, I finally got around to building a driver/interface for it so I can use it with my rgb led controller.

The time has come!

three channel constant current led driver

Specs:

Three LM317T adjustable voltage regulators, configured in constant current variable voltage mode.
Six one-watt 10 ohm resistors, wired in parallel for 5 ohm loads on the adjust pin of the regulator.
Three 1uF smoothing capacitors on the regulator output, one 100nF filter capacitor on the power connection.

Each channel is configured for 250 mA, which is 100 ma less than my leds can handle, but, this is good enough for a start – I have proper sized resistors on order. I will probably make a PCB for the second iteration of this project, and I’ll be using a single resistor instead of two in parallel.

The six pin connector goes to the LED module, the five pin connector is the power and control lines from my rgb led controller.

protoboard solder three channel constant current led driver

I started out by laying out the three biggest components of the project, and getting them secured to the protoboard. I’m using a protoboard with two supply busses on it, they’ll come in handy for carrying nearly an amp of current to my regulators. You can see the Vin pins of the regulators all bent ‘up’, overlapping the central power bus.

one watt resistors lm317 voltage regulator constant current led driver

Now for some resistors. These resistors set the current output based on voltage on the adjust pin. You can clearly see two 10 ohms resistors. I have wired these in parallel, giving me a result of 5 ohms, which sets the drive current at 0.250 A

protoboard solder constant current led driver

The beginning of the soldering; tacking parts down one at a time.

lm317t constant current led driver wiring

These three red wires each carry the drive current for one color, red, green and blue to the led module connector.

three channel constant current led driver molex kk connectors

Same wires, different angle!

three channel constant current led driver LM317T

I’ve installed some 1uf smoothing capacitors and a 100nF filter capacitor as per the LM317T datasheet… they help make the leds fade smoother under PWM control.

I’ve got a haloween task planned for this driver, stay tuned!

LED Sensors II

Having spent only a few hours cooking up the first vb app to talk to my array, I shouldn’t be surprised that its performance was rather lack luster, not to mention the wiggly lines on the bar graph although visually stimulating really offered nothing in terms of interpretation.

visual basic led sensor data analysis

Here is a view of the new application… I’ve re-designed a good deal of the internals, and changed the graph around so it represents more clearly the data being received from the array. Each row in the bargraph represents a row in the array, and the height of each bar indicates the amount of light the sensor is receiving.

So as I interact with the array, the bars follow along.

LED Sensors

Things are moving along … With my new understanding of I2C master/slave communications, I’ve started work on larger arrays and finding the best way to manage the array and communicate the data to the host PC.

led sensor array breadboard microcontroller pic

Above is the latest iteration of the project… and here is a lengthy description of what you’re seeing:

Along the top row you see six ICs, from left to right they are:

(hehe, I bet you’re thinking, I only see four ICs … well, there are six, trust me)

#1
Power Supply – 7805 – This is a regulated 5 volt power supply, with some filter caps, buffering caps and a power-on led. The 7805 is infact an integerated circuit, just disguised as a transistor.

#2
“SlaveA” – PIC16F876A – This is one of my slave microcontrollers … it autonomously scans its row (the bottom row) in the array with blistering speed, approx 500 uSec per pixel in the array, so 2 mSec total – which is kind of slow actually, as I add more lights to the array, the responsiveness of the array grows … I can probably shorten my sample time now. The blue LED indicates the slave is operational and the program is running.

#3
“SlaveB” – PIC16F876A – This is the second slave microcontroller, which scans the top row of leds. It is running the same program as SlaveA, but with a different slave address.

#4
“Master” – PIC18F252 – This is the third microcontroller, playing the master roll. It polls the slaves every 100msec for an update, and feeds that data to the host PC. This microcontroller is severe overkill for the job its doing, but these are the PICs i had on hand, so thats how the chips fell (har har har). The blue led indicates the master is polling a slave (in real-time, the led blinks very fast)

#5
“Clock” – DS1065T-060 – This is a digital clock generator from Dallas. It is programmed to generate any clock frequency I want, currently provideing a 20mHz clock that is used by all three pics. Although not as accurate as a crystal, it does provide better temperature stability … the only reason I am using it is to save board space (and the fact I obtained a sample of one from Maxim a long time ago but never used it) … three separate crystals and their associated load capacitors would have taken up way too much board space. The DS1065 is the first TO-92 package (on the left). Next to it is a regular 2n2222 transistor which controls the MCLR (reset) line on the slaves)

#6
“Interface” – MAX233 – This is a Maxim RS232 line driver IC … The MAX233 is very similar to the popular MAX232 except it requires no external capacitors for its voltage doubler circuit, again to save board space. This chip boosts the cmos level serial data from the “master” pic to TTL level for transmission to the host pc.

Operation of the slaves:

Each slave normally runs in a infinite loop, sampling the LED sensors as fast as it can and storing their values in a memory buffer. When a polling request is received from the master, an interrupt is generated which branches out of the sampling loop. I2C commands are pretty complex on paper, but merely a matter of setting and clearing bits in the digital world, so at 20mHz the pic handles them with lightning speed. Here is the blow by blow of the most complex series of commands, a multi-byte read

1) Master sets a “start condition” which basicly places a certain state on the bus

2) Master sends the slave address onto the bus with the read flag cleared… a slave address is the seven most significant bits of a byte (7:1), with the least signifcant bit (0) reserved for a read flag.

3) The I2C hardware in the slaves simultaniously receive this address, and compare it to their internally programmed addresses. The slave matching the address then sends an acknowledge bit on the bus.

4) Master receives the acknowledge bit and sends a command byte. Since the start condition is still present, the last slave addressed acknowledges receipt of the byte by sending an ack bit. This command byte is $04 in my application.

5) Slave receives the command, executes it and sends an acknowledge. The command $04 tells the slave to copy the ADC buffer to the transmit buffer.

5) Master receives the ack and sets a “restart condition”, which causes all the slaves to actively watch the bus for a slave address.

6) Master sends the slave address this time with the read flag set.

7) Slave matching the address sends an acknowledge. It then sends the first byte of the transmit buffer, without further prompting from the master.

8) Master receives the first data byte, and stores it in the receive buffer. The master sends an acknowledge.

9) The slave last addressed (since bus state is still START) sends the second byte in its transmit buffer.

10) Master receives the byte, stores it in its buffer, and sends an ack.

11) steps 9 and 10 repeat until the master sends an NACK and sets the bus state to STOP. This tells the slave to stop sending bytes.

each of these steps takes a tiny fraction of a second … the entire transaction is comprised of a multitude of commands and data going both ways and is finished in the blink of an eye, indicated by a fast flashing of the masters’ status led, which blinks twice (once for each slave), but the blinking repeats so fast, it looks as if the led is solid on.

If you’ve made it this far, congrats!

It is interesting to point out (not that I’ve seen any evidence of it on the host pc), that there is some lag introduced by the i2c routines in the ADC sampling process. Since i2c transactions are not just simple “one shot” commands, the slave is continuing to do ADC sampling while waiting for the next event from the master. This is acheived through the use of interrupts. whenever the slave is in the ADC loop, it gets pulled out to talk to the master, but since each time it talks to the master is only a very brief instant, its spending 99% of its time in the ADC loop. however, by me copying the ADC buffers to a transmit buffer only once during a transaction, the data in the buffer is ‘stale’ by the time it gets requested by the master. I’m going to look into ways of directly interfacing the i2c routines with the ADC buffers, which should let the master receive the freshest data possible. The problem here is, the ADC buffer is eight double-byte (word) values (only which four are actually used) but the transmit buffer is sixteen single-byte values, since the i2c protocol deals strictly with bytes. so the command to copy the adc buffer actually breaks the words into bytes to store in the transmit buffer. If I wanted to use the array to detect fast moving objects this would be important, but it responds to human interaction quite nicely now, even with the 100msec sampling delay imposed by visual basic. I think is due to the fact that the ‘missed’ samples are discarded instead of buffered, so the PC is still receiving real-time data from the array, just not very fast.

A fresh order of more LEDs has arrived, so I’ll be building up a much larger led array.

I2C Slavery

*Blah*

Pulling “all night” (and well into the morning) programming sessions ain’t as easy on the body as it was back in my college days.

But, with approximately 16 hours coding time, I have mastered the ‘art’ of i2c slavery on the picmicro.

I2C stands for inter-ic communications. It is something Philips cooked up mainly to allow microprocessors to communicate with other devices on the board, as sort of a back-channel communication

Most desktop computers use I2C to read information about the system memory and monitor the health of system components (temps, voltages, etc).

My objective is to use I2C to allow data collection from a large bi-directional led sensor array. I plan to have several PIC microcontrollers each controlling a line in an array of leds and then use another PIC as an I2C master to coordinate scanning of the array and interface with a host PC. Most compilers support I2C master communications ‘out of the box’ for things like talking to serial eeproms and real-time clocks. However, no compilers that I know of offer any support for I2C slave-side communications. I think this is because very few picmicro actually have the proper hardware to implement the i2c slave role (which is very timing sensitive), and there are other methods (which may have been easier) such as RS485. I also think that the majority of picmicro compilers are used by hobbyists, and hobbyists have little need to network multiple picmicros – usually programming and managing a single pic is enough trouble.

I have the basic interrupt driven i2c slave routines available in heavily commented source code if anyone needs them. I will probably setup a static webpage with some more information, but its lower on the priority list. It is written is in Proton Basic. If anyone wants the code, let me know and I’ll send it your way.

Bi-directional LEDs II

Things are going well.

For a small prototype, everything is working as it should. I have a 2×2 array of LEDs (4 LEDs total).

I’ve managed to work the sampling time down into the sub-visible range, so you don’t notice any flicker at all from the leds.

I got my visual basic program working well, providing a real time graph of what the sensors are reading.

Right now I’m trying to figure out the best way to scale up this project, into at least a 8×8 array.

Anyway, here’s some pictures:

led sensor array breadboard

There are my four led sensors … the light from the additional leds has really improved the dynamic response of the sensors, they can actually see my fingertips now, before my fingers would barely register.

visual basic led sensor array readout

This is a quick program (hah, quick = 6+ hours) I wrote in visual basic. It receives serial data from the microcontroller that manages the sensor array, and displays it on the line graph. You can see the variations in the sensors caused by me running my finger around the array.

Bi-Directional LEDs

As a glutton for punishment, I find it is best to keep as many irons in the fire in terms of micro-electronic projects as possible.

My latest fascination is with the bi-directional properties of light emitting diodes. From reading a few dry papers on using LEDs as inputs, I have found there are at least two ways of accomplishing this. First an LED by itself will generate a tiny DC voltage when exposed to a light source of the same or higher frequency of the LED. I think of this as photovoltaic operation. Any high-impedance voltmeter can measure this voltage, and it ranges based on intensity from 0 to 1.5 volts. The other, and perhaps more useful method, is using the LED as a light dependent capacitor. By reverse biasing the LED, a charge is placed on the junction. This charge is then dissipated by the LED’s photovoltaic properties once the reverse bias is removed.

So, using a microcontroller, I have been able to take advantage of this knowledge to create a simple ‘interactive interface’ with a pair of LEDs. The process works like this:

Breadboard setup: 2 LEDs, 2 current limiting resistors in series with the LEDs. LED anodes are connected to bi-directional digital I/O pins on the mcu. LED cathodes are connected to bi-directional digital/analog I/O pins on the mcu.

Step 1> Forward bias the led array (all LEDs lit). This entails setting the anode connected IO lines to output a HIGH logic state (current source) and the cathode connected pins to output a LOW logic state (current sink).

Step 2> Reverse bias the first led in the array. I accomplish this by switching the rolls of the anode and cathode pins. Anode = sink, Cathode = source. This charges the capacitance of the led up to a logic HIGH potential (+5v).

Step 3> Switch the cathode connected pin into a high-z input mode and connect it to the microcontrollers ADC.

Step 4> Perform an analog to digital conversion on the LED, reading the voltage potential stored in the LED. I’ve obtained values around 3.3 volts while the led is “dark” and as low as 0.9 volts while the led is brightly lit by the rest of the array via a mirror. Using a red laser pointer fully discharges the LED resulting in a 0 volt sample.

Step 5> Forward bias the LED again, switching the cathode connected pin back into a digital output of a logic LOW state.

Step 6> Repeat steps 2 through 6 for remaining LEDs in the array

Step 7> Dump ADC results to the serial port for analysis by the host PC.

On paper, this sounds like a lot of work, but thanks to the mighty Microchip PIC microcontroller, it’s really just a series of setting bitwise registers on the PIC and reading the ADC results.

I want to try connecting an op-amp inline with the ADC sampling to try to increase the response time of the led… right now I’m using a 1ms analog sample time, which is causing a slight flicker in my array. If I can halve that it should eliminate any flicker. The problem with a faster sample time is I loose dynamic range or “brightness sensitivity”. I believe this is due to the fact the LED does not discharge fast enough.

A forum member on the linear1 forum recommended I place a resistor across the LED to speed up this discharge. It is certainly worth trying, and simpler than wiring in an op-amp!

Stay tuned…

Illumination Grade

I’ve written a new article; “Three Watts of Light“. The subject is my first experiences with ‘true’ illumination grade solid state lighting. I’ve played with a lot of leds over the years, but these leds are in a class of their own. The light they generate and the power they require makes it a “whole nother ball-game”.

luxeon clone ufo power led rgb mix

Finally, A New Theme

I finally became bored with the word-press default theme – not that there is anything wrong with it, but hey, change is good right?

This new theme is called “Ocadia” designed by Becca Wei.

I like the shaded boxes in the side-bar and the fact this theme is not overloaded visually or functionally. Some of the themes out there have way too many links, buttons, do-dads and hoopla for simple ‘ol me.

UFO Sighting

UFO … That’s what they’re called, maybe because they are around, maybe because the vendors grew weary of calling them luxeon clones. No, I’m not writing about some errant weather balloon, the planet venus, or my neighbors truck seen through beer goggles… I’m writing about some high-output LEDs

These are the first of any ‘next gen’ leds I’ve worked with … I’m stoked they are so tiny … its often hard to tell the scale when you just see pictures of these things online with nothing of known size in the shot.

luxeon clone ufo led 1 watt

the big black module is an RGB ufo, with three one watt emitters in a single package. It’s wired as a common anode device… should work out well with my led controller project. The small led in the top of the picture is a white piranha led. The smaller silver module is a blue UFO.

luxeon clone ufo led 1 watt

This is the die of a blue ufo, running at a greatly reduced capacity. I still had to stop my camera all the way down to take this shot with any amount of detail … (1/4000s f7.3)

More pictures to come. I have a red, blue and green mounted to an old 586 heatsink which provides ample cooling to the 3 watt load, I’m going to work on mounting the driver circuitry to the backside of the heatsink and should have some pictures shortly!