A while back, I came across an article on the web discussing the Apple IR Remote Format and specifically the protocol.

[Link: en.m.wikipedia.org]

IRScrutinizer currently can decode and generate the Apple format. However, it does so using a Device ID that is 8 bits in length. I've previously posted codes on this site that call out Device ID 229 and Device ID 238. Pairing Device would be Device ID 224.

I've taken the protocol specification from IR Scrutinizer and refined it to create an AppleV2 format as well as an AppleV2-NoDefaultDevice.

As of now, I have a text file that contains both of these protocol definitions. What I've not done is to update the uei-executor section of each.

I will email you my text file for testing locally. For consistency with the above article, I'm wondering if we should replace Apple or add an AppleV2 deriviative (one of 2 new protocol defintions) to simplify Apple to match the format outlined in the article.

My preference is the AppleV2-NoDefaultDevice as upon a decode you can immediately see which device is being used whereas with AppleV2 protocol definition, if device = 14, it is not displayed.

Here are 2 codes that can be used to vet out the new protocol definitions (Note the 229 and 238 as I used the original Apple Protocol to generate these signals).

229_002_CURSOR_DOWN
0000 006C 0022 0002 015B 00AD 0016 0041 0016 0016 0016 0041 0016 0016 0016 0016 0016 0041 0016 0041 0016 0041 0016 0041 0016 0041 0016 0041 0016 0016 0016 0016 0016 0016 0016 0016 0016 0041 0016 0016 0016 0016 0016 0041 0016 0016 0016 0016 0016 0016 0016 0016 0016 0016 0016 0016 0016 0041 0016 0041 0016 0041 0016 0041 0016 0041 0016 0041 0016 0041 0016 05CB 015B 0057 0016 0E6C

238_047_PLAY_PAUSE
0000 006C 0022 0002 015B 00AD 0016 0016 0016 0041 0016 0041 0016 0041 0016 0016 0016 0041 0016 0041 0016 0041 0016 0041 0016 0041 0016 0041 0016 0016 0016 0016 0016 0016 0016 0016 0016 0041 0016 0041 0016 0041 0016 0041 0016 0041 0016 0041 0016 0016 0016 0041 0016 0016 0016 0016 0016 0041 0016 0041 0016 0041 0016 0041 0016 0041 0016 0041 0016 0041 0016 04C7 015B 0057 0016 0E6C

To maintain backward compatibility with older devices such as the iPod Hi-Fi, the aluminum Apple Remote does not replace the existing IR code for Play/Pause/Select. Instead, to allow newer devices to distinguish between the separate Select and Play/Pause buttons, it sends two IR codes for each press of those: a prefix code (0x2e and 0x2f, respectively), followed by the original Play/Pause code (0x02). Older devices ignore the prefix code and thus interpret either button as Play/Pause, while newer devices interpret both codes and use them to determine which button is being pressed.

It turns out that the ATV units don't require 0x2E or 0x2F to be sent as code #1 in a 2 code sequence 0x2E + 0x02 or 0x2F + 0x02.

I have made some minor modifications so that it is a complete irp protocol file, checked in at [Link: raw.githubusercontent.com] . To use, just download to anywhere on your computer, and select it as "secondary" (Options -> IRP Protocol database -> Select secondary... and restart the program.)

Background: The protocols in IrScrutinizer/IrpTransmogrifier are not authored by me. The have developed more-or-less continuously the last 20 years in the JP1 community (and also others). In particular, DecodeIR should be mentioned. In particular, they are used in the RMIR/RemoteMaster program. For this reason, I think that changes in the protocol definitions should be made only with considerable afterthought, in order not to break existing data collections, or other programs, like RMIR/RemoteMaster. The existing protocol definitions are far from perfect, but we know what the quirks are and how to live with them.

Also, I do not consider the linked Wikipedia article to be an authoritative source. It is Wikipedia policy WP:NOR not to base articles on original research, but exactly that appears to be the case here. No real source is given for the main claims. So, from that point of view, it is hard to claim that the wiki parametrization is more justified than the one presently used.

I have really no stakes in the Apple protocol. I am open to people's opinions and arguments. Let's hear from you! I have posted in the JP1 forum, [Link: hifi-remote.com]

Thanks for all the support.

I dropped you a private note via email.

Lyndel