There is a lot of spectacle on display at Maker Faire. But to be honest, what I love seeing the most are well-executed builds pulled off by passionate hackers. Such is the case with [Debra Ansell]. She wasn’t exhibiting, just taking in all the sights like I was. But her bag was much better than my drab grey camera-equipment filled backpack; she build a handbag with an LED matrix and did it so well you will scratch your head trying to figure out if she bought it that way or not.
Gerrit and I walked right up and asked if she’d show it to us. We weren’t the only ones either. [Debra’s] bag started drawing a crowd as she pulled out her cellphone and sent “Hackaday” to the 10×15 matrix over Bluetooth. Check out our video interview below.
Continue reading “Exquisite LED Handbag in the Wild”
RGB LED cubes are great, but building the cube is only half the battle – they also need to be driven. The larger the cube, the bigger the canvas you have to exercise your performance art, and the more intense the data visualization headache. This project solves the problem by using Unity to drive an RGB LED cube in real-time.
We’re not just talking about driving the LEDs themselves at a low level, but
how you what you want to display in each of those 512 pixels.
In the video, you can see [TylerTimoJ]’s demo of an 8x8x8 cube being driven in real-time using the Unity engine. A variety of methods are demonstrated from turning individual LEDs on and off, coloring swaths of the cube as though with a paintbrush, and even having the cube display source image data in real-time (as shown on the left.)
Continue reading “Real-time Driving of RGB LED Cube using Unity3D”
A lot of projects get made because someone just has the parts lying around. In this case, [Ed Nisley] got given a nice 8×8 RGB LED matrix, and needed something to display. [Ed] details the transformation of stuff-lying-on-the-desk into a unique matrix display for a Geiger counter (which he also presumably had sitting around somewhere). The result is a lightshow that’s as random as radioactive decay, and that’s pretty darn random.
The first post covers the hardware layout. It’s build on protoboard, but ends up looking a lot nicer than our projects because [Ed] spent some time hiding the shift-register ICs and row-driver transistors underneath the matrix itself, which was nicely socketed above. A sweet touch is the use of SMT resistors soldered upright underneath the board to save space. Cute.
The second post covers the circuit design, and is worth a look if you’re new to driving many LEDs from a minimum number of microcontroller pins. There are eight rows, and three colors each for eight LEDs per row. Without using shift registers, this would require 8*8*8*8 = way too many pins to control. If you want a worked example of how to do this with just four microcontroller pins, have a look. (Spoiler: cascaded shift registers driven by the AVR’s hardware SPI peripheral.)
The third post starts to flesh out the software. [Ed] settled on seven colors (and off) for the display, so the matrix’s total state can be crammed into just 32 bytes, which fits nicely in even a tiny microcontroller, much less the gargantuan ATmega328. Wrapping this all up in an array of structs and providing a couple of helper functions makes quick work of the software side. The addition of a sync pulse to trigger an oscilloscope at the end of a row is a nice touch.
Next up is the Geiger counter interface software post. When a radioactive decay event is detected, the code reads out the time in milliseconds and uses that as the source of randomness. To whiten the noise, the times are run through a simple hash function: the Jenkins hash (link). This hash function was new to us and seems pretty useful for quick-and-dirty microcontroller applications.
The last post details pre-loading the matrix on startup and running a test sequence that blinks each LED to make sure they’re all working. Using a single random value to seed a software pseudo-random number generator ensures that it will (almost) never start off with the same display twice.
Phswew! That’s a lot of well-documented writeup of a well-polished project! Hope it inspires you to dig out something cool from your junk drawer and build.
The most fascinating project you can build is something with a bunch of blinky hypnotic LEDs, and the easiest way to build this is with a bunch of individually addressable RGB LEDs. [Ole] has a great introduction to driving RGB LED matrices using only five data pins on a microcontroller.
The one thing that is most often forgotten in a project involving gigantic matrices of RGB LEDs is how to mount them. The enclosure for these LEDs should probably be light and non-conductive. If you’re really clever, each individual LED should be in a light-proof box with a translucent cover on it. [Ole] isn’t doing that here; this matrix is just a bit of wood with some WS2812s glued down to it.
To drive the LEDs, [Ole] is using an Arduino. Even though the WS2812s are individually addressable and only one data pin is needed, [Ole] is using five individual data lines for this matrix. It works okay, and the entire setup can be changed at some point in the future. It’s still a great introduction to individually addressable LED matrices.
If you’d like to see what can be done with a whole bunch of individually addressable LEDs, here’s the FLED that will probably be at our LA meetup in two weeks. There are some crazy engineering challenges and several pounds of solder in the FLED. For the writeup on that, here you go.
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”
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”
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”