RGB Pixel Nodes over Ethernet - New Design

[secanell]

Hello all:
I have seen some threads discussing RGB over DMX, Pixel Nodes and the like. I haven't seen a solution, so I prose the following. I would like feed back from those more knowledgeable so that the design can be reasonably flexible.

I am starting a new design starting with a Microchip DM320004 Ethernet controller to 2 I2C interfaces ( There are 4 I2C Interfaces on a PIC32MX795F512L chip, but 2 I2C interfaces are used for the Ethernet interface).

A daughter card to the DM32004 will have 16 I2C to dual SPI interfaces with differential drivers to drive CAT5 cable (thats 32 spi ports).

The Pixel Node string will have a differential SPI receiver that will convert back to digital to drive a string of A6281 rgb led drivers.
The circuit board for each A6281 (pixel node 32 bit per node) will be configured to support both a PLCC6 5050 led, or a 3 led strip (cut from the 5 meter strips).

Even though the pixel nodes could be 1000 nodes long, the limitation is the power requirements... a node of either 3 leds or single led is 60 mills X 100 nodes = 6Amps. I estimate that the Pixel Node string will have to use 24 ga wire for the power, which is what CAT5 cable uses. If one uses 2 wires for + and 2 wires for -, then a 200 node string could be created. I'll have to see what I can do on the circuit boards to insure that the trace widths can be created and yet keep the circuit board reasonably small. Besides, now many could really use a 200 node string?

An alternative to this is to put a driver interface on the end of the first string that would allow a second string with separate power supply so that one could continue a 100 node string with n+ strings. Each A6281 has a buffered driver output capable of driving CAT5 cable. The I2C to SPI interface is capable of driving at 1.8 MHz SPI clock, but the I2C is limited to about 400KHz clock. One would have to do the math to make sure that the a decent refresh rate for the entire I2C array could be maintained.

When one finishes populating the Ethernet configuration, you will have 3200 Pixel Nodes or 9600 leds!

Now the software.
The Ethernet controller will be configured to accept the art-net command from vixen and will look like a DMX interface.

The Ethernet software will consist of a matrix to convert each pixel node, or led node to a DMX channel. If by Pixel Node, then the DMX value could be divided up to address colors with intensity, or else address each led in a node with its own channel. If Vixen could address more than 256 values, then setting up a color table in the Ethernet controller might make better sense and then each RGB node could be addressed as one DMX channel (3200 DMX channels in on Ethernet interface).

I still have some issues to address like how to tell the Ethernet interface how many nodes are on an I2C interface to configure the software. The software will then have to turn the node quantity list into DMX channels.

So this is what happens: The software convers the node list into I2C interface (qnty 2), to 1 of 8 I2C channels, to 1 to 100 Pixel Node.
DMX 1 = I2CM-A, I2CS=50, PN1 (I2C Master Interface A, I2C Slave address 50 (50 - 57), First Pixel Node).

OK, so a design from the ground up. I know this is a lot to consume, but the only way I see to do RGB is a ground up design. What are your thoughts?

-Steve

[Entropy]

I really don't think RGB is best done as a ground-up design, not when there are some VERY good candidates for the nodes themselves (such as WS2801 pixel strands). As someone who tried to design an "alternative" node (driven via I2C), I gave up because it was simply not possible to beat or even come close to 60 cent/node Aliexpress imports. (My original target was to beat $2/node, which was cheap at the beginning of 2010. 2010 was the year of cheap RGB strands.)

Driving WS2801s from Ethernet is not new - there are at least two designs in progress at a relatively high degree of maturity (DynamoBen's PropController and jstjohnz's project) that take in E1.31 via Ethernet and drive WS2801 or other pixel node protocols.

As someone who has done some I2C work - using I2C as the "trunk" protocol is IMO not a good idea - I2C is capable of far lower speeds per bus than SPI. The fastest I2C implementations now are 1 MHz clock rate - I've seen microcontrollers that support SPI at over 10 MHz clock rate. SPI-trunk-to-multi-I2C makes a lot more sense

What chip are you using to do I2C to SPI??? I have never seen such a chip.

Also, IMO someone focusing on new Ethernet designs should seriously start considering a microcontroller with built-in Ethernet to avoid the bottlenecks/limitations imposed by stuff like the Wiznet. I have a Luminary/TI LM3S6965 eval board I'm starting to play with for just such projects - $15 or less for a beefy ARM Cortex-M3 micro with built-in Ethernet MAC/PHY. Once you've gone SMD, you may as well go for a proper integrated solution.

I haven't talked about it much as I wanted to be farther along in the project (i.e. have at least one subcomponent in working order on Github) before mentioning it, but I've had a similar idea of a project where there was a "trunk" interface from the Ethernet microcontroller to something that did the "heavy lifting" of driving lots of pixel nodes. In my case, the uC is likely going to be the above LM3S6965 or similar, and the "heavy lifting" done by a Xilinx Spartan-3E. The microcontroller writes to the FPGA's BRAM using SPI with a protocol similar to SPI EEPROMs, and then the FPGA drives out pixel node data or DMX on multiple outputs directly from the BRAM buffer. An XC3S250E is around $12-15 and should have enough BRAMs for at least 4906 channels, probably 8192 channels. It should be able to support "truly ridiculous" scales. For those that don't need "truly ridiculous", the Propeller-based solutions are better (unless you just want a bit of a challenge, like I do - yes this is more of a project to challenge myself and learn two new ICs than due to any need for THAT many channels.)

[P. Short]

Hmm...24AWG is ~3Ω/100 feet, times 6A ...

[P. Short]

Secanell, tell us more about who you are and what you are trying to accomplish. Is this a one-off project for yourself, is this intended as a commercial product, as an open-source project, or what? What is your degree of interest and commitment at this point? Something that you are determined to do, or just sticking your toe in the water? And are you in the US, somewhere else, etc.

[secanell]

Entropy:
The Microchip DM320004 uses an 80mip PIC32MX795F512L chip. The chip has Ethernet built in. Microchip provides the ethernet lib for free. The board is a development kit, so one either uses one of their add on boards (about the same price as the ethernet board) or make your own - which I planned on doing.

The chip has about 80 I/O ports, so one could create many spi interfaces and drop the I2C.

I took a quick look at the ws2801 pixel node... looks almost like I2C.... haven't found the specs on it yet.

P.Short:
Keep in mind that the first pixel node would see 6 amps. The current drops along the string by about 60 ma for each node.... so your 100ft would be attached to the first pixel node... now you have a problem :-).

As for my location:
I live in Southern California in Rancho Cucamong. I am currently responsible for business systems data security.
My back ground: I started in electronics (tubes - ok so I'm 62) at 12 years of age.

As for my interest: I've just begun to investigate and evaluate syncronizing music to lights... beyond the sampling of the audio and driving 110 volt lights.... ya I build one of those many years ago.

I like what I see with regards to RGB lighting, but haven't seen a lot out there and have questioned some of the designs that I have seen.

I agree that I2C is a poor performer, but its really a matter of what work is being performed and what devices (ICs) are available vs cost. In short can the design specs be met.

as for the I2C to spi. The device is SC18IS602B. It has 8 addresses ( 50 - 57 Hex ) with SS0-SS3/GPIO0-GPIO3, a 200 byte buffer.

With regards to the design, because of the double buffer design of the A6281, I could actually use the two available spi interfaces on the DM320004 and in conjunction with the I/O ports, drive the /OE line to do the final load on the string. The PIC chip has lots of those. That would simplify the design. Hmmmm thinking on line! :-) The A6281 can be driven to 5 MHz, so that mean that each SPI line could drive about 4000+ nodes. Two of those... I should look at Entropy's design idea. Thing I liked about the Microchip device is that the pic chip with ethernet is designed, all I had to do is develop a daughter board and write software.

Ok now I am babling on.....

-Steve

[P. Short]

Just pointing out that the voltage drop can be an item of concern, particularly on the ground line. If you assume that the cable length is, say, 33 feet (3 pixels/foot), the current (averaged over that 33 feet) is 3A, and the cable resistance is 0.5 Ω (33 feet of paralleled 24 GA wire), the voltage rise on the ground wire is 1.5V. Maybe a problem, maybe not.

[Entropy]

As far as existing designs, other than the fact that the Propeller is a bit of an unusual chip with an even more unusual language and no open source dev tools, what don't you like about the PropController or jstjohnz's pixel controller projects? I'm assuming the lack of open source dev tools doesn't bother you since you've chosen PIC though.

You say the PIC32 has built-in Ethernet, but then mention that Ethernet is eating two I2C ports? I'm getting a little confused here, it sounds like the dev board has an offboard Ethernet interface. (Or are the Ethernet pins shared with some of the I2C ports on that chip so you can use one or the other but not both?)

There's a link to the WS2801 datasheet somewhere on these forums. At some point this weekend I may add a new page to the DIYC Wiki with the known English-language pixel strand datasheets. (There is what seems to be a cleanly translated one for the WS2801, and a fairly badly translated one for the LPD6803.) The WS2801s are definitely not I2C - They're much closer to SPI (and in fact I think some people here might be using the hardware SPI ports of microcontrollers to drive them. Not the Propeller guys, Propeller is all about software bitbanging.)

(Yes, I realize the FPGA I mentioned above doesn't have open source dev tools, but unlike the microcontroller world, there is no option along these lines in the FPGA world.)

[secanell]

Entropy,
For PIC development, they do provide development tools for free, but the code is not optimized. There is also a Linux group that has put together a set of development tools for the Microchip PIC devices, but I haven't looked into the details on that yet.

What i noticed about the WS2801 modules, they have three IC's on the board along with the 3 5050. The A6281 device, though it requires an additional load line ( /OE ), has a built in 5 volt regulator for the internal electronics. It truly is a single chip device, so it can reduce the board area even more. It has two Vcc input lines, one for up to 17V and the other if your running a 5 volt system.

It is interesting that the WS2801 is able to get the price so low. When I have looked into the cost of 5050 devices, the prices has always been higher than a 5 meter string of 300 5050 devices.

-Steve

[P. Short]

What are you seeing on the price of 5050 chips?

Also, isn't the WS2801 the part that had licensing issues that affected their importation into the US? If so, has this been satisfactorily resolved yet?

[secanell]

What are you seeing on the price of 5050 chips?

Also, isn't the WS2801 the part that had licensing issues that affected their importation into the US? If so, has this been satisfactorily resolved yet?

The PLCC6 5050 chips in quantity of 1000 is about $0.15 each. Entropy implied $0.60 a pixel node for the WS2801 and it used 3 of these chips. I was trying to figure out how they (China) got the price so low with 3 RGB chips, 3 ICs, a PCB, case and assembly.

Have to admit that there is no way to come close when you are paying 45 cents for the 5050 alone. The A6281 is about $0.83 each at qnty of 1500 and then a pcb and assembly, though reflow soldering is not that difficult to do.

As for the history of the WS2801, I have no background with that product except what I have seen in the past couple of days.

-Steve

[Entropy]

I was not referring to the 3-5050 modules, but the single diffused emitter modules, which have a form factor more appropriate for many Christmas uses. These have a price around $0.60 - Quite a few people have ordered them, http://www.aliexpress.com/fm-store/701799/209889132-320389559/12mm-8mm-led-pixel-RGB-led-channel-lettet-waterproof-WS2801IC-256-level-gray-scale-DC5V-input.html

[P. Short]

Oops, too slow.

[secanell]

In looking at the WS2801 vs the A6281, this is what I see positive and negative.
The WS2801: Positive: clock rate up to 25 MHz. Lower cost per node (may be!). Negative: data/clock framing a bit weird, not really in an SPI data stream format. Requires additional components to run on 12 volt system per node.
The A6281: Positive: Has built in register to configure RGB control to adjust light balance (pre load). Standard SPI data/clock stream can be used, true synchronous transfer. Will directly run off of 12 volt circuit. Doesn't require additional components, self contained. One resistor current regulator. Negative: Max clock of 6 Mhz. Requires two control lines vs SPI SS (LI=Latch buffer, OE=Output enable which is a second latch to the PWM), thus 4 line. $0.83 per 1500.

[David_AVD]

Put simply, the Philips patent covers the use of PWM to colour mix LEDs. There is no "chip license". The license applies to the assembled product, not the individual parts.

It makes no difference what chip (2801, 6803, PIC, etc) you use to PWM the LEDs. It's the combination of PWM + colour mixing that is the subject of the patent.

That's why there are no licence fees payable on the sale of LEDs, ICs, etc. The fee applies to the end product and is calculated on its sell price.

[secanell]

I was not referring to the 3-5050 modules, but the single diffused emitter modules, which have a form factor more appropriate for many Christmas uses. These have a price around $0.60 - Quite a few people have ordered them, http://www.aliexpress.com/fm-store/701799/209889132-320389559/12mm-8mm-led-pixel-RGB-led-channel-lettet-waterproof-WS2801IC-256-level-gray-scale-DC5V-input.html

Impressive. Can't beat the price. Ordered a few to evaluate. Thank you for the info.
I think I understand the programming of the WS2801. Correct me if I am wrong. It appears that as long as the clock is running, that the data stream will flow from one device to the next (in a string). Once the clock is held low for some period of time, all data in the shift registers is loaded into the PWM. Clever approach. Just keep the data stream running until you've hit the last node and then stop the clock.

Does that sound about right?

-Steve

[David_AVD]

Yes, if you hold CLOCK low for more than 500uS, that signals all pixels to update with the new data just loaded.

[secanell]

Yes, if you hold CLOCK low for more than 500uS, that signals all pixels to update with the new data just loaded.

Interesting design, but one must then be careful on how long they make the string (aside from power requirements). If the spi master had an interrupt driven routine and that routine took to long, then one could experience a glitch in the upload of the data string. Also, this would preclude running a very slow clock :-)

[DynamoBen]

As far as existing designs, other than the fact that the Propeller is a bit of an unusual chip with an even more unusual language and no open source dev tools, what don't you like about the PropController or jstjohnz's pixel controller projects?

The IDE is free, and there are a number of open source tools that already exist. Parallax open sourced their bytecode documentation (http://propeller.wikispaces.com/Spin+Byte+Code) so anyone can create a compiler. (SPIN uses bytecodes to save on space) Pick a language and OS and there is going to be a compiler you can use: http://forums.parallax.com/showthread.php?113091-ULTIMATE-List-of-Propeller-Languages

[Entropy]

Put simply, the Philips patent covers the use of PWM to colour mix LEDs. There is no "chip license". The license applies to the assembled product, not the individual parts.

It makes no difference what chip (2801, 6803, PIC, etc) you use to PWM the LEDs. It's the combination of PWM + colour mixing that is the subject of the patent.

That's why there are no licence fees payable on the sale of LEDs, ICs, etc. The fee applies to the end product and is calculated on its sell price.

Not correct - Some IC manufacturers pay the license themselves, and thus anyone using their ICs is OK.

For example, the NXP PCA9635 purchase price effectively includes the license fee for related patents, same for the TI TLC series and Allegro products.

[David_AVD]

Not correct - Some IC manufacturers pay the license themselves, and thus anyone using their ICs is OK.

For example, the NXP PCA9635 purchase price effectively includes the license fee for related patents, same for the TI TLC series and Allegro products.

Really? That directly contradicts the information I got from Philips: "Unfortunately, the Philips SSL license program is not directed/available to components, such as microcontroller or drivers, but instead is directed to finished goods such as luminaires and bulbs."

[David_AVD]

Interesting design, but one must then be careful on how long they make the string (aside from power requirements). If the spi master had an interrupt driven routine and that routine took to long, then one could experience a glitch in the upload of the data string. Also, this would preclude running a very slow clock :-)

You can stretch or stop the clock as much as you like, as long as you only do that to the high time. But yes, if you assume a symmetrical clock there is a lower limit.

[Entropy]

Really? That directly contradicts the information I got from Philips: "Unfortunately, the Philips SSL license program is not directed/available to components, such as microcontroller or drivers, but instead is directed to finished goods such as luminaires and bulbs."

There's also some wording somewhere that if you use certain licensed products (NXP controller ICs being one such product, given that NXP is a Philips spinoff), you do not have to pay licensing fees as you effectively paid them as part of the purchase price of the components.

I think in addition to the high-level RGB color mixing patents, there may be some lower-level IC patents the World Semi chips may infringe on. Not sure, but it's clear that at the chip-level, the World Semi dimmer ICs have some sort of patent issues.

[P. Short]

Apart from the licensing issues, are there also some EMI/RFI issues out there? It strikes me that passing the FCC emissions requiements with products sending multi-MHz signals through external wires might not be a slam-dunk. I doubt that anyone on this board particularly cares, but anyone marketing certain types of products based on these approaches might run into problems.

[Entropy]

Interesting design, but one must then be careful on how long they make the string (aside from power requirements). If the spi master had an interrupt driven routine and that routine took to long, then one could experience a glitch in the upload of the data string. Also, this would preclude running a very slow clock :-)

500 microseconds = half a millisecond = one millisecond for a full clock period = 1 kHz clock

And typically, interrupt-driven routines have the best latency... Perhaps you mean if someone were polling???

If using a hardware SPI engine (which I believe is possible in the case of the WS2801 - you just don't have any MISO coming back and no SS), you'd have to have a half millisecond interrupt latency to break - this is an eternity for a microcontroller, and also, nearly all microcontrollers have at least a 1-deep buffer on the SPI engine, so there is always at least one byte queued up for when the engine finishes shifting out data. Better uCs (like any one that has Ethernet) are likely to have multi-byte FIFOs.

[David_AVD]

There's also some wording somewhere that if you use certain licensed products (NXP controller ICs being one such product, given that NXP is a Philips spinoff), you do not have to pay licensing fees as you effectively paid them as part of the purchase price of the components.

Hmmm.... interesting. Any chance you can dig up where you found that? I can't seem to see anything about it at all.

[secanell]

With regards to patents and licenses with NXP / Phillips, Phillips originally had a patent on the I2C, but it is my understanding that ended in 2006. Then people were talking about licensing the I2C address. I sent an email to NXP on this one and that came back negative as in there is no licensing fee for I2C addresses. Does anyone have specific verbiage from NXP on PWM?

[Entropy]

Hmmm.... interesting. Any chance you can dig up where you found that? I can't seem to see anything about it at all.

Unfortunately, when the patent discussion came up about a year ago when I was working on my I2C-addressable RGB node project (basically a dead project now for a variety of reasons), eventually the patent discussion was moved to another thread. A good idea at the time, but it is making it difficult to find that thread. I know that Philips had such verbiage early last year.

As I understand it, NXP purchased the rights to patents 7,015,825 and 7,327,337 from their inventor, Jeffrey S. Callahan, who was briefly active on these forums early last year under the userid Prismalites.

[David_AVD]

Unfortunately, when the patent discussion came up about a year ago when I was working on my I2C-addressable RGB node project (basically a dead project now for a variety of reasons), eventually the patent discussion was moved to another thread. A good idea at the time, but it is making it difficult to find that thread. I know that Philips had such verbiage early last year.

As I understand it, NXP purchased the rights to patents 7,015,825 and 7,327,337 from their inventor, Jeffrey S. Callahan, who was briefly active on these forums early last year under the userid Prismalites.

Ah, it seems we're talking about totally patents here. The I2C patents and the PWM + Colour Mixing patents are quite separate issues. I was talking about the PWM patents, which apply to completed items, not chips.

[secanell]

Ok,
So looking at the comments, and the feedback that I've received, aside from patents, I've decided to go with the following:
* Ethernet to 16 SPI ports (enhanced to handle both the WS2801 and the A6281 ( the A6281 will directly work with 12 volts, no extra components, but extra control lines ).
* SPI differential transmitter/receiver over CAT 5 and RJ45 connectors.
* An A6281 PCB with 3 PLCC6 5050 led circuit board (though this will be an easy design, I will make it last since there are already WS2801 rgb light strings out there.

Software design
* Of course, 10/100 mb Ethernet ( Configured for ART-NET ).
* A translation table from DMX address to Pixel Node.
* Ability to address individual Pixels and a pre defined Pixel node color table of 256 values. This will simplify programs like Vixen, instead of 3 rows, one row per Pixel node.

Thank you for all the feedback.

As for this project, this will not be commercial, but it will rely upon surface mount components. Though, with a 200X mag USB camera, a toaster oven, a control board to run the reflow profile for the toaster oven, and SMD becomes even simpler than through hole!

Don't know if anyone has done a forum on reflow, though there is plenty of stuff on youtube to help anyone who is interested.

So as it stands, there will be 3 boards. The first to interface with the Microchip DM320004 Ethernet kit. The second, a differential receiver board that one will be able to solder the wires from the WS2801 rgb led string to. Finally, an A6281 board with 3 5050 led chips. If PWM is an issue, then this will be a board only for others to obtain and populate with their components.

Now to do the design and programming!

-Steve

[Entropy]

Ah, it seems we're talking about totally patents here. The I2C patents and the PWM + Colour Mixing patents are quite separate issues. I was talking about the PWM patents, which apply to completed items, not chips.

Those patents are licensed as part of Philips's pool on RGB LED control, but not the only ones. They happen to, however, be the ones to spark quite a long discussion on these issues a year or so ago when the listed inventor stopped by. What I do remember was verbiage that said you did not have to pay licensing fees if all of your components were sourced from Philips licensees.

[Entropy]

Ok,
So looking at the comments, and the feedback that I've received, aside from patents, I've decided to go with the following:
* Ethernet to 16 SPI ports (enhanced to handle both the WS2801 and the A6281 ( the A6281 will directly work with 12 volts, no extra components, but extra control lines ).
* SPI differential transmitter/receiver over CAT 5 and RJ45 connectors.
* An A6281 PCB with 3 PLCC6 5050 led circuit board (though this will be an easy design, I will make it last since there are already WS2801 rgb light strings out there.

Software design
* Of course, 10/100 mb Ethernet ( Configured for ART-NET ).
* A translation table from DMX address to Pixel Node.
* Ability to address individual Pixels and a pre defined Pixel node color table of 256 values. This will simplify programs like Vixen, instead of 3 rows, one row per Pixel node.

Thank you for all the feedback.

As for this project, this will not be commercial, but it will rely upon surface mount components. Though, with a 200X mag USB camera, a toaster oven, a control board to run the reflow profile for the toaster oven, and SMD becomes even simpler than through hole!

Don't know if anyone has done a forum on reflow, though there is plenty of stuff on youtube to help anyone who is interested.

So as it stands, there will be 3 boards. The first to interface with the Microchip DM320004 Ethernet kit. The second, a differential receiver board that one will be able to solder the wires from the WS2801 rgb led string to. Finally, an A6281 board with 3 5050 led chips. If PWM is an issue, then this will be a board only for others to obtain and populate with their components.

Now to do the design and programming!

-Steve

Other than using the Microchip dev board (which, tbh, is quite an expensive board...) instead of Propeller + Wiznet, what do you feel that this offers over the PropController or jstjohnz's project?

The two things new I see are:
A6281 support (and a side project for A6281 nodes) - could be added to PropController or jstjohnz's pixel controller in software
Differential driver for long runs - could be done as a PropController daughterboard

Have you considered working with Ben or Jim on their projects?

(Unless, of course, your goal here is learning/personal challenge, in which case - go ahead!)

[P. Short]

What if it's just fun?

Part of the name of this forum is 'doityourself'. This is, admittedly, a fairly big project, and perhaps partially overlapping other projects, but so what?

[ErnieHorning]

What I do remember was verbiage that said you did not have to pay licensing fees if all of your components were sourced from Philips licensees.This is only an issue if you are going to sell something you make that does the same as a patent. If you make it for personal use, you can use anybodies patent. I regularly check out patents for idea's, it's public info.

This is DIY and you can do darn near anything you want for your own use.

[Entropy]

This is only an issue if you are going to sell something you make that does the same as a patent. If you make it for personal use, you can use anybodies patent. I regularly check out patents for idea's, it's public info.

This is DIY and you can do darn near anything you want for your own use.
Technically, a patent holder COULD go after you in this case. By the letter of the law, you can go after an end user of an unlicensed infringing product.

However, it almost never happens, as it is rarely worth the time and effort on the part of the patent holder and it's bad PR. It would never happen in the case of a DIYer. The biggest risk for us is the potential for some of our orders to get impounded by customs in the case of importing unlicensed WS2801-based devices from Asia. (However, it is currently highly unlikely.)

[ErnieHorning]

Technically, a patent holder COULD go after you in this case. By the letter of the law, you can go after an end user of an unlicensed infringing product.I've researched this a bit and believe that under the experimental use doctrine, scientific experiments which do not deprive a patent owner of his lawful rewards for having made his invention are exempt from infringement liability. I believe that anything that we do here that isn't intentionally aimed at ripping off a patent holder won’t be an issue. At the most I also believe we would just be asked to remove such a design from this site.

[David_AVD]

Those patents are licensed as part of Philips's pool on RGB LED control, but not the only ones. They happen to, however, be the ones to spark quite a long discussion on these issues a year or so ago when the listed inventor stopped by. What I do remember was verbiage that said you did not have to pay licensing fees if all of your components were sourced from Philips licensees.

Well, all I can say is that when I spoke to the actual Philips licensing guy, he made it very clear that the patents for PWM + colour mixing did not apply to chips. He confirmed it in writing as per my other post.

Anyway, sorry to the OP for the diversion - back on track!

[Entropy]

Well, all I can say is that when I spoke to the actual Philips licensing guy, he made it very clear that the patents for PWM + colour mixing did not apply to chips. He confirmed it in writing as per my other post.

Anyway, sorry to the OP for the diversion - back on track!

I think they changed the program slightly in the past year. I'm absolutely positive that NXP was previously listed as a "qualified supplier".

Either way, it really doesn't affect us other than the possibility that import strands have the potential to run afoul of customs. See http://doityourselfchristmas.com/forums/showthread.php?12082-WS2801-controllers&p=123139#post123139 - mrpackethead knows the specifics of licensing, I believe his company has paid all relevant licensing fees for his strands.

Getting somewhat back on track - the PIC32 looks kind of interesting given that it has a MIPS core, so support as a GCC target is possible for it. However the question is how robust the debug functionality is compared to that available for ARM Cortex-M3 micros - These provide quite robust debug functionality using fairly inexpensive hardware (For 3.3v parts you pretty much need an FT2232 and that's it to debug with OpenOCD.)

As to P. Short's question of "what if it's just fun" - Some of secanell's comments led me to believe he might not be familiar with what is out there already. I may have been wrong about that, but I think when duplicating effort, it should be a conscious fully informed decision based on full knowledge of what is available.

[secanell]

Other than using the Microchip dev board (which, tbh, is quite an expensive board...) instead of Propeller + Wiznet, what do you feel that this offers over the PropController or jstjohnz's project?

The two things new I see are:
A6281 support (and a side project for A6281 nodes) - could be added to PropController or jstjohnz's pixel controller in software
Differential driver for long runs - could be done as a PropController daughterboard

Have you considered working with Ben or Jim on their projects?

(Unless, of course, your goal here is learning/personal challenge, in which case - go ahead!)

As for cost of the Microchip board, I agree that it is not cheap, but then compared to some of the commercial DMX systems that I've seen that use USB, I feel that the bandwidth gained is not a bad improvement for the cost.

With regards to the other projects, I am not familiar with these projects and the people that are leading them.

I am certainly am willing to work with others, I really do play well in a sandbox! :-)

Finally, one of the things that I've learn over time is that if you want to understand something, then build it, so that is what I am looking to do, but certainly not to interfere with other designs.

As for my background experience in Christmas lighting as you guys experience here, I am about as green a sprout as you can find, so I am still coming up to speed on what work is being performed.

If you think the A6281 would be a nice addition, that is a simple project to put together. The only thing I need to do is get together with Ben or Jim to see how it would fit into their project since the chip requires a bit more in signal control compared to the WS2801, but certainly uses less components for a higher voltage project (12V vs 5V).

-Steve

[DynamoBen]

If you think the A6281 would be a nice addition, that is a simple project to put together. The only thing I need to do is get together with Ben or Jim to see how it would fit into their project since the chip requires a bit more in signal control compared to the WS2801, but certainly uses less components for a higher voltage project (12V vs 5V).

I'm Ben and I'm working on the PropController (http://doityourselfchristmas.com/forums/showthread.php?12334-NEW-PropController-Project). The A6281 does look interesting and if memory serves the ShiftBrite uses it, this could be a cool addition to the ever increasing list of RGB solutions.

Its your call whether you blaze your own trail or lend a hand on an existing project (or do both), either way we are here to help.

[Entropy]

I think the A6281 does have potential as a "module controller" for RGB elements sized somewhere between "pixel strands" (WS2801 seems to be optimal here) and "large floodlights" (May as well just have per-node DMX reception for large floods since the LEDs alone dominate the cost). It might do very well for an application like a "path" of medium-large RGB globes - need more power than single-emitter pixel strands but not as much power as the "big gun" floodlights. (I remember someone had a show where they stuck Mighty Minis into a bunch of snowmen to create RGB snowmen. TBH the MMs were overkill for this.)

I think for a "midscale" application like what I describe, the extra required control lines wouldn't be too much of an issue.

Heck, if you get a board design done I'll probably order up a few to play with and maybe add support to it for a project I have in mind.

Another board you might find interesting is http://www.mouser.com/ProductDetail/Texas-Instruments/EKC-LM3S6965/?qs=AFkNxQkJKALa537ntUKhFA%3D%3D - Similar in price to the DM320004, similar capabilities.

Pros: ARM Cortex-M3 core (The CM3 has quite a few nifty features such as bit-banding)
Support by open-source development tools (gcc compiler, OpenOCD debugger)
CM3 core is present in a wide variety of micros from multiple manufacturers, leading to a potential for code reuse. (Although in reality, while CMSIS is constantly improving, it "isn't quite there yet", only supporting core functionality.)

Cons: Slightly slower than the PIC32 on that board (50 MHz instead of 80 MHz), however the "nifty tricks" available in the ARM core might result in better performance on some types of workloads.

The neat thing about the Luminary eval kits is that they can actually be used as a JTAG debugger for any ARM target board with the standard 20-pin ARM debug header.

[secanell]

Ben,
Your correct about the ShiftBrite. It does use the A6281.
My plan for the A6281 is to configure a circuit board that one can mount 3 PLCC6 5050 rgbs, but I plan to place them close together in a circle ( opinions welcome ). The IC and resistors (1 cap) will be on the bottom side of the board and the top side will be display leds only. I also thought about providing 4 pads on the led side so that is someone wanting to cut up some of those 5m 150/300 led strips, that they would be able to attache the 3 led strip to the circuit board as well.

For weather protection, I was going to use Sylgard 184 to cover all of the components ( and see if there is an appropriate plastic case to encase the PCB with the Sylgard. Sylgard seems to get used a lot for solar panel creation, so it should be reasonably weather worthy.

I currently have 25 of the A6281 chips.. nice package... QFN-16. Should flow nicely in a reflow oven.
Currently coming up to speed on Eagle PCB program. Designed a board using PCB123 but found that the cost from SunStone for development didn't apply to those that used their PCB program, so have looking at a cost of over $300 for PCB, I dropped the design. I had even uploaded the data to their web site but never followed up with any boards.

So.... back to the drawing board.

As for the Microchip, there is a Linux software development that has been going on for some time, so that is also a posibility. Microchip provides development software for free for their hardware, but it doesn't contain optimized code. I haven't investigated the Linux path yet to find out what is supported....etc, only know that it exists!

-Steve

[DynamoBen]

Ben,
Your correct about the ShiftBrite. It does use the A6281.
My plan for the A6281 is to configure a circuit board that one can mount 3 PLCC6 5050 rgbs, but I plan to place them close together in a circle ( opinions welcome ). The IC and resistors (1 cap) will be on the bottom side of the board and the top side will be display leds only. I also thought about providing 4 pads on the led side so that is someone wanting to cut up some of those 5m 150/300 led strips, that they would be able to attache the 3 led strip to the circuit board as well.

Sort of like this? http://www.sparkfun.com/products/10236


Currently coming up to speed on Eagle PCB program. Designed a board using PCB123 but found that the cost from SunStone for development didn't apply to those that used their PCB program, so have looking at a cost of over $300 for PCB, I dropped the design. I had even uploaded the data to their web site but never followed up with any boards.

So.... back to the drawing board.

I use DipTrace which is free up to 200 pins. Super easy to learn and use and doesn't have an odd UI.

[Entropy]

Satellite module - I believe that is minus the actual A6281. I think what he's describing is kind of along the lines of a ShiftBar + SM combo, with the possibility of disconnecting the onboard LEDs and attaching an external device instead?

Popular options here seem to be Eagle and also some people are starting to use Kicad. I plan on making the transition sometime this year or next but haven't yet. There's a thread here somewhere on PCB development software, which also started branching into a "favorite boardhouse" discussion. Seeed's Fusion service and the group buys run by Laen at DorkbotPDX both have great promise for low-mid quantities (which is best depends on board size and quantity).

As to "free" development tools - there's "free as in beer" and "free as in freedom", which is how the term "open source" came into play. (Too many people associate "free" with "freebeer", Stallman wants people to associate it with "freedom" but everyone else realizes that isn't going to happen, hence "open source".) ARM-targeted GCC is in the "open source" category, not just "free beer" like it appears Microchip's tools are. Sounds like the lack of optimization in the free PIC32 compilers might make up for the clock speed deltas. I admit I'm a bit of an idealist here - I'll consider non-open tools when they provide a clear undeniable advantage (e.g. "free-beer" Xilinx or Microsemi/Actel tools vs none whatsoever for FPGA work), but have a strong preference for the "open source" stuff (hence my tendency to go towards AVR and ARM microcontrollers, since both happen to be GCC targets).

[budude]

I use DipTrace which is free up to 200 pins. Super easy to learn and use and doesn't have an odd UI.

+1 on DipTrace - absolutely hate Eagle but I know many folks use it. Another good one is PCBArtist - very easy to use.

[ags0000]

...As to "free" development tools - there's "free as in beer" and "free as in freedom", which is how the term "open source" came into play. (Too many people associate "free" with "freebeer", Stallman wants people to associate it with "freedom" but everyone else realizes that isn't going to happen, hence "open source".)...

Whew, I thought you were going to post the Manifesto here :-)

[aussiephil]

Steve

Very late to this thread, if you are doing this as a learning experience then a huge thumbs up, have fun.

We already have a PIC32 based SPI/Pixel controller that would be quite easy to add hardware SPI outputs to so we could also drive the A6281's.

Seriously I looked at doing exactly what you are doing for my icicle light project this year but with one of the TLC* variants........
I shelved it as it is just easier/cheaper to do it with 2801/6803/1804 pixel nodes from China and use the existing TP3244 controller to drive them.

The PIC32 platform has plenty of performance but any platform will need careful coding to handle the incoming Ethernet data and stream out the SPI.

Entropy: i was even looking at using I2C as the transport medium using PCA* chips for each vertical drop, plenty of time to do around 4k channels from the one PIC32 even at 25ms timings from Vixen.
The trouble is I just don't want to build the strings anymore

Aussiephil

[secanell]

Steve

Very late to this thread, if you are doing this as a learning experience then a huge thumbs up, have fun.

We already have a PIC32 based SPI/Pixel controller that would be quite easy to add hardware SPI outputs to so we could also drive the A6281's.

Seriously I looked at doing exactly what you are doing for my icicle light project this year but with one of the TLC* variants........
I shelved it as it is just easier/cheaper to do it with 2801/6803/1804 pixel nodes from China and use the existing TP3244 controller to drive them.

The PIC32 platform has plenty of performance but any platform will need careful coding to handle the incoming Ethernet data and stream out the SPI.

Entropy: i was even looking at using I2C as the transport medium using PCA* chips for each vertical drop, plenty of time to do around 4k channels from the one PIC32 even at 25ms timings from Vixen.
The trouble is I just don't want to build the strings anymore

Aussiephil

Phil,
I chose to go with the DM320004 because it was already configured with debug, ethernet, usb.... so my choices for configuration are great... in my opinion.

The interface connector in small quantities is rather expensive at $7+ each in small quantity. I have 3 of those so I'm on the way along with the DS26LS31/32 differential chips for the spi. The DM320004 uses PHY for the ethernet interface, so binging integrated with Ethernet, I felt it was save to work with for a project like this. Ive also picked up a couple of Sparkfun 328 boards to investigate, but will work first with the the Microchip.

As for price of the board ($79), I purchased a Open Source DMX for almost that much, so can't say that it broke the bank.

As for the PCA9635, I picked up some PCA9622 because the output side would handle 40V and about 100ma, so lots of room, but decided against I2C do to speed once I found the A6281s and the communication profile for those devices. The 2801 look great, but finding those bad boys on the market seems to have 3 chances... fat, slim and none.... at least from my research so far. Thats ok though, the A6281 works directly with up to 17 volts and 150 ma per led. Only requires a resistor and a capacitor, 1uf at about 16 volts. The chip has an internal voltage regulator. Cool in my book, but boy is the chip small.... qfn-16 and the chip is 3mmX3mm. The pads are about .9mm by .3mm, 4 per side.

-Steve

[mrpackethead]

What are you seeing on the price of 5050 chips?

Also, isn't the WS2801 the part that had licensing issues that affected their importation into the US? If so, has this been satisfactorily resolved yet?

I have sucessfully imported tonnes of WS2801 based systems into the USA for commerical use. We have a licence aggreement in place with the Patent owner to do so. At least for me, its resolved. THe chip itself is not the problem. Its the end use of it. Its also interesting to note that the same thing applys for almost all of the other chipsets that are being used in these "pixel" type lights.. certainly if you import made up pixels with 6803, WS201, TM1804, 3005 ( not an exhauative list ), then you have the patent infringement problem.

At least for me, arguing the point about the validity of the patents and their applicaiton is just not worth the aggro, and i don't want to defend some very expensive litigation with a large multi-national. Can't say i'm happy that i have to pay money out for the priviledge of using this, but its just the way it is, and we have to move on.

[mrpackethead]

Last year, we built our E16 based on a pic24, and connected it one of microchips ethernet controllers, used the Microchip IP stack, and got both Art-net and E1.31 going happily.. ON the output side, we use teh hardware SPI ports and drive 16 different strings by multiplexing them. FYI, i've had teh DM320004 for some time, and i'm currently porting out 16bit code stack across to the 32 bit PIC32, and am in the last stages of debugging it. in 2009, i did a project using a propeller, it worked, but it was a dog. ( bad code/bad design i don't know ), but i do know that with the PIC24 we can happly receive 8+ universes, and drive lots of pixels..

Point i'd like to make is, that you're heading down a path that is very fesible, has been proved to work with many hundreds of these controllers deployed in the field.. Keep tracking down this path and you'll be sucessful.

[secanell]

Last year, we built our E16 based on a pic24, and connected it one of microchips ethernet controllers, used the Microchip IP stack, and got both Art-net and E1.31 going happily.. ON the output side, we use teh hardware SPI ports and drive 16 different strings by multiplexing them. FYI, i've had teh DM320004 for some time, and i'm currently porting out 16bit code stack across to the 32 bit PIC32, and am in the last stages of debugging it. in 2009, i did a project using a propeller, it worked, but it was a dog. ( bad code/bad design i don't know ), but i do know that with the PIC24 we can happly receive 8+ universes, and drive lots of pixels..

Point i'd like to make is, that you're heading down a path that is very fesible, has been proved to work with many hundreds of these controllers deployed in the field.. Keep tracking down this path and you'll be sucessful.

Just curious about configuration control. I planned to do the same, to do 16 strings from the DM320004 daughter board, but the output will be with differential drivers.

How did you tell the software in the PIC how many pixel nodes per string? Is this something that is dynamic, did you use an I2C eeprom to store the info, default the configuration for each string in the program????

Since I am not totally up on art-net and certainly not E1.31, is there a command in there to dynamically upload the configuration?

Thank you in advanced.
-Steve

[mrpackethead]

Just curious about configuration control. I planned to do the same, to do 16 strings from the DM320004 daughter board, but the output will be with differential drivers.

I've built a diff driver/recever and DC/DC converter to drive a string of pixels down a bit of cat5 about 200m.. Sticking 48V down it, keesp the current to about 300mA which is quite feisble.




How did you tell the software in the PIC how many pixel nodes per string? Is this something that is dynamic, did you use an I2C eeprom to store the info, default the configuration for each string in the program????



Config is via a onboard web page, which you access. and yes, we used an I2C to store all the config data.

[ags0000]

I've built a diff driver/recever and DC/DC converter to drive a string of pixels down a bit of cat5 about 200m.. Sticking 48V down it, keesp the current to about 300mA which is quite feisble.

If you're keeping up with this thread, you might have noticed that's what I've been considering for some time now. I think it's the most flexible, robust and elegant solution. Allows for the most options when designing/constructing a display (strings can located based on aesthetics, not where the controller/power supply is). However, it does add cost and may not be needed in many configurations (as in a megatree where all strings can be supplied/controlled from a central point).

Can you provide some guidance as to how I'd most efficiently (in terms of both power loss and cost of components) construct a 48->5V (or even 24->5V) DC-DC converter for use at the strings? The diff rx/tx is just a simple component, I believe.

Thanks.

[P. Short]

For voltage conversion, someone suggested using an LM2576...a switching converter good for 3A.

[mrpackethead]

If you're keeping up with this thread, you might have noticed that's what I've been considering for some time now. I think it's the most flexible, robust and elegant solution.


Sorry i'd missed that.



Can you provide some guidance as to how I'd most efficiently (in terms of both power loss and cost of components) construct a 48->5V (or even 24->5V) DC-DC converter for use at the strings? The diff rx/tx is just a simple component, I believe.
Thanks.

Heres the schematics of the circuit i use regulally, based on a National LM5085. Its good for inputs between 12 and 50VDC and its > 90% efficent, and it will ouput 5VDC at 3A. Its packaging may be a problem to you, its an MSOP.. Its got an external fet rather than than an internal one. If you are looking to do smaller currents there are better placed options ( lower cost ). Capacistor choice is quite important in these designs, electroyltics don't like much ripple, so, on the output, you need to either use a tantilum, or pick a way over rated electrolyic ( say 50V ), to keep it reliable.

http://sphotos.ak.fbcdn.net/hphotos-ak-snc6/hs007.snc6/165768_10150094553582661_645277660_6013858_2734175 _n.jpg

http://http://sphotos.ak.fbcdn.net/hphotos-ak-snc6/hs007.snc6/165768_10150094553582661_645277660_6013858_2734175 _n.jpg

[ags0000]

@P.Short: Yes, that looks good. Would that require a linear regulator at the output before driving a differential Rx? I don't have a scope so don't know how clean the OEM supply for my RGB string is, so I don't know if that might require a linear regulator even if the Rx chip doesn't.

@mrpackethead: I have to get my head around that design a bit. VCC connected to +V through a cap in series? 3A @ 5V (or perhaps 5.6V depending on what I find when I can get test an OEM supply under load) is the design goal, as is cheap and reliable. I'm not sure if I'll need to go to 48v or if 24v will be enough down the Cat5 line (design goal is 100' Cat5 line).

Also, let me clarify: My "If you're keeping up with this thread" poorly-chosen comment was meant to point out that my "thoughts" on the subject are getting buried in the past, not that you should be reading carefully and not post similar information. Heck, the farthest I've gotten on this topic is thinking - you've actually implemented a design. Thanks for the response.

[mrpackethead]

the VCC bit looks odd, i know.. But it is correct. VCC is the output of the gate driver bias regulator.. Its a negative voltage regulator ( relative to Vin ) that provides bias to the Gate driver. Theres lots in the national datasheets about it.

[secanell]

the VCC bit looks odd, i know.. But it is correct. VCC is the output of the gate driver bias regulator.. Its a negative voltage regulator ( relative to Vin ) that provides bias to the Gate driver. Theres lots in the national datasheets about it.

So mrpackethead,
I've looked at your dc/dc converter design which matched National Semi web site. I went to digikey and put the parts together and it turns out that I can build a 6A version @ 12V for the same price as your 3A 5V, at least according to digikey for parts prices... turns out to be over $10 ea for qnty 10 and not much better for qnty of 20.

I was curious about pic32 design... which by the way, I have the hirose male connector defined in my eagle lib.
For the multiplexing, did your use an "and" gate with separate diff driver, or did you find something a bit more elegant.

I am planning on using the DS26LS31 driver and 32 receiver. The only thing is if I use RJ45, then, in my case, will loose the ground line for the driver due to the A6281's requirements of 4 lines (diff would = 8 wires) hmmm just the same amount as an RJ45 line!

I am thinking that only the data/clock line needs to be diff and the load / output line be single ended.
In the document for the A6281, they indicate to bring the output high and then trigger the load and then enable the output after the pwm register is loaded.

I'll have to build up one of the A6281 boards to see what would happen if the OE is left enabled.

As for the A6281, I have a 3 RGB 5050 board designed and ready to go to the board house. Haven't sent the gerber files yet since I do not have anything to test with if I did get the boards printed and populated.

I feel like the chicken and the egg thing! :)

Ok, anything that you would like to share on the subject is appreciated.

-Steve

[secanell]

There were a couple of respondents that clicked how to do reflow oven work for smd / smt devices.
There are some youtube sessions on this using a toaster oven.
My recommendation is to get a toaster oven reflow controller. I've found two out there on the market. One on ebay for about $63 and the other doing a google search. Both units require additional components such as a K type thermocouple, an SSR with heatsink, cabinet and electrical cord, and power supply for the board, but hey, you guys are DIY aren't you?
The first: techFX reflow 3.0 toaster oven SMD controller! http://www.thesiliconhorizon.com/Products.htm
The second is Reflow Toaster Controller from Sparkfun. Sells for about $90.

The first one comes with free computer software but with addtional I2C components, can be made standalone. The software talks to you!

-Steve

[budude]

There were a couple of respondents that clicked how to do reflow oven work for smd / smt devices.
There are some youtube sessions on this using a toaster oven.
My recommendation is to get a toaster oven reflow controller. I've found two out there on the market. One on ebay for about $63 and the other doing a google search. Both units require additional components such as a K type thermocouple, an SSR with heatsink, cabinet and electrical cord, and power supply for the board, but hey, you guys are DIY aren't you?
The first: techFX reflow 3.0 toaster oven SMD controller! http://www.thesiliconhorizon.com/Products.htm
The second is Reflow Toaster Controller from Sparkfun. Sells for about $90.

The first one comes with free computer software but with addtional I2C components, can be made standalone. The software talks to you!

-Steve

I have the SparkFun controller - works great and follows the standard heating profile almost perfectly. It comes with the firmware needed to run it - you don't need a PC to run it but it does have a serial port so that you can record the actual temp (it shows it on the LCD panel as well). I built the bulk of my ACL strobes with it so far.

[timon]

I have sucessfully imported tonnes of WS2801 based systems into the USA for commerical use. We have a licence aggreement in place with the Patent owner to do so. At least for me, its resolved. THe chip itself is not the problem. Its the end use of it. Its also interesting to note that the same thing applys for almost all of the other chipsets that are being used in these "pixel" type lights.. certainly if you import made up pixels with 6803, WS201, TM1804, 3005 ( not an exhauative list ), then you have the patent infringement problem.

At least for me, arguing the point about the validity of the patents and their applicaiton is just not worth the aggro, and i don't want to defend some very expensive litigation with a large multi-national. Can't say i'm happy that i have to pay money out for the priviledge of using this, but its just the way it is, and we have to move on.

If I found the correct information on Phillips's web site the license is 5% of the net selling price. I would assume that's only for the strings and not the DMX to SPI controller since it has nothing to do with the PWM patent. Now if you had a non-pixel string with the DMX controller doing the PWM the it would be subject to the license.