Apple iPod Remote Control Protocol

세상에는 벼래별 희안한 사람들이 다 있다.

I reverse-engineered a second-generation iPod remote (theversion that has the touch-sensitive scroll wheel). The remote probablyworks exactly as-is with the first generation iPod (with the mechanicalscroll wheel). The newest third-generation ipods (thinner, rounder, andwith 4 buttons in-line)have a similar remote with an identical circuit board, but with adifferent square 4-pin remote connector-- the new pinout hasn't been completely figured out, and it's notknown if the same protocol is used.
 
 

Remote is labeled "MITSUMI" and "66-6616A". The cable has 6 pins: 3analog signals are fed directly to the headphone jack, 3 go to a smallmicrocontroller and handle the remote-control functions. To reducenoise,they do not share a common ground in the remote (but I can still heartheremote affecting the sound).

Disassembly
The shiny exterior that looks like shiny metal really is - don't tryto bend it! I thought it was just a metalized plastic, but it's nice tosee such a nice quality case. I first considered this a cover thatcouldbe snapped off, but it's really the body of the remote; remove thewhiteplastic portion - the clip and back of the remote - by prying it out ofthe metal case by "b" in the phrase "assembled in china". The pcboard (including the headphone jack) will remain in the case. Probablythe easiest way to remove the plastic is to slip a thin screwdriver onthe same side as the hold switch, just past the green dot (away fromtheswitch, not on top of it). A picture would be helpful, but I haven'ttriedto put it back together yet - that looks like a challenge. There aretwopins in the metal case that hold the pc board; these don't bend andmake removing the pc board somewhat difficult.

Pinout
The generation 2 remote connector is compatible with standard 1/8thinch headphonejack, and also looks like the same connector used in the iBook AV cable(no confirmation on this, though).
It contains six unshielded wires, whichare soldered to the PC board.

morganw has kindly provided the information (and pictures) of thegeneration 3 connector. All of the remote functionality has been movedto a unique 4-pin square connector, and two additional contacts mayhave new signals on them.

Generation 3
The third generation iPod seems to use the same remote (internally andexternally) as the second generation, but with adifferent connector. It's still unknown if the microcontroller containsdifferent firmware (and so it may use a different protocol). Here's apicture of morganw's remote:

The remote uses a general-purpose Microchip 12C508A microcontroller (datasheet):

Two other unpopulated 5-pin IC's (IC2 and IC3) are on the buttonsideof the PCB; not sure what the purpose of these would be.

Schematic
I didn't trace the whole button-side of the schematic, but the rest ofit is pretty simple. Because we have the datasheet of themicrocontroller, the data output (TP7) and power(TP1) connections are well defined electrically.

Testpoints:
TP1 = IC1 pin 1, VDD (3.3v), connected to blue wire.
TP2 = (pulled up to VDD by R3)
TP3 = (pulled up to VDD by R2)
TP4 = SW2 (pulled up to VDD by R1)
TP5 = IC1 pin 5 (pulled up to VDD by R5)
TP6 = IC1 pin 6 (pulled up to VDD by R4)
TP7 = IC1 pin 7. Connected via 1K ohm resistor R7 to the green wire,the data out to the iPod.
TP8 = IC1 pin 8, VSS (ground), connected to yellow wire.
TP9 = [probably hold switch, SW1] (pulled up to VDD by R6)

IC2 (unpopulated) - connects to SW2 & SW4
IC3 (unpopulated) - connects to TP5, SW5

Communications Protocol
Electrical:
digital CMOS output (low = 0v, high = 3.3v) through a 1K ohm resistor,normally low.

Logical:
I've only measured the second generation protocol. I assume the 3rdgeneration is the same, but the code in the processor could be totallydifferent.

I measured about 108.75 uSec/bit, but my equipment wasn't the mostcapable; 9600 baud is 104 uSec/bit and it's a safe bet that this isactuallywhat's used, and jives with other peoples' measurements. Also, sincethemicrocontroller relies on an RC oscillator, it won't be totallyspot-on.My measurement could also have been messed up by a non-integral bittimebetween words (which I couldn't detect too well).

Upon pressing the button, the output goes high for about 45msec andthen sends the first version of the code. This high signal is probablyused to wake the iPod when sleeping.  After that, the remoterepeatsa pattern of waiting about 26msec with a low output, and then sendingthesecond version of the pattern (4msec), until the button is released. Iwasn't able to see if something different happened when the button wasreleased.

The first version of the code (transmitted when button is firstpressed)is:

where the xxx depends on which button is pressed.  The secondversionof the code follows this format:

Although my limited test equipment wasn't able to capture it, otherpeople report (thanks!) that a button release code is sent upon (guesswhat) button release.

This looks like the standard asynchronous protocol implementing a8-bit,no parity, 2 stop bit (8N2) protocol (or it could be also defined as8-bit,mark parity, 1 stop bit depending on how you look at it). This issimilarto the often-used 8N1 protocol, except there is an extra '1' betweencharacters;it's not known if the iPod actually needs this bit. Each group of 11bitsabove is classified composed of one start bit (a 0), followed by 8 databits (least significant bit first), then two hard-to-classify ones.Theseones could be either two stop bits, a stop bit and a mark parity bit,ora stop bit and one just-for-fun mark bit.

So, restated, the 3-byte message sent is:

There is an interesting quirk brought on by the fact that usualserialprotocols require the data line to be signaling high during the timeinbetweencharacters, but the iPod lowers the signal inbetween the 3-byte packets(although it does keep it high inbetween bytes). At least 4 high highbitsprecede valid data, which seems to be enough to satisfy the iPod'sUART.But, after the three bytes are sent, the data line quickly goes low.Thisisn't usual, and the iPod UART seems to interpret this string of zerosas any other UART would: a start bit, 8 bits of low data (0x00), andthena missing stop bit (a missing 1). The iPod firmware apparently dependson receiving this 0x00, but it's not known if it actually checks to seethat the stop bit is missing. If emulating the remote with a serialport,you should send the 0x00.

Example Microcontroller Code
I made a remote emulator using an Atmel AVR microcontroller. I knowthat doesn't sound like a reasonable thing to do -- after all, the iPodcomes with a perfectly suitable microcontroller -- but it's a goodstartat the design of a protocol translator. This only implements twobuttons- forward and reverse - but it's easily expandable.

The chip I picked is the Atmel ATtiny12-8PI. This is a small 8-pindevicewith 6 usable I/O pins, built-in 1.2 MHz RC oscillator (factorycalibratedto ±1% accuracy), 1K of flash memory, 32 bytes of RAM, and 64bytesof EEPROM. You probably noticed the lack of UART - instead I'm justbit-bangingthe output. It's ok for this single use, but when I eventually try tosimultaneouslyreceive data from my car's bus, I'll have to rewrite this code. Thisversionalso runs off of 5 volts and won't run at 3.3v, so it requires someinterfacecircuitry - you may want to use the 3.3v version, especially if youwantto use the iPod's power, or it's power output as a "connected" signal.

The schematic is pretty simple; I'll just describe how the 8 pins ofthe microcontroller connect:

• pin 1 - Reset - pull up to +5v with a 50K ohm resistor  (you canremovethe resistor if you program this as an input, but I haven't done thatyet)
• pin 2 - PB3 - reverse button. Connect with a normally-open pushbuttontoground. No pullup needed.
• pin 3 - PB4 - forward button. Connect with a normally-open pushbuttontoground. No pullup needed.
• pin 4 - ground. Besides the power supply, connecting this to the metalback of the iPod worked (instead of connecting to the digital ground inthe remote connector).
• pin 5 - PB0 - not used
• pin 6 - PB1 - not used
• pin 7 - PB2 - output. This needs to be reduced to 3.3 volts, so I useda series divider - this connects to a 220 ohm resistor, which goes tothecenter of the divider, which connects through a 330 ohm resistor toground.I used a 10k ohm resistor from the center to the actual ipod input.Thisdivider is far from optimal - it draws waay too much current (9milliamps!),which is almost enough to pull the output down to 3.7 volts, almosteliminatingthe need for a divider -- but those were the spare parts I had layingaround.
• pin 8 - +5 volts

Others' Work
Bernard Leach has been tackling the iPod side of the remoteinterface. His ipod portoflinux includes a driver for the remote, where he controls aUART. He sees 4 interrupts, one for each byte including the messed-up 0x00terminator. When four bytes are accumulated (there seems to be no synchronizationrulein software that specifies which byte is the first; hopefully the iPodfirmware does this), the bytes are passed to this translationcode:  (version 0.3 shown)

static int ipod_remote_buttons[] = {KEY_1, KEY_2,KEY_3,KEY_4, KEY_5};
static void ipod_remote_process_input(struct ipod_remote *ipod)
{
       static int last_button = 0;

       if ( ipod->data[2] ==0xf0) {
              input_report_key(&ipod->dev, last_button, 0);
       }
       else {
              int pos = ipod->data[2] - 0xf1;
              if ( pos >= 0  && pos < 5 ) {
                      last_button = ipod_remote_buttons[pos];
                      input_report_key(&ipod->dev, last_button, 1);
              }
       }
}