Networked LED driver: rough design, options

[ian]

Goals:
48 channels of 10bit PWM LED control
Ethernet interface
up to 120mA per channel
LED current set with a single resistor (no individual resistors needed!?!?)

Seeed Studio bought 500 additional PIC24FJ64GA002-SOs that went unused after the Hack a Day Bus Pirate presale. I've been considering various ways to use these chips since they'll be reasonably priced and immediately available.

The design that I'm most interested in working up at the moment is a 48 channel LED controller with an ethernet interface.

The board would use the 24FJ64GA002-SO as the main microcontroller, and an ENC28J60 for the network connection. A 25AA02E48 EEPROM would hold settings and a unique MAC address so multiple boards can share the same network.

The LEDs would be driven by three TI TLC5940s, each with 16 channels of 10bit PWM. The current of the LEDs connected to the TLC5940 is set with a single resistor, ideally this would be done with a digital pot for easy network configuration. This chip is cascadable, so an expansion header would make it possible to stack multiple expansion boards on top of the base.

This design will have a bootloader, but it will be brought to a serial header only. I'll ask seeed to find a cheap USB->serial cable and make the header compatible with that.

Like the #twatch, I'd like to give the board a 'default' demo mode, probably an implementation of the internet-driven daft punk table.

Any thoughts, suggestions?

[ian]

Here's my sketch.

[Scorpia]

i really like this idea.

couple of things to note.

1. please at least wire the serial uart to a header for serial input or output.

2. even better would be a uart-dmx or uart-rs485 output.

3. from memory the LED driver chips are limited to about 17v output. but they can be configured with fets on the output to then drive almost any voltage led string. i know here in AUS 24v and 36v christmas strings are easy to find. this would allow driving alot more than just a single led on the output.

4. Im not sure how many of those led driver chips can be cascaded but maybe think about a header to allow for more chips to be added.

5. a header from the eeprom chip for expandability with some extra i/o for sopme c/s pins would be good. From my understanding this would allow for a rom board with multuiple chips each selectable via c/s i/o pins to me added for extra storage.

6. consider the sd card for starage as well. This would allow for huge sequences and standalone operation easily.

7. Audio output? sync lights to MP3 tracks?

8. allow the current for each chip to be set individually. that way the different chips can drive different current loads

From my point of view i would love to see this developed the same way the sump pump was. as the development process that is going into the sump pump was great to watch even if alot of it was over the head of some of us :)

anyway great idea. lets see what happens with this.

[ian]

Thanks for the input. 1, 4, and 8 are planned features, the other suggestions are great too!

[andrew]

Hi Ian,
I've been keen to get into some design for a while and seemed to miss the boat on the logic analyser, so I'd like to help out here.

I like the idea of incorporating DMX, shouldn't be too difficult. If cost is an issue it could be a daughterboard (consisting of an rs485 driver chip).

I'd vote against sound output - that's a lot more complex. A control signal to sync with an external mp3 player might be helpful for that application though? ie. the LED controller presses "play" and starts the show, while all that annoying mp3 decoding is dealt with elsewhere.


Anyway, let me know how I can help :)
(I haven't programmed PICs before, but I'm sure with some experimenting on my soon-to-arrive web platform I'll figure it out. I have used EAGLE to make PCBs.)

[IPenguin]

The PIC UART programming header could have a multi-purpose fuction:

- Serial communication (the cheapest ready available 3.3V UART/USB converters are the Nokia CA-42/DKU-5 compatible cables. You can get them from about € 2 /US$ 3 plus shipping - they work up to 115200 baud) ...
- USB Flash disk interface via FTDI VDRIVE2
- USB Flash disk interface plus MP3 playback via FTDI VMUSIC2

[brett]

i second the vote for LED decoration string usage for "standard" ("common"?)  LED strings in AU - I think every single one I have here right now is 24v.... but that is a sample size of 2 :)

[iDream]

Hi Ian,

I like the idea of networked LED controller. Do you think three TLC5940s get a bit too dense and too hot under full load? The ENC28J60 is not exactly cool running! One is good enough for me. I'd prefer if you reserve those space for the micro-sd card and other features. If the final board is similar to #twatch in size or smaller, that would be nice too.

I'd also like to see one or more cascade ports on the side of the board, this make cascading easier.

How about consider making the TLS5940 and LEDs as an add-on daughter board that plugs into the controller? (or attach via cables)  For example, you can make add-on boards with TLS5940 and RGB 8*8 LED matrix (seeed's Rainbowduino) so that you can cascade them to form a long strip of color dot matrix display(another #twatch?!?), or an add-on board with TLS5940 that has 4 strips of 4 LEDs (4x4 matrix) hanging out which you can cascade to make the 3D LED cube similar to those you see in Youtube and various other website. You never know, these add-on boards may become another users hackable projects. (Shields?)

I hope I'm making sense?;-)

[andrew]

How about consider making the TLS5940 and LEDs as an add-on daughter board that plugs into the controller? (or attach via cables) 

If I understand this right: the main controller board just has the µP etc, no TLC5940s. Instead it has a port to plug in daughterboard(s), each with n TLC5940s.
That sounds like a good idea to me. That way people only pay for the amount of LED drivers they need. A version of the daughterboard could easily cater for the 24V strings mentioned previously.

The daughterboard connector would need the TLC5940 serial data pins, power, and probably I2C/SPI for the digital pot.

Question for Ian:
Have you seen the TLC59401?
It's almost the same as the TLC5940, except it doesn't have an EEPROM inside. Since your design has EEPROM already for the MAC address, why not use that same EEPROM for the dot correction data and load it each time on power up?
Then you don't need a 22V supply to program the EEPROM in the TLC5940s.
Plus the 59401 is cheaper. Less suppliers listed on the TI website though.

[ian]

At the moment I'm planning a single board with all components, not a modular system (expansion boards can be used though). I had looked at the TLC59401, but it was listed as unavailable at the time. I was also hoping to use the DIP package for better heat dissipation (59401 is SSOP and QFN only).

[andrew]

Ahh, I see. I was deceived by the seemingly better heat/power figures of the SMD packages, didn't notice that you need a giant hunk of copper to solder the "PowerPAD" on to.

[Rubi]

awesome

>I'll ask seeed to find a cheap USB->serial cable and make the header >compatible with that.
If you could use the pinout of the ftdi cable, that would be great.
This became a quasi standard.

Your device could light an awesome xmas tree. :)

[sburlappp]

At the moment I'm planning a single board with all components, not a modular system (expansion boards can be used though).

All this discussion of Arduino-like add-on boards got me to wondering....

Couldn't you just replace the LCD on a #twatch with a TLC5940 daughterboard and different software? You'd need a separate power input for the LEDs, but that's probably required anyway.

[ian]

Sure. For this design though, I'm going to hit on a few points that were left out of the Twatch. First, it's going to use a 16bit processor because they're cheaper and easier to use than the 8bit PICs. Also, I don't want to use chips with a limited write cycle anymore because it limits hackability. Finally, I want to use the MAC EEPROM so each board has a truly unique ethernet address. The final board looks more like the v1 #twatch with a 24fj64ga002 than the v2 twatch with the 18f67j60. It should be ready soon, I'll post a preview ASAP.

[brett]

I agree, the 100 write cycle Ethernet chips seem kinda.....pointless as a hackable device.

Kind of a side topic, but I'm interested to know how your code had to be changed between #twatch and Web Platform (integrated Ethernet vs ENC28J60).  How truly portable was the code to move back and forward, so was the limited write cycle really an issue (in "static" projects, obviously)