More on Controlling RGB LEDs

[P. Short]

A few days ago when chatting with JEC he mentioned the Triklits site, which uses a proprietary protocol scheme (http://nw.com/nw/triklits/protocol.html) to control up to 24 pixels. The baudrate is 40,000, and the data format is completely proprietary, so it requires some sort of bridge if you want to use a PC to drive them. The best case update interval in this scenario is about 15 ms, which is quite a good number.

The PIC used for this design is apparently a PIC10F200, which costs about $.50 from mouser in quantities of 25. This part is available in either an 8-pin DIP package or a 6-pin SOT23 package, has 16 bytes of RAM. 1 timer, no interrupts, and 256 bytes of instruction space. This makes programming it quite a challenge, but I've figured out how to do it.

It strikes me that this might lead to a cheaper RBG pixel than the current JED design. The PIC itself is a bit cheaper than the PIC16F688, and (arguably) the lower data rate would remove the need for the RS485 receiver. The downside, of course, is that it is not longer DMX compatible, the distance is more limited, and the need for a bridge.

There are other potential approaches to lowering the cost. The driving factor for cost at the moment is the desire to make each pixel completely standalone. If the PIC and RS485 chips could be shared among more than one pixel (easy to do 3 pixels with a PIC16F688, 4 pixels with PIC16F627) it would help the cost.

Using a zener and resistor for regulating the voltage instead of the 78L05 would also have a minor cost savings.

Considering the time of year, it seems like more of a project for next year than this one. For me this is more of a programming challenge than a serious project at this time, since I don't have any burning desire to build it this year. The next challenge will be switching over to a DMX-like protocol (still at either 38400 or 40000 baud) to reduce or eliminate the need for the bridge.

Thoughts?

--

Phil

[ErnieHorning]

I’ve been thinking of doing something like this also. I’ve been wanting to do something cool with those little PIC10’s. Those balls are just ping-pong balls.

Does the communications speed really need to be that fast? It only needs to be one way. Use two wires for both power and communications.

A string of 4 bytes or less should be enough to send an address, color and value. Just keep doing what you’re doing until told different. 24 4 byte commands are only 5 mS and that’s assuming everyone is different. The PIC10F has no UART so a byte isn’t really relevant.

You can probably compress some of the commands, though Vixen has never been asked to work this way. One command for everybody does the same thing. Ramp from this level, to this level, in this amount of time. Maybe cycle through all colors in ‘X’ amount of time.

The PIC10F202 gives you twice the memory for only a couple of cents.

If you pulse an LED at the right width, you can increase the current 3 to for times, which makes it brighter and your average current is still low.


When do we start? I’ll probably be ready the second week of January.

[JEC]

A few days ago when chatting with JEC he mentioned the Triklits site, which uses a proprietary protocol scheme (http://nw.com/nw/triklits/protocol.html) to control up to 24 pixels. The baudrate is 40,000, and the data format is completely proprietary, so it requires some sort of bridge if you want to use a PC to drive them. The best case update interval in this scenario is about 15 ms, which is quite a good number.


These were for sale briefly last fall, but there were some quality control problems with the manufacturing process. I don't think they've shipped for over a year now, and there's no estimate as to when they'll start back up.


The PIC used for this design is apparently a PIC10F200, which costs about $.50 from mouser in quantities of 25. This part is available in either an 8-pin DIP package or a 6-pin SOT23 package, has 16 bytes of RAM. 1 timer, no interrupts, and 256 bytes of instruction space. This makes programming it quite a challenge, but I've figured out how to do it.

It strikes me that this might lead to a cheaper RBG pixel than the current JED design. The PIC itself is a bit cheaper than the PIC16F688, and (arguably) the lower data rate would remove the need for the RS485 receiver. The downside, of course, is that it is not longer DMX compatible, the distance is more limited, and the need for a bridge.

There are other potential approaches to lowering the cost. The driving factor for cost at the moment is the desire to make each pixel completely standalone. If the PIC and RS485 chips could be shared among more than one pixel (easy to do 3 pixels with a PIC16F688, 4 pixels with PIC16F627) it would help the cost.

Using a zener and resistor for regulating the voltage instead of the 78L05 would also have a minor cost savings.

Considering the time of year, it seems like more of a project for next year than this one. For me this is more of a programming challenge than a serious project at this time, since I don't have any burning desire to build it this year. The next challenge will be switching over to a DMX-like protocol (still at either 38400 or 40000 baud) to reduce or eliminate the need for the bridge.

Thoughts?

--

Phil[/quote]

I'd love to help with this one.

John

[A Marchini]

A few days ago when chatting with JEC he mentioned the Triklits site, which uses a proprietary protocol scheme (http://nw.com/nw/triklits/protocol.html) to control up to 24 pixels. The baudrate is 40,000, and the data format is completely proprietary, so it requires some sort of bridge if you want to use a PC to drive them. The best case update interval in this scenario is about 15 ms, which is quite a good number.

The PIC used for this design is apparently a PIC10F200, which costs about $.50 from mouser in quantities of 25. This part is available in either an 8-pin DIP package or a 6-pin SOT23 package, has 16 bytes of RAM. 1 timer, no interrupts, and 256 bytes of instruction space. This makes programming it quite a challenge, but I've figured out how to do it.

It strikes me that this might lead to a cheaper RBG pixel than the current JED design. The PIC itself is a bit cheaper than the PIC16F688, and (arguably) the lower data rate would remove the need for the RS485 receiver. The downside, of course, is that it is not longer DMX compatible, the distance is more limited, and the need for a bridge.

There are other potential approaches to lowering the cost. The driving factor for cost at the moment is the desire to make each pixel completely standalone. If the PIC and RS485 chips could be shared among more than one pixel (easy to do 3 pixels with a PIC16F688, 4 pixels with PIC16F627) it would help the cost.

Using a zener and resistor for regulating the voltage instead of the 78L05 would also have a minor cost savings.

Considering the time of year, it seems like more of a project for next year than this one. For me this is more of a programming challenge than a serious project at this time, since I don't have any burning desire to build it this year. The next challenge will be switching over to a DMX-like protocol (still at either 38400 or 40000 baud) to reduce or eliminate the need for the bridge.

Thoughts?

--

Phil

My concept has been a head end power supply 3V at say 2 amps and a 485 to some kind of bit stream protocol , like i2c. So you have 3 wires, +V, data, and ground. I believe that most of the low power pics have wide input voltage ranges for battery operation.

At the head you have the power and converter chip (not unlike the Ren-T) and it can even be powerful enought to save state and also run canned routines (like the lamps you buy in the store now). You have maybe 32 drops on it (I don't know I didn't work the power budget out). The head end could take DMX, renard, whatever and rasters the values out on the single wire bus to the individual RGB nodes.

Then you get creative and send data down a 485 bus at the head nodes, which redirect the indivual columns and you get Ledtriks on steroids with full color and dimming... etc.

Not a new idea, just a concept that we could approach, I am pretty sure I have brought this up before.

Tony M.

P.S. As an alltenative branch to the concept a similar board could PWM an isolated MOSFET SSR and you could run a string of these controlers along a string of C7s giving you individual control of these lights. Isolated MOSFETS circuits are not cheap I suppose, I was just trying to get around zero cross issues.
I guess the cost of a single SSR with zero cross detect circuit is probably not all that expensive in retrospect. Drop down to TO-92 models to save space and all, we are only controlling one buld after all.

[P. Short]

The desired power supply voltage would depend on how many LEDs you want to have on each board. If you want several LEDs for each color of each pixel, you'd be better off using a higher voltage, so the LEDs can be placed in series. The IR losses in the wire would be less this way, making longer distances more feasible.

Also, I think that using normal asynchronous character format at standard baud rates is more desirable (perhaps 38400, 8N1). This could make the head-end much simpler. I'm playing around with coding things up to using a simple protocol consisting of a sync byte (0x00) followed by binary data (only allowing 255 levels, rather than 256). The update rate with this scheme is essentially the same as the triklits scheme, with the advantage that it can be driven from the PC serial port very simply.

--

Phil

[JEC]

Also, I think that using normal asynchronous character format at standard baud rates is more desirable (perhaps 38400, 8N1). This could make the head-end much simpler. I'm playing around with coding things up to using a simple protocol consisting of a sync byte (0x00) followed by binary data (only allowing 255 levels, rather than 256). The update rate with this scheme is essentially the same as the triklits scheme, with the advantage that it can be driven from the PC serial port very simply.

--

Phil

Very elegant. I'm interested to see how you attack this without interrupts! How many pixels will a packet of data support?

[A Marchini]

The desired power supply voltage would depend on how many LEDs you want to have on each board. If you want several LEDs for each color of each pixel, you'd be better off using a higher voltage, so the LEDs can be placed in series. The IR losses in the wire would be less this way, making longer distances more feasible.

Also, I think that using normal asynchronous character format at standard baud rates is more desirable (perhaps 38400, 8N1). This could make the head-end much simpler. I'm playing around with coding things up to using a simple protocol consisting of a sync byte (0x00) followed by binary data (only allowing 255 levels, rather than 256). The update rate with this scheme is essentially the same as the triklits scheme, with the advantage that it can be driven from the PC serial port very simply.

--

Phil

I was thinking tri-color LEDs , and a voltage doubler, since they usually have a high drop internally). With high current power supplies this would work. I wanted to keep the voltage low with small power supplies, and probably no more than 32 units per string.

The idea of the head processor would be to handle localized raster commands and to turn the bus into a Tree. The head processor would handle the relative slow speed individual nodes while handling the higher speed bus on their behalf (also the potential is that these front end node could potentially manage parts of the"show" independant of the main computer). The head processors would be daisy chained in standard 485 fashion.

The reason I am visuallizing a higher speed bus is because using individual lamp control like this, the channel numbers are going to increase fast. So each upstream tap will require more bandwidth.

Of course, I make an assumption on topology, and depending on the application of the light display, one topology is better than another.
If you have a bunch of trees in a row, then daisy chaining them works great. However if you have items out in a yard here and there , then daisy chaining might not be so efficient.

Perhaps we should just take a page from the model railroaders. They run multiple DC cabs with various "communication over DC" tricks. So at that point it can just be DC bus.

I have a problem about running multiple serial streams but it does make the electronics easier.

Tony M.

Its too bad the propeller can't be cheaper.

[P. Short]

What sort of lamp count are you thinking of? Right now I'm not really thinking about scaling up above 100 or so (maybe three or four serial channels). I think that is the upper end of the range where a PIC per pixel makes any economic sense. Having each micro control many LEDs makes more sense, I think, with the higher lamp count systems.

--

Phil

[JEC]

What sort of lamp count are you thinking of? Right now I'm not really thinking about scaling up above 100 or so (maybe three or four serial channels). I think that is the upper end of the range where a PIC per pixel makes any economic sense. Having each micro control many LEDs makes more sense, I think, with the higher lamp count systems.

--

Phil

If we could have 32 on a string with a decent framerate, it wouldn't be difficult to build a head-end receiver to parse out a faster datastream to many, many strings.

[P. Short]

It's not clear to me that saving a little bit of money by using a cheaper micro is worthwhile. You (JEC) are charging $9.20 for the existing board, which I think provides fairly bright lighting. I suspect that the price of the PIC is around $1.50 in the quantities that you are purchasing, and could go down to perhaps $1.00 in larger quantities. While I have heard some comments about the current price, I don't think that reducing the price by $1.00 would affect things very much. Reducing the price of the PIC makes sense in certain other circumstances (high-volume manufacturing, or if the price of the other componentss were similarly reduced), but I think that the PIC16F688 is is probably not a handicap in the current situations.

If I'm not certain about whether this makes any sense, why am I working on it? Simple. I view it as a type of puzzle, something that I enjoy working on. And it won't cost me anything to check it out, since the code can be tested out on almost any PIC.

--

Phil

[A Marchini]

What sort of lamp count are you thinking of? Right now I'm not really thinking about scaling up above 100 or so (maybe three or four serial channels). I think that is the upper end of the range where a PIC per pixel makes any economic sense. Having each micro control many LEDs makes more sense, I think, with the higher lamp count systems.

--

Phil

Actually, there is no reason, ( and I suppose that is what JEC is mentioning ) that it couldn't be both ways. The design you propose could be augmented with upstream controllers, independant of your proposed design.

100 lamps (equating to 300 channels in the vixen software scheme) is probably sufficent for most people. It really depends on what else they are already controlling.
As far as economics, I suppose it depends on who is buying.

Another idea, that may be integrated into the first run. Suppose the Pic portion was simply a small board , say 1"x 1" . There are 5 signal lines output (+V,Gnd, R,G,B). Then secondary boards could be made which contain the 3 power transistors and leds.
Why this way? You can scale the output using the same controller. You want 3 LEDs and 3 transistors to fit in a thimble sized device, you got it. You want a grid array like in the pixels now? You got it. You want to use 3 large 5 watt LED bars, you can do that to (if PWM works on them of course).
Also it could be used to drive a single AC lamp too (obviously with a different program).

Programming on such a small device is much like the original 16C54 device, hmm now I can't remember if that is the device that started it all for Microchip. I was thinking of a creative way of doing AC dimming with it, where you use the zero cross to reset the chip and then time from then, but I digress (as usual).

Tony M.

[RavingLunatic]

The “pixel project” has really got me curious, so I decided to make a version of the LED section of JEC's design on a strip board and use a Renard64 to control it. Seems to work rather well.

Lessons learned:

1) Choice of LEDs is extremely important. Even tho all my LEDs said “ultra brite” they had big differences in their luminous intensity values. This seems to be making it very hard to get an even color blend. JEC seems to have done his research because the LEDs he found have similar/equal intensity values.

2) Viewing angle of the LEDs also important. My LEDs have a small viewing angle and result in “hot spots” of color and hampers the color blending also.

3) The Renard64 seems to control this well, as long as the sourcing PWM firmware is used. Makes it possible for current Renard users to switch over to controlling “pixels” as part of their display.

4) The RGBLED add-in for VIXEN will need some work to make it more usable for this effort. It is a good start but needs more user flexibility. But I wouldn’t suggest bothering KC with that til after this season is over.


Questions/suggestions raised for future “pixel project” boards:

1) How many of these could realistically be daisy-chained together using CAT5? Using the JEC design, the LED section is at least 150 mA and you still have 2 chips and the voltage regulator. So lets just say 200-250mA (could be more, I’m sure JEC could provide numbers) on the 12 VDC line. 4 pixels together would already be drawing around 1 amp on the source CAT5 cable. How much current can 24 awg wire actually handle safely?

2) If each daisy-chain is limited to 4-8 pixel units then it would appear that a main controller unit would be needed to take the PC output and route the data down the correct daisy-chain line in a large display.

3) For me a design like JEC’s with multiple LEDs of each RGB color seems to be the way to go. I envision using these as stand alone items along the edge of yard (much like JEC’s video from 2005). Cutting down on the amount of LEDs (and thus amount of light) from each unit would also reduce the “WOW” factor that can be achieved.

4) Would it be worth it to add a set of white LEDs? Why you ask, well to get white now you will need to run all three channels at full intensity thus max current.

5) Suggest any future boards be able to be configured as a “smart” board (PIC on board) or as a “dumb” board (only transistors and LEDs). “Dumb” boards could be used by current Renard owners (just need a lot of CAT5) or others who have their own protocol/method.

I’m sure this project will spawn several different variations once all the creative brains have time to think about it once this years displays are done.

Ok, I’m done rambling again…..

[P. Short]

Thanks, RL. I have a few additional comments regarding power.

1) The PIC and the regulator draw fairly minimal current (around 5 mA each), the RS485 chip is spec'd at 50 mA (max). So figure 200 mA per pixel at full brightness. The real question about the 24AWG cable is the resistance (27 Ohm/1000 feet one-way, or 54 Ohm/1000 feet round-trip). This may very well be the limiting factor, and (depending on the distance) at smaller pixel counts than you describe.

1a) I don't remember the prices, but coming up with a scheme to use lawn lighting cable for distributing power might be worthwhile.

1b) Putting more LEDs in series and using a higher voltage (perhaps 24VAC) might be another possibility. If you use the suggestion from the next item, you don't even need a regulator for the LED p/s, just diodes and a filter cap.

1c) On future designs it might be worthwhile changing the LED drive circuit to reduce sensitivity to power supply voltage. To do this you put the current limiting resistor on the emitter of the drive transistor, rather than the collector. You need more transistors, they're quite cheap.

--

Phil

[JEC]

1) How many of these could realistically be daisy-chained together using CAT5? Using the JEC design, the LED section is at least 150 mA and you still have 2 chips and the voltage regulator. So lets just say 200-250mA (could be more, I’m sure JEC could provide numbers) on the 12 VDC line. 4 pixels together would already be drawing around 1 amp on the source CAT5 cable. How much current can 24 awg wire actually handle safely?

Note that I'm using 3 conductors for +12V and 3 conductors for ground in the CAT5 cable. But yes, current draw is definitely the limiting factor.

On my house, I'll be using long runs of 14 gauge wire and shielded DMX cable to reach each group (10 - 30) of pixels. Then, I'll have a small circuit board which merges data and power into an RJ-45 jack.

So the CAT5 cable only needs to carry current for about 25 feet max. At least in my case. My roofline breaks down into six discrete chunks.





4) Would it be worth it to add a set of white LEDs? Why you ask, well to get white now you will need to run all three channels at full intensity thus max current.

The '688 has enough output pins to do Red, Green, Blue, White and Amber. It's exceedingly difficult to get a nice yellow, I've found. It increases the DMX channel count, but would be neat to see. There are some professional LED theatre fixtures that have taken this same approach, with good results.

Maybe for next year...

[P. Short]

Another consideration is price. It already can get to be pretty expensive if you are purchasing 20 or 30 pixels, and it might be helpful to some people if there were lower cost variations. My guess is that a significant part of the price that John is charging are assembly costs, and that coming up with a through-hole design with a PCB that could be home-etched would be useful to a number of the people here.

I think that a target price around $4 per pixel in moderate to high volumes should be easy to attain through parts and PCB coops with the user doing the assembly. Decreasing the cost even further might be possible.

--

Phil