Mapping WiFi Signals in 3 Dimensions

[Charles] is on a quest to complete ever more jaw-dropping hacks with the popular low-cost ESP8266 WiFi modules. This week’s project is plotting WiFi received signal strength in 3D space. While the ESP8266 is capable of providing a Received Signal Strength Indication (RSSI), [Charles] didn’t directly use it. He wrote a simple C program on his laptop to ping the ESP8266 at around 500Hz. The laptop would then translate the RSSI from the ping replies to a color value, which it would then send to the ESP8266. Since the ESP8266 was running [Charles’] custom firmware (as seen in his WiFi cup project), it could directly display the color on a WS2812 RGB LED.

The colors seemed random at first, but [Charles] noticed that there was a pattern. He just needed a way to visualize the LED over time. A single frame long exposure would work, but so would video. [Charles] went the video route, creating SuperLongExposure, an FFMPEG-based tool which extracts every video frame and composites them into a single frame. What he saw was pretty cool – there were definite stripes of good and bad signal.

wifiPOVThumbArmed with this information, [Charles] went for broke and mounted his ESP8266 on a large gantry style mill. He took several long exposure videos of a 360x360x180mm area. The videos were extracted into layers. The whole data set could then be visualized with Voxeltastic, [Charles’] own HTML5/WEBGL based render engine. The results were nothing short of amazing. The signal strength increases and decreases in nodes and anti-nodes which correspond to the 12.4 cm wavelength of a WiFi signal. The final render looks incredibly organic, which isn’t completely surprising. We’ve seen the same kind of image from commercial antenna simulation characterization systems.

Once again [Charles] has blown us away, we can’t wait to see what he does next!

Continue reading “Mapping WiFi Signals in 3 Dimensions”

Hackaday Links: February 1, 2015

It’s Sunday evening, and that means Hackaday Links, and that means something crowdfunded. This week it’s UberBlox. It’s a modular construction system based on Al extrusion – basically a modern version of an Erector set. Random musings on the perceived value UberBlox offers in the comments, I’m sure.

[Trevor] sent in something from his Etsy shop. Normally we’d shy away from blatant self-promotion, but this is pretty cool. It’s reproductions of 1960s Lockheed flying saucer plans. We’re not sure if this is nazi moon base/lizard people from the inner earth flying saucer plans or something a little more realistic, but there you go.

3D computer mice exist, as do quadcopters. Here’s the combination. It looks like there’s a good amount of control, and could be used for some aerobatics if you’re cool enough.

Who doesn’t love LED cubes? They’re awesome, but usually limited to one color. Here’s an RGB LED cube. It’s only 4x4x4, but there’s a few animations and a microphone with a beat detection circuit all powered by an ATMega32u4.

A while ago we had a post about a solar powered time lapse rig. Time lapse movies take a while, and the results are finally in.

RGB LED Matrices With The STM32 and DMA

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”

RGB Bike Rim Lights

[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”

FPGA Ambilight Clone Packs a Ton of Features

[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”

The Epoch Christmas Tree

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.

Video below.

Continue reading “The Epoch Christmas Tree”

Digging into the APA102 Serial LED Protocol

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