We covered SparkFun’s new RGB button pad controller a few weeks ago. This is a full-color clone of the monome interface; a 4×4 grid of buttons with tri-color LEDs underneath. Each LED has 24bits of color control, for more than 16million color combinations. Up to 10 panels can be chained together to create huge button grids, like SparkFun’s Tetris table. We previously used a smaller version in our RGB combination lock.

We asked SparkFun to send us the SPI version of the button controller to test. This is a new product developed in-house at SparkFun, with open source hardware and software. Read about our experience interfacing this board below.

4×4 RGB button pad controller SPI (SparkFun #WIG-09022, $39.95)

The button pad controller is a bare PCB, we also received a button pad cover (SparkFun #COM-07835, $9.95), and two of each bezel (SparkFun #COM-08747, #COM-08746, $3.95).  The SPI version we’re working with can be driven directly by a microcontroller, or by a USB ‘master’. The USB controller version has an additional microcontroller and FTDI USB->serial converter for PC connectivity.

When the button pad arrived, we immediately sat down with the datasheet and tried to interface the board with our Bus Pirate universal serial interface. The protocol described in version 1 of the datasheet didn’t work, at all.

SparkFun open sourced this project, so we determined the correct interface protocol from the source code for the button pad SPI (ZIP) and the button pad USB controller (ZIP). We figured out most of the protocol from the source, but it still took help from SparkFun’s engineers to uncover some of the undocumented, finer points of interfacing the board. Version 2 of the datasheet (PDF) accurately depicts the interface protocol.

Connections

The button pad’s SPI signals are described as they relate to the on-board microcontroller, which is opposite the usual notation. The MOSI (master out, slave in) signal is actually the board’s data output, and MISO (master in, slave out) is the data input.

We tested the button pad with the Bus Pirate, but the same basic principals apply to any custom microcontroller code. The board runs at 5volts, so we powered it from the Bus Pirate’s on-board 5volt power supply. The SPI interface operates at 5volt logic levels, so we connected the Bus Pirate’s pull-up resistors to the 5volt power supply and enabled them on all signal lines.

We interfaced the button board using the Bus Pirate’s raw3wire library. Raw3wire is a software SPI library with bit-wise operations. The hardware SPI library only allows full byte operations which aren’t granular enough to interface the board. We put the Bus Pirate in raw3wire mode (menu option M), and chose the HiZ pin option because the pull-up resistors will hold the bus at 5volts.

RAW3WIRE>l <–configure bit order
1. MSB first
2. LSB first
MODE>2 <–least significant bit first
LSB SET: LEAST SIG BIT FIRST
RAW3WIRE>W <–enable power supply
VOLTAGE SUPPLIES ON
RAW3WIRE>

The button pad communicates least significant bit first, so we also configured the library to communicate LSB first. Finally, we hit capital ‘W’ to enable the Bus Pirate’s power supplies. The button board will flash each color momentarily as part of its power-on self-test.

Single/multiple button board setup

Each board needs to be configured for single or multi-board use. Boards come pre-programmed for single-board operation, but it might be a good idea to set the configuration anyways. The board configuration is permanently stored in EEPROM, so it only has to be done once.

RAW3WIRE>[\_ <--take all signals low
CS ENABLED <--CS enabled is 0volts
CLOCK, 0
DATA OUTPUT, 0
RAW3WIRE>

A special sequence places the board in configuration mode. Begin with all signal lines low (]\_).

RAW3WIRE>-^ 1 1 <–set single board operation
DATA OUTPUT, 1 <–data high
0×01 CLOCK TICKS <–one clock tick
WRITE: 0×01 <–config option 1, number of boards
WRITE: 0×01 <–set the number of boards
RAW3WIRE>w <–small ‘w’, power off
VOLTAGE SUPPLIES OFF
RAW3WIRE>W <–capital ‘W’, power on
VOLTAGE SUPPLIES ON
RAW3WIRE>

To enter configuration mode, take the data line high (-) and send one clock pulse (^), but leave chip select low. The board is now ready to accept configuration settings.

The first byte sent after entering configuration mode tells the board which setting to modify. Currently, only the number of boards can be configured (0×01). Next, send the number of connected boards, between 1 and 10. we sent 1 because we’re interfacing a single board. Reset the board and it will light a LED corresponding to the programmed number of boards.

Set colors and read button status

Now we’re ready to send color data to the board and read the button status. First, note that the CS (chip select) signal is opposite normal conventions. Usually CS activates a chip when the signal is low (0volts), and idles it when the signal is high (5volts); this is usually denoted by /CS, #CS, or !CS. Instead, the button controller is active when CS is high.

A 64byte transaction sets the LED colors and retrieves the button status. The first 16bytes program the red level for each LED, followed by 16bytes of green, and 16bytes of blue. Finish by reading 16bytes from the board to get the status of each button. Buttons data is sent as 0×00 if pressed, and 0xff if not pressed. The datasheet recommends a 400us delay between writing the color frames and reading the button data, but the Bus Pirate is slow enough that we won’t worry about that.

The protocol is simple enough, but there’s one major catch. The clock line must be high before raising CS, or the bytestream will be off by 1 bit. For this reason, many hardware SPI modules won’t work with the board.  This isn’t a problem if your microcontroller lets you twiddle pins that are controlled by a hardware module, but the micros we’ve worked with don’t allow this.

RAW3WIRE>/]255:16 255:16 255:16 r:16[
CLOCK, 1 <--clock must be high prior to raising CS
CS DISABLED <--CS to 5volts, opposite normal use
BULK WRITE 0xFF , 0x10 TIMES <--red LEDs
BULK WRITE 0xFF , 0x10 TIMES <--green LEDs
BULK WRITE 0xFF , 0x10 TIMES <--blue LEDs
BULK READ 0x10 BYTES: <--read button state
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
CS ENABLED <--CS to 0volts, opposite normal use
RAW3WIRE>

This command sets every color of each LED to full, and reads back the 16 button status bytes.

We first set clock high (/), and only then can we raise CS to 5volts (]) and begin the data transaction. 255:16 is a repeated command that sends the value 255  sixteen times. As each color channel has 8bits of intensity control, 255 is 100% on. We send 255 a total of 48 times, once for each color of each LED. Finally, we retrieve one 16byte frame of button data (r:16) and lower CS to end the transaction ([). The button values are all 0xff, indicating that no buttons are pressed.

RAW3WIRE>/] 0:16 0:16 128:16 r:16[
CLOCK, 1
CS DISABLED
BULK WRITE 0x00 , 0x10 TIMES
BULK WRITE 0x00 , 0x10 TIMES
BULK WRITE 0x80 , 0x10 TIMES <--all blue to 50%
BULK READ 0x10 BYTES:
0x00 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
CS ENABLED
RAW3WIRE>

Here, we set the blue level of every LED to 50% (128) and turn off all other colors. The button output now shows that button 0 is pressed.

RAW3WIRE>/] 0 0 0 0 255 255 255 255 0 0 0 0 0 0 0 0 0:16 0:16 r:16[
CLOCK, 1
CS DISABLED
WRITE: 0×00 <– red LED 0, off
… <–more of the same
WRITE: 0×00 <– red LED 3, off
WRITE: 0xFF <– red LED 4, 100% on
WRITE: 0xFF <– red LED 5, 100% on
WRITE: 0xFF <– red LED 6, 100% on
WRITE: 0xFF <– red LED 7, 100% on
WRITE: 0×00 <– red LED 8, off
… <–more of the same
WRITE: 0×00 <– red LED 15, off
BULK WRITE 0×00 , 0×10 TIMES <– all green LEDs off
BULK WRITE 0×00 , 0×10 TIMES <–all blue LEDs off
BULK READ 0×10 BYTES: <–read button status
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
CS ENABLED
RAW3WIRE>

This example shows how to address single LEDs. This time we actually write out all 16 bytes of the red color frame. Buttons 0-3 and 8-15 have a red value of 0 (red off), buttons 4-7 are set to 100% red (255). All green and blue LEDs are off (0, 0%).

Conclusion

It was really frustrating to get this board working because the first version of the datasheet had so many errors. SparkFun’s engineers and support were really helpful, and posted a corrected datasheet within days. As long as you have the updated datasheet, this is an easy board to work with.

We’d like to see a firmware update that eliminates the need to keep the clock signal high before raising CS. This quirk makes the board incompatible with many hardware SPI modules, leaving slow bit-bang routines as the only interface option. Fortunately, the source code is open and available to anyone who wants to make this change.

The button pad controller is a really neat board, and we look forward to using it in a future project.

Hack a Day review disclosure: We asked for a free board and SparkFun sent it to us. We had a terrible time getting it to work with the instructions in the first version of the datasheet, we documented that experience here.

Sensirion’s SHTxx is a digitally interfaced humidity and temperature sensor. Accurate humidity measurements usually require careful analog design, but the SHTxx moves all that complicated stuff into a single chip. Through-hole (SHT7x) and surface mount (SHT1x) versions are available, we used the surface mount SHT11 with +/-3% accuracy. We’ll show you how to use the SHTxx below.

Sensirion SHT1x/SHT7x precision humidity and temperature sensor (Octopart search, starting at $25).

This isn’t a cheap sensor. Octopart lists a few places to buy it. Several smaller hobby electronics stores carry it; Hobby Engineering has it for $29 (#H01509-01C). We found compatible PCB footprints in sht10_11_15.lbr and sht11.lbr on the Cadsoft library download page. Pin connections for the different package types are in the datasheet: SHT1x (PDF), SHT7x (PDF).

The SHTxx has a two-wire serial interface that requires pull-up resistors (R1,2), values between 2K and 10K should work. Sensirion recommends a decoupling capacitor (C1) only if the sensor is powered over a length of wire, but we think it’s always a good idea to include one.

We’ll demonstrate the SHTxx using the Bus Pirate universal serial interface in raw2wire mode with Hi-Z outputs. The SHTxx is powered from the Bus Pirate’s 3.3volt supply. The Bus Pirate’s on-board pull-up resistors hold the bus high, eliminating the need for external resistors R1 and R2.

Interface

The SHTxx communicates over two wires using a simple serial protocol. The protocol isn’t compatible with I2C, but a single SHTxx can exist on a bus with I2C peripherals.

Five commands control the SHTxx, these are outlined in the table. The first 3 bits are the address (always 000), the remaining 5 bits are a unique command code.

Reset

Start a transaction by clearing any partial commands or data from a previous use. A minimum of nine clock ticks while data is high will clear the SHTxx interface. The Bus Pirate syntax to for this is -^:9; data high (-), 9 clock ticks (^:9).

Commands to the SHT11 begin with a unique start condition. Like an I2C start condition, this is the only time when the data signal changes with the clock signal high. This illegal condition causes the chip to prepare for a new command. The SHTxx start condition is different than I2C, allowing both types of devices to exist on the same bus.

The Bus Pirate code to generate an SHTxx style start condition is -/_\/-\ ; data starts high (-), clock up (/), data goes low (_), clock low (\), clock high (/), data goes high (-), and a final clock low transition (\) ends the sequence.

A soft reset is a good idea because it puts the chip in a default state. Prior to the first temperature or humidity conversion, we send the soft reset command.

RAW2WIRE>-^:9 -/_\/-\ 0b00011110 !<–command
4xx RAW2WIRE DATA OUTPUT, 1 <–clear interface
4xx RAW2WIRE 0×09 CLOCK TICKS
4xx RAW2WIRE DATA OUTPUT, 1 <–start condition
4xx RAW2WIRE CLOCK, 1
4xx RAW2WIRE DATA OUTPUT, 0
4xx RAW2WIRE CLOCK, 0
4xx RAW2WIRE CLOCK, 1
4xx RAW2WIRE DATA OUTPUT, 1
4xx RAW2WIRE CLOCK, 0
420 RAW2WIRE WRITE: 0x1E <–soft reset code
4xx RAW2WIRE READ BIT: 0 <–acknowledge bit, OK
RAW2WIRE>

First, we clear the interface (-^:9), then send the start condition (-/_\/-\). The reset command (0b00011110=0x1E) follows. The SHTxx acknowledges (acks) commands by pulling the data line low for one bit after a command is transmitted. We read one bit (!) to get the acknowledgment status; 0 is success, 1 signals an error.

Temperature

Now we can read the temperature. This happens in two steps, with a delay for the temperature conversion.

RAW2WIRE>-^:9 -/_\/-\ 0b00000011 !
4xx RAW2WIRE DATA OUTPUT, 1  <–clear interface
4xx RAW2WIRE 0×09 CLOCK TICKS
4xx RAW2WIRE DATA OUTPUT, 1 <–start condition
…
4xx RAW2WIRE CLOCK, 0
420 RAW2WIRE WRITE: 0×03 <–start temperature conversion
4xx RAW2WIRE READ BIT: 0 <–ack bit, OK
RAW2WIRE>

First, we send a start condition and the temperature conversion command (00000011=0×03). The SHTxx replies to a successful command by pulling the data line low for one bit (ack). After the ack bit, the data line goes high until the conversion finishes.

RAW2WIRE>.
4xx RAW2WIRE DATA INPUT, STATE: 0 <–data low when done
RAW2WIRE>

When the data line goes low, the temperature conversion is finished. ‘.’ is the Bus Pirate command to read the data state without a clock tick. Now we can grab the result.

RAW2WIRE>r_^ r_^ r_^
430 RAW2WIRE READ: 0×17 <–data byte 1
4xx RAW2WIRE DATA OUTPUT, 0 <–data low
4xx RAW2WIRE 0×01 CLOCK TICKS <–send ack bit
430 RAW2WIRE READ: 0xCC <–data byte 2
4xx RAW2WIRE DATA OUTPUT, 0
4xx RAW2WIRE 0×01 CLOCK TICKS
430 RAW2WIRE READ: 0x0C <–crc
4xx RAW2WIRE DATA OUTPUT, 0
4xx RAW2WIRE 0×01 CLOCK TICKS
RAW2WIRE>

Each byte read (r) requires an I2C style acknowledgment bit with the data low. We do this with the _^ sequence; data low (_), one clock tick (^).

The first two bytes are the temperature reading (0x17cc), followed by a CRC (0x0c). The raw value (0x17cc=6092) is converted to degrees Celsius using the equation and coefficients on page 9 of the datasheet. Temperature readings are 14bits by default:

T = -39.7 + 0.01*X

21.22C = -39.7 + (0.01*6092)

Humidity

Humidity conversions are started with code 00000101 (0×05 hex).

RAW2WIRE>-^:9 -/_\/-\ 0b00000101 ! <–command
4xx RAW2WIRE DATA OUTPUT, 1 <–clear interface
4xx RAW2WIRE 0×09 CLOCK TICKS
4xx RAW2WIRE DATA OUTPUT, 1 <–start condition
…
4xx RAW2WIRE CLOCK, 0
420 RAW2WIRE WRITE: 0×05 <–start humidity conversion
4xx RAW2WIRE READ BIT: 0<–ack bit, OK

As before, a ninth acknowledgment bit is low if the SHTxx processed the command.

RAW2WIRE>.
4xx RAW2WIRE DATA INPUT, STATE: 0 <–data low when done

The data line goes high and then returns low when the humidity conversion is done.

RAW2WIRE>r_^ r_^ r_^
430 RAW2WIRE READ: 0×05 <–data byte 1
4xx RAW2WIRE DATA OUTPUT, 0 <–data low
4xx RAW2WIRE 0×01 CLOCK TICKS <–ack bit
430 RAW2WIRE READ: 0×80 <–data byte 2
4xx RAW2WIRE DATA OUTPUT, 0
4xx RAW2WIRE 0×01 CLOCK TICKS
430 RAW2WIRE READ: 0×46 <–crc
4xx RAW2WIRE DATA OUTPUT, 0
4xx RAW2WIRE 0×01 CLOCK TICKS
RAW2WIRE>

A complete conversion generates a three byte response. The first two bytes are the raw humidity reading (0×0580=1408), the final byte is a CRC (0×46) that can be used to verify data integrity.

Humidity readings have 12bits of resolution by default, convert to humidity using this equation:

RH = -2.0468 + 0.0367(X) + (-0.0000015955*(X^2))

46.46%RH = -2.0468 + 0.0367(1408) + (-0.0000015955*(1408^2))

Conclusion

This isn’t a cheap sensor, but it doesn’t require careful analog design like the Honeywell HIH series. Have you worked with a humidity sensor?

Like this post? Check out the parts posts you may have missed.

Download: buspirate.v0d.zip

Dallas/Maxim’s 1-Wire protocol is the most requested addition to the Bus Pirate.  We finally got some 1-Wire parts, and today we’ll demonstrate the DS1822 1-Wire digital thermometer. Grab the datasheet (PDF) and follow along.

This post is accompanied by release v.0d of the Bus Pirate firmware for hardware version 0. This includes the new 1-Wire protocol library, more configuration options, and other improvements.

DS1822 Economy Digital Thermometer (Digikey #DS1822+-ND, $3.87) We found a footprint in the 1-wire library for Eagle on the Cadsoft download page.

The 1-Wire protocol uses a single wire for data transfer, and sometimes power. Data is transferred in time-sensitive ‘slots’ because there isn’t a separate clock to delineate bit periods.

The DS1822 connections are shown in the table. We used the Bus Pirate’s 5volt supply to power the DS1822, but it also works at 3.3volts. A resistor (R1, ~5K) holds the bus high.

All 1-Wire commands start with a reset procedure, followed by one of five ROM commands.

ROM commands are described on page 10 of the datasheet. All ROM commands are available as macros in the Bus Pirate 1-Wire library, see (0) for a menu. ROM command macros include the 1-Wire bus reset procedure.

Single device

All 1-Wire devices have a unique 64bit (8 byte) address, and some 1-Wire devices are used exclusively to give electronics a unique tracking number. When a single device is connected to a 1-Wire bus, the READ ROM command will extract its address.

1-WIRE>{ 0×33 r:8 <–command
xxx 1WIRE BUS RESET OK
xxx 1WIRE WRITE: 0×33 <–READ ROM
xxx 1WIRE BULK READ, 0×08 BYTES:
0×22 0×47 0×45 0×22 0×00 0×00 0×00 0×29 <–ID#
1-WIRE>

The command sends a bus reset ({), the READ ROM command (0×33), and reads the 64bit address (r:8, 8 bytes *8bits/byte=64bits).

The first byte (0×22) identifies this as a DS1822 thermometer. The next 6 bytes are unique to this device, and the final byte is a CRC of the previous 7 bytes.

Now we can address the device with the MATCH ROM command and send it further instructions.

1-WIRE>{ 0×55 0×22 0×47 0×45 0×22 0×00 0×00 0×00 0×29 0×44
xxx 1WIRE BUS RESET OK
xxx 1WIRE WRITE: 0×55<–MATCH ROM command
xxx 1WIRE WRITE: 0×22<–start address
xxx 1WIRE WRITE: 0×47
xxx 1WIRE WRITE: 0×45
xxx 1WIRE WRITE: 0×22
xxx 1WIRE WRITE: 0×00
xxx 1WIRE WRITE: 0×00
xxx 1WIRE WRITE: 0×00
xxx 1WIRE WRITE: 0×29
xxx 1WIRE WRITE: 0×44 <–start conversion
1-WIRE>

First, we send the MATCH ROM command (0×55) and the device address (8 bytes).  Next is the CONVERT T command (0×44, datasheet page 11) that starts the temperature conversion.

A second command sequence retrieves the temperature reading from the DS1822.

1-WIRE>{ 0×55 0×22 0×47 0×45 0×22 0×00 0×00 0×00 0×29 0xbe r:9
xxx 1WIRE BUS RESET OK
xxx 1WIRE WRITE: 0×55
xxx 1WIRE WRITE: 0×22
…long 1-Wire address…
xxx 1WIRE WRITE: 0×29
xxx 1WIRE WRITE: 0xBE <–read scratchpad command
xxx 1WIRE BULK READ, 0×09 BYTES:
0×71 0×01 0xFF 0×00 0x7F 0xFF 0x0F 0×10 0xF8
1-WIRE>

The READ SCRATCHPAD command (0xBE, datasheet page 11) returns 9 bytes. We only care about the first two bytes, the rest can be decoded according the the table on page 7 of the datasheet. Temperature is calculated according to page 4 of the datasheet: 0×0171 HEX=369 DEC, 369*0.0625=23C  (74F).

Multiple devices

When multiple 1-Wire devices share a bus it’s more difficult to determine all the addresses. The fastest way to find attached devices is with the SEARCH ROM command (0xF0) and a binary branching procedure. The Bus Pirate automates this with macro (240).

1-WIRE>(240) <–macro 240
xxx 1WIRE ROM COMMAND: SEARCH (0xF0)
Found devices at:
Macro     1-WIRE address
1.0×22 0×50 0×28 0×22 0×00 0×00 0×00 0x0A <–address
*DS1822 Econ Dig Therm <–type according to family code
2.0×22 0xD0 0xC7 0x1A 0×00 0×00 0×00 0×01
*DS1822 Econ Dig Therm
3.0×22 0×47 0×45 0×22 0×00 0×00 0×00 0×29
*DS1822 Econ Dig Therm
Found 0×03 devices.
The first 10 device IDs are available by MACRO, see (0).
1-WIRE>

The SEARCH ROM command shows the devices it found, and the type according to the family code.

We think typing 8 byte 1-Wire addresses is really tedious, so the first 10 device addresses are stored in memory and can be accessed with the macros (1)…(10). A buffer for up to 50 device addresses can be defined in the 1-Wire library at compile time. Ideally, this data will be stored in a global scratch buffer shared by all modules in a future firmware update.

1-WIRE>(0) <–show macro list
0.Macro menu
Macro     1-WIRE address <–enumerated device addresses
1.0×22 0×50 0×28 0×22 0×00 0×00 0×00 0x0A
*DS1822 Econ Dig Therm
2.0×22 0xD0 0xC7 0x1A 0×00 0×00 0×00 0×01
*DS1822 Econ Dig Therm
3.0×22 0×47 0×45 0×22 0×00 0×00 0×00 0×29
*DS1822 Econ Dig Therm
1-WIRE ROM COMMAND MACROs:<–normal commands
51.READ ROM (0×33) *for single device bus
85.MATCH ROM (0×55) *followed by 64bit address
204.SKIP ROM (0xCC) *followed by command
236.ALARM SEARCH (0xEC)
240.SEARCH ROM (0xF0)
1-WIRE>

The macro menu (0) will also include the device addresses stored in the roster. Now we can just address devices by macro, rather than typing the whole 64bit address every time.

1-WIRE>(85) (1) 0×44 <–start conversion
xxx 1WIRE BUS RESET OK
xxx 1WIRE WRITE ROM COMMAND: MATCH (0×55) *follow with 64bit address
xxx 1WIRE ADDRESS MACRO 1: 0×22 0×50 0×28 0×22 0×00 0×00 0×00 0x0A
xxx 1WIRE WRITE: 0×44
1-WIRE>(85) (1) 0xbe r:9 <–fetch reading
xxx 1WIRE BUS RESET OK
xxx 1WIRE WRITE ROM COMMAND: MATCH (0×55) *follow with 64bit address
xxx 1WIRE ADDRESS MACRO 1: 0×22 0×50 0×28 0×22 0×00 0×00 0×00 0x0A
xxx 1WIRE WRITE: 0xBE
xxx 1WIRE BULK READ, 0×09 BYTES:
0×81 0×01 0x4B 0×46 0x7F 0xFF 0x0F 0×10 0×71
1-WIRE>

(85) is a shortcut for a bus reset and MATCH ROM command. (1) is the device address macro, and 0×44 is the command to begin a temperature conversion. Retrieving the reading involves the same macros, but substitutes the command to read the device (0xBE) and grabs 9 bytes (r:9). The temperature is 0×0181, or 24C next to the PC fan.

Taking it further

We used the Bus Pirate to give a visual demonstration of the 1-Wire protocol, but the real challenge is integrating it into your own design. Maxim provides example code, Microchip has an app note (PDF), and you can check out the example code we used.

Firmware download: buspirate.vod.zip

3.5mm stereo connectors for headphones and microphones are almost mandatory for audio projects. X1 (left) is a simple plug with connections for the audio channels (pin 2,3), and ground (pin 1). X2 (right) has pass-through contacts (pin 2,3) that divert audio to an internal speaker when headphones aren’t connected.

Here’s a breakdown of the audio connectors illustrated above. We found footprints for these parts, and several other SMD audio connectors, in the con-cuistack part library on the Cadsoft download page.

X1 3.5mm stereo audio jack (Mouser #161-3334-E, $1.16) This is a simple stereo audio jack with no internal pass-through. Fits footprint SJ-3523 in the con-cuistack library.

X2 3.5mm stereo audio jack with internal pass-through (Mouser #161-3335, $1.25) This is our favorite audio jack, but it looks like it’s going to be discontinued soon. Can anyone recommend an equivalent? Fits footprint SJ-3515 in the con-cuistack part library.

Don’t forget to check out our previous parts posts.

SD cards add cheap persistent memory to your project, but the holder takes a lot of board space. A smaller option is the microSD flash format. MicroSD cards are compatible with regular SD cards, and most come with a free adapter. We looked at four holders for our mini web server. Which should you choose? Read about our experience below.

Here’s a breakdown of the microSD card holders illustrated above:

Alps SCHA1B0100 $1.27 – Can you see pins through the holes in the first holder? They ‘re hard to see, and almost inaccessible. We didn’t find this holder very useful for prototyping.

JAE ST6S008V4AR1500 $1.46 – This is another model with pins located at the front, but these are further forward for easier access. It’s still going to be a pain to solder, avoid if possible.

SparkFun PRT-00127 $3.95 – Finally, a holder with pins at the back. This is a fairly easy-to-solder part, but it’s not ideal. The soldering tabs are very small and slightly recessed under the shield. It’s also the most expensive microSD holder we’ve seen. SparkFun has a Cadsoft Eagle footprint for this part in their library. We think Molex 538-502702-0891 ($3.58) is probably very similar. We used this holder with the mini web server.

Alps SCHA2B0300 – $1.27 – The long pins along both sides of this holder are easy to solder. The holder is reversed, meaning the card inserts upside-down. Reversed holders seem weird on an all surface mount board, but they fit nicely in through-hole designs. There’s no Eagle footprint yet, but we’ll send an SCHA2B0300 to the first person who makes one; here’s the datasheet (pdf).

Check out our previous parts posts: 0.1uF decoupling capacitors, the LM317 adjustable regulator, and tactile switches.

Most ICs need to be decoupled from their power supply, usually with a 0.1uF capacitor between each power pin and ground. Decoupling is usually used to remove noise and to smooth power fluctuations. Every project will need a few decoupling capacitors; our mini web server project has three ICs that require a total of 11. This can be an expensive part to buy in singles, so it’s crucial to stock up online. Read more about our favorite bulk through-hole and surface mount decoupling capacitors after the break.

The capacitors we selected should be sufficient for most projects. All three parts are rated for 50volts, far more than most digital circuits. We used cheap 20% tolerance parts because it’s not critical that decoupling capacitors be exactly 0.1uF. Higher or lower tolerance capacitors will also work, but there’s no advantage to using high quality decoupling capacitors. Here’s a breakdown of the 0.1uF capacitors pictured above:

C1 through-hole 0.1uF capacitor, such as Mouser #594-K104M15X7RF53L2, ($4 per 100 ) – This cheap 0.1uF capacitor will fit almost any design that calls for through-hole decoupling capacitors. Leads are spaced 2.5mm apart, and fit footprints such as C-EU025-025×050 in the default Cadsoft Eagle rcl library. Part number -L2 has straight legs, -K2 has an outside kink as shown in the picture.

C2 1206 SMD 0.1uF capacitor, such as Mouser #77-VJ12Y50V104K, ($4 per 100) – You might be tempted to try 1206 size parts in your first surface mount experiments. We urge you to skip 1206 and head right on down to 0805. 1206 parts have very little cost benefit over through-hole parts because they’re no longer an industrial favorite. 0805 is just a bit smaller, but costs half as much. Fits Eagle footprint C-EUC1206 in the default rcl library.

C3 0805 SMD 0.1uF capacitor, such as Mouser #80-C0805C104M5R, ($2 per 100) – An 0805 capacitor fits between two pins on a through-hole DIP chip, and aligns nicely with pins on an surface mount SOIC chip. All our new designs, surface mount and through-hole, incorporate this dirt-cheap decoupling capacitor. Fits footprint C-EUC0805 in the default Eagle rcl library.

Check out our previous parts posts on the LM317 adjustable regulator and tactile switches. Are there any parts you’d like us to cover?