Forum Rule: Always post complete source code & details to reproduce any issue!
Results 1 to 16 of 16

Thread: Design advice for 1600 LED array installation please

  1. #1

    Design advice for 1600 LED array installation please

    Hi, I'm looking for some advice on the best way to connect up two Teensy controllers and a Raspberry Pi 2 in different configurations.

    The Project

    I'm building an irregular array of about 1600 LEDs as a kind of art installation. Got two Teensy 3.1s each driving half of the LEDs using the excellent OctoWS2811 library by Paul Stoffregen (thanks so much!).

    The Goal

    I want to be able to do a wide range of things with the display, some of which will need a lot of numerical processing (e.g. Complex wave simulations or image processing) and others not so much (e.g. Show a clock face).

    The Problem

    The two Teensy's will be be permanently mounted in the LED display with USB ports on the outside so I can program them either with a laptop or the Raspberry Pi.

    The questions are:

    1. What's best way to communicate with both Teensy's in real time when I want the Raspberry Pi to be the central processor and the Teensy's to be 'slaves' just updating the LEDs? I've figured out basic serial communication through the USB cable but I don't know if there are better ways of transmitting synchronous data fast (USB-Bridge perhaps?) to two Teensy's at the same time.

    2. What if I want to run the display without the Raspberry Pi for simple tasks? Then the two Teensy's need a way of communicating with each other if they are sharing the processing task and sharing data to keep each other up to date on each half of the display. Again, what's the best way to connect two Teensy's for this purpose?

    Note: I need to be able to switch between each mode of operation as needs be.

    Thanks!

  2. #2
    Senior Member
    Join Date
    Apr 2013
    Posts
    1,853
    You are trying to build a distributed parallel computer with redundancy here, so doing it right isn't going to be easy. That said it's by no means impossible either. The easy choice is probably using the hardware serial port for inter Teensy Communication, possibly paired with the existing frame sync pin to trigger the actual display. The fun way to do it would be parallel pattern generation, with the serial traffic parsing the seed numbers for your pattern, but a frame of 800 LEDs is only 2400kb so do-able as a raw pixel stream. That said some basic compression would help, for starters while WS2811 LEDs are nominally 24 bit colour with 256 levels per colour the actual useable bit depth is closer to 32, so turning those three bytes per pixel into 2 works. Compressing them into a single byte is also doable if you can preload a colour table. After all that's what VGA did.

    If you want to simplify the parsing code add a frame sync and data/command line to the inter teensy loop. Frame sync triggers the the write of whatever has been sent to the actual LEDs (rather than just 'whenever the frame fills' which will have variable time if compression is happening), and also retriggers the counter that tracks which pixel the streaming data refers to while the data/command line means you can send 'mode change' commands without having to have special escape characters eating into your colour bits, and makes the handling of dropped serial bytes more robust over header commands encoding length.

    Pi's have a 3.3V hardware UART so perfectly possible to use the same interface Pi ->t1 ->t2 though getting real time hardware pin changes on a PI is a bit fiddly.

    SPI and I2C are also possible for any of the legs and may give higher data rates, though as always higher data rates always mean shorter useable distances.

  3. #3
    Thanks GremlinWrangler. This is really helpful advice and I am investigating your recommendations. Much appreciated.

  4. #4
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    19,248
    Quote Originally Posted by billtubbs View Post
    1. What's best way to communicate with both Teensy's in real time when I want the Raspberry Pi to be the central processor and the Teensy's to be 'slaves' just updating the LEDs? I've figured out basic serial communication through the USB cable but I don't know if there are better ways of transmitting synchronous data fast (USB-Bridge perhaps?) to two Teensy's at the same time.
    USB Serial is by far the most efficient. One Teensy will appear as /dev/ttyACM0 and other other as /dev/ttyACM1. Which is which depends on factors outside your control, so it's best to put the info onto each Teensy and query it from the RPi. See the VideoDisplay example.

    Use a Multi-TT USB hub between the RPi and both Teensys for best performance.


    2. What if I want to run the display without the Raspberry Pi for simple tasks? Then the two Teensy's need a way of communicating with each other if they are sharing the processing task and sharing data to keep each other up to date on each half of the display. Again, what's the best way to connect two Teensy's for this purpose?
    Serial1 is the simplest.

    If the distance isn't long, you can connect GND to GND, TX1 to RX1 and RX1 to TX1. If the distance is within a few feet, a 100 ohm resistor at each TX1 pin and keeping the 3 wires close or inside a shielded cable might work. For long distance, you might need RS232 (1 wire per signal) or RS485 (2 wires per signal) chips to get the signals reliably send and received between the boards. RS232 is very reliable up to about 20-50 feet. RS485 works up to thousands of feet.

  5. #5
    Thanks PaulStoffregen. This is great. My Teensy's are right next to each other so I will connect the Serial1 pins directly. Also, I'll investigate what a Multi-TT USB hub is because I was just going to use two USB cables. Maybe I could put this hub inside the display so then I would only need one cable from the RPi to the display. Presumably I could power the hub from the 5V supply inside the display.

  6. #6
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    19,248
    When the hub is connected to your Raspberry Pi, or any Linux machine, you can use "lsusb -v" to get lots of info about it and all other connected USB devices.

    For example, here's info about one of the hubs connected to my Linux desktop machine:

    Code:
    Bus 002 Device 121: ID 2109:2812  
    Device Descriptor:
      bLength                18
      bDescriptorType         1
      bcdUSB               2.10
      bDeviceClass            9 Hub
      bDeviceSubClass         0 Unused
      bDeviceProtocol         1 Single TT
    As you can see, it's a cheap Single TT type.

    Often these cheap ones are fine, especially when you only have 1 full speed (12 Mbit/sec) or low speed (1.5 Mbit/sec) device, or when no 2 devices use significant bandwidth at the same time.

    But when you have two of more Teensys (which are 12 Mbit/sec) doing lots of communication, a Multi-TT hub will allow much better sharing of the upstream 480 Mbit/sec connection.
    Last edited by PaulStoffregen; 06-07-2015 at 11:09 AM.

  7. #7
    Quote Originally Posted by PaulStoffregen View Post
    ... a Multi-TT hub will allow much better sharing of the upstream 480 Mbit/sec connection.
    Thanks Paul. Is this the kind of thing you are referring to?

    MICROCHIP EVB-USB2512BC USB2512B High Speed USB 2.0 Multi TT 2 Port Hub with Battery Charging Support Customer Evaluation Board, Wired Connectivity
    http://www.microchip.com/Development...=EVB-USB2512BC

  8. #8
    Quote Originally Posted by PaulStoffregen View Post
    ... a Multi-TT hub will allow much better sharing of the upstream 480 Mbit/sec connection.
    Project is coming along and I have all three devices communicating now!

    I have been using my own protocol for serial communications between the devices but now I want to open up the code to other users and I wonder, should I rather adopt a standard?

    I've been looking at Firmata (which has your name on it!). It looks good but it's very general purpose and I wonder if it adds too much unnecessary functionality given my specific custom application here (driving 1593 LEDS using your OctoWS2811 library). How compatible is Formata with OctoWS2811?

    What do you recommend?
    - Use an industry standard protocol like Firmata
    - devise my own protocol that suits my specific needs

    B.t.w. the host is a Raspberry Pi running Python scripts.

    thanks your advice is much appreciated!

    Click image for larger version. 

Name:	161231photo_LEDdisplay.jpg 
Views:	43 
Size:	113.9 KB 
ID:	9259
    Last edited by billtubbs; 12-31-2016 at 02:58 AM. Reason: Minor typo

  9. #9
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    3,984
    Quote Originally Posted by PaulStoffregen View Post
    USB Serial is by far the most efficient. One Teensy will appear as /dev/ttyACM0 and other other as /dev/ttyACM1. Which is which depends on factors outside your control, so it's best to put the info onto each Teensy and query it from the RPi.
    What I have done in the past is use udev rules to handle cases like this. From my RPI notes, I used to have a couple of FTDI devices that would attach to my robot, so in this case they showed up as /dev/ttyUSB0 and ...ttyUSB1.

    I would then find out information about these devices using a command like: udevadm info --query=property --name=ttyUSB0

    Which gives lots of information about the devices and then create a /udev/rules file like the one the Teensy needs on a Linux machine.

    On one machine I had a file 99-usb-serial.rules which contained:
    Code:
    SUBSYSTEM=="tty", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", ATTRS{serial}=="A800fclo", SYMLINK+="ttyXBEE"
    SUBSYSTEM=="tty", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", ATTRS{serial}=="A4014UWE", SYMLINK+="ttySSC-32"
    Again this was FTDI, but it created two new symbolic links: /dev/ttyXBEE and /dev/ttySSC-32 Then my code could always look for these files and took away the issue of sometimes the device was /dev/ttyUSB0 and other times /dev/ttyUSB1

  10. #10
    Quote Originally Posted by KurtE View Post
    ... my code could always look for these files and took away the issue of sometimes the device was /dev/ttyUSB0 and other times /dev/ttyUSB1
    Thanks KurtE. I may look into that method but I already solved that problem. I used some serial communication whereby each Teensy is asked to report who they are and then they are thus identified by the RPi. Here is my Python code to find all the Teensy's on the USB port. I'm not sure if it is robust but it works for me. It relies on the fact that my Teensy's always seem to connect with a name that starts with 'ttyACM'.

    Code:
    addresses = ('/dev/ttyACM0', '/dev/ttyACM1')
    
    
    class Display1593(object):
        """Irregular LED array driver class."""
    
        def __init__(self):
            self.tys = None
    
    
        def connect(self, addresses=addresses):
    
            print "Finding Teensies..."
    
            tty_files = []
            for file in os.listdir('/dev'):
                if file.startswith('ttyACM'):
                    tty_files.append(file)
    
            print "Trying to connect to Teensies..."
    
            self.tys = []
            for a in tty_files[0:2]:
                self.tys.append(Teensy('/dev/' + a))
    
            if len(self.tys) != 2:
                raise Display1593Error("Could not find two Teensies to connect to.")
    
            for t in self.tys:
                t.connect()
    
            if self.tys[0].name == 'Teensy2':
                self.tys[0], self.tys[1] = (self.tys[1], self.tys[0])
                print "(Teensies swapped)"
    
            if (self.tys[0].name, self.tys[1].name) != ('Teensy1', 'Teensy2'):
                raise Display1593Error(
                    "Could not find the right pair of Teensy controllers.  "
                    "Found these instead: %s, %s" % (
                        self.tys[0].name,
                        self.tys[1].name
                    )
                )

    If you have any advice on the serial communication protocol question I just asked it would be much appreciated!
    Last edited by billtubbs; 12-31-2016 at 06:16 AM. Reason: Added missing code

  11. #11
    Just returning to this post to ask a follow-up question. I just learned about I2C protocol:

    I2C addresses several drawbacks in the other communication protocols, giving it an advantage over the others in some applications. These include:
    - The ability to connect multiple masters to multiple slaves
    - Synchronicity (just like SPI), which means higher speed communication
    - Simplicity: implementation only requires two wires and some resistors
    Any reason why this wouldn't be a good idea for my application here?

  12. #12
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    19,248
    Is this still the same project? It's been more than 2 years since your earlier questions....

  13. #13
    Yes! Same project. Itís been working quite well for a few years but Iím struggling with a few communication issues. E.g. trying to get the RPi (master) to send the data for all LEDs to both Teensys (slaves) fast enough over the USB to change the whole display before one of them refreshes. Might just be a syncing issue. Also Iím getting some corrupted data transmissions now and then. Maybe the wireless transmitter?

  14. #14
    Senior Member crees's Avatar
    Join Date
    Dec 2016
    Location
    Utah
    Posts
    126
    Have you considered using sACN or artnet? Requires You to neteork them up. One teensy can do several thousand leds synced by a raspberry pi. It’s a major shift from what your doing but it works well

  15. #15
    Quote Originally Posted by crees View Post
    Have you considered using sACN or artnet? Requires You to neteork them up. One teensy can do several thousand leds synced by a raspberry pi. Itís a major shift from what your doing but it works well
    To be more clear, this is my current setup:

    Click image for larger version. 

Name:	led_display_architecture.jpg 
Views:	18 
Size:	134.6 KB 
ID:	15711

    I'm wondering if there is a better (easier, faster, more reliable) way to handle the communication between the Raspberry Pi Zero and the two Teensies. There is no problem with the Teensies controlling the LEDs. That is working well but I have to write code for them to listen and receive instructions and data from the RPi to change some or all the LEDs intermittently. The maximum size of a data communication to each Teensy is 798 x 3 bytes but two of these 'packets' have to be sent by the RPi and I'm not sure how to get them both sent and received before both Teensy update the LEDs (they are synced together and update at the same time).

    Would sACN or artnet work for communicating bytes between RPi and 2 Teensies?

    Also I was advised that each Teensy can only handle about 1000 LEDs, hence I used two in parallel.

    I'd like to stick with what I've got first and see if I can get it working but just wanted to make sure there isn't a simpler solution out there since I'm running into a few problems (which maybe are solvable).

  16. #16
    Senior Member crees's Avatar
    Join Date
    Dec 2016
    Location
    Utah
    Posts
    126
    My current setup I can handle 5440 pixels on one teensy3.2.

    This one is about 1600 pixels

    https://youtu.be/l3cA2Wv3P_k

    Rpi has no problem controlling this setup. Check out falcon pi player project and the enormous lights they control. Again this is a big direction change for your current setup but works well. If your able to adapt your code to artnet or sACN then itís worth Considering. There is syncing abilities with artnet and sACN.

    I would think that what you have should be able to factor in a sync method. Typically itís the start of the serial data with a unique character that could tell both teensy to ďframe or led sendĒ

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •