Shop OBEX P1 Docs P2 Docs Learn Events
Design Dilemma - seeking advice on cable/border architecture — Parallax Forums

Design Dilemma - seeking advice on cable/border architecture

Timothy D. SwieterTimothy D. Swieter Posts: 1,613
edited 2007-07-18 11:23 in General Discussion
I have a project I am doing for my living room and wanted to get some community feedback.·

Background:
A couple months ago I moved to Hong Kong from the US.· I love it here, the resources that are available for hobby and electronic projects are amazing!!! (A whole other post sometime).· Anyway, HK has a fabulous light show in the downtown area.· Victoria Harbor and 40+ building light up and dance synchronously to a music show.· Some buildings have LEDs, some large spot lights, some with laser and every now and then they have fireworks too.· http://en.wikipedia.org/wiki/A_Symphony_of_Lights
I can see this show nightly from my flat in Tsing Yi. So I was thinking, why not have part of the show be in my own room.....

The idea:
There are three book cases in my living room.· I am designing a system of LEDs to go in the columns between the book shelves (the book cases are spaced about 20 cm apart, 2 columns).· The LED system would be mood lighting in the evenings and perhaps I would program it to also do some dancing with the show that happens in the harbor nightly.· There would be several channels of control.· A diffusing material would cover the LEDs to create the column of light.

The design:
I have a Prop in the DIP package that I would like to use.· I have also procured six TLC5940 from Texas Instruments to use as the LED control chip.· For the LEDs, I bought a couple meters of "RGB Light Ribbon" which is essentially a flexible printed circuit with RGB LEDs.· The design is that each column (the area between the book cases) will have 16 channels of RGB (each TLC5940 does 16 channels, one chip per color per column).· I will also add a user interface with a VFD display I have laying around a couple tact switches.· I will program the design to have several different modes.· One mode may cycle the colors and the user can set the speed.· Another mode may loop some sequence of popping the colors on and off.· Another mode may play back a show that is downloaded to it from the PC.

So, in summary the final design will have a Prop and 32 Channels of RGB control, separated into two sets of outputs (16 channels each) using the TI chips.

The design dilemma:
The TI chips have a serial in/out for daisy chaining multiple chips together.· There are also several other signals used for controlling the device.· My original thought was to design a 16 Channel RGB driver board.· I would produce two (or more) of these boards and place one at each column.· I would design a second board with the Prop and the user interface to place some where convenient for turning on the display and adjusting it.· Depending on LED update rate and how fast the Prop communicates with the TI chips, I could be communicating from 1 MHz to 5 or 10 MHz.· The length of cable between the controller (the Prop) and the driver (the TI chips) could be 5 to 6 feet.· To me, these sounds like it needs design attention.· Does the community have any advice?· I thought maybe I could use Ethernet cable between the controller board and the driver board because of the twisted, shielded pairs.· I was wondering about signal integrity and other items I need to watch out for.· Also, the signals will be 3.3 V or 5 V.· Because of the quantity of signals I would have to use two cables to each driver board or source some high conductor count cable.

Another possibility would be to design one board with all the driver and user interface components and parts together in one place.· Of course then I am running all the LED wiring (a lot of it) to one central location and it might be unsightly.· I would have to use pluggable connectors so I could pull out the board or the columns if needed.· The board would be fairly large with all those connectors.

Any advice on the architecture or distribution of control is welcomed.· Thanks for reading through all the words.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Timothy D. Swieter
tdswieter.com
One little spark of imagination is all it takes for an idea to explode

Comments

  • big_markbig_mark Posts: 49
    edited 2007-07-17 16:32
    Hi Timothy

    I have been looking at the TLC5940 chip for use in one of my projects. Funnily enough I am planning on building a DMX-controlled LED wall using your DMX code!

    My understanding of the way the chip handles cascading is that each chip only buffers the data and introduces a small delay between Sin and Sout. I don't think that the first 16 grayscale values go to the first chip, and then the second set go to the second chip, and so on. I could be wrong of course, but the datasheet does not seem at all clear on how serial data is handled when cascading multiple chips.

    As for the communication speed you are proposing, even 1Mhz might be a bit overkill. For each chip, each data packet is only 192 bits. Thats enough for 16 12-bit grayscale values. Even if you were updating that at 100 packets per second the data rate would only need to be 19.2kbps. Of course the grayscale clock would need to be faster than that, or you could use an 8-pin PIC local to each Led driver to provide the GSClk and Blank signals. This would cut out 2 data lines, though it would also increase the complexity a little.

    Twisted pair sounds like the right route to go down to maintain signal integrity though I don't know what the maximum cable lengths could be. If anyone else knows, or knows of a better communication method, please let us know. For my project I envisage cable lengths of at least 2 meters, and maybe more.

    For controlling you LEDS how about DMX? You've already written some Prop assembly to receive it. You could extend it so that it 'grabs' a sequence of DMX either to main memory or an SD card and plays it back again. For programming the DMX, I would recommend MagicQ for the PC. The software is free to download and use, and it works with many PC-to-DMX dongles including the open-sourced Open DMX dongle.

    Hope all this helps


    Mark
  • Timothy D. SwieterTimothy D. Swieter Posts: 1,613
    edited 2007-07-18 00:23
    Thanks Mark for the feedback and ideas!

    Wow - I posted that DMX code sometime ago, I am glad to see it is of use. Some of the project/products that I planned with it fell to the back of my “to do” list so I have not touched that code in a while. Let me know if you need help though. I do have one product I am designing that needs DMX, so in a month of two I will revisit the code because I am using a Prop in the product.

    The TLC5940 is a serial shift register. Think of it as a FIFO, first in first out. If you have three chips in cascade, the farthest chip (that is to say the last chip) in the cascade will receive the first bits the MCU clocks out. Maybe this will help you in your picturing and understanding on how the setup of the TLC5940 works.

    Now that I take a deeper look at the datasheet (and actually run the numbers) you are right, my communications speed can be much slower than I originally thought. At these slower rates my concerns of cable length are mostly put aside, but there are still some small concerns. I like the idea of putting a PIC near the chips for the gray scale. If I go this route I would use an SX or MSP430, perhaps even an Atmel of some sort (because I have wanted to learn more about these chips).

    I had not really considered DMX in my design. Hmmmm.... I was thinking that the driver board would be something I could post on my website and sell blank boards. If it was DMX, there would be more of an audience. Hmmmm.... Tell me more about the board you are designing. Is it suitable for driving RGB LEDs? How far are you along in the process of designing the board? Perhaps we should cook up a design together.

    If I am to use DMX (I need to ponder this more), each driver board would have an in and a thru DMX port. Each driver board would use three TLC5940 (one for each color. Each driver board would do 16 channels of RGB LED. I would devote one channel of DMX per channel of RGB. The board would need a micro, perhaps the Prop or an SX (I like the idea of a cheaper micro on the driver board). The DMX address of the board could be input with DIP switch (Yuk – how old school) or a couple tact switches and three 7-Segment displays (Much easier for the novice to use).

    The controller board could still use the Prop. The controller board in this case would be a DMX generator or capture/playback. For the standalone routines, like color fading, I would write the software in the Prop to generate the DMX. For those intense (algorithmically challenge routines), I would have the Prop capture the data as you suggested and store it to SD or FRAM memory. I don’t want to have the LED light show only work when the PC is connected, it must be simple enough to flip a switch and turn it on.

    I clicked over to the MagicQ PC website. Very nice. Have you used this software with Enttec’s Open DMX USB device? I have one of those devices and I have been using other software I found on-line, but it really is not that great. Of course my needs are not usually for a large stage show, only testing lighting fixture or DMX device in new installations.

    Any other thoughts or feedback? The DMX is a great suggestion. I need to think it through some more.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Timothy D. Swieter
    tdswieter.com
    One little spark of imagination is all it takes for an idea to explode
  • big_markbig_mark Posts: 49
    edited 2007-07-18 11:23
    Glad you like my ideas!

    When you get to looking at your DMX code you may want to make a few changes. For a start your code expects 513 DMX values, whereas the DMX standard does not specify the number of values that must be in each packet. The smallest valid DMX packet could be just the start code followed by the first DMX value. The way to check for the start of a new packet before receiving 513 values would be this :

    -When you detect the start bit (pin goes low), grab the value of 'CNT'
    -Read 8 data bits and two stop bits
    -If we have 2 valid stop bits, store the data and wait for the next start bit.
    -If all bits are low we may have the start of a break, so jump back to the point where we wait for the break to end (pin goes high). Use the value of CNT we grabbed earlier when determining the length of the break.

    The reason we grabbed the value of CNT when the pin first went low was so that we count the 10 bits as part of the break. If we didn't, we may have read the break as being 10 bits shorter than it actually was. This could have meant that we missed one entire packet of data.

    For my LED wall, I am planning on making a series of 4 LED by 4 LED 'tiles' which can be put together in any configuration. I am only planning on making it single-colored to start with (most likely white, or maybe pale blue) as a full universe of DMX will only give me 32 by 16 single-color pixels. The tiles will look something like this :

    ledtile.jpg

    The body will be built from 65mm square black PVC drainpipe, with 5mm thick black ABS side plates. The sideplates will be designed to allow the tiles to be bolted together in rows, columns, or grids. Each tile will be 520mm square. Each cirle will have 4 20mA LEDS wired in parallel to give 80mA total per channel. I've got some semi-opaque plastic sheet which I'm going to use to diffuse the light from the LEDs.

    For the controller I'm just going to use a Prop proto board with an RS485 transceiver chip and opto isolator for protection. This will sit in an enclosure with an off-the-shelf PC power supply. I need such a large power supply because each tile will use upto 1.3A (16*0.08A plus a bit for the driver chip). The prop will drive several tiles. Each tile will only have a TLC5940 chip, the current limiting resistor, and a capacitor. I'm not to all the hassle of making my own PCBs for this. It will be much easier just to use stripboard. For now I'll just be using one TLC per tile with no cascading. The grayscale clock for all tiles will be driven by one 'core' of the Prop. chip.

    I haven't used the Chamsys software with an Enttec dongle. I'm considering buying a Velleman dongle if it will work with the software. The Velleman dongle should be better than the Enttec, as the Enttec is little more than a USB to serial adaptor. It relies on the host PC for all DMX timings. The Velleman, on the other hand, can run in stand-alone mode for testing which would suggest that it can generate its own timing and would therefore be more reliable than the Enttec dongle. I'm not sure if its compatable with the MagicQ software though...
Sign In or Register to comment.