1768 LEDs, Because 96 Just Wasn’t Enough

Some people would look at a massive 6’x4′ LED matrix hanging on the wall playing animations and be happy with the outcome. But [Ben] just isn’t one of those people. The original FLED (Fantastic LED thingy) was eight rows of twelve addressable LEDs for a total of 96 pixels. This spring he upped his game and retrofitted the display with 1768 LEDs.

It wasn’t simply an issue of restlessness, the original build suffered from LEDs dying. We actually featured it for that reason as a Fail of the Week.  This is not strictly a hobby project, it’s hanging on the wall in the Supplyframe offices, so pulling it down frequently to fix broken parts is not ideal.

fled-reborn-LED-layoutTo make FLED more reliable [Ben] sourced strips of the new APA102 LEDs which we looked at back in December. They use an SPI bus instead of the bizarre timing scheme of the WS2812. At first glance you’d think this would mean easier assembly compared to soldering both sides of each of the original 96-pixels. These do come in strips, but laying out 52×34 still means soldering to the ends of each row.

A lot of love went into making sure those rows were laid out perfectly. A sheet of white foamed PVC serves as the substrate. There is grounding braid on either end of the rows, one is the voltage bus, the other is ground. It fits the original enclosure which is acrylic and does a great job of diffusing the light. I’ve seen it in person and it looks pretty much perfect!

It’s not just the physical layout of this many pixels that is a challenge. Pushing the data to all of them is much harder than it was with 96. [Ben] transitioned away from RaspberryPi. He considered using a Teensy 3.1 and ESP8266 but the WiFi of these cheap modules is far too slow to push frame information from a remote box. In the end it’s a BeagleBone Black that drives the reborn display. This is a great choice since there’s plenty of power under the hood and a traditional (and much faster) WiFi dongle can be used.

Don’t miss the animation demos found after the break.

39 thoughts on “1768 LEDs, Because 96 Just Wasn’t Enough

    1. Yeah a single 600w 120amp 5v supply is used. We have a buck boost regulator off of that to ensure a stable supply for the beaglebone black. Since the voltage drop varies greatly depending on the LEDs that are turned on.

      I would recommend using multiple separate supplies really though as this is quite the balancing act with a single supply.

      1. You might consider using some of the brick modules similar to the Vicor or Astec ones. they come in a variety of input voltages and can be run in parallel as needed. some individual modules can supply 5V at up to 60A and could be distributed behind the display. Remote sensing is also an option to reduce line loss getting to the load. Heat dissipation could be a problem but that would be the case for most any power supply. I have run the 300V input ones using a simple voltage doubler and AC line voltage directly.

        1. Yeah heat inside the case is a big issue.

          Got any links for 60a 5v bricks? They could be very useful indeed.

          I think I like tekkieneets solution best though. Running a 12 or 24v supply outside the case with 5v regulators inside. Should limit the heat dissipation inside the case substantially.

    1. Excellent! I made a prototype but couldn’t get the baud rate past 921600 bits per second or
      115200 bytes per second.

      Doing the math (1728 * 3 bytes per led) * 30 for = 155520 bytes per second. Just didn’t add up.

      Though I suppose if you skipped the teensy and just drove the LEDs direct from the esp module you could avoid that limitation. But will the spi bus on those run without interrupts blocking the WiFi?

  1. Thanks for the write up Mike.

    One thing you missed though which I think is the best bit of the system is that all those pretty animations are actually coded and running in Javascript.

    You can go to a Web page hosted on our internal network that let’s you write and test animations in the browser and then save them to the server which streams the resulting data to the display.

    UI is a little ugly but the code is up here https://github.com/SupplyFrame/fled for those interested. This is now actually part of our front end developer test!

    1. Yeah data becomes a problem at that scale. Ethernet definitely becomes the way to go. I think our supply is about as large as you can go with WiFi and keep a stable 30fps streaming, just too much interference in our office to push it much further.

    2. Looks amazing.
      I’m doing something similar with extremely modest numbers of LEDs (16×11) but even I realized that I could probably do with a much more capacious processor than a crappy Arduino! Simply holding a frame buffer should rule out Arduinos.
      I use a Raspberry Pi.

  2. i love this project and have been working for a long time on doing one of my own built in to a wall
    not to complain about 1768 LEDs but the gap between the LEDs are a bit off putting

  3. Would be wonderful if you guys could share more info on your driver solution in beaglebone! Is it only acting as a buffer receiving data from a computer? Or is it generating it also?

    What framework / code base are you using?

    I’ve been doing a lot of work with the teensy 3.1 and managed to get as much as 3,200 pixels out of one at 60 fps only using it as a buffer receiving serial from a pc. (sending from Touch Designer)

    I imagine the BBB is capable of more due to it’s horse power but programming it is a giant task for someone who doesn’t know linux.

  4. I don’t get it, no offence but why spending so much money, energy and effort on emulating what looks like a Sinclair Spectrum running on a first generation flat screen TV….?

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.