Apple Aluminum Remote Codes
Update (5/17/12): A reader alerted me that the command code all Apple remotes is only 7 bit, with the last bit being a parity bit. If we then only use the 7 most significant bits, then there is no such thing as an “odd” code. All the codes for all versions of the remote are the same. I’ve summarized the new information here: [link]
Update: I’ve set up a separate page to gather all the relevant information regarding the Apple Remote in one place: [link]
Previous posts [link1, link2] discussed using the Apple aluminum remote as the IR remote of choice as in interface to Arduinto to control the volume in the Buffalo II DAC. In this post I to explain the meaning of the codes emitted by the remote.
REMOTE CODES
The codes from the remote are:
Up key: 238 135 011 089 Down key: 238 135 013 089 Left key: 238 135 008 089 Right key: 238 135 007 089 Center key: 238 135 093 089 followed by 238 135 004 089 Menu key: 238 135 002 089 Play key: 238 135 094 089 followed by 238 135 004 089
in Hex:
Up key: EE 87 0B 59 Down key: EE 87 0D 59 Left key: EE 87 08 59 Right key: EE 87 07 59 Center key: EE 87 5D 59 followed by EE 87 04 59 Menu key: EE 87 02 59 Play key: EE 87 5E 59 followed by EE 87 04 59
Keep in mind that these are the codes I extracted from my remote.
The remote codes are sequences of 4-bytes. The first two bytes I believe, represent a company code as they are the same for every single remote from Apple, including the original white remote. You can see evidence here where the codes for the white apple remote have been extracted.
For the white Apple Remote, the codes are:
Up key: EE 87 0B XX Down key: EE 87 0D XX Left key: EE 87 08 XX Right key: EE 87 07 XX Menu key: EE 87 02 XX Play key: EE 87 04 XX [same as center key and play key in Aluminum remote]
I use XX to indicate that this is different for each remote.
Notice that in order to maintain compatibility, the center key and the play key in the aluminum remote has the same codes [the second set of codes] as the play (center) key in the white remote
The fourth byte is the remote ID and it is used to pair the remote to a particular Apple device and it is different with up to 255 variations. These remotes have different IDs in order to support “PAIRING”. Pairing is a feature of Apple devices where you can set a device to listen only to a particular remote.
This ID can also be changed in the remote by pressing a combination of keys. This paper explains how this works and more. Basically you hold the menu key and the center key for 5 seconds and the ID increments by one. This is useful if you happen to have two remotes with the same ID and you need to pair them to different devices.
The third byte is the one that is mapped to the individual keys. Notice that the aluminum remote emits and additional set of codes in order to differentiate the center and play keys. In my code I ignore the first, second and fourth bytes and only use the third byte.
“ODD CODE”
There exist an “odd” set of codes for Apple Aluminum Remote that a reader found out while using remote code. The only difference with the “standard set” is that the third code is changed by the value of 1. I am not sure why this “feature”…
Update: Apparently, this set of code is not “odd” at all. Other readers have reported that their remotes emit this set of codes [link]
Update (6/5/11): the remote that comes with the Apple TV2 also emits this set of codes. I just tested mine and can confirm that this is the set of codes from the bundled remote. The Apple TV2 works with either remote (accepts both set of codes)
Up key: EE 87 0A 68 Down key: EE 87 0C 68 Left key: EE 87 09 68 Right key: EE 87 06 68 Center key: EE 87 5C 68 followed by EE 87 05 68 Menu key: EE 87 03 68 Play key: EE 87 5F 68 followed by EE 87 05 68
If you come across an apple remote that does not work, you can change the s/w to use this set of code instead. You can also enable the debug feature in the s/w in order to see what codes are emitted by the Apple remote.
This is the code section to change. For the “odd” codes change “case 11” to “case 10” and “case 13” to “case 12”
switch(IRkey){
case 11: // 11 is the up key, we will use for volume up
…
break;
case 13: // 13 is the down key, we will use for volume down
…
break;
…
Troubleshooting
If all fails, you can test if the remote is actually emitting IR signals by pointing the remote to a video camera. [Apple remote troubleshooting doc]
Apple Remotes: Aluminum and Original
Leave a Reply
Latest Comments
 | Chris Bowen on The Soekris R-2R DAC: Technica… |
 | wushuliu on Inside FiiO D3 |
 | sqicqb@gmail.com on BUILDING THE DIYINHK ES90… |
 | Prakit on INTRO |
 | CurtisBah on Musiland 03US Dragon |
 | CurtisBah on Projects Are Getting Better An… |
| free Cool wordpress on Dual-Mono TPA3122D2 AMP | |
 | tmRHYNC on Musiland Driver 2.X: Release… |
 | hung on BEAGLEBONE BLACK: BASE OPERATI… |
 | unixdeveloper on AKM Verita 4490EQ DAC |
 | David Kounkel on Soekris dam 1021 R-2R DAC ILLU… |
| PC Engines ALIX 2d2… on BEAGLEBONE BLACK: NAVIGATING T… | |
| Raspberry Pi B+ Digi… on Raspberry Pi B+ Digital A… | |
 | Chay Meredith on Musiland Dragon with True 32Bi… |
 | Marek on First One Amplifier Modul… |
When using the switch case, how would you write the sketch so it will keep in a high state when remote is continously pressed down?
My sketch using switch case, for ex. When volume up is pressed, will turn pin 7 high and then low. It only receives single button press though so I’m not sure how to make it work for continual but press until release. When button press release go back to low.
This is to drive logic to a l298 controlling volume motor pot. Since you want to be able to press down and hold vs. single button presses to increase or decrease volume.
Thanks
Are you using my code for the volume code? In my code the repeat codes will continually be read while the button is pressed.
How do I use your remote codes? I’m using the ir remote library from Ken’s site.
ex. Up key, I get this 77E1D08B and using the decimal equiv. seems to work 2011287691
case 2011287691:
digitalWrite(led8, LOW);
delay(500);
digitalWrite(led8, HIGH);
break;
I tried using your remote code but get this error:
integer constant is too large for ‘long’ type
Thanks
You can read all about it here: https://hifiduino.wordpress.com/apple-aluminum-remote/
Basically I read the 4-bytes in the pulse one at a time, but only use the third byte.
this is the sketch I’m trying. Only the decimal equivalent works. I tried your hex code and it does not detect the remote.
Thanks for your help!
#include
int RECV_PIN = 11;
IRrecv irrecv(RECV_PIN);
decode_results results;
int led7 = 7;
int led8 = 8;
void setup()
{
pinMode(led7, OUTPUT);
pinMode(led8, OUTPUT);
Serial.begin(9600);
irrecv.enableIRIn(); // Start the receiver
digitalWrite(led7, LOW);
digitalWrite(led8, LOW);
}
void loop() {
if (irrecv.decode(&results)) {
switch (results.value) {
case 0xEE870B59:
// case 238135011089:
//case 2011287691: //UP
digitalWrite(led7, HIGH);
delay(500);
break;
case 2011279499:
digitalWrite(led8, HIGH);
delay(500);
break;
}
digitalWrite(led7, LOW);
digitalWrite(led8, LOW);
irrecv.resume(); // Receive the next value
}
As I have another piece of diy equipment that also uses the ali Apple Remote I was thinking of having a go at molesting your code to read that fourth byte of the emitted IR code and incrementing one of the remote IDs by one to pair it. Any stumbling block you can think of before I attempt it?
Go right ahead. I don’t think there are stumbling blocks, but I have not experimented with the pairing of the remotes. There is code to echo the remote codes on the serial port, so enable that code to see what comes is actually emitted by the remote. All the relevant information should be in the posts. Good luck and let us know how it turns out.
swiss watches
human edited directory
interstate removalists
KittenWire Blog
Pressure Cooking Recipes
buy phentermine
LCD enclosure
CSR Classics Cheats