On the old iPods, generally referred to here in the future as iPod Classic, there lives a tiny, undocumented chip called Mikey. It sits at the headphone output and performs only two functions: powering the Apple wired headset microphone and handling button presses from the three buttons. Despite these headphones and iPods having existed for nearly two decades, no one in the open source community has figured out the protocol Apple used for these buttons until now.
As [Hemant] discovered after finding a single archived blog post from 16 years ago about it, the chip is relatively simple by modern standards. Besides handling microphone bias, it sits on an I2C bus and monitors presses from the three buttons on the headset. Each button has its own resistive load, so a press from any of them drops the voltage on the line to a certain amount which the chip can read. The more involved part is a “chirp” that’s a sort of handshake between headset and iPod, which took a bit of work with a debugger that [Hemant] built into a custom Rockbox firmware.
With the chirp sorted out, [Hemant] built the feature into an existing version of Rockbox, and submitted the update to the Rockbox team for integration in future official builds. It’s a long overdue feature for those still using wired headphones and iPods from the turn of the century, but welcome. Some of those iPods are still working to this day, but only conditionally if they’re very cold.
Never had an iPod, hence this question: why does an mp3 player need a microphone?
Why does a cell phone need a camera, or even a touch screen, or even a color screen?
Camera: there are things of which one could take pictures. Screen? Similar to choosing between manual and automatice transmission in a car. Unhelpful.
It doesn’t. Unless it’s a Smartphone.
There was a “voice memos” function where you could record audio.
Thanks.
it was nice for being able to rip analog sources directly to the ipod. i never used it as a voice memo recorder, but i did use it to get white rabbit off of a jefferson airplane vinyl.
Same reason god needs a starship, of course.
Voice memos, stereo connection for example.
They had a voice recorder function IIRC. Not sure how good the quality was, don’t think they were as good as a minidisc for recording jam sessions, but probably still better than a cassette deck.
I used to have a microphone addon (30 pin connector) for my old iPod Nano (2G) that turned it into a handy audio recorder.
recorder function. same as a phone, you can record audio with it, not very high quality, but you can
I’ve always been curious about the signalling. Great post :-)
I’m reminded of my very first video recorder, a JVC HR7200EK. It came with a basic wired remote control, that had a long cable that was terminated with a mono 2.8mm audio jack. It had a nasty habit of misinterpreting button presses, so every now and then I’d press Play, and it would go into record instead. In the end I gave up using it as it was so fraught.
When I opened up the remote, I noticed that the PCB had just one component on it other than the buttons, a SIL resister package. Sure enough, each button press corresponded with a different resistance measured at the jack. I concluded that noisy contacts of the buttons, was probably the cause of such poor performance.
When I got into embedded software and hardware, I vowed never to use this technique to multiplex buttons. I wonder how reliable these Apple headphone buttons were?
The same method was / still is used for headphone buttons on Apple and Android phones until they removed 3.5mm jacks. They worked fine, don’t recall any issues with any I ever owned – but a headphone has a shorter cable so maybe less issues than your recorder?
It’d work better these days with higher precision resistors and faster ADC with more bits. As usual, poor connections and switch bounce causes problems, but that’s true no matter what you do.
Apple used its own protocol, that made their headsets incompatible with Android (and Apple devices incompatible with Android headsets). It went beyond that CTIA/OMTP nonsense.
I had a JVR with one of those remotes as well. Never had a problem with it.
The technique hasn’t gone anywhere, you still see it pop up. Repaired something the other day that had 9 buttons with a resistor for each. Didn’t look too closely to see what technique it used.
The usual way is to have a series of equal values which acts a voltage divider. To detect simultaneous presses each button has a resistor double the value of the previous, so it gives a “binary” input.
And believe or not, the resistive coding is used in some koreans cars to control windows open and close.
I was 1/2 of the 2 engineer team from TI that designed Mikey for Apple. It was was on a headphone line AND the Microphone line and therefor absolutely had be sub-audio. Since it was on the microphone line we named it Mickey so we would always remember that goal. Apple wanted it quick, cheap, and low low current. and we delivered! How did you find that name? I thought the name was strictly internal.
The article says that the name comes from firmware. Apple likes their vendors to use codenames or custom part numbers for off the shelf chips to (try to) throw off reverse engineering and keep repairs in house.
Thanks for the story :-)
I hasn’t realised that the button presses were encoded on the same lines as used for the microphone. Now it makes sense to use resistance encoding.
Also, I think that the JVC implementation must have been a particularly bad implementation, for button presses to be misinterpreted. Especially given that Record was the most likely error.
I do not understand the limitation reported on long-presses. Apple used a lot of long presses both in iPod and iPhone. Hold is text to speech (voice over) of current track. This was later repurposed for Voice Calling and Siri. Dubble click and hold is fast-forward. Triple click and hold is rewind.
From the quick read of the writeup, it’s a software limitation from how the specific driver was written and/or how rockbox (the linux os ported for ipods) handles the input. Of course the oem stock apple ipod os doesn’t have this limitation.
not too sure about the cold thing. living in alaska ive had situations where the hard drive could not function correctly if it was too cold. requiring an inside pocket to stay functional in the winter. these days it lives in its dock and is seldom used. i can barely read the screen anymore (not a problem with the screen, but my deteriorating near vision).
Rockbox functionality still needs a bit of work.
The current build no longer shuts down the iPod by holding down a button on the remote, which is good, but whatever was done to fix that, is now blocking repeat keypresses completely, so it is not possible to change volume beyond 1dB. And the play/pause button still does not work reliably.
Nevertheless, this is a very good start, and [Hemant]’s reverse engineering work deserves recognition.
I found the linked article to have a pungent smell of AI slop, so much that I stopped reading. I’d be curious to know whether I’m the only one to smell it.
You weren’t, I found it quite hard to read too, the tinymicros wiki article about the signalling was very interesting though,
I like screen, phisical keys, and long, long working time. I need podcast or book for weeks, not fom minutes
“after finding a single archived blog post from 16 years ago about it”
Just to save others some time, here’s the original blog post archived on IA, and the tinymicros.com wiki mirror. I checked and every image on the original post was (thankfully) saved, by the way.