LONG TLC5947 LED Driver Daisy Chain Flickering RESOLVED Moderators: adafruit_support_bill, adafruit

[mpinner]

Hi,

I got 60 tlc5947 breakout boards each with white leds. they're hanging to sparsely populate a 10ftx5ftx5ft space and create a light sculpture. in general they are solid and a real joy to work with. i got them all mapped out and started running more complex 3d geometries... then the flickering started.

many lovely sunrises

2-sunrise.jpg (420.17 KiB) Viewed 1115 times

it is bright and lovely sight to behold, but there is a FLICKING badly further down the daisy chain. (once it is hung i expect the people to be flickring;) )

love these solid tlc5947 breakouts

1-tlcs.jpg (217.23 KiB) Viewed 1115 times

i think there are multiple things going on from these three observations:
- the flickr gets worse the further you go down the line. even when i send 0xFF0 to every pixel they flickr. I put a logic analyzer in multiple positions and noticed the clock and latch out of phase (skewed?) from the data. the clock and latch share a rail through the entire 60 device bus due to the nature of the breakout and possibly the tlc5947. the data sheet ( pg 10 https://www.adafruit.com/datasheets/tlc5947.pdf ) seems to suggest that there is a delay (no surprise) of Tdo for the data in to progate to the data out. i couldn't quite glean from the data sheet what the actual duration of this delay is expected. would be a nice validation. ANY POSSIBLE SOLUTIONS ? i'd thought maybe to impose a delay on the clock and latch periodically with a few micros in line, but i'm hoping for a super solid and standard.

clock and latch out of phase (skewed?) from the data. data sent was 0xFF0 to each pixel

tlc5947-number40-tight.png (662.58 KiB) Viewed 1115 times

- the flickr is always REALLY bad at the end. if i go from 60 to 50 devices in the chain, the really bad flicking moves from 58-60 to 48-50.. this might be due to a reflection of the clock from the end of the line. i've tried anywhere from 12mhz to 2khz. it seems a little better at slower speeds. i tired tying the clock and data at the end back to the 74lvc245 that is driving this from the beginning. it dint seem to fully fix it.. maybe there are multiple issues. another suggest would be to add resistors to the end.. what values ? why? how?

- in viewing the spi lines at different location in the chain i noticed the latch pulsing high during a frame. sometimes veruy often and sparatically. i have no explaination for this besides maybe it is a symptom of the above. i suspected a bad ground (or reference?), but im not sure how to validate my power system. i took some care to ensure that there is good power through the system with two 30A power supplies and 18awg power lines running every 7 tlcs5947s and to the ends. there is a drop to 4.8vdc when everything is on.

Thanks much for the boards, beagle bones, proto cape, sensors, breakouts, and continually awesome support and documentation. I'm posting updates, code, and more tech details here: https://github.com/mpinner/Active


-matt

[adafruit2]

whew this stuff can get hard!
ok. how about you try to slow down the clock rate? what do you have it hooked up to? what code are you running, arduino library?

[mpinner]

I've tried clock rates from 12mhz to 2khz. It looked better at the slower speed but there was still some effect further down the line and the frame rate was not acceptible.

I've used both an arduino w the libs and am trying to ultimately use a beagle bone black with hardware SPI at >4mhz with 12bits per tlc.

[adafruit2]

what if you split the chain in half, then run two SPI lines (or three? four?) the Arduino can do software SPI on up to 4 or 5 parallel 'Ports'. not sure about the BBB however.

also, try to put termination diodes at the *end* of the CLK/LAT lines
like so:
http://digital.ni.com/public.nsf/allkb/ ... 3E007593BC
2 x 1N5818 per should be good!

"NI recommends terminating as close to the receiving device as possible and using Schottky diodes (Figure 1) to clip the overshoots at 5.3 Volts and –0.3 Volts. A problem might occur with the parasitic capacitance of these diodes where you might still notice some large voltage spikes before the diodes allow the current to flow."

[navegen]

Hi Admin, I wanted to chime in while Matt is away...

If I understand you correctly. Place the diodes on the last TLC output... CLK/LAT ---->Ground?

I have some 1N5819's not 1N5818's like you suggested lying around. I shall give those a try.

[adafruit2]

yes see the url link for diagram of how to connect the diodes. two per terminated line so you'll need 4
any schottkey diode will do

[mpinner]

thanks for the pointers and hints about the termination. we think the ending device leds are flicking less, but there is still the major issue of data being skewed (out of phase) from the clock and xlat.

do you have any option on the limit to which these devices should be daisy chained at various data rates?

once slowed i can get more devices, but there is a limit to how slow one can send data to 60 devices.

i asked a few questions about how to interpret the TDO value in the data sheet:

DATA OUT vs DATA IN is delayed by tDO to cause issues further down the chain. was is the value of tDO and limit to a chain size?

TDO_tlc5947_timing_datasheet.png (62.33 KiB) Viewed 1052 times

the spi lines directly after the 74lvc245 from the BBB:

the spi lines directly after the 74lvc245 from the BBB. note the 0xFF0 for each pixel is in alignment

tlc5947-number0-tight.png (680.08 KiB) Viewed 1052 times

the spi lines directly after the 7th device:

the spi lines directly after the 7th device. note the 0xFF0 for each pixel is mis aligned

tlc5947-number07.png (672.69 KiB) Viewed 1052 times

has anyone experienced chains longer than 20? i've used 16 with a great deal of success in the past.

thanks again!

-matt

[adafruit2]

Yes that is right, tDO will add up. you may also have been experiencing ringing on the latch lines, which would be visible with an oscilloscope rather than a logic analyzer. I do suggest looking at the lines with a 'scope and then dividing your 60 in to 3 or 4 individual strands

[ajwormgoor]

I'm afraid I can't answer your question but Adafruit staff seem to be doing an awesome job already. I'm curious about the BBB you're using and in what way you're running the scripts to drive the led boards. As far as I know there's Bonescript, Python or using the PRUs. The latter should give massive speeds but seems kind of hard core to get into. Was wondering if you know how you'd be using the BBB with this installation (which looks great, by the way!)

[mpinner]

@ajwormgoor

we're writing to the /dev/spidev1.0 . im in this fork/branch as things aren't merging back to the main cleanly enough yet: https://github.com/mpinner/openpixelcon ... 7_server.c

Basically we need at least 1MHz to get 1,440 pixels over 30 frames a second. we need the memory of the beagle bone to address them and the full network stack and opc are super handie so content can be generated from anywhere. yay standards!

i'd be curious how you might do this via bonescript. you could likely write to the spi vis ada's bbb libs just as easily.

-matt

[ajwormgoor]

@mpinner thanks for the link. I won't be passing framebuffers to the Beaglebone but mainly want to be able to control my shiftout lines faster than with an Arduino. ?That, and I didn't mind the chance to give a Beaglebone a spin :) Didn't know about OPC, looks like a cool product.

As far as Bonescript, I'd have been surprised if you were using that because my first little forays into using it suggest that it's only suitable for non time-critical applications where it might be nice to quickly connect Node.js webserver functionality with the Beaglebone's i/o pins, ie toggling stuff on/off. I could be wrong because I haven't had much time with the Beaglebone, but I found that although simple scripts did function, it just didn't feel very solid.
Adafruit's bbb scripts already look more solid but I was curious to know how fast python can execute stuff, like at SPI speeds?

Have you considered using the PRUs on the board?

[mpinner]

@ajwormgoor not really needing the pru yet. if you want to get dirty there start with https://github.com/osresearch/LEDscape

[ajwormgoor]

@mpinner yes, got that repo favorited already :) Nice project. As for your project: I recall a few years ago when I did a project using TLC5940's (also PWM drivers) that we introduced a signal buffer IC halfway through the train of 24 TLC's, to keep the 1's 1 and 0's 0. Maybe that helps, I'm not sure if Adafruit's TLC5947 board does something like that itself already...

[mpinner]

back to the topic.....

1-IMG_20140803_211054.jpg (312.7 KiB) Viewed 997 times

I designed this project around 60 of these TLC5947 breakout boards from adafruit. the standard headers and available ribbon connectors, adafruit's support, and adafruit's quality control make it easy to build and warranty this installation for many years to come.

It was said

the design is completely chainable. As long as there's enough power for all the boards you can chain as many as you'd like, like a little trail of blue PCBs stretching out into the sunset.

now im to learn that the sunset is in fact on 10-15 boards aways with little explanation and i should throw more arduinos at the problem.

the piece is now installed 10m in the air. my time and ability to test/revise is getting very.

the termination diodes seem minimally helpful.

adding additional buffers per some recommendations from the local hackerspace. this article on using too many shift registers suggests more buffers as well, although the tlc5947 should be less prone to this type of error as it includes a Schmitt-trigger buffer on data in already:
https://electronics.stackexchange.com/q ... -registers

i might have pinned down the TDO value in data sheet to something between 15-25ns. will a little help i could argue that this should be plenty fast over my 480" and 1440 leds to run at 1MHz with now skewing issue. please correct me here if im wrong. is this TDO skew is infact additive, then the 25ns * 1440 could be 36 microseconds. then my clock speed would have to be 1/36000000 or 3MHz... so im good?


i will be onsite again next week and find an oscilloscope for further analysis.

thanks for any additional insight you (or the community) can provide.

https://vine.co/v/MVOvaKawTzg

-matt

[adafruit2]

now im to learn that the sunset is in fact on 10-15 boards aways with little explanation and i should throw more arduinos at the problem.

You may not need (more) Arduinos, you can multiple software SPI ports on one BBB/Arduino, and bitbang to each strand. It's not 100% clear what the problem is, we're suggesting multiple options you can explore, we can't provide engineering consulting, but we can offer suggestions!

This is just one of the tools you have in your arsenal to attack the problem.

You can also look at the product page for the chip itself and/or contact TI's app engineers (we only solder the chip onto a PCB and test it, we didn't design the chip itself)
http://www.ti.com/product/TLC5947?keyMa ... =Search-EN

i might have pinned down the TDO value in data sheet to something between 15-25ns. will a little help i could argue that this should be plenty fast over my 480" and 1440 leds to run at 1MHz with now skewing issue. please correct me here if im wrong. is this TDO skew is infact additive, then the 25ns * 1440 could be 36 microseconds. then my clock speed would have to be 1/36000000 or 3MHz... so im good?

There's the theory and there's the actual measurements :)

You've also got the capacitiance of the transmission lines, any power supply dips or spikes, and any other 'minor' effects that then become 'major' effects when you've got that many boards.

If you have a staff electrical engineer, or someone you can hire to bring on-site with you, they may be more versed in these effects!