MPD Control Panel

Introduction

I was making good progress on the toy kitchen last fall, and then my son Eliot was born a month too soon, and we moved to a new house that same week.  It was some time before I was at leisure to revisit the project (long after the contest was over) and it looks like the OLED screen (which had always been rather flaky) was no longer functioning at all.

I had still hoped to make something of the Grove Toy Kit and submit some step-by-step instructions for it, since the folks at Seeed so very kindly sent me the kit.  At work recently, I finally received authorization to install Linux on my main workstation, but there have been a few things that I have wanted:

• I wanted an easy way to lock my screen when I got up.  Windows had WIN+L, and I hadn’t bothered finding the Linux equivalent key combination.
• I wanted an easy way to control my music player.  I use MPD and Sonata, and frequently have to pause or adjust the volume when someone comes by to consult me.
• I wanted a better notification for my Pidgin IM client.  The default (as far as I could find it) merely changed the color of the chat window’s entry in the system bar, but it didn’t stand out enough for me to notice it in a timely manner.  My mis-configuration of MPD prevented any aural notifications from working, so I was quickly getting rather unresponsive to IMs, which annoyed my teammates.  I fixed the MPD configuration, but still wanted additional notification (if, say, I wasn’t wearing my headphones).

Design Notes

A front view of the controller in its classy enclosure, with four touch sensor buttons, a potentiometer, and an RGB LED (on the side). The leftmost button is "previous track", the left-center is "pause/resume", the right-center is "next track" and the rightmost is "pause and lock screen".

I decided to build a stand-alone controller for MPD, something that would use a serial interface to a bunch of buttons and a knob, and maybe an LED for status.  I had (almost) everything I needed in the Grove Kit:  Seeeduino, Grove Base Shield, Chainable RGB LED, and an I2C Touch Sensor, along with a bunch of cables.  I had to roll my own Potentiometer, but that wasn’t too tricky.

The thing I like most about the Grove system is that it is pretty easy to assemble the hardware in a meaningful configuration in short order.  If Seeed would package up a solid Arduino utility library for their various sensors, it would be even more powerful.  As it was, I had to cobble together the software myself.  I was able to re-use the touch sensor library I made from my earlier work on the kitchen project.  I had to implement my own interface to the RGB LED (based on some examples they gave).  I will be posting the source for the whole project, but I may try and package that up as more of a standalone library.

Anyway, here are some step-by-step instructions for the project.

Electronics

A top view. It's crowded in there! Note the classy twist-tie mounting mechanism. Also note the homebrew potentiometer plug, wired in on the right, and insulated with heat-shrink. On the lower-left is the I2C touch controller board.

1. Construct the potentiometer twig:
   1. Take a spare Grove cable and cut it in two (save the spare, you can make something else out of it).
   2. Solder one side of the pot to VCC (red), the other side to ground (black), and the center tap to either of the data wires (yellow or white).  The data line you pick just determines which of the two inputs the pot goes to, but you can also pick which socket on the shield you use, so it doesn’t matter a whole lot.
2. Put it all together:
   1. Connect the I2C Touch Sensor to one of the I2C ports (Note: this makes A4 and A5 unavailable for other purposes).
   2. Connect the potentiometer you made to one of the other analog inputs (say, A0 or A1).
   3. Connect the RGB LED to one of the unused digital ports (Note: D0 and D1 will be used by the serial connection.  I chose D12 and D13)
   4. Plug the shield into your Arduino (or Seeeduino, or other device with a compatible form factor).

Software

I’m afraid the software is rather unwieldy to include inline here.  In the github repo, you’ll find the main sketch as ‘mpd_control_panel.pde’, which puts together the MPR121 interface library (included) and the control for reading the pot and activating the LED.  I hope it’s relatively self-explanatory (though it probably needs some cleanup).

Enclosure

A better view of the back, showing more twist-tie mounting connectors. The whole system is weighty enough that, combined with the sensitivity of the touch sensors, it will not slide on the desk under the touch required to activate an input button.

For the enclosure, I used a sturdy cardboard box I had that was about the right size (though I had to hang the LED off the side).  I wanted something that I could possibly mount to the bottom of the desk, right at the edge, to keep the desk surface clear.  Cardboard was pretty easy to cut out and mount things to, and seems sturdy enough for my purposes.  I had to cut extra stuff out around the top of the touch sensor buttons, because of the glue holding the sensor wires in place.  Some masking tape on the back helps hold the buttons in place.

I don’t have a photo from the correct angle, but there’s a small cutout on the left for the USB cable, which will allow the system to be connected to the PC for the serial interface.

Interface

The PC interface is a Python script that communicates over the FTDI USB serial port provided by the Seeeduino.  It uses the mpc command-line client for the MPD server.  The command protocol is as simple as it can get:

T# (for # = 0-F): Current status of the touch sensor buttons, as a 4 bit int, with the LSB representing the leftmost button, sent on change.  Note that 0 means no buttons are touched, I’m not using this at the moment, but may someday.

A# – A###:  The current volume level, from 0 to 100, sent on change.  This was actually a bit on the noisy side, so I’d get events from time to time.  I might lower the sensitivity and only send even numbers, if it proves to be annoying

L######:  Set the LED to the given hex RRGGBB color.  The total latency from the PC to the LED is pretty bad, so you can’t really use this sequence to do cool, fast color changes.  I have considered using a built-in set of various fading programs, but haven’t gotten around to it.

The python script itself listens for Serial events, and invokes the corresponding commands.       When a command is successfully received, it lights the LED green for 1 second.  To allow the separate Pidgin notifier script to work, I added a UDP socket listener.  When a new IM is received, the IM notifier sends a message on that socket, and when the control script receives it, it turns the LED blue for 1 second.  I tried making it robust to unplugging and replugging the control panel in (so it could always just be running in the background), but it appears that if I am trying to access /dev/ttyUSB0 with the script and plug the device in, it enumerates as /dev/ttyUSB1.  I don’t want to bother making the script try and detect this, so for now, I think I will just force a restart.  Now that I’m done taking photos, I see little reason to disconnect it.

This all sounds complicated, but it really wasn’t too bad.  Here’s the python script for the notifier (latest version available in the github repo):

The python script for the MPD console controller itself is available in the github repo, as ‘mpd_control.py’.  It starts a threaded UDP server in the background (to listen for IM notification commands) and then listens on the Seeeduino’s serial interface for commands in the protocol language.

There is a separate script for listening to the Pidgin IM client protocol for new message notification, called ‘pidgin_notifier.py’.  When there’s a new message to a window that is not in the foreground, it opens a UDP connection to the controller and sends a few bytes, which causes the controller script to trigger the LED notification.

Conclusion

It could hardly have been easier to assemble this thing.  I had it in one piece, enclosure and all, in less than an hour.  I implemented the basic button software in an hour, another 30 minutes for the volume control, and another hour for the LED.  The Python interface was another 15-20 minutes.

Space Age Robotics

I’ve got a new site up at http://www.spaceagerobotics.com/, a place I can put more formal projects.  I will continue to post other more hackish projects here, but feel free to go over and check it out.  I still have a few SARduino328 boards left, yours shipped anywhere in the world for $5.

SSD1308 (128×64 OLED) I2C Arduino Library

The other part of the oven control panel is the OLED Display 128×64 Twig, which has an I2C interface.  Since the Seeeduino168 I’m using has only 1KB of RAM, and since the screen has 1024×8 pixels, I do not have the RAM to maintain a framebuffer, like some other approaches.  But I wanted to have a general purpose library that would allow me to write text and basic graphics (boxes, etc.) to the display without rendering them to a framebuffer and then updating the display.

So I created an SSD1308 library as another module for Jeff Rowberg’s i2cdevlib library.  It has a basic text model, which uses a fixed-width font and divides the screen (along page boundaries, according to the page model of the SSD1308’s display RAM) into 8 rows and 16 columns of 8×8 character blocks.  You can write text to an arbitrary X, Y position on this grid, and it will wrap around the end of one line to the next, and around the bottom of the screen to the top.  There is some example code included in the library.

It is also possible to write graphical data directly to the screen, but if you cannot maintain an internal buffer or some other record of what is on the screen, it is not possible to draw graphics without overwriting the data underneath the area on which you are drawing.  Still, I hope it will prove useful as a way to use these displays with processors that don’t have RAM to spare.  It would be nice to add optional support for a framebuffer, or for an SPI interface (instead of just I2C) to have a more high-performance project, so if you’re interested in contributing, feel free to start on those.

My next goal for the OLED library is basic support for drawing boxes and other shapes to the display, stay tuned for more on that.

I have also been working on the MPR121 touch sensor interface, and have added some basic support for callbacks (with a polling interface).  You can check that out in the i2cdevlib repository soon.

MPR121 (I2C Touch Sensor) Arduino Library

As part of my Play Kitchen Retrofit project, I’m building a control panel for the oven using this I2C Touch Sensor module from SeeedStudio.  I couldn’t get the demo code to work (invalid ZIP, posted something to support about it, but am still waiting to hear back), but the interface looks pretty simple, and I’ve had experience with I2C before, so I thought I’d write my own interface abstraction library.

While checking to see if anyone else has already done this, I found the i2cdevlib project, by Jeff Rowberg.  He has written an I2C abstraction layer and library framework which looks pretty good, and had a placeholder for the MPR121 driver code.  I whipped up a partial implementation that sets up all channels as simple touch sensors and provides a way to poll the results, and submitted it, and he was kind enough to include it in the library.

It’s far from a complete driver implementation for this device, but it was enough to work for the 4-channel controls I had, and I hope it will be a good foundation for someone who needs more features to build upon (maybe me, in the future, who knows?).

When implementing it, I ran into some trouble trying to test pins 8-11, which are the other pins broken out to connectors on the Twig.  I’ve asked support about that, too, in case there’s a software workaround I can use, but since I don’t need those channels for this project, I’m not gonna sweat it too much.

Stay tuned for a module (for the same library) for controlling the OLED 128×64 display Twig!

Play Kitchen Retrofit

Seeed Studio is running a toy hacking contest, they’re looking for step-by-step instructions for projects using their GROVE Toy kit.  The GROVE wiki page says it all.  I submitted an entry, and was accepted as a contestant.  Here’s some more info about my entry, and the progress I’ve made so far.

We refinished an old wooden play kitchen set for our two-year-old daughter last Christmas.  She love playing with it, and, mimicking the way her folks use their own kitchen, she’ll say “beep beep beep”, and go over and look in, and say, “Is it done?”.  Too adorable.  Here’s the kitchen:

I thought a good project would be to retrofit it with some electronics.  I’d like to add a timer (and possibly temperature) control panel for the oven, with buttons to set the timer and the oven, and a display showing the time left (not with numbers, but just a progress-bar-esque thing trickling down).  There will be a buzzer or beeper for when the timer goes off.  I’d also like to include a light inside the oven that is turned on when the door is opened.  Maybe the color of the light would respond to the temperature set on the oven.

Here’s a closeup of the stove.  I’m planning to attach the panel to the back, somehow, just like our non-play oven.

With the things available in the contest pack, I thought I could use the PIR motion sensor to determine when the oven door was opened, the RGB LED for the light, and the touch sensor, OLED display, and buzzer (or possibly, the vibrator) for the control panel.  Since I don’t actually have an Arduino form-factor controller board to plug into the Stem shield, I requested one as part of the kit, and Seeed was kind enough to include it for me.

Stay tuned for more details, example programs, and a few Arduino libraries to support these hardware components.

Schamplifier – Heat Sink Design

[Edit:  Whoa!  I was way off with my calculation of the heat sink surface area.  12″x3″ is 0.023 m², not 0.21 m².  This changes a lot, it makes , which is way too much.  If I up the heat sink size to 12″x6″, I get , which is not as awesome, but is probably doable.  I’ve updated the analysis to reflect all of this.]

Introduction

Like the Squelette, I aim to design an enclosure that can also serve as the heat sink for the amplifier ICs (and any other power electronics that end up inside, like voltage regulators for control circuits, and so forth).  The heat-sink portion of the enclosure will be made of sheet and angle aluminum.

Since I’m don’t yet have a list of everything I want to include inside the enclosure, I’d like to provide a little more breathing room than the Squelette enclosure would offer.  Further, the two amplifier ICs will probably not be attached to the same panel of the enclosure.  Finally, I’d like to hook some kind of heat sink up to the ICs before I construct the enclosure so I can test out the circuit without burning everything up.  I could just use the dimensions specified for the Squelette enclosure, but that would be unwieldy for my test and wasteful of raw material for my enclosure, so I’d like to understand thermal design enough to figure out what kind of heat sink this device requires and determine with some level of confidence whether a particular enclosure design will function to dissipate heat adequately for the amplifier.

I had a helpful exchange with the author of the Squelette, Ross Herschberger, in the “Heatsink Design” thread on the Squelette main page.  This exchange led me, ultimately, to this analysis.

Background

Knowing zilch about heat dissipation and transfer, I had to start learning from scratch in support of this project.  I found this EEVblog episode on thermal design the most helpful.  This short page and calculator on convective heat transfer helped me to understand how convection factors in.  This page on heat sink design provides a lot more general background information.  Here is a calculator for heat sink temperature rise that made it quick and easy to check my results as I was fiddling around with numbers.  The Wikipedia page on Thermal resistance in electronics helped me understand how the heat travels through heat sink materials.  Finally, I found this calculator that was somewhat helpful in finding the thermal resistance of an aluminum slab.

Maximum Power Dissipation

Before we can determine what kind of heat sink capability we require, we must first determine how much power the amplifier will be dissipating.  From the LM1875T datasheet, given the power supply voltage and average load, we can compute the maximum power dissipation of the device.  The formula is

Where:

• is the maximum power dissipation
• is the total power supply voltage (in this case, for the Squelette, ±18V = 36V)
• is the load resistance (in this case, 8Ω impedance speakers)
• is the quiescent power dissipation of the device

The datasheet gives 100mA as the maximum quiescent current, and claims for example that a 60V system would have 6W of quiescent power, but it is not clear to me whether we can just use Joule’s law (P=IE) to determine the power here (since it’s not just a plain DC system).  If we did cheat and use Joule’s law, we’d get at most 3.6W for .  Plugging everything else in to solve for , we get roughly 11.8W for the power dissipation (not far off from the 11W given in the Squelette instructions).  This also looks pretty close to the value shown on the datasheet graph for power dissipation for a ±18V supply, which is further confirmation that we’re pretty close.(1)

The datasheet lists some example calculations for determining the maximum allowable heat sink to ambient thermal resistance.  The relevant formula is

Where:

• is the total thermal resistance from the junction to ambient, the sum of
• (junction to case) (listed in the datasheet as 2 ^oC/W)
• (case to heat-sink, e.g., the thermal resistance of your insulating pad or thermal compound layer) (in my case, the insulating pads are claimed 0.33 ^oC/W
• (heat sink to ambient) (this is what we’re trying to determine)
• is the maximum junction temperature from the datasheet (listed as 150 ^oC)
• is the maximum ambient temperature at which we are planning to operate the device (for example, 70 ^oC)
• is the maximum power dissipation necessary (computed above as ~12W)

For our example, if we want to maintain a die temperature below the maximum rated 150 ^oC for ambient temperatures up to 70 ^oC, with our power dissipation at 12W, we would need a total thermal resistance from junction to ambient of less than (150 – 70)/12 = 6.67 ^oC/W.

Since the other components of are known,

or

.

So, given a chunk of aluminum of arbitrary size, how can we determine whether its thermal resistance is less than 4.33 ^oC/W?  There are two factors at play here:

1. How quickly does the heat sink material transfer heat from the area where the heat source is connected (assuming it is smaller than the size of the heat sink itself) throughout the body of the heat sink?  We’ll call this value “heat sink thermal resistance due to conductance”, or
2. How quickly will the heat be dissipated from the heatsink due to convection and thermal emission?  We’ll call this value “heat sink thermal resistance due to convection” or

They both contribute to the total thermal resistance of the heat sink.  Imagine a heat sink made of a perfectly conductive material that instantly changed temperature across its entire mass — its thermal resistance would still be bound by the amount of heat that could be dissipated by convection.  Likewise, imagine a forced cooling system so effective that any heat on the surface of the heat sink would be instantly whisked away to the frigid depths of space — no matter how quickly the heat could be drawn off the surface of the heat sink material, it must still travel from the source through the material to the surface, and so presents some thermal resistance.  Such a cooling system would be of little use if the heat sink had a thermal conductance so poor (and therefore, that the heat took so long to travel from the source to the surface) that the IC had been fried by the time the heat could be dissipated.

Since I don’t know how these two factors affect one another, so will we take the naive, conservative approach and model thermal resistance of the heat sink as a whole as the sum of the two factors:

Thermal Resistance of the Heat Sink

The rate at which the body of the heat sink can conduct heat away from a warmer place (where the IC is attached) to a cooler place (presumably, the edge of the heat sink) is determined by the heat conductivity of the heat sink material and its shape.  For a simplified model, consider Fourier’s Law for heat conduction (from Wikipedia, Thermal Resistance in Electronics):

From Fourier’s Law for heat conduction, the following equation can be derived, and is valid as long as all of the parameters (x, A, and k) are constant throughout the sample.

where:

• R_θ is the thermal resistance (across the length of the material) (K/W)
• x is the length of the material (measured on a path parallel to the heat flow) (m)
• k is the thermal conductivity of the material ( W/(K·m) )
• A is the total cross sectional area of the material (measured perpendicular to the heat flow) (m²)

This gives us the general idea (that is, thermal resistance depends on how much material through which the heat must flow, and how fast the material carries heat).  Heat will be transferred faster through a shorter distance and through a wider cross section.  This equation might work for us if our heat sink were the shape of the IC package (TO-220, in this case) and extruded out for some length.  Since we want to incorporate the heat sink into the enclosure as a broad plate, rather than extruded solid mass, however, it’s not so simple.  The heat will be spreading along the (vary narrow) cross-section of the aluminum from some point (presumably, near the middle) to the edges.

I could not find a good example set of equations with which to model this.  However, I did come across this online calculator for “Slab Thermal Resistance With Constriction”, which models thermal resistance from a smaller source (like our IC) to a larger slab of material (like our heat sink).  It does not take into account convection, but that’s okay, we’re handling that elsewhere anyway.

If we plug in the following values:

• heat source width (TO-220 package dimensions, roughly 10mm)
• heat source length (TO-220 package width, roughly 15mm)
• slab width (heat sink width, 6″ or 0.1524m)
• slab length (heat sink length, 12″ or 0.3048m)
• slab height (heat sink thickness, 1/8″ or 3.175mm)
• thermal conductivity (of aluminum, 200 W/m^oC)
• film coefficient (of air, 5 W/m^2oC), though this value doesn’t seem to matter much

We get a result of   (see note (2))

Thermal Resistance Due to Convection

Ultimately, all heat dissipated by the heat sink must be dissipated by free convection (since I don’t want to use a fan or other active cooling system).  Since we know the amount of power we want to dissipate (12 W) and the size of the heat sink we are trying to use, we can use Newton’s Law of Cooling to determine the temperature at which the heat sink will dissipate that power.  According to this handy explanation of convective heat transfer,

The equation for convection can be expressed as:

where

is the heat transferred per unit time
is the heat transfer area of the surface (m²)
is the convective heat transfer coefficient of the process (W/m²K or W/m^2oC)
is the temperature difference between the surface and the bulk fluid (K or ^oC)

In our case, we know:

• (the power to dissipate, 12 W)
• (the area of our heat sink, for a 12″x6″ plate, roughly 0.046 m²)
• (for air, 5 W/m^{2 o}C.  Various places I looked had widely differing values for the convective heat transfer coefficient of air, but 5 W/m^{2 o}C seemed generally to be the worst value, so we’ll be conservative and start with that)

We want to solve for dT (the temperature rise above ambient), which works out to

or, substituting our values, ~48.2 ^oC.  This means that, with a 12″x6″ heat sink attached to a device dissipating 12W of power, we can expect the heat sink to rise ~48.2 ^oC above the ambient temperature.  To compare, by the same formula, if we had a 3″x3″ heat sink, we would expect a rise of ~386 ^oC above ambient at the same power dissipation.

Now that we know the temperature our heat sink will be when dissipating a given amount of power, it is easy to compute the effective thermal resistance.  In this case, it will be:

Substituting Eq. 4 into Eq. 5 yields:

which simplifies to:

So, for our 12″x6″ chunk of 1/16″ aluminum plate, substituting 5 W/m^{2 o}C for k and 0.046 m² for A, we get an of 4.3 ^oC/W.

Conclusion

Equation 8 seems to be a severe simplification, but perhaps we can determine experimentally whether it is an oversimplification.  The question remains whether it is useful as a rule-of-thumb in the absence of better information.

Working with our conservative, naive approach, we can go back to equation (3) to get what should be an upper bound for the thermal resistance of the heat sink to ambient, using our example values:

Since we have a max limit of 4.33 ^oC/W (from (2b)), it looks like we won’t be able to run quite at 70^oC ambient temperature.  If our total thermal resistance with this heatsink is 2 + 0.33 + 4.8 = 7.1 ^oC/W, we can see that at an ambient temperature of 20 ^oC, dissipating 12 W of power, our junction temperature should be:

This is within the max operating temperature, but is quite hot.  If we recompute our maximum allowable ambient temperature, we get 64^oC.  At the very least, this means we must be careful to make sure the ambient temperature stays within reason (for example, we shouldn’t put the amplifier, enclosure and all, into some other sealed container).

An oft-repeated quotation, commonly attributed to Albert Einstein, goes something like

Everything should be made as simple as possible, but not simpler.

Now that we have made the heat sink design for this amp simple, we need to determine whether we have made it too simple.  There was certainly a lot of assumptions and fudging going on in these calculations, and there’s nothing better than to confirm them (or prove them wrong) than by some experimentation.

Let’s revisit our assumptions:

• Our computation of using the power rule and the eye-balling of the graphs in the datasheet is pretty close to the right value
• The value of from the insulating pad datasheet is accurate
• My model of isolating the convection and conduction factors and summing them for an approximation of the total thermal resistance is not too far off
• The value of the conduction thermal resistance factor, which came from an online calculator (the correctness of which I cannot examine and verify), is pretty close to the right value
• It is sufficient to use in that calculator the total package dimensions instead of the dimensions of the die itself (see note 2)
• The value of 5 W/m^2K for the convective heat transfer coefficient of air is a good lower bound, and is not made even worse by size, shape, and orientation factors
• I didn’t screw up the algebra and arithmetic anywhere

To put these assumptions to the test, I will actually construct a heat sink, re-do this analysis (based on the final size and shape of it), and then run some tests to see if the measured case and heat sink temperatures line up with the expectations.  That at least should give me some sense of how close this approach will get me, or if it’s so far off as to burn up my amplifier chip.

Notes:

1. The datasheet also provides a graph for supply current vs. supply voltage.  If this is to mean quiescent current, then it looks like the chip draws ~60mA (instead of ~100mA) at ±18V, which (again, cheating with Joule’s law) would give us 2.16W instead of 3.6W for (quiescent power dissipation) in our total equation), which would bring to just under 11W instead of just under 12W.  Working on the upper side of these values will provide us with a bit more headroom.  We can always go back and recompute with more precision if the ballpark answers are too difficult to work with.
2. In email discussions, a technical associate of Novel Concepts, Inc. (the organization which produced the calculator) advised me to use not the dimensions of the TO-220 package as the source but rather the dimensions of the die inside the chip (which he gave as ~4.27 mm).  I am not so sure about this approach, mainly because we already have from the datasheets the , but also because most datasheets I have seen do not provide the dimensions of the die itself.  Using the reduced dimensions results in a value of ~0.8 ^oC / W, rather than ~0.5 ^oC / W.  That seems relatively insignificant to me, but I’m certainly open to other feedback on the matter.

Schamplifier – Introduction

I am working on my own version of the Squelette mini chip amp, as presented in Make Magazine #23.  My ambitions for this project are relatively unbounded, but knowing the trouble I have with follow-through, I am trying to start small and get a working stereo amp with a single input and potentiometer volume control in an enclosure, and I can leave the integrated WiFi radio, IR remote control interface, smart phone remote control interface, integrated digital tone and volume controls, blinkenlights, and mind-control interface projects for later on.

What could I call it, but the “Schamplifier”?

Anyway, the circuit is pretty-much the same as the one presented in Make, but I decided to design my own PCB for it.  I took inspiration from a number of other LM1875 PCB layouts described on various DIY audio forums.  Each channel has its own (identical) board, and they are all interconnected with wires and terminals (so I can experiment with other modules later on, e.g., tone controls).

Here’s the schematic, layout, and finished board for one of the amplifier channels:

This is pretty much the schematic from the Make article.

Note the star ground point, and the super wide power and signal traces.

Another fabulous result of my toner-transfer silk screen process…

The etched boards, with my attempt at tinning the traces.  I consider this to be “mixed results”, we’ll see how it sounds.  I’m considering having some PCBs professionally fabbed, more on that later.

Here’s the schematic, layout, and finished board for the power supply:

I’m thinking of re-swizzling the board a little bit, and ordering a few professionally fabbed (all the more if there are noise issue because of my crummy home-made PCB).  If you are interested in getting in on the group order, let me know, they would run about $5 each, shipped (remember, you probably want two of them…).

Current source files for the boards are available on my GitHub repository.

Before I can really test the circuit out, I need to get an adequate heat sink, and since my heatsink is ultimately going to be the enclosure, I’m trying to finish the design for that before going on.  This is not too difficult, but finding the right information proved a bit tricky, so I’ll be covering heatsink design in its own post real soon now.

Radio Control Panel – Tweeting Status

I made a few updates to the WiFi Radio Control Panel.  I fixed a few bugs in the display, and in the start and stop logic, but the biggest addition was the ability to tweet the currently playing song and station.  Whenever the radio detects a new song is playing, it tweets a message to @SchampsNetRadio.  You can probably tell I’ve been listening to a lot of Groove Salad lately…

Anyway, there  are no new photos, but here are some of the old ones, to remind you how cool it looks:

This is all part of an entry in the AdaFruit Make It Tweet Challenge on Instructables, though I readily admit it has limited usefulness.  A nifty future update would be to allow some kind of Twitter-based control interface.  You’d need some kind of crypto or authentication system to prevent random strangers from messing up your tunes, though.

The updated code is in my GitHub Repository.

Bus Pirate Breakout 3.2

There was some interest in making another run of these, so after I fixed some of the spacing issues with the 6-pin ISP/SPI header (it was too close to the 10-pin BP header to have cables hooked up to both at the same time), I made another run.

I updated the version to be 3.2, meaning it is compatible with Bus Pirate v3, version 2 of the breakout board.

Here’s the Bus Pirate Breakout topic on the Dangerous Prototypes Forum that I’m using to track updates to the project.  There is a possibility that Ian will add this to the Dangerous Prototypes free PCB drawer.  If there is enough interest, I can do another run, hopefully at the low, low price of $3.

The source, as always, is available in my github repository.

Bus Pirate Breakout 0.1

My new Bus Pirate is great, but it’s kind of a pain to use the 10-pin cable and test clips to hook onto small components, and trying to find room for the Vpu pin alongside Vcc drove me to innovate.  So I made this breakout board, which connects to the Bus Pirate with a 5×2 to 5×2 cable.

Features:

• breadboard breakout for all 10 pins
• a power connector for providing VCC from an external source
• a VCC select jumper so you can pick 5V or 3V3 from the Bus Pirate (or leave it open for external power)
• a VPU-VCC select jumper, so you can tie Vpu to whatever you have selected for VCC
• a 4-pin “standard” I2C header
• a 3-pin “standard” 1-wire header
• a 6-pin AVR ISP header (can also be used as an SPI breakout)

I got the boards from the DorkbotPDX PCB order, the same place I got the Bus Pirate v3b FTDI boards.  Once again, they are this totally awesome shade of purple.

You might be interested in the original forum post discussing it.

Download:

The Eagle design files are available from my Github repository.  I’ll probably be breaking everything out into separate repositories soon.

Photos:

The front.  It’s kind of crowded, because I wanted to keep it under 1 sq. in.  I did, but the 10-pin cable connector gets a little tight with the 6-pin SPI connector.  The “Vcc Select” header allows you to tie either the 3V3 or 5V pin from the Bus Pirate to “Vcc”  If you don’t choose, you can provide something else for Vcc at the “Power” header.  The “Vpu-Vcc” header allows you to connect whatever you have on Vcc to the Vpu pullup pin.  This is super handy for I2C stuff (my primary use for the BP at the moment).

Another angle of the front.  Those little tabs on the edges break off quite easily.  You can see the staggered header pins, which I got from the “Sneaky Footprints” Sparkfun Tutorial.  They help the headers stay in place and lined up better during assembly, which is great when you have things in the way that keeps you from just sticking it in a breadboard.

The back side.  I would have made this myself, but there just wasn’t room to make it one-sided without some jumpers, and I wanted a nice clean design.  The PCB order is cheap enough that it’s worth it (although the wait can get old).

Here it is, assembled.  You can tell it took me enough time to put together that the light got much worse, and I really had to drive up the exposure on these images of the assembled version.

Another shot of the front, kind of blurry.  I should try harder not to focus on the tips of the header pins…

This one’s a little better.  Longer header pins for the breadboard make it easier to get in.

The back, assembled.