原创 My own BADASS display (Part 3)

Just to recap, I've decided on the overall look and feel of the first incarnation, as illustrated below. My first big decision is using a 16x16 array of tri-colored LEDs. The panel on which the LEDs are mounted will be pressed board painted to look like antique brass. This board will be mounted on a larger plywood panel stained to look like expensive cherry wood. The two boards will be attached using brass acorn nuts, which I'll age to look old. (All this was discussed in more detail in my previous blog on this topic.)

 

Now, since I've been spending so much time playing with Adafruit's NeoPixels recently, I've decided to use these for this project. The great thing about these tri-colored LEDs is that each one contains their own PWM controllers (one each for the red, green, and blue sub-channels), and they have only four pins: power, ground, data in, and data out. You can daisy chain hundreds of the little scamps together and control each element in the chain individually using only a single pin on your microcontroller.

 

If I were going for a smaller display, I might be tempted to use Adafruit's new 8mm diffused NeoPixels and the associated WS2811 driver chips. However, I've decided to use Adafruit's NeoPixel strips. Of course, I am tempted by the 144 NeoPixel per meter strips, but these are rather expensive, and the resulting display would be quite short. To get around this, I'd be tempted to use 32 or 64 elements per column, but that would further increase the cost and complexity.

 

What I need to do is get my first-pass display up and running and use it as the basis for any future versions. Similar issues -- cost and small display size -- would come with the 60 NeoPixel per meter strips. Thus, I've opted for the 30 NeoPixels per meter strips, as illustrated below.

 

One downside to using NeoPixels is that they are a bit temperamental with regard to timing. In real terms, this means you have to use an Arduino Uno or an Arduino Mega. I'll use an Arduino Mega. Furthermore, since I'll have 54 digital input/output pins at my disposal, I'm thinking of using 16 pins to drive 16 strips, each of which will form one of my columns, as illustrated below.

 

OK, that's the easy part done (well, decided). This is where things start to become more complicated.

I know I'm jumping around a bit here, but I've got all sorts of ideas buzzing around in my mind. As a starting point, let's assume that we are working with a mono audio stream, and that we will present the lower frequencies on the left side of the display and the higher frequencies on the right.

 

Let's further assume we will use the entire column to represent the amplitude. One possibility is to divide the columns into four colored bands, as illustrated in (a) below. Another option is to keep the same bands but make the entire column the highest-amplitude color, as shown in (b).

 

An alternative is to make the signals grow out from the middle, as illustrated in (c). A variation on this theme would be to make the signals grow up from the bottom and down from the top, as illustrated in (d).

 

Of course, the (c) and (d) versions could be used to display the two channels from a stereo audio stream, but I want to keep things reasonably simple in this first iteration of the display, so I'm sticking with mono. Actually, this raises a question. To drive my display, I will use my iPod or my iPad, both of which have stereo outputs. Thus, I will need to combine the two stereo channels into a single mono channel. Remember that I've not really played with audio like this before, so I'm going to need to work out how to do this.

 

Two more questions that pop into my mind at this point are how we scale the horizontal and vertical axes. Let's start with the horizontal axis. We will divide the audio spectrum into 16 buckets. Let's say that the lowest bucket includes anything equal to or less than 50 Hz, while the highest bucket includes anything equal to or greater than 16 KHz. How do we divide the frequencies across the remaining buckets? Do we go linear and partition things into equal chunks, or should we perform the split in a logarithmic manner?

 

The same question applies to the vertical axis. When it comes to presenting amplitude, my knee-jerk reaction is that a logarithmic presentation is the way to go. Once again, however, audio signal processing and display is not my area of expertise; perhaps the amplitude should be presented in a linear manner.

The next consideration is that an Arduino Mega has only 8 KB of RAM, which is pretty limiting in the scheme of things. Also, the poor little ragamuffin runs at only 16 MHz.

 

When I decided to create my BADASS Display, my first thought was to use digital signal processing (DSP) techniques to extract the spectrum information from the audio stream. If I were to go this route, should I use a fast Fourier transform (FFT), a discrete Fourier transform (DFT), a discrete cosine transform (DCT), or something else entirely?

 

But then I started to worry that my poor little Arduino Mega might not be up to the task. What I really want my Mega to do is focus all its attention on displaying the information. This means that I need to extract the spectrum information from the audio stream by some means and then simply present it to my Mega along the lines of "Bucket/Column X = Amplitude/Row Y."

 

If I performed my signal processing in the digital realm by means of an FFT, DFT, or DCT, then one solution would be to use a second processor. For example, I could use a chipKIT Max32 to perform the DSP and feed the results to my Arduino Mega via an I2C link, as illustrated below.

 

Another alternative is to move the signal processing into the analog realm. This is based on the fact that my Arduino Mega has 16 analog inputs. I was thinking about creating a simple four-pole band-pass filter using an op-amp combined with a few discrete components. Then I would replicate this 16 times, varying the values of the resistors and capacitors for each stage to extract the appropriate portion of the spectrum, as illustrated below.

 

One reason I thought this op-amp solution might be interesting is that it would be relatively easy for a hobbyist to implement. Also, it would be scalable. If you could afford to implement only a four-channel display, for example, you could simply select the appropriate discrete components to divide the audio spectrum into four bands.

 

But then I started to think about the problems involved in setting everything up. Also, these op-amps would be set to some nominal output level. If you have a prolonged quiet piece of music, you might want to boost the outputs on the display a little. By comparison, if you have a prolonged loud piece of music, you might want to do something else at the outputs. All these considerations swung my attention back to performing my signal processing in the digital realm.

 

There is, of course, another option. Suppose I were to implement the DSP functions in an FPGA, which can perform a humongous amount of processing in a massively parallel fashion. For example, suppose we had the scenario illustrated below.

 

In this case, we're probably looking at a lower-cost FPGA, so we'll use an external analog-to-digital converter. How many bits should I use? Eight? Ten? Twelve? I'd also like the FPGA implementation to be scalable and configurable. Maybe my Mega can send a series of configuration instructions telling the FPGA how many channels we want and the frequency band for each channel.

 

We could then leave the FPGA to do the heavy lifting -- sampling the audio stream and generating the spectrum data. The Mega could read the values for each channel periodically and then go off and concentrate on displaying the results.

 

Good grief. There are so many options available that my head is spinning. I'm going to go ponder this further. Meanwhile, if you have any expertise in this area, this would be a really good time to wave your hand in the air and say, "Max, I'd love to help."

My own BADASS display (Part 4)