A few years ago, [Frans-Willem] bought a few RGB LED panels. Ten 32×16 panels is a lot of LEDs, and to drive all of these panels requires some sufficiently powerful hardware. He tried working with an FPGA development board, but that didn’t have enough memory for 24-bit color. The microcontroller du jour – a TI Stellaris – couldn’t get more than 16 bits of color without flickering. With a bunch of LEDs but no way to drive them, [Frans-Willem] put the panels in a box somewhere, waiting for the day they could be used to their fullest capacity.
This day came when [Frans-Willem] was introduced to the STM32 series of chips with the F1 Discovery board. While looking for some electronic playthings to use with this board, he stumbled upon the LED panels and gave them one more try. The results are spectacular, with 33 bits of color, with animations streamed over a router over WiFi.
The panels in question are HUB75 LED panels. In the 32×8 panels, there are six data pins – two each for each color – four row select pins, and three control pins. The row select pins select which row of pixels is active at any one time. Cycle through them fast enough, and it will seem like they’re all on at once. The control pins work pretty much like the control pins of a shift register, with the data pins filling in the obvious role.
The code that actually drives the LEDs all happens on an STM32F4 with the help of DMA and FSMC, or the Flexible Static Memory Controller found on the chip. This peripheral takes care of the control lines found in memory, so when you toggle the write strobe the chip will dump whatever is on the data lines to a specific address in memory. It’s a great way to take care of generating a clock signal.
For sending pixels to this display driver, [Frans-Willem] is using the ever-popular TP-Link WR703N. He had originally planned to send all the pixel data over the USB port, but there was too much overhead, a USB 1.1 isn’t fast enough. That was fixed by using the UART on the router with a new driver and a recompiled version of OpenWRT.
All the software to replicate this project is available on Github, and there’s a great video showing what the completed project can do. You can check that out below.
Continue reading “RGB LED Matrices With The STM32 and DMA”
[Yvo] sent us his latest creation, this awesome POV RGB bicycle rim light build, which features a circular interweaving of common RGB LEDs that face outward along the rim as they display constantly changing animations based on the wheel’s rpm.
Like many POV wheel builds, [Yvo]’s takes advantage of a hall effect sensor and stationary magnet to determine how fast the wheels are spinning. Unlike most POV builds, however, [Yvo’s] creation doesn’t have just one or two RGB sticks clamped onto a spoke. Instead, his wheels boast several individual RGB LED modules mounted along the rim.
Each wheel has six modules, and each module contains a scratch-build LED controller (a daisy chain of 74HC595 shift registers) that fits into a custom-made 3D-printed enclosure. The enclosures mounts onto some aluminum strips along with the RGB LEDs, and the aluminum strips mount to the wheels by straddling the rim.
At speed, the lights go into POV mode to simulate headlights / brakes with white in the front and red in the back. Check out the difference these custom circular modules make when riding and when at rest in a video below.
Continue reading “RGB Bike Rim Lights”
[Stephen] designed a standalone Ambilight clone built around an FPGA and recently added many new features to make his design even better. His original design was based around a Spartan 3-E FPGA, but his new design uses the Papilio One board with a Spartan-6 LX9 FPGA. This gives him dedicated DSP hardware and more RAM, allowing him to add more processing-intensive features.
[Steven]’s new board can drive up to 4096 LEDs total, and each LED is colored from one of 256 segmented screen areas. The output of the LEDs is smoothed over a configurable time period which makes the result a bit more pleasant. [Steven] also added color correction matrices and gamma correction tables to make up for differences in LED coloration and so the output can be fine-tuned to the color of the wall behind the TV.
Finally, [Steven] added multiple configurations which can be stored in Flash memory. The FPGA can detect letterboxes and pillarboxes in the video stream and change to a corresponding configuration automatically, so settings rarely need to be manually adjusted. He also added an extensive serial interface to configure all of the parameters and configurations in Flash. Be sure to check out the video after the break to see his setup in action.
Continue reading “FPGA Ambilight Clone Packs a Ton of Features”
It’s that time of the year again, and the halls are being decked with trees, the trees covered in lights, and everyone working in retail is slowly going insane from Christmas songs piped over the PA. [Dan] has a tree and a bunch of programmable LEDs, but merely pumping jollity down that strip of LEDs wouldn’t be enough. The Nerd Quotient must be raised even higher with a tree that displays a Unix timestamp.
This build was inspired by an earlier, non-tree-based build that displays Unix time on a 32 LED array. That build used an ATMega328p for toggling LEDs on and off. This time around, [Dan] is using a dedicated LED controller – the AllPixel – that just wrapped up a very successful Kickstarter campaign. The AllPixel is, in turn, controlled by a Raspberry Pi running the BiblioPixel library,
The tree displays the current time stamp in binary across 32 spaces, with green representing a ‘one’ and a red representing ‘zero’. The top of the tree is the least significant bit, but in case [Dan] gets tired of the bottom of the tree staying completely still for the rest of this holiday season, he can switch the order making the base of the tree the LSB.
Continue reading “The Epoch Christmas Tree”
[Tim] got his hands on some APA102 RGB LEDs, which are similar in function to the common WS2812 addressable LEDs seen in many projects we’ve featured. The advantage of APA102 LEDs is that they don’t have the strict timing requirements of the WS2812. These LEDs are controlled with a SPI bus that can be clocked at any arbitrary rate, making them easy to use with pretty much any microcontroller or embedded system.
After working with the LEDs, [Tim] discovered that the LEDs function a bit differently than the datasheet led him to believe. [Tim] controlled a strand of APA102 LEDs with an ATtiny85 and connected a logic analyzer between some of the LEDs. He discovered that the clock signal of the SPI interface isn’t just passed through each LED, it actually looks like it’s inverted on the output. After some investigation, [Tim] found that the clock signal is delayed by a half period (which looks like an inversion) before it’s passed to the next LED. This gives the next LED in the strand enough time for data on the data line to become valid before latching it in.
Since the clock is delayed, [Tim] discovered that additional bits must be clocked as an “end frame” to generate clock signals which propagate the remaining data to the end of the strand. Although the datasheet specifies a 32-bit end frame, this only works for strings of up to 64 LEDs. More bits must be added to the end frame for longer strands, which the datasheet doesn’t even mention. Check out [Tim]’s post for more information, where he walks you through his logic analysis of the APA102 LEDs.
[johannes] writes in with a pretty impressive LED table he built. The table is based around WS2801 serially addressable LEDs which are controlled by a Raspberry Pi. The Pi serves up a node.js-driven web interface developed by [Andrew Munsell] for a room lighting setup. The web interface controls the pattern shown on the display and the animation speed.
[johannes] built a wooden coffee table around the LED matrix, which includes a matte glass top to help diffuse the lighting. An outlet to plug in a laptop and two USB charging ports are panel-mounted on the side of the enclosure, which are a nice touch. The power supply for the LEDs is also inside the enclosure, eliminating the need for an external power brick.
While [johannes] hasn’t written any software of his own yet, he plans on adding music synchronization and visualizations for weather and other data. Check out the video after the break to see the table in action.
Continue reading “A Wooden LED Matrix Coffee Table”
A few years ago, [Marc] had access to a really big, very expensive 3D printer. Daft Punk helmets were – and still are – extremely cool builds, so with a bit of modeling, [Marc] and his friend [Alex] put together a model and printed out a Daft Punk [Thomas] helmet with the intention of turning it into the keystone of a great costume. A few things got in the way, and the [Thomas] helmet was left on a shelf for a few years. Fast forward to a few months ago and [Marc] took up the project again. The result is a 3D printed Daft Punk helmet loaded up with 320 WS2811 LEDs.
The 3D printed helmet was modeled well and printed in polycarbonate, but with any extrusion-based printer, there will be ridges and layers to sand, fill, prime and paint. This task was delegated to another friend, [Shaggy], while [Marc] got busy on the electronics.
The LEDs for the visor and ‘earmuffs’ are WS2811 LEDs, but not the SMD versions we’re so used to seeing. These are 8mm through-hole LEDs mounted in a lasercut piece of acrylic. Control of the LEDs is done with a Teensy 3.1 with [Paul Stoffregen]’s OctoWS2811 library. With the matrix wired up, batteries installed, WiFi capability added, and the helmet painted (not chromed; that will probably happen later, though), [Marc] had a copy of the [Thomas] helmet controllable through an iPhone.
If you’d like to check out more of [Marc]’s work, we posted something on his RGB LED suit and pneumatic Star Trek doors a few years ago.
Continue reading “iPhone-Controlled Daft Punk Helmet”