iPod controller Using Atmel Mega32
Have you ever imagined, “What does that cable I plug into my iPod every day actually do, and how do I take advantage of it for myself?” We did too, and that’s what we aimed to do with our 476 project. The iPod is, of course, the popular digital music player developed by Apple. The heart of the project is to use the Mega32 microcontroller to transmit and receive commands from the iPod using the built-in Dock Connector, as opposed to cracking the iPod open and wiring it up. The Dock Connector is the little port at the bottom of the iPod that you would normally connect a white USB or FireWire sync cable into. Commands that are currently implemented include play, stop, fast forward and other basic commands that allow the user to enjoy music from the iPod, as well as the ability to display the current track’s Title, Artist, and Album on an external LCD display.
This document is written for, primarily, the 476 graders! Just as importantly though, this document is intended for future 476 classes looking for interesting project ideas to tackle, because as far as we could tell, no one had attempted a project dealing with the iPod before. This document is also intended for those searching on the Internet for help on hacking their iPod.
At first we were worried about the feasibility of the project. We had decided early on that we wanted a project with obvious user feedback. After speaking to Bruce Land about the concept of an iPod dock, we decided that it would be our final project — what is more obvious than music starting or stopping?
A huge amount of our time involved researching the iPod communication protocol. The iPod’s communication protocol through the Dock Connector is not actually publicly available from Apple. However, thanks to the reverse engineering efforts by many hobbyists, there is a lot of information about the protocol (termed the “Apple Accessory Protocol”) available on the Internet.
It is possible that the protocol isn’t public due to the “Made for iPod” licensing program, which lets accessory makers in the “iPod ecosystem” connect to the iPod and display certain logos on their packaging after licensing. This could present certain legal issues, as it may be considered some form of protected intellectual property. However, as the protocol has been obtained through reverse engineering methods and not through a breach of contract, we do not anticipate this to be a big factor. Additionally, this is only an educational exercise and not in any way intended to be a commercially viable product.
The structure of our project is to have the Atmel Mega32 controller talk to the iPod in both sending and receive mode through the iPod’s Dock Connector. We would send commands over the serial pins on the Mega32 and receive on the appropriate iPod pins as well. We can verify that the commands worked by simply observing the iPod and checking to see that the iPod responded appropriately, e.g. with a volume change, skipped track, etc.
The only relevant standards that we use are 8-N-1 serial communication for talking to the iPod. The actual Apple Accessory Protocol is an Apple creation, so not quite a “standard” in a usual sense. Otherwise, we do not make any use of any other standards, such as IEEE or ISO standards. The iPod sends out responses for strings in ASCII format.
A large amount of work went into determining whether this idea was actually feasible. No one appears to have made any similar efforts in 476 final projects before, and though there is a similar idea in ECE 313, that course was designed around a standard CD player and controlled the player by shorting the buttons.
Important Pins on the iPod
|12||iPod RX; microcontroller transmits on this pin|
|13||iPod TX; microcontroller receives from this pin|
|21||iPod Accessory resistor: We use 500k|
It’s important to note which pins are the receive and transmit pins. On the pinouts.ru page, pin 13 is “Serial RxD,” which means serial receive from the iPod’s point of view. Mixing it up could confuse you unnecessarily for a few hours.
Once we had a pinout and what looked like usable, if unofficial, documentation of the protocol, we started looking at actual connectivity to the iPod. There were a few efforts done by other people to create their own docks, but these were not quite what we were looking for.
After a bit of searching, we managed to find a hobbyist’s website that had the actual iPod connectors available for sale. Even better, they also had a custom PCB available for sale to break out all of the individual signals from each of the pins, which was very useful because the pins themselves are rather small.
A short while later, we ended up discovering a second source for our PCB, which cost about the same as the original source but came with the dock connector pre-soldered, which was very useful as it was probably going to be a better soldering job than we could hope to accomplish by ourselves. Additionally, unlike the other source, it would ship within the United States. Using First Class Mail, we received our component in about 2 days (shipped on Thursday from CO, received on Saturday).
Next, we had to determine what commands it is we wanted to implement. We decided that the basic control functions we’re all familiar with – Play/Pause, Volume Up and Down, Skip Forward and Backward – must be implemented. We decided next that the “good to have” functions would be receiving data from the iPod and displaying it on the LCD screen, namely the current track’s Title, Artist, and Album.
All of the control details can be reverse engineered using a breakout board with a pass-through connector (in other words, a female iPod connector) and a commercial accessory that implements the same feature. All you’d have to do is plug the accessory into the pass-through connector, the pass-through into the iPod, and listen in on the serial pin.
It turns out that the iPod has a set of “modes” that it categorizes the functions in. The basic set of functions all belong in Mode 2, while the “good to have” receiving functions are all Mode 4. We also use functions from Mode 0 in order to change the iPod mode. This is important, because it changes how you expect to send and receive the data packets with the iPod.
Communication with the iPod is conducted over a serial protocol with a standard 8N1 setting at 19200 baud. This means that each packet has 10 bits. The packet starts with a low start bit, 8 bits (1 byte) of information, no parity, and a high stop bit. Each packet has a very ordered structure, which is as follows:
|Section||Size of Section (in bytes)||Value|
|Length of packet||1||Indicates the number of bytes for mode, command, and parameter|
|Mode||1||Mode for this command|
|Command||2||Command we’re sending or receiving|
|Parameter||0 to n||Optional – Some commands use this to supply more info|
|Checksum||1||(0x100 – [actual values of length + mode + command + parameter]) & 0xff|
This table is modified slightly for clarity from the iPodLinux page on the subject. This is the case for other tables that appear in this section as well.
Incidentally, each 8-bit chunk of data in a serial packet is transmitted in Little Endian mode. The serial protocol also idles at VCC-high when not sending.
The command codes for the functions we have selected are shown below:
Mode 0 Commands
|0x01 0x02||Switch to Mode 2|
|0x01 0x04||Switch to Mode 4|
Mode 2 Commands
|0x00 0x00||Button Release|
|0x00 0x02||Volume Up|
|0x00 0x04||Volume Down|
Mode 4 Commands
|Command||Parameter (in bytes)||Function|
|0x00 0x1e||0||Get Current Position in playlist|
|0x00 0x1f||4||Current Position Result|
|0x00 0x20||4 – current position||Get title of current song|
|0x00 0x21||string – unknown length||Title result|
|0x00 0x22||4 – current position||Get artist of current song|
|0x00 0x23||string||Artist result|
|0x00 0x24||4 – current position||Get album of current song|
|0x00 0x25||string||Artist result|
We were led to believe that Mode 2 commands needed to be sent 66 times per second until button release. However, from our experience this is not necessary. The command only needs to be sent once for the iPod to act upon it. Once the command is sent though, it is necessary to sent a button release command to indicate, well, the button’s release. Otherwise, the iPod is going to assume that the button is being held and will do what it normally does in such situations. For example, pressing Play without a Button Release will turn your iPod off (a tidbit that confused us for a little bit).
The Mode 4 commands that we implemented seem basic, but as far as we could tell, very few accessories currently on the market take advantage of the mode 4 commands. As far as we know, only iPod car-kits use the mode 4 commands; these car kits scroll similar information on the dashboard.
Mode 4 commands require that the iPod be switched into Mode 4 using a Mode 0 command, when the iPod will display “OK to disconnect” and cut off interaction with the physical on-iPod controls until the dock connector is removed. With exception of volume control, the standard Mode 2 commands are still accepted, even though it is currently in Mode 4. Annoyingly, switching into Mode 4 also pauses the currently playing track.
The current position numbering is transmitted in 4 bytes, with each byte in Big Endian notation. Do not confuse this with the Little Endian transmit inside the individual bytes. The returned strings for Title, Artist, and Album are null terminated.
|Power Supply for STK||1||Lab||$5|
|Dock Connector PCB||1||Purchased||$14|
For more detail: iPod controller Using Atmel Mega32
Leave a Comment
You must be logged in to post a comment.