Backyard Boardwalk

After a few weekends of work, I’ve finally finished building a short wooden path off the side of our patio! The construction was pretty easy, and could have been done in about a day and a half. However, our yard is made up of about 90% rock with a thin coating of dirt on top, so the digging took forever.

I based the design on these plans, but had to adapt a little for my situation.

Walkway next to patio and wall

That looks pretty nice… sticking off the side of the patio there!

Close-up view

Close-up view

Pile of rocks

This is but a small sample of what I excavated to dig the footings!

Posted in Outdoor, Woodworking | Comments Off on Backyard Boardwalk

Adafruit LED Matrix Library Overview

Adafruit provides an Arduino library to drive the LED Display Matrix they sell. The library code does an impressive job of using the limited clock speed and RAM of the Arduino platform to get great performance out of the LED matrix. While the code contains lots of comments that describe technical specifics of the code, it doesn’t give much of a conceptual overview of how the display is driven. It took me several reads to figure out what was going on. I’m going to try to explain generally how the code works to help others who want to try to modify it or drive the display themselves. If you haven’t read my previous post about how the display works, I’d recommend it.

The Adafruit code uses a technique called Binary Code Modulation to control the colors of the display. Batsocks provides a good description of this, which I recommend reading get a full understanding of it. Here is a quick summary. Driving an LED with Pulse Width Modulation (PWM) would turn the LED on for an amount of time proportional to the desired brightness, then turn it off for the rest of the period. BCM divides the period into binary-length segments (1x, 2x, 4x, etc), and turns the LED on or off for each of these segments according to the bits of the LED’s desired brightness. Instead of using lots of equally-sized interrupts like PWM, BCM achieves the same color resolution with fewer varying-length interrupts, using less CPU time overall. The total on/off time for the LEDs is the same.

To use BCM, the pixel data must be divided up into bitplanes. A bitplane is an array in which each element is a single bit from a color value in the displayed image. The least significant bits form one plane, the next most significant bits form the next plane, and so on up to the most significant bitplane. Conceptually, a bitplane is an array of single bits, so each pixel would require three separate bitplanes, one for each color element. However to drive the display, all three colors are written out for two different pixels at the same time. The Adafruit code stores six bits, one from each bitplane, together in a byte. This way the bytes are immediately ready to be written to the GPIO port during the interrupt. The Adafruit code referes to the arrays of ready-to-write bytes as “planes,” presumably taken from “bitplanes.” Since the images displayed by the Adafruit code use 4-bit values for each color, there are four total “planes.”

In each interrupt (RGBmatrixPanel::updateDisplay) a byte from the appropriate plane is written out to the GPIO port and the delay until the next interrupt is set. Because of the way BCM works, the display interval for the second plane is twice as long as the first, the third is twice as long as the second, and so on. The actual interrupt behavior is a little trickier than it seems at first. As mentioned in the earlier post about the display matirx, data can be shifted into the display shift register while other data is being displayed. The shifted-in data does not drive the pixels until it is latched in. To maximize the amount of time that the display is on, the display is only turned off long enough to latch in the new data and calculate the correct row to power, then is turned back on. New data is then shifted in. However, this means that while the row to power and the delay until the next interrupt are calculated for the current interrupt period, the data shifted in is for the next interrupt period. This data is in a different bitplane and may be for a different row than the one currently driven.

Each data write to the matrix uses 6 bits: red, green, and blue for each of two pixels. The data bytes are stored so that these bits are ready to write. However, storing six bits per 8-bit byte is an inefficient use of the Arduino’s limited RAM. The six bits per byte required for each of four planes hold a total of 24 bits. 24 bits can be more efficiently held in 3 fully-used bytes, and the Adafruit code does exactly this. Three planes are stored with six ready-to-write bits, leaving 2 unused bits per byte. The two extra bits from three bytes are enough to represent the six bits needed for the fourth plane. Three interrupts write their bytes directly to the output port, while the fourth needs to assemble its data from the extra bits of the other three planes. It takes more processor time to assemble these bytes, so this is done during the interrupt that has the longest display time. This makes sure that the extra time spent in this interrupt does not delay the start of the next interrupt.

The display data is stored in ready-to-write bytes, but users of a display want to be able to control the display by saying “This pixel is this color,” so at some point this RGB pixel data needs to be broken down into “planes.” When the user specifies an RGB value for a pixel, the non-interrupt code immediately does all the bit-shifting work to update the bitplanes with the new pixel. (RGBmatrixPanel::drawPixel) The display data is never stored as an RGB pixel matrix, and instead is only stored as ready-to-write “planes”.

The rest of the code is all support code, including initialization, debugging, translation between the color resolution of the Adafruit graphics library (16-bit) and the LED matrix color resolution (12-bit), etc. The optimization of the interrupt code is interesting, and I intend to take a closer look at this in a future post.

Posted in Uncategorized | Comments Off on Adafruit LED Matrix Library Overview

Simulavr from Source

I discovered today that the Ubuntu repository version (through Mint) of Simulavr is quite out of date. Here are the devices supported by the package:


And here are the devices supported in the current build from the Git repo:


That’s a big difference if you’re targeting ATMega devices! It’s easy to build from source. Clone the repo:

git clone git://

Install needed dependencies (there may be more, but these are the ones I was missing):

apt-get install zlib1g-dev g++ binutils-dev texinfo

Switch to the checkout directory and build:

cd simulavr

I’m glad to see development on this is still going on. I hope to see more devices added in the future.

Posted in AVR, Linux, Programming | Comments Off on Simulavr from Source

LED Matrix Internals

I have long wanted to make some kind of LED-based display for my wall, but when I looked into it a while back, RGB LEDs were too expensive for me. I was excited to find the RGB matrix offered by Adafruit for just about $40! With 512 RGB pixels, this is a good value! I was also pleased to discover that this thing is BRIGHT. It is almost uncomfortable to look at the fully lit display in indoor lighting. Perfect!

Sadly, there is no datasheet available for the matrix. Several people have done a nice job explaining the basics of the display. (Adafruit, HobbyPCB, RaysLogic, RHB) However, it still took me several reads of these posts and some diving into the example code before I really understood how it works. I will try to fill in the blanks here to provide a reasonable description for anyone wanting to experiment with this display on their own. I also drew a conceptual schematic of part of the matrix to help explain what’s going on. It is not an accurate depiction of the actual matrix circuitry, but it should help to explain how it works.


Electronic Layout

The electornics of the matrix are configured as two 8-row by 32-column matrices of pixels, one on top of the other. I will describe how a single 8×32 matrix works, then expand a bit at the end to incorporate the full 16×32 display.

Each LED in the matrix has separate red, green, and blue color elements. Each element is controlled separately, but they are all in the same “pixel” so that they blend well to form a color. The matrix does not handle PWM control of the LEDs automatically. Each RGB element can only be turned on or off. If the software does not perform PWM itself, the display can only show 8 colors (all combinations of red/green/blue each on or off). The matrix is designed for software PWM, and in practice a huge range of colors are available.

Each color element has two devices determining whether it is on or off: a switch allowing current to flow into the anode (positive) side, and a current sink allowing a controlled current to flow out of the cathode (negative) side.

The switches are controlled by the row selector lines A, B, and C. These are run into a decoder. The decoder uses the binary number made by the three row bits to turn on one (and only one) of the eight output lines. These outputs are then used to control switches that enable or disable the power to an entire row of pixels. For any state of the inputs A, B, and C, there is always one and only one row of pixels enabled at any time. All color elements in the same row are enabled by the same switch.


The real workhorse of the LED matrix is the CYT62726 constant current LED driver. This is the device on the “bottom” of the LED that allows current to flow out of it. There are two main parts to this device, a shift register and a constant current sink. Internally the device stores 16 bits of data in a register. Each time the clock pin pulses, the data in the register is shifted down one spot. The bit in spot 0 moves to spot 1, spot 1 to spot 2, and so on. The data in spot 15 shows up on the “SDO” (serial data out) line. (More on this in a minute). This is pretty simple. To fill the register up with ones, drive the SDI (serial data in) line high and pulse the clock 16 times. To fill with zeros, drive the SDI low and pulse 16 times. To fill with a pattern of data, set the SDI line to the desired bit before each clock.
The second part of the CYT62726 is a constant current sink. This just means that the device only allows a certain amount of current to flow into it. (It’s kind of confusing that they call the pins “outputs” when the current goes into them, but it’s an output in the sense that you control the “input” lines (SDI/CLK/LAT/EN) and the behavior of the “outputs” changes). Each output can either draw the set amount of current or no current at all, depending on whether it is on or off. Each time the “Latch” signal is pulsed, the data that is currently in the shift register is used to update the state of each output. If bit 0 is 1, then output 0 will be on (drawing current). If it is 0, then output 0 will be off (drawing no current).

If more than 16 outputs are needed, the SDO line can be connected to the SDI line of another CYT62726 chip. Since this line reflects the previous state of shift register bit 15, bit 15 on the first chip is shifted into bit 0 of the second chip. This makes two 16-bit chips behave as though they are one 32-bit register.

Since there are 32 pixels in each row, two CYT62726 chips are hooked together to provide 32 “outputs” for the current to flow into. And since there are 3 color elements in each pixel, 3 pairs of chips are used to control a row, one pair per color. Instead of using six chips for every row in the display (which would reqire 96 chips for a 16-row display!), the same six chips are shared by all eight rows. The cathode (output) of all red color elements in each column are all connected to the same output line on the red CYT chip, and the same for the blue and green elements.

Taking Control

Okay, so we have the rows of LEDs powered by selecting the correct row on the row lines (A,B,C), and we have the constant current sinks allowing current to flow out of each pixel in the row. So how do we tell this thing what to do?

To program a row, shift in the 32 pixels of RGB values to turn the color elements on or off. It is important to remember that the shift mechanism works independently of the latched current sinks, so you can shift in the next display values while a row of LEDs is still lit. Once the data is shifted in, disable the enable line to turn off all the LEDs. With the LEDs briefly off, pulse the latch line to update the state of the current sinks with the register values. Select the row value on the ABC lines to send power to the correct row, then enable the current sinks by re-enabling the enable line. The new row of LEDs should light!

RaysLogic notes that there is some circuitry that is designed to shut down the whole display if the row lines are not changing at some certain rate. This is to protect the LEDs from burning out. LEDs have a maximum current with which they can be continuously driven without overheating and breaking. It is okay to drive them with more current, but only for very short periods of time so that they can cool off in between. Since the display is designed to cycle through the 8 rows very quickly, the constant current sunk by the CYT chips is high. After being driven for 1/8th of a frame period, each row has 7/8 of a frame period to cool off while the other rows are driven. However, if you don’t cycle the rows and instead continuously drive a single row, the LEDs will quickly burn out. This is a nice protection feature, but it does make it hard to experiment with the matrix, as you can’t send a command to just one row or pixel and leave it on for a test.

Double Duty

Earlier I promised to explain how the 8×32 arrangement is expanded into 16×32. Basically the full matrix is just two 8×32 matrices, one on top of the other. All of the signals to them are the same, except for the RGB lines.

When a row is selected, it provides power to two rows, one row in the top eight and the corresponding row in the bottom eight. When you turn on row 0, row 8 is also powered. Rows 1 and 9, 2 and 10 are pairs, and so on. If these rows also shared the same current sink chips, both rows would display the same pixels. To control the pixels separately, there is a complete second set of current sinks for the lower matrix. Instead of just 6 constant current chips, there are 12. There are two sets of RGB control pins for the matrix: R1,G1,B1 and R2,G2,B2. With each clock pulse, the RGB values for both the upper row and the lower row are shifted into their respective registers. When the row is selected and the enable line is enabled, both rows light up with their correct data.

In a later post, I plan to explain how the Adafruit code works. It is the basis for the code I wrote to drive the matrix and uses a lot of good concepts for getting the maximum performance out of this display with a simple microcontroller.

Posted in Uncategorized | Comments Off on LED Matrix Internals

Photo Timestamp Adjustment

My wife and I recently returned from a vacation to Glacier National Park in Montana with lots of pictures we had both taken. I wanted to combine our photos so that they would all appear in chronological order for easy review.

Unfortunately, my wife’s camera resets its clock when the batteries are removed. A few days before the trip, she charged the batteries and replaced them, setting the clock to midnight on 01/01/06. My camera keeps its time even when the battery is removed, so the photos have the correct times. To get a chronological listing of all our photos, I needed to set the timestamps of her photos to their correct times. Her camera keeps accurate time from the reset date, so relative to each other, the pictures timestamps are correct. To set the timestamps to the correct times, I needed to apply an offset (the difference between 01/01/06 and the day she replaced the batteries).

I wrote a bash script that reassigns file timestamps to a configurable interval in the future. I found two photos of the same thing, one of mine and one of hers, so that I knew they were taken about the same time. I copied the “Modified” time from the file manager properties dialog of each picture. I pasted the time from her picture into the INPUT_BASE_TIME and the time from my picture into the OUTPUT_BASE_TIME (see script). The times are processed by the “date” command, which can parse many different date formats, so you should be able to specify the date nearly any way you like. Then, I ran this script to correct the timestamps:

#! /bin/bash

# Set this to the time the camera assigned to a picture
INPUT_BASE_TIME="Tue 03 Jan 2006 11:38:24 AM CST"

# Set this to the time the picture was actually taken
OUTPUT_BASE_TIME="Wed 19 Jun 2013 12:22:00 PM CDT"

# Convert the specified times to seconds-since-epoch
in_base=$(date -d "${INPUT_BASE_TIME}" +%s)
out_base=$(date -d "${OUTPUT_BASE_TIME}" +%s)

# Calculate the time offset in seconds
offset=$((out_base - in_base))

# For each file...
for file in $*; do
    # Read the time in seconds of the input file
    time=$(ls -l --time-style=+%s ${file} | awk '{print $6}')

    # Adjust by the offset
    time=$((time + offset))

    # Convert to a date string (so that touch can interpret it)
    time=$(date --date="1970-01-01 ${time} sec GMT")

    # Update the file timestamp
    touch -d "${time}" ${file}

The script updates the timestamps of all files specified on the command line, so I just specify all the files in her directory:

./ wifephotodir/*.jpg

Then I copied all of her photos into the same directory as mine. Her camera uses a different image naming format, so there is no danger of her files overwriting mine with the same name. If two cameras use the same naming, you will want to either avoid this step, or rename one set to be unique. If you’re using “cp” to copy, you’ll want to pass the option to preserve the newly generated timestaps instead of creating all the copies with the current time. I think nautilus and other graphical file managers preserve timestamps by default.

cp --preserve=timestamps wifephotodir/*.jpg photodir/

Lastly, I wanted to rename the photos so that they are in the correct order when listed alphabetically. To do this, I listed them in order by modification date, then copied them to a different directory with an increasing number for the new file name:

for file in $(ls -rt *.JPG); do
    name=$(printf "%03d" $idx).jpg
    cp --preserve=timestamp ${file} finalphotodir/${name}
    idx=$((idx + 1))

Now our photos are all named in order for easy viewing!

Posted in Linux, Scripting | Comments Off on Photo Timestamp Adjustment

Virtual Machine Directory Export

The company I work at, like many, uses Windows for our workstation PCs. I much prefer developing in Linux, and so do most of my day-to-day work in a virtual machine. (I love VirtualBox’s Seamless Window feature for this). I do my work in a VirtualBox shared folder, which means that it is actually a folder on the host OS, but can be mounted in the guest OS as well. This makes the files I work on in Linux easily accessible from Windows too.

Sometimes I’m plugging away in a Linux shell and want to do something in the same directory on the Windows host. I quickly got tired of opening explorer (the Windows file browser) and navigating down to the directory I was working in under Linux, so I came up with a reasonable 2-step process to quickly open an explorer window in the current Linux directory. (We use Windows 7 at work, but I think a similar process should work for other Windows versions).

I wrote a script in Linux that creates a Windows batch file. When passed an argument, the script causes the batch file to open Windows explorer in the directory specified by the argument. Otherwise it uses the present working directory. The batch file is created in the root of the shared folder. Each time the script is run it overwrites the old batch file so that the same file now points to a new location.

Here are the steps to make this work in your environment:

  1. Download the script and put it in a directory that is in your Linux $PATH so it is easy to use from anywhere.
  2. Edit the script to match your VirtualBox setup:
    1. change the “HOSTSHARE” variable at the top to be the shared directory path on your Windows host machine.
    2. change the “SHAREMOUNT” variable at the top to be the mountpoint for the shared directory on your Linux guest machine
  3. Make sure that the script has executable permissions:
    • chmod u+x
  4. Run the script once to create the batch file (linlink.bat).
  5. In Windows, open explorer and navigate to the shared folder.
  6. Create a shortcut to the batch file (right-click, “Create Shortcut”).
  7. Right-click on the shortcut and select “Properties”.
  8. The “Target” field of the “Shortcut” tab shows the path to the shortcut target. In front of this path insert the word “explorer” (no quotes) and press “OK”. (Windows 7 refuses to let you pin a file shortcut to the taskbar, so this alters it to be an application shortcut. The application shortcut runs explorer, which then runs the batch file.)
  9. Now drag the shortcut to the task bar to pin it so it is always quickly available.

Now the two-step process to open the current directory in Windows is:

  1. Type “” in the Linux shell
  2. Click the shortcut on the Windows toolbar to open the directory

Now you can quickly drag the file to attach it to an Outlook e-mail or whatever else you need to do with it in Windows.


  • If you want to change the icon for the toolbar link, you need to do it before you pin it to the toolbar. After you create the shortcut, bring up the properties and click the “Change Icon…” button.
  • You can delete the original shortcut after you have dragged it to the taskbar (but not the target batch file, of course).
  • I learned about the pinnable shortcut trick from a lifehacker tip.
  • At first I thought it would be simpler to avoid the batch script and just create the link directly. However, Windows “link” files are some complicated binary format, so I quickly gave up looking into that. After completing the process, I’m not sure it would have worked anyway, as from Linux I couldn’t directly modify the shortcut that lives on the Windows toolbar.
Posted in Linux, Programming, Scripting | Comments Off on Virtual Machine Directory Export

In-Car USB Power Final Assembly

This post is part 3 of the In-car USB Power series. You may want to read part 1 and part 2 first.

When all the parts for the power converter arrived, I breadboarded the circuit, and it worked as expected. It could charge my cellphone in about the same amount of time as the wall charger. After a few sketches, I came up with a reasonable way to connect all of the components on a small piece of perf board. The leads for the buck converter IC are pretty close together, so I decided to connect some on the top and some on the bottom to give myself more room and minimize the chance of shorting two connections together. A little work with the Dremel made a reasonable slot for the leads to pass to the underside.

Drilled perf board

A bolt holds both the IC and the heatsink in place on the board, while also holding the IC firm against the heatsink. Before placing the IC, I put some leftover thermal paste I had lying around after my last computer build on both the IC pad and the heatsink surface to create a good thermal connection.

LM2576 mounted on perf board

I made the rest of the connections by just soldering the leads together. The result isn’t exactly a work of art, but it’s compact and works great! I held everything in place with hot glue for mechanical stability (these things are going to be vibrating around a lot in the car) and for electrical insulation so the connections don’t short together or to other metal behind the panel if it shifts around. It’s important to not cover the diode or the IC/heatsink, as they need to be able to dissipate heat.

Top view of buck regulator circuit
Bottom view of buck regulator circuit

The easiest place to mount the USB and audio ports in the car is in the lower dashboard near the cigarette lighter. This gives me easy access to a power line, and is a nice place for the cables to connect without getting in the way of the rest of the dash. There also happens to be a sizeable cavity behind this panel, so there’s room for everything to fit.

After measuring everything carefully, I put down some masking tape and marked off the holes I wanted to cut. I drilled out the corners of the square hole, then used a spiral bit to mill out the middle. After milling out most of the material, I cleaned up any jagged edges and squared out the round corners with a utility knife.

Cutouts drawn on car panel on masking tape
Holes for USB and audio jack drilled in car panel

I didn’t know of a better way to hold the jacks in the panel than to just epoxy them in place. I roughed up both surfaces with sandpaper, then glued the jacks in. This is pretty irreversible, and if I were doing it again, I’d probably do something a little different. It would be better to glue in standoffs to either side, then mount the jacks to another piece of perf board, which could then be screwed into the standoffs. This would probably be a little less mechanically rugged, but would be removable if I needed to change anything about the jack connections.

To connect to the power line in the car, I used a molex connector from an old PC power supply. This allows me to unplug and remove the circuit, instead of having it forever attached to the car. After disconnecting the battery, I clipped both the power and ground wires leading to the cigarette lighter. After stripping both ends of the clipped power wire and the wire from the molex connector that I wanted to splice in, I twisted all three together and then connected them with a screw-on wire cap. I did the same with the ground wire. The mating molex plug is soldered to the input side of the converter circuit, so it can be easily connected and removed from the car power.

Molex connector spliced into power line

With everything installed, I reconnected the battery and gave it one last test before putting the panel back together. The charging works great! I used zip ties to collect the extra wire length and secure the perf board in place.

Converter installed behind dash

I am really pleased with the whole build. The jacks fit into the look of the panel really well; almost like they might have been designed there.

Final installation in the car

After putting all of this together, I realized that I hadn’t accounted for Apple devices, which require a certain resistor configuration to charge. I just put up with this for a while, but eventually pulled the panel back out to add the resistors to make my iPod work too. (This is where it would have been really nice to be able to remove the USB jack from the panel. :))

It also turns out that if you try to use the audio input jack to play audio from a device that is charging from the USB port, there is a LOT of noise on the line. It increases in frequency with engine RPM, so I believe that it’s noise on the power line from the ignition system. It’s possible that if you used another power circuit in the car, it might be quieter; I’m not sure. I also think that adding an inline choke on the power output or maybe a few smaller decoupling capacitors on the output of the voltage regulator might help filter out some of the noise. With all of the hot glue on there, there’s really no way I can get back in to test this out. It isn’t a big deal; I just don’t charge a device while I’m listening to it. If anyone knows what might fix this, please post in the comments to let me know!

Posted in Automotive, Electronics | Comments Off on In-Car USB Power Final Assembly

In-Car USB Power Supply Design

This post is part 2 of the In-Car USB Power series. You may want to read part 1 first.

The USB 2.0 standard power output is 500mA, but modern smartphones, tablets, music players and other devices take a long time to charge at this rate. The wall adaptors for these products provide something closer to 1 amp at 5 volts. With two USB jacks, I wanted to be able to provide 2 amps total power so that two devices could charge quickly at the same time. To make sure that the system could handle this comfortably, I decided to set the design requirement at 3 amps.

A car’s electrical system is nominally about 12 volts. The alternator output voltage is more like 13-15 volts while the engine is running to charge the battery. USB power provides 5 volts, so we need a way to convert from a variable input voltage of 10-15 volts to a fixed output of 5 volts.

The simplest way to convert to a lower voltage would be to use a linear regulator such as the 7805. However, linear regulators drop the voltage by converting extra power to heat, which just wastes it. To provide our design requirement of 3 amps at 5 volts, we would be drawing 3 amps at 12 volts and burning off the extra power. 3 amps at 5 volts is 15 watts, and 3 amps at 12 volts is 36 watts. This means that we are burning off 21 watts of power for a terrible efficiency of 40%. Not only is this horribly wasteful, but it’s going to be almost impossible to dissipate this much power with a passive heatsink. We need to do something smarter.

A switching regulator is a much better choice for this task. A buck converter with a regulated output of 5 volts will handle the job quite nicely. Using Digikey’s parametric search, I found the Micrel LM2576, which takes a wide range of input voltages and generates a fixed output voltage of 5 volts at 3 amps with a minimal number of external components. The datasheet claims 82% efficiency for the 5v fixed output version with an input voltage of 12 volts. This isn’t amazing for a switching regulator, some of which can do much better than 90%. However, for a DIY project like this simplicity and cost are more important than excellent performance, and 80% is sufficient for this purpose. To generate 15 watts at 80% efficiency, we will be drawing 18.75 watts. The 2576 will be dissipating the extra 3.75 watts, a much more manageable number.

We now have to figure out how to get rid of those extra 3.75 watts. The maximum operating temperature for the chip is 150°C, and the thermal resistance to ambient air is 65°C per watt. This means that when the TO-220 package of the chip is dissipating heat to the surrounding air without being connected to a heatsink, PCB copper plane, or any other heat diffuser, the chip temperature will rise 65°C above the ambient air temperature for every watt dissipated. It is not unreasonable to estimate that a car that has been parked in the sun in the summer where I live could reach 50°C. The 3.5 watts we need to dissipate will raise the temperature 65 * 3.5 = 227.5°C above ambient, for a total of 277.5°C, much higher than the maximum temperature for this chip. We’re going to need a heatsink.

There are all sorts of heatsinks you could choose for this purpose. I found a pretty simple one for a TO-220 package that has a thermal resistance of 25.9°C/W without moving air. The 2576 has a thermal resistance of just 2°C/W to its own case, for a total of 27.9°C/W. This solution rises to about 98°C above ambient, for a total of 148°C. This is very close to the maximum operating temperature, and if I actually intended to operate the device at 3 amps, I would want to find a better solution. But since the design requirements were set artificially high (3 amps instead of 2 amps) to make sure the design could easily manage the typical use case, this will do fine. (The actual intended draw of 2A at 5V is 10 watts, dissipating 2.5 watts at 80% efficiency for a temperature rise of 75°C above ambient. On that hypothetical hot summer day, the chip will reach 125°C, which is well within its limits).

The rest of the components I selected using the typical application circuit shown in the 2576 datasheet. I placed my Digikey order, and my parts were on their way! Next up: test and assembly.

Posted in Automotive, Electronics, Uncategorized | Comments Off on In-Car USB Power Supply Design

Automotive Line-In Audio and USB Charging

I consider a line-in jack to be an essential feature for a car. Since I started driving, I have always had some device with audio on it that I wanted to play in the car. In my first car I put in an aftermarket stereo with line-in connections on the back, and loved it. It was kind of a hackish job with one end of an 1/8th inch audio wire connected behind the dash, and the other end sticking out of the dash, but it did what I needed it to do. However, after graduating from college, that car was nearing the end of its life. I got a new car and was once again without audio input.

I have many times gotten into the car to go somewhere only to discover that my mp3 player, cellphone, bluetooth headset, or other device is completely dead. A long drive just gets longer without good music or a podcast to listen to, and it’s nearly impossible to find a serviceable payphone around anymore. I decided I also need to have a USB charger built into my car.

An aftermarket stereo may have solved both these problems. However, the stereo in my car is perfectly good and is one of those that is integrated into the dash to the point that a replacement is either going to look very hackish or be very expensive. Besides, just buying what you need is no fun.

I very briefly considered an FM short-range broadcaster system. I’ve used these before, but they are hackish at best and tend to be pretty useless in the city where I live, as the FM spectrum is pretty saturated. My car (a Mazda 3) has support for a tape deck built into the head unit, which I hoped I could use as an auxiliary audio input. After some searching, I learned that the head unit uses a proprietary connection and protocol to interface with the external unit. Some of the connections are analog audio, but the head unit won’t use them unless it can communicate with the external device using the proprietary protocol. I was very happy to find the AuxMod project, which has already solved the problem of integrating with the Mazda radio bus. I bought one, installed it, and never looked back. It’s worked perfectly, and I’m very happy with it.

I wanted to design the USB charger system myself. Again, I’m sure there’s an aftermarket solution to do this, but the ones I found were all expensive, ugly, or both. I decided to put together a simple power converter to provide the 5 volts to a USB jack. This time I wanted to integrate the USB and audio connections into the dash somewhere. Wires dangling out from the edges of panels or hidden in the console are a hassle to dig out, are always getting in the way when they are out, look unsightly, and can’t be changed without tearing the dash apart. I wanted a nice set of connectors built into the dash to look like they were intended to be there.

After some browsing on Digikey and elsewhere, I found a great looking panel-mount USB jack. The Digikey picture makes it look like white plastic, but this is a very rugged, nickel-plated connector. It has two connectors, just in case I want to charge two devices at the same time. I also found a nice audio jack that has a similar metallic finish.

With the basics of the project fleshed out, it was time to begin designing the power supply. More on that in the next post.

Posted in Automotive, Electronics | Comments Off on Automotive Line-In Audio and USB Charging

FazCAN Shield v2.0

After a few months of off-and-on work, I finally have version 2.0 of the CanShield ready! I received some good feedback from users and had several ideas of my own I wanted to implement. Now called FazCAN to differentiate from any other CAN shields, there are several improvements to the new shield.

FazCAN Shield

There are now two RJ-45 terminals on the board, making it much easier to connect your own CAN network. Each terminal on the board connects to one neighboring board using ethernet or phone cables. Since each board can have two neighbors, any number of boards can be daisy-chained together into a network. The electrical connections to the RJ-45 terminals are built into the board, which means no more manual wiring. This makes it easier to set up a CAN network quickly, and is less susceptible to failure.

The connections to the D-Sub terminal are also built into the board. However, the connections to the CAN lines on the board pass through 0-ohm resistors (jumpers), which are placed when the board is assembled. All of the pins from the terminal are brought out to pads on the board, so the jumpers can be used to fit any required cabling scheme. The markings on the board indicate the the most common wiring scheme. The pads that the pins from the terminal are brought out to are 0.1-inch spaced, so if you need more configurability, you can solder a 9-pin header here instead of the jumpers. Then you can make manual wired connections between the pins and the CAN lines.

Of course the screw terminal is still available to connect to any other type of cabling.

The INT line from the MCP2515 is now brought out to a pin on the Arduino. The software does not require this line to be connected, though, and the line is connected by a jumper, which can be omitted. The this allows the pin to be used for other purposes if needed.

The 120-ohm bus termination resistor is now connected to the CAN bus by a switch. The two shields at the either end of the CAN bus need to have their switches set such that their resistors form the electrical ends of the bus. The middle shields (if any) should have their switches set such that their resistors are not connected to the bus. When connecting to an existing CAN network, the bus is already properly terminated, so the shield should be configured as a “middle” node.

There are some software improvements too. Some users requested the ability to use speeds other than those predefined in the library. I’ve added the ability to specify the bus speed by the length of each bit (bit time). This allows the shield to operate at nearly any speed. Also, multiple data types can now be packed and unpacked from a single CAN message, minimizing the number of CAN messages that need to be sent. This also allows for easier integration with existing CAN networks. The library has been updated for the Arduino 1.0 environment, and will no longer work with older environments. However, there should be no problem using the newest version of software on the original CANShield. It is likely that the library will also work with other MCP2515-based CAN shields on the market.

The documentation for the library has been greatly improved, and I’ve generated a documentation page generated with Doxygen to make it easier to understand and use the library.

Thanks, everyone, for your support on the first shield, and the great feedback that has helped me develop version 2.0. Further design details, build instructions, usage information, and more are available on the product page.

Posted in Arduino, CAN, Electronics, PCB | Comments Off on FazCAN Shield v2.0