1768 LEDs, Because 96 Just Wasn’t Enough

April 17, 2015 by Mike Szczys 39 Comments

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.

To 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.

Continue reading “1768 LEDs, Because 96 Just Wasn’t Enough” →

The Possibility Of Driving 16,000 RGB LEDs

April 16, 2015 by Brian Benchoff 17 Comments

Like just about everyone we know, [Luis] decided a gigantic RGB LED matrix would be a cool thing to build. Gigantic LED matrices are very hard to build, though: not only do you have to deal with large power requirements and the inevitable problems of overheating, you also need to drive a boat load of LEDs. This is not easy.

[Luis] found a solution to the problem of driving these LEDs with a new, fancy ARM Cortex M4 microcontroller. All Cortex M4 ARMs have DMA, making automatic memory transfers to peripherals and LED strips a breeze.

The microcontroler [Luis] is using only supports 1024 transfers per transfer set, equating to a maximum of 14 LEDs per transfer. This problem can be fixed by using the ping-pong mode in the DMA controller by switching between data structures for every DMA request. Basically, he’s extending the number of LEDs is just switching between two regions of memory and setting up the DMA transfer.

The result is much better than [Luis]’ original circuit that was just a bunch of SPI lines. It also looks really good, judging by the video below. It’s not quite a gigantic LED matrix yet, but if you want to see what that would look like, check out the huge 6 by 4 foot matrix hanging in the Hackaday overlord office.

Continue reading “The Possibility Of Driving 16,000 RGB LEDs” →

Documenting Poorly Documented LED Strips

April 12, 2015 by Brian Benchoff 24 Comments

While [Drew] was in China for the Dangerous Prototypes Hacker Camp, he picked up some very bright, very shiny, and very cheap LED strips. They’re 5 meter “5050” 12V strips with 20 LEDs per meter for about $15 a spool. A good deal, you might think until you look at the datasheet for the controller. If you want an example of how not to document something, this is it.

A normal person would balk at the documentation, whereas [Drew] decided to play around with these strips. He figured out how to control them, and his efforts will surely help hundreds in search of bright, shiny, glowy things.

You are expected to tell the difference between 'GMODE', 'OMODE' and 'CMODE' in this pinout. — You are expected to tell the difference between ‘GMODE’, ‘OMODE’ and ‘CMODE’ in this pinout.

The datasheet for the LPD6803 controller in this strip – available from Adafruit here – is hilarious. The chip takes in clocked data in the order of Green, Red, and Blue. If anyone can explain why it’s not RGB, please do so. Choice phrasing includes, “VOUT is saturation voltage of the output polar to the grand” and “it is important to which later chip built-in PLL regernate circuit can work in gear.” Apparently the word ‘color’ means ‘gray’ in whatever dialect this datasheet was translated into.

Despite this Hackaday-quality grammar, [Drew] somehow figured out how to control this LED strip. He ended up driving it with an LPC1768 Mbed microcontroller and made a demo program with a few simple animations. You can see a video of that below.

Continue reading “Documenting Poorly Documented LED Strips” →

Overengineering Beer Pong

April 11, 2015 by Brian Benchoff 15 Comments

If there’s one game that deserves to be overengineered with hundreds of LEDs, sensors, and electronic modules, it’s beer pong. [Jeff] has created the most ostentatious beer pong table we’ve ever seen. It’s just shy of playing beer pong on a single gigantic LED display, and boy, does it look good.

The table includes a 32×12 grid of LEDs in the center of the table, with 10 pods for Solo cups at each end of the table. These pods have 20 RGB LEDs each and infrared sensors that react to a cup being placed on them. The outer edge of the table has 12 LED rings for spectators, giving this beer pong table 1122 total LEDs on 608 individual channels.

With that many LEDs, how to drive all of them becomes very important. There’s a very large custom board in this table with a PIC24 microcontroller, TLC5955 PWM drivers, and enough IDC headers to seriously reconsider using IDC headers.

Put enough LEDs on something and it’s bound to be cool, but [Jeff] is taking this several steps further with some interesting features. There’s a Bluetooth module for controlling the table with a phone, a VU meter to give the table some audio-based visualizations, and air baths for cleaning the balls; drop a ball down the ‘in’ hole, and it pops out the ‘out’ hole, good as new. If you’ve ever wondered how much effort can go into building a beer pong table, there you go. Video below.

Continue reading “Overengineering Beer Pong” →

DIY Seven Segment Displays

April 4, 2015 by Brian Benchoff 9 Comments

[Esai] wanted to build an electronic clock from scratch. A noble quest, but ordinary seven-segment displays are just that – incredibly ordinary. Instead of a few displays that can be bought from the usual retailers for a dollar a piece, [Esai] made his own four digit, seven-segment display on some perfboard.

Before soldering 58 SMD LEDs to a small rectangle of perfboard, [Esai] traced out each segment with a marker. Two LEDs make up each segment, and they’re all connected to a breadboard-friendly pin header with 30 gauge wire.

Each segment is connected as a single column in the LED matrix, and each digit is a row. It’s a simple design, but there aren’t any resistors on this board. Hopefully [Esai] will be using a proper LED driver with this display; you really don’t want LEDs to burn out twice a day at 1:11.

3D Spectrum Analyzer Uses 1280 LEDs

March 23, 2015 by Ethan Zonca 47 Comments

One of [Dooievriend]’s friends recently pressed him into service to write software for a 3d spectrum analyzer/VU that he made. The VU is a fairly complex build: it’s made up of 1280 LEDs in a 16x16x5 matrix controlled by a PIC32 clocked at 80MHz. [Dooievriend] wrote some firmware for the PIC that uses a variation on a discrete Fourier transform to create a 3D VU effect.

When [Dooievriend] set out to design the audio analyzing portion of the firmware, his mind jumped to the discrete Fourier transform. This transform calculates the amplitude in a series of frequency bins in the audio—seemingly perfect for a VU. However, after some more research, [Dooievriend] decided to implement a constant Q transform. This transform is very similar to a Fourier transform, but it takes into account the logarithmic way that the human ear interprets sound.

[Dooievriend] started implementing the constant Q transform using an interrupt-based sampler, but he quickly ran into issues with slow floating-point math on his PIC32 (which doesn’t have a hardware floating-point unit). Thankfully he rewrote his code using fixed-point math, and the transform runs nearly real-time. Check out the video after the break to see the VU in action, and a second video that gives some details on the hardware build.

Continue reading “3D Spectrum Analyzer Uses 1280 LEDs” →

Rebraining An LED Marquee With A SparkCore

March 20, 2015 by Mike Szczys 6 Comments

Wires? Where this LED scroller is going we don’t need wires. Well, except for power but everything needs power. The 90×7 LED marquee hangs over the entrance to NYC Resistor’s laser cutter room. Thanks to a Spark Core and a bit of work from [Trammell Hudson], the sign is working and attached to the network.

The original unit called for an RS485 connection for input. Other than that there wasn’t really a reason it had been collecting dust. Closer inspection of the internals proved that the display is driven exactly as you would expect: transistors for the rows and shift registers for the columns. Well, actually the columns are split into separate shift registers for the even and odd but that doesn’t complicate things too much. GPIO takes the seven row-driving transistors, two shift register clocks, data, latch, and enable for a total of twelve pins.

The Spark Core completely replaces the Atmel 80C32X2 and its RTC by pinging the network for UTC time synchronization once per day.

[via NYC Resistor]