Archive for the 'Computers' Category

LED Wall Lamp Schematics and PCB Layout

(Note: a hardware failure caused this post, originally posted August 17, to be lost…)

I’ve pretty much finalized the schematics for the wall lamps. They’re available as a PDF or as a gschem file (with a symbol for the TLC5926).

I chose TI’s TLC5926 to drive the LEDs. It is a constant current sink, so it can drive common anode LEDs. It has 16 output channels, each capable of sinking up to 120mA, and the outputs can be placed in parallel.

I decided to order some professionally-printed boards from ExpressPCB. I used their PCB layout tool (which runs fine in Linux under Wine) to create a board that could handle sinking up to a total of about 6A (roughly 2A per channel):

You can grab the PCB layout file here.

The 5926 is controlled by serial input, which should be a good way to get data over long distances. So, I wired up a DB9 connector with all of the relevant data lines that will come from the FPGA.

The boards should be here in a few days; ExpressPCB has really fast turnaround time for their MiniBoard service. I’ll end up with 6 of them, which will probably be useful if (i.e. when) I mess something up.

DIY Etching of QSOP Traces

Last week, I finally found some current sinking LED drivers that would work well with the LEDs that I chose for the wall lamps.  The TLC5926 has pretty much exactly the capability that I need to power these LED arrays.  Because the LEDs have a common anode instead of a common cathode, it is necessary to use constant current sinks instead of sources because they sit between the LED and ground.

Unfortunately, the only ones I could find in stock were in TI’s ultra-small QSOP package (other manufacturers use the term “SSOP”).  After they arrived, I realized that it would be pretty difficult to prototype with them.  Eventually, I planned to order PCBs from ExpressPCB (more on that later), but I wanted a quick way to access one of the drivers I had purchased for testing.  I started by trying some 30-gauge wrapping wire, but neither of my attempts yielded anything decent.

I then began reading about DIY PCB etching.  I’ve wanted to try this for a long time now (I even had a bottle of ferric chloride just waiting to be used).  Unfortunately, I don’t have a laser printer.  We do, however, have an old, half-broken laser copier, which decorates copied documents with ghost images and random streaks.  I couldn’t find any information on manually etching QSOP traces (they’re so small that I was almost positive either the inkjet printer or the copier wouldn’t have the resolution required to print the traces out).  So, I tried it out anyways.  I managed to print a simple breakout design and transfer it onto  the board using glossy photo paper, heating the board with an iron (on its highest temperature) for about 30 seconds, putting the transfer paper onto the board, and then just holding the iron in place for about 5 minutes.  After transferring the toner, part of the paper came off very easily, but the other piece needed to be dissolved away in water.

Next, it was time for the ferric chloride.  It’s pretty nasty stuff, so we did all of the work outside.  After about 45 minutes of swishing the board around (we should have masked more of the PCB to speed up the process), the copper had dissolved, and I washed the masked traces  off with some acetone.

Finally, it was just a matter of soldering the device onto the board.  To do this, I soldered all of the pins together and then used a wick to wipe away all the bridges, leaving nicely soldered joints.  If you saw the pictures above, you probably noticed that the traces aren’t the right size!  This is a result of the old copier we have; it somehow slightly changed the paper size.  Fortunately, it doesn’t matter for this chip, which only uses the first four pins on each side individually, while the rest of the pins are all combined together to act as one big current sink.

Surprisingly, it’s quite possible to etch QSOP-sized traces using the “standard” method of DIY PCB etching.

I’m currently in the process of testing these drivers.  In the meantime, I’ve already made an order with ExpressPCB for the actual driver boards.  I’ll post those, along with schematics for the entire wall lamp soon.

Evaluating LEDs for ACRIS

I got sidetracked (what else is new) from my audio visualization project and things have been progressing somewhat slowly.  First of all, my oscilloscope has randomly decided to stop displaying channel 2, so I need to fix that at some point so that I can use my spectrum analyzer again.

Anyways, I recently received four RGB LEDs from DealExtreme.  DX sells two types, so I bought two of each to determine which one to buy for my lighting project.  The first one I saw is on a star board and is cheaper than the second, which is enclosed in its own casing.

First, a few pictures:

These pictures were taken while the LEDs were being driven with very little current.  The star emitter is supposedly rated at 350mA for each channel and when each color is driven at this current, the LED is extremely bright.  I initially anticipated needing around 20-25 LEDs for each wall lamp, but I can see that 5-10 will definitely suffice.

I think I know why the star emitter is so cheap.  It’s labeled incorrectly.  The emitter, like most others, is common anode, meaning that the + terminal is common to all three colors.  The markings on the board are indeed wrong.  The enclosed emitter is also common anode.

Here’s a graph of some preliminary tests of driving the diodes at different voltages.  I pushed the enclosed one a lot harder, so I will need to set up a more rigorous test for complete characterization of the diode.  Also, I wasn’t able to heatsink the encased emitter, but stuck the star emitter on a big block of aluminum with some thermal compound.

As is fairly easy to see, the voltage curves look very similar between the two emitter models, except for the green channel.  However, it is also important to note that at 350mA, the first LED did not get anywhere near its rated operating voltage.  I haven’t pushed it far enough to see just how much current is necessary for it to be at is operating voltage, but the diode is certainly bright enough at 350mA.  I don’t want to overly degrade the diode by pushing it too far, or my wall lights will keep breaking.

I’ll probably go with the star emitter because it’s easier to attach a bunch of them to a heatsink block.  I’ll definitely need some kind of diffuser for the lamp, though.

The enclosed diodes are great for custom LED projects where you only need one or two of them; I wouldn’t recommend it for creating a compact array, though.  I might use them in my computer case or something; I could make them change color depending on processor load.

tmux Extended Window Status Patch

Well, time to cross something off of my ideas list.  One of the few frustrating things about tmux is that its status bar doesn’t distinguish between different types of window alerts.  If a bell goes off in the window, the window’s label in the status bar is changed to the same color as it would be if just some content changed.

To me, that seemed like counterintuitive behavior, so I wrote up a quick patch that breaks out the window-status-alert-* style into three new styles: -activity, -content, and -bell.

You can grab the patch here.  If you run Arch Linux, you can get the PKGBUILD for tmux-cvs with the patch applied in the AUR instead.  I will also submit this patch to the tmux devs.

AVR-Oscilloscope Spectrograph

Sometimes, when you’re working with waveforms, it’s helpful to get a live picture of the frequency spectrum.  Since I’m trying to develop audio visualization algorithms, I thought it would be a good idea to create a tool to plot the FFT of a signal.  I was inspired by this excellent project, which uses an Atmel ATMEGA8 and an LCD to display a waveform and its corresponding FFT with a delay only on the order of milliseconds.  The project designer built a nice FFT library, which I incorporated into my project along with his recommendation for an anti-aliasing filter.

The problem was that I didn’t have an LCD to play with, so I had to settle for something slightly different; I wrote up a quick block to display the FFT data on my trusty Tektronix 335 oscilloscope.

There are basically two parts to the modification: first, I created an 8-bit DAC resistor ladder so that I could represent the intensity of each frequency of an FFT as an analog value.  Secondly, I created a low-frequency clock line that changed with each transition to a new frequency.  Finally, I just needed to trigger on the clock line with the oscilloscope to be able to view the full FFT.  This is easier to explain with a picture:

This FFT from an audio clip shows a large low-frequency component and a smaller mid-range component.  I tried playing some sine waves, sawtooth waves, etc. as well and the output was pretty accurate.  Here are a few pics of my setup (yes, I’m really bad at board layouts):

There are still a few major problems that I need to work through.  The biggest one is due some pretty painful noise coming from the clock lines and what looks to be my computer.  The latter can probably be solved by implementing a decent filter, though I’m not sure how the other project’s designer had so much success with his setup.  The other sources of noise seem to be coming from the clock lines and other lines around the board.  These can be solved by properly implementing this circuit on a PCB like the author did.  I’m seeing a lot of strange low-frequency noise in the FFT as well (the quick fix was to just remove the lowest few bars from the FFT output).  In addition to solving the noise problem, I need to fine tune some of the delay values I have for oscilloscope output to make it look better.

I’ll have code and schematics up in a few days.

Electronics Lab Done

I procrastinated a lot, but I’ve finally finished organizing all my electronics stuff.  Now, I actually know what kinds of parts I have so that I don’t end up buying them again.  My passive components are organized by value in drawers, I have a bucket full of power supplies, and I have a shelf just dedicated to laser stuff.  A few buckets on the bottom shelf hold all of the larger stuff that I plan to repair or use in other projects (e.g. a GameCube that someone gave away which just needs a new drive motor, a keyboard that needs a driver, etc.).

Work on my lighting system begins tomorrow.  :)

Free VoIP Calling using Google Voice, Antisip, and IPKALL (and a CLI utility)

I’ve been experimenting with my FreeRunner recently and came across some articles about free VoIP.  As it turns out, thanks to Google Voice and a few extra services, it’s possible to both receive incoming and make outgoing calls completely for free.  After setting these services up, I wrote a CLI utility that combines a Python Google Voice framework with Linphone in order to make the task of placing a call easy.

Getting free VoIP

You need three things: a Google Voice account, an Antisip account, and an IPKALL phone number.  Go to each of these websites to create them.  For Antisip, you can use your Google Voice number for the PSTN Phone.  For IPKALL, you’ll need to provide the following information:

SIP Phone Number: [antisip username]
SIP Proxy: sip.antisip.com

After some time, you’ll receive a Washington state phone number.

Now, open up Linphone using either the GUI or the CLI client (probably easier with the GUI).  In the preferences of the GUI, there is a tab called “Manage SIP Accounts;” go there.  Add a proxy account with the following information:

Your SIP identity: sip:[antisip username]@sip.antisip.com
SIP Proxy address: sip:sip.antisip.com
Register at startup: yes

Now, Linphone should register.  You can try calling a SIP echoline at sip:*010600@ekiga.net to see if things are working.

Putting it all together

Lastly, we want to be able to make free calls to regular phones, too.  This is where the IPKALL number and Google Voice come in.  Antisip only allows incoming calls.  When you call a number from Google Voice, it first calls you and then calls the other person, thereby acting as a link between the two connections.

So, add the phone number you got from IPKALL to Google Voice and try calling a phone number from the Google Voice interface.  It should call your SIP client first and then call the other number.

CLI App

To make this process quick and painless, I wrote a quick Python script called gvcall.  Basically, it makes the process of calling a number from your computer as painless as gvcall 5555555555.  You can also use your non-VoIP numbers as well.

ACRIS – A Hardware-Based Audio Visualization Project

I’ve always found audio visualization to be pretty interesting — it combines the complex (hah, pun) mathematics of signal processing with the entertainment of watching cool effects. Many audio players have interesting audio visualizers built-in; others are available as addons. MilkDrop seems to be quite popular.

Funky patterns on a screen changing to music is cool, but for a while, I’ve wanted to create a more entertaining experience. Essentially, my idea has been to create a set of wall lamps powered by arrays of multicolored LEDs. A microprocessor would adjust the color and intensity of the lamps based on audio input.

From a high-level standpoint, this kind of system is not too complicated. A low-latency audio processor takes audio signals as an input, performs some frequency analysis on them, and generates PWM signals. These PWM signals are fed into LED arrays making up the wall lamps. As always, though, the devil’s in the details.

System Design

The final design will use an FPGA with some simple support hardware to do the audio processing. Overkill? Probably… A fast microcontroller is usually good enough for these kinds of things. But, I wanted to make this a hardware project. The FPGA I plan to use is a Spartan 3, available cheaply on this eval board.

To elaborate a bit, I’ll feed an audio signal into a high-frequency opamp, which will buffer the audio signal and send it to an 8-bit ADC, whose output is fed into the FPGA. The FPGA will take an FFT of the data and then, based on the color mixing algorithm I choose, will operate on the frequency data. Finally, after deciding the final desired color, the FPGA outputs PWM signals to the wall lamps, those internal circuitry amplifies and uses those signals to light up the desired color. I’m hoping for a total latency on the order of tens or hundreds of microseconds.

I’d like to put up three or four lamps. One will be on the left side of my room and another will be on the right. These two lamps will be controlled solely by their respective stereo components. The other lamps will be above my desk and will be controlled based on a combination of left and right audio data.

I was originally hoping to make the wall lamps interact wirelessly, but I don’t think that’ll be possible given the price of wireless modules. Also, there is a latency problem as well as a security issue involved with wireless.

Anyways, I’ve had a few ideas for the color mixing algorithm. One was to separate the frequency graph into three large chunks (e.g. “low” frequency, “medium,” and “high”) and then define some sort of color scale for each chunk. Next, for each chunk, the center of mass is determined and is used to locate a color on the chunk’s color scale. The relative intensities are compared and then a final color is mixed. This algorithm is actually very easy to implement. A friend of mine suggested another interesting algorithm (harder to implement, but definitely worth a try): split the frequency graph output from the FFT into octaves and then define the same color scale for each octave. Colors are mixed in proportion to their intensity. This guarantees that all equivalent pitches (across octaves) have the same color. You could also improve the algorithm a bit to make the lower octaves biased toward one color and the higher octaves biased toward another. There will be three multiplexers
to determine the FPGA input. The first will allow switching between 2 or 3 analog audio channels. The second can bypass the ADC and send digital data directly into the FPGA. The third will bypass the FPGA directly and allow some device (e.g. a microcontroller) to send in PWM signals to the LED arrays.

Finally, as a finishing touch to bring out the bass, I’d like to add blue backlighting to the wall lamps that lights up only to low frequency responses.

As for the LEDs to use, an array of Cree MC-Es would be spectacular, but pricey. Another option would be to use a bunch of cheaper chips from DealExtreme.

Current Status

Right now, I’ve ordered and AVR and supporting hardware in order to use this project I discovered as a starting point. Instead of outputting a graph to an LCD, though, I am going to begin testing simple color mixing algorithms with whatever LEDs I can find. Using a microcontroller will allow me to quickly test algorithms, although the latency may be noticeable. In the future, I’ll switch the function of that AVR so that it can take input from other sources and control the lighting system.

As I begin building stuff, I’ll start posting my notes and diagrams.

Drive Upgrade: OCZ Vertex 2 SSD

Last week, I purchased an OCZ Vertex 2 50GB SSD drive ($174.00) and a Samsung 1TB drive ($79.99; I’m using it to keep the backups I take with DAR).  After doing some research, I decided on the Vertex 2 SSD for its impressive speed: reads peak at 285MB/s and writes peak at 275MB/s.  The reviews indicated that the manufacturer’s specifications were accurate, so I decided to give the drive a try.  As usual, NewEgg shipping was ridiculously fast; the drives shipped from New Jersey, so it took all of a day for them to get here.

Image taken from OCZ's WebsiteLike most SSDs on the market, the Vertex 2 is in a 2.5″ form-factor, but comes with a convert to secure it into a 3.5″ bay.  Unfortunately, this converter is not immediately compatible with the Antec 1200 (well, any of the Antec cases that use special screws to secure drives in the bays).  The problem is that the screws for the drive bay have a smaller diameter than the ones that come with Antec’s drive bay.

This is a problem because Antec’s screws are very long.  The drive bay has an outer and an inner wall, with a plastic piece connecting the two; the screws go through both walls and into the hard drive.  Since I could only use the screws that came with the SSD, which were obviously very short, I thought I was out of luck.

It turns out that by popping out the plastic pieces highlighted in red in the image below (the drawing itself is taken from the Antec 1200 mechanical drawings, available on the Antec website), you can access the inner wall of the drive bay directly.

Original drawing from Antec's websiteNext, you need to use a pair of tweezers to get the SSD mount screws in through the hole highlighted by the orange arrow (they won’t fit through the screw hole in the outer wall of the drive bay).  Once you have positioned the screw at the hole in the inner wall, you’re all set.  This process is a little tricky and can take some time and patience, but it will mount the drive very securely into the bay.

According to my initial testing, this drive absolutely performs up to the specifications listed on the website and the POST that my computer does on startup now is the slowest point in booting.  More importantly, I’m using this drive for everything in / besides /home, so application load times are fantastic.  My 1.2TB RAID 5 array is now entirely devoted to my home partition.  Disk read times were once the major bottleneck in my computer’s operation (as they usually are for any computer), but the addition of this SSD has improved the speed dramatically.

Lastly, I can’t help but make a small plug for Arch Linux.  I chose to reinstall all of my software on my new drive instead of copying it over with DAR.  So, I backed up my home directory, etc directory, and used Arch’s package manager, pacman, to create lists of packages I installed both from the main Arch repositories and from the AUR.  That’s literally all I needed to make a complete backup of my system.

April Screenshots

This month, I’ve switched to the Awesome Window  Manager (configs coming eventually) and rxvt-unicode.  That’s pretty much it.