I've been searching for a way to daisy chain the tlc5940 over medium distances and started to think it was not possible until I saw this guy:
His web site is short on details and in a language I don't understand. Can anyone tell what he is doing?
I have the 4 tlc5940s that I need for my project working great when they are connected close together. But as soon as I start separating them by the 2.5 feet I need (maximum run 10 feet) they stop working. I want to have TLCs separated and close to the leds they will driving because it will greatly cut down on the number of wires I need to run between the sections. I understand there are distance limitations with the method the TLCs use to communicate. But I see there are allot of add on modules for the arduino that allow it communicate over longer distances (such as with rs-485). Is there anything like this that would work for the TLC5940? Thank you.
I use the 8 LED version the TPIC6B595 and have strung them all over the place on 2.5 x 3.5 meter boards like this one, with ribbon cable between with no problems .
I use Shiftout which I think is slow, but works fine - and who needs milliseconds to score a game like cricket !
and who needs milliseconds to score a game like cricket !
A few hours update period should be OK for cricket I would think. Actually in Aus we use modified versions of those devices they use to measure tectonic plate movement.
I have done spi over 10ft at 100khz. If you have issues, it is most likely with capacitance on the line, limited drive or too high of a speed. Using shielded cabling helps and you can always slow down your speed.
Somehow I doubt that it has anything to do with shielded ethernet cable, those are a couple twisted pairs of wires with a wrapped shield and drain wire, its not very good shielding. Cable TV type cable has braided shield, that would work good if you really need shielding.
Hippynerd:
Somehow I doubt that it has anything to do with shielded ethernet cable, those are a couple twisted pairs of wires with a wrapped shield and drain wire, its not very good shielding.
Thanks everyone for taking the time to reply to my questions.
I have already bought a bunch of tlc5940, and I want pwm control, so I am pretty much locked into them for now. After seeing this video I did give a 5 ft long cat5e cable a try. I didn't have any female connectors like the guy in the video, so I had to solder the wires to header pins. Maybe I did a crap job on the soldering, but it didn't work. One thing that occurred to me is he is only connecting two tlc5940s. I am trying to connect a 4th one with a long cable. Maybe that is a significant difference?
I have read in other places that reducing clock speed can increase range. But can I do this for the TLCs? That will not interfere with how they communicate/operate? What are the drawbacks?
It seems like RS-485 would solve my problem. But what I am confused by is do I need an arduino at each node? Of course it would not need to be a full arduino, just basically a processor that can talk to the RS485 chip and then send the correct spi signals to the TLC? That sounds like it might be a whole project in of itself. I did some searching for a ready made spi --> RS485 ---> spi device but did not turn anything up. Does anyone know of the existence of a product like that?
I am basically trying to weigh the effort/cost of investigating a node based solution against the pain of just making a bunch of connectors and using a ton of wiring. Going at it from the other direction, is there an efficient way to churn out wires with connectors? 4 segments each needing to connect to each other. The last segment 1 connector, the one before 3 connectors, then 5, then 7 for the first one in the chain and its connecting 7 for a total of 23 connectors. With 18 wires in each connector that is 414 individual connections I have to make! Its amazing how quickly something like this scales up. 10ft of lights didn't really seem like it would be that big of a deal...until I actually tried to do it
BTW: I really dig that controller for the cricket board.
I saw on the datasheet for the TLC5940 an equation for clock speed depending on the number of devices daisychained ( which they say can be up to 40 )
Figure 22 shows a cascading connection of n TLC5940 devices connected to a controller, building a basic
module of an LED display system. The maximum number of cascading TLC5940 devices depends on the
application system and is in the range of 40 devices. Equation 10 calculates the minimum frequency needed:
where:
f(GSCLK): minimum frequency needed for GSCLK
f(SCLK): minimum frequency needed for SCLK and SIN
f(update): update rate of whole cascading system
n: number cascaded of TLC5940 device
BTW: I really dig that controller for the cricket board.
The first cricket board I made had to be operated by an 80 odd year old scorer, who didn't want any menus or that rubbish , so I used the thumbwheel switches laid out exactly as the board, WYSIWYG, and its so simple I have stuck to it since.
Boffin1:
I saw on the datasheet for the TLC5940 an equation for clock speed depending on the number of devices daisychained ( which they say can be up to 40 )
Figure 22 shows a cascading connection of n TLC5940 devices connected to a controller, building a basic
module of an LED display system. The maximum number of cascading TLC5940 devices depends on the
application system and is in the range of 40 devices. Equation 10 calculates the minimum frequency needed:
where:
f(GSCLK): minimum frequency needed for GSCLK
f(SCLK): minimum frequency needed for SCLK and SIN
f(update): update rate of whole cascading system
n: number cascaded of TLC5940 device
That's nothing to do with electrical limits of the wires/chips, it's just about having enough time to send all the data for a given update rate (never a problem for cricket).
Hmm, I dont know why you are having trouble then, I thought of perhaps using those chips myself as they have constant current drive, but after seeing the price, and the troubles you are having, I think I will stick to what I have.
For most of my boards I only need 7 pins on a driver behind each display number anyway.
I cant find the screenshot of it, but I checked the waveforms coming out of the micro and that coming out of the 19th display chip and all looked identical on my scope, and thats after say 20 meters of daisychained shiftregisters via ribbon cable....
They just need 5v, gnd, and the data signal input. This outputs a balanced signal pair which goes down a twisted pair cable. The same chip can receive this signal and convert it back into the original unbalanced data.
I've tested over >120m of cat5 but apparently you're good for >1000m
Thanks everyone, this has been a great help to me. After much research I have come to the conclusion that using rs485 is the answer. I was resistant at first, but after researching it actually doesn't seem like it will be too difficult. The needed hardware is also much cheaper than I thought it would be. I have ordered a batch of tlc5940s for about $1.10 each, atmega328p batch for $1.20 each, and the max485 for $0.18 each. With a few of the small extra parts needed, I might be able to have addressable long range 16 channel pwm led nodes for under $4 each. That would be amazing...if it works
There is one thing left that puzzles me. Would I be able to use the max485 to upload my sketches to the remote atmega328s? It would be a bummer if I had to pop the chips out, load the sketches and then put them back every time I wanted to make a change. The following link has a tutorial where this guy is using a max232 wired to tx/rx of the atmega328 and the other end connecting to a pc via serial cable:
If I wired up the max485 in a similar way, would I be able to upload sketches in this manner?
The 328's bootloader is happy as long as you can delivery the bytes to the UART, if that's by RS-485, USB or modulating a flash light it doesn't matter.
The trouble is you have to reset the processor first, and that's normally done with a cap on the DTR pin of the USB interface. Somehow you have to implement that reset to get into the existing bootloader.
The other way is to write your own bootloader that does things differently. Not a task for a beginner, but you could have a protocol that accepted commands form the master device and one of those commands could be to jump to you bootloader.
OK, having written that I wonder if you can fudge the existing setup. Send the special command and have your program jump to location 0. That's easy, the question is does that go into the bootloader? Off hand I don't know, but if it does you may be able for immediately follow the command with the standard avrdude programming.
You can have the processor hardware reset itself with external hardware to hold the pulse. You can't do it without some form of pulse stretching because as soon as the outputs resets the chip it turns to an input and all bets are off.
A simple diode and cap may do the trick, I've not thought about it much. A uC supervisor chip would be better I think, many of them have an input for a push button, you could control that.
