Sure, the new BMW/Apple integrated iPod/car solution is cool—if you have a BMW. If you don’t, you can still integrate your iPod into your car’s electronic system in no time.
When I’m driving, I want easy access to a wide variety of music that doesn’t take up a lot of space. The iPod is an almost perfect solution, and third-party vendors offer a wide range of accessories that make integrating an iPod into your vehicle easy.
Still, controlling the iPod while driving can be awkward and distracting. My car, like many others, has steering wheel buttons that can be used to control the factory-installed radio and CD player. With this hack, you will be able to use these buttons to control your iPod from your steering wheel. How? By hacking the iPod remote.
It’s always fun to take things apart, so let’s start with that. I have a generation 2 (G2) iPod, which means that it has a standard FireWire connector instead of a dock, and it uses a different connector for the remote than the latest iPods do. The shiny exterior that looks like metal really is metal—don’t try to bend it! Remove the white plastic portion (the clip and back of the remote) by using a small screwdriver to pry it out of the case, as in Figure 1-38. The best place to do this is on the same side as the hold switch, just past the green dot, by the b in the phrase “assembled in China.” The PC board (including the headphone jack) will remain in the metal case.
Tip
There are two pins in the metal case that hold the PC board. These don’t bend and make removing the PC board somewhat difficult.
Although the connector at the end of the G2 iPod’s remote differs from that of the G3 or G4 iPod, both cables carry six wires: three analog signals are fed directly to the headphone jack, and three go to a small microcontroller and handle the remote-control functions. To reduce noise, the analog and digital grounds are kept separate in the remote. The extra pin on the later iPod’s connector is not connected to any wires in the cable. See Figure 1-39 for a peek at the button side and chip side of the opened remote.
The heart of the remote is a general-purpose Microchip 12C508A microcontroller. This is a simple self-contained computer designed to execute only one simple program. This tiny chip has eight pins: two are for power (3.0–5.5 volts) and six are general-purpose input/output (I/O). Most microprocessors require a reset signal and a clock, but this chip generates those internally so as not to waste precious pins. Programs may occupy up to 512 words of memory and use 25 bytes of RAM. Two other unpopulated five-pin integrated circuits (ICs) are on the button side of the circuit board, but it’s not clear what their purpose is.
Using a multimeter, we can trace all the signals from the connector back to the processor. Microchip’s web site ( http://www.microchip.com; search for “12C508A”) has the datasheet for the microcontroller that tells us which pins are used for power and ground. The last pin goes through a 1kΩ resistor (R7) to reach pin 7 of the IC, a general-purpose I/O pin. Table 1-2 shows the wire colors and signals for G2 and G3/G4 iPods.
Table 1-2. Wire colors and signals for G2 and G3 iPods
Wire color | G2 iPod | G3/G4 iPod | Signal |
|---|---|---|---|
Black | Tip | Tip | Audio, left |
White | Ring (next to tip) | Ring | Audio, right |
Red | Ring 2 (third ring from end) | Ring 2 | Audio ground |
Green | Sleeve (fourth ring from end) | Pin 1 | Data to iPod |
Blue | Inner ring | Pin 4 | Power to remote, +3.3V |
Yellow | Outermost ring | Pin 3 | Digital ground |
Pin 2 | Serial port transmit signal from the iPod to the remote | ||
Sleeve | No connect/unknown |
Since only one pin is used to tell the iPod which pin is pressed, the data must be transmitted serially—that is, the message is sent one bit at a time at a preset speed, and with a known pattern so that it can be decoded. It’s similar to Morse Code, and if the data was sent slowly enough, you would be able to see it turn a light on and off. But, since this data is sent much faster than a person could interpret, you must use an oscilloscope to make a plot of the voltage on the pin.
Pressing a button causes the remote to send a stream of data similar to that illustrated in Figure 1-40, but varying slightly depending on which button is pressed.
Although the G2 and G3/G4 iPods’ remotes share the same circuit boards, the processors are programmed differently, and the G3/G4 remote uses a slightly different protocol to talk to the iPod.
The G2 iPod’s remote most likely uses specialized hardware to detect the initial 45-millisecond pulse and wake the processor out of a low-power sleep. It then listens for the specific button codes to determine which button is being pressed. Each G2 code depicted in Figure 1-41 is a three-byte serial message, sent one bit at a time every 104 milliseconds (9,600 bits per second, or baud).
To help the iPod identify the message reliably, a start bit (0) is issued before each byte, and two stop bits (1) follow. Some systems use a simple error-checking code known as a parity bit before the stop bits, but the iPod does not. In standard serial-port terminology, this is referred to as 8N2, because each byte has 8 data bits, no parity is used, and there are two stop bits. Each byte is transmitted with the least-significant bit first. Figure 1-41 shows the results.
Most serial ports remain at the 1 state when idle. The G3 iPod’s remote follows this convention, but the G2 iPod does not: the 1 state is used only for the wake-up pulse and for a few clock cycles before the start of each message burst. Most serial ports would see the 1 to 0 transition at the end of each burst as either a malformed byte (detected because it won’t have a 1 where the stop bit is expected) or a special signal called a break.
The G3/G4 iPod’s remote uses a slightly different protocol than the G2 iPod. The wakeup pulse has been eliminated, and the G3/G4 hardware has a lower-power serial port that can be left on while the processor sleeps. The baud rate has been upped to 19,200 baud, while the message format now uses just one stop bit (8N1). The code repetition rate has also been doubled to 66 times per second, which should allow more precise control. However, the most interesting changes are in the new seven-byte code:
The first two bytes, 0xFF and 0x55, were probably chosen because they are interesting patterns: 0xFF has the lowest possible frequency signal (a 9-bit high pulse), while 0x55 has the highest frequency (alternating 1s and 0s). A sophisticated receiver could use these pulses to measure and adapt to the transmitter’s rate, allowing both components to use lower-cost, lower-precision frequency references.
Instead of a numeric code indicating which button has been pushed, the buttons are bit-mapped. This means that the remote can now indicate that more than one button has been pressed by setting more than one bit. The presence of a 0x00 before the sixth byte suggests that a total of 16 buttons may be accommodated by this protocol.
The messages are protected from errors by a checksum. The last byte varies so that the sum of bytes 3–7 will form an even multiple of 0x100.
Figure 1-42 shows the button codes for the generation 3 and 4 iPods.
Table 1-3 lists the three-byte and seven-byte button release codes for the G2 and G3/G4 remotes.
Table 1-3. Button release codes for G2 and G3/G4 iPods
Button | G2 three-byte code | G3/G4 seven-byte code |
|---|---|---|
PLAY/PAUSE | 0xFF 0xFD 0xF1 | 0xFF 0x55 0x03 0x02 0x00 0x01 0xFA |
VOL+ | 0xFF 0xFD 0xF2 | 0xFF 0x55 0x03 0x02 0x00 0x02 0xF9 |
VOL- | 0xFF 0xFD 0xF3 | 0xFF 0x55 0x03 0x02 0x00 0x04 0xF7 |
SKIP>> | 0xFF 0xFD 0xF4 | 0xFF 0x55 0x03 0x02 0x00 0x08 0xF3 |
<<SKIP | 0xFF 0xFD 0xF5 | 0xFF 0x55 0x03 0x02 0x00 0x10 0xEB |
Button release | 0xFF 0xFD 0xF0 | 0xFF 0x55 0x03 0x02 0x00 0x00 0xFB |
If you read the datasheet for the Microchip microcontroller carefully, you’ll notice that it does not have a serial port. Yet, we’ve seen that the output mostly looks like a standard serial output, and the iPod (which has a built-in serial port) recognizes that signal.
The trick lies in the microcontroller’s blazing speed: it can execute 1,000,000 instructions per second. To generate serial output at 9,600 bits per second, the code must be carefully written so that it takes exactly 104 instructions to generate each new bit. The program to do this is relatively simple, and in fact it spends most of its time idly waiting for the exact moment to release the new bit.
The technique is called bit-banging, because the output bit is manipulated (banged) under direct software control. Since many low-end processors are sufficiently fast enough to do this, it’s often cheaper for a simple device to implement a serial port in software rather than hardware. The down side to this technique is that while the processor is carefully controlling its output, it’s too busy to do anything else. In the iPod’s case, there is plenty of time to check for button presses during the relatively long pauses between code bursts.
My car, like many modern cars, uses a single wire (called the bus) to communicate serially between many of its different systems. This approach saves wiring, which in turn lowers weight, lowers cost, and increases reliability. There is no dominant standard yet, but many manufacturers use the same general protocol over a range of their models. My steering wheel contains a small microcontroller similar in concept to the one in the iPod’s remote: both monitor buttons and output codes to a serial bus. Controlling the iPod from the steering wheel is a simple matter of listening for the steering wheel’s output (while ignoring other messages on the bus) and translating that into a format that the iPod can understand.
After searching on the Web, I found specifications for my car’s bus on OpenBMW.org ( http://www.openbmw.org). Most BMWs built since about 1996 use a bus called the I-Bus. It is a single white wire marked with a red and yellow stripe, and it’s accessible from a number of places in the car. For experimenting, it’s often easiest to find this in the trunk (where a CD changer would connect), but this hack’s final installation will tap into the harness that connects the radio.
Electrically, this bus can be considered a simple serial port operating at 9,600 baud, with eight data bits, even parity, and one stop bit (8E1). A logical 0 is represented with 0 volts, and a logical 1 is nominally represented with 12 volts (a simple resistor divider chain can reduce this to a voltage safe for our microcontroller translator).
While the general format of the packets sent over the bus is more complicated, the data we need to look for from the steering wheel is relatively simple. Pushing or releasing a button on the steering wheel generates one of the messages shown in Table 1-4.
Table 1-4. Messages sent by various button presses
Action | Message (hex) |
|---|---|
Pressing TRK+ | 50 04 68 3B 01 06 |
Releasing TRK+ | 50 04 68 3B 21 26 |
Pressing TRK- | 50 04 68 3B 08 0F |
Releasing TRK- | 50 04 68 3B 28 2F |
Since the radio already responds to the volume-control buttons, we can ignore them.
There is a little more to it than that, though, because a good program will listen to all the messages on the bus so that it can keep in sync with the start of each message. Otherwise, if one of the codes above just happened to appear in the middle of a longer, totally unrelated message, the iPod might erroneously react.
I decided to use a different microcontroller for my project than Apple did for their remote. For a simple project like this, there isn’t much difference between microcontrollers; for me, it came down to availability of programming tools, personal preference, and what I had on hand. Most major manufacturers will provide example code that either controls a built-in serial port or emulates one by bit-banging; this can serve as a good basis on which to build the real code.
The chip I used, an Atmel ATtiny12-8PI, is comparable in specifications to the Microchip controller used in the remote. If we stop listening to the car’s bus while sending a command to the iPod, we might miss an important message (such as “buckle up”), so we need to simultaneously transmit and receive. Unfortunately, this chip doesn’t have a built-in hardware serial port, and it’s difficult to do these two things simultaneously with bit-banging. Using two of these relatively cheap ($2) processors is a compromise solution that makes programming it much simpler.
A 7805 voltage regulator converts the car’s 12-volt power down to the 5 volts that can safely be used by the processors, while two capacitors help reduce noise that could cause malfunctions. Two resistor dividers translate higher voltages down to lower ones: one knocks the 0–12V I-Bus down to 0–5V for the first processor, while the second brings the 0–5V output of the second processor down to 0–3.3V. The first processor just listens for the messages of interest on the I-Bus. It then recreates the state of the steering wheel buttons on the “track-” and “track+” wires: +5 volts indicates that the button is pressed, 0 volts means it’s not. The second processor monitors these and outputs the proper codes to the iPod. Since the timing of these two inputs isn’t critical, this works well with bit-banging. This give us the final remote schematic, shown in Figure 1-43.
As a finishing touch, the second processor will sense when the iPod is connected (using the +3.3V power line that would normally power the remote) and use this to issue a series of phantom volume-up keypresses until maximum volume is reached. This way, the sound will be at a consistent level, so that the radio’s knob is the only thing that affects the actual volume.
The third- and fourth-generation iPods (including the mini) have a more robust remote connector with one or two additional pins that appear to currently be unused. My best guess is that these mystery pins, with the proper firmware upgrade, will provide some sort of textual “currently playing song” output. This could be incorporated into a fancier remote control with a small screen of its own, or it could be used to provide titles to a car stereo’s display.
I document the original hack on my web page (http://www.maushammer.com/systems/ipod-remote/ipod-remote.html). You can download the program I used to control the iPod from this web page.
BMW uses a bus called the I-Bus to control noncritical devices, including the radio. More information is available athttp://www.openbmw.org.
Other car manufacturers and radio manufacturers use other buses. Here are some of the major ones:
Alpine Ai-Net/MBUS: http://kiora.ath.cx/alpine/
Sony UniLink: http://www.cus.org.uk/~cleggy/
JVC J-Link: http://www.jvc-victor.co.jp/english/tech/jlip/index.htm
You can find the datasheet for the microcontroller used in the iPod by searching for “12C508A” at http://www.microchip.com.
You’ll find the datasheet for Atmel’s AVR ATtiny12-8PI microcontroller at http://www.atmel.com/products/avr/.
The 7805 voltage regulator is a common part made by many manufacturers. National Semiconductor has a datasheet at http://www.national.com/pf/LM/ LM78M05.htm.
Dension ( http://www.densionusa.com) sells an I-Bus-to-iPod adaptor that pretty closely matches the functionality of this hack.
Get iPod and iTunes Hacks now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
