The Apple protocol revisited

[Barf]

The Apple protocol, both in IrpTransmogrifier and in DecodeIR, goes

Code: Select all

{38.4k,564}<1,-1|1,-3>(16,-8,D:8,S:8,C:1,F:7,PairID:8,1,^108m,(16,-4,1,^108m)*){C=1-(#F+#PairID)%2,S=135}[D:0..255=238,F:0..127,PairID:0..255]

A RemoteCentral person wrote me that he has been encountering Apple devices using some other Ds. It turns out that if the D has an odd number of ones, the above definition will have the wrong C. So the suggestion is to change the definition to

Code: Select all

{38.4k,564}<1,-1|1,-3>(16,-8,D:8,S:8,C:1,F:7,PairID:8,1,^108m,(16,-4,1,^108m)*){C=1-(#D+#S+#F+#PairID)%2,S=135}[D:0..255=238,F:0..127,PairID:0..255]

which appears to be consistent with the Apple devices (and it also looks more symmetric).

Anyone like to comment on this? What is the UEI executor (01E0) doing?

[The Robman]

I just did a breakdown of the 3 known variants of the UEI executor, and the 1 JP1 homemade executor here:

http://www.hifi-remote.com/forums/dload ... e_id=26180

[3FG]

I agree that including D and S in the parity bit makes sense.

There are at least 3 UEI 01E0 executors, but all of them expect that the parity bit is explicitly included in the first variable byte. The executor doesn't calculate the parity bit. RMIR does the calculation, so we would need to change protocols.ini.
ETA: I didn't notice Rob's post before I posted.

[The Robman]

The newer 2 UEI executors include a vector call (017C) that I don't have documented, so I don't know what it does.

[Barf]

Please have a look at this thread at RemoteCentral and give you view on the proposed re-parametrization, here or in that thead.

[The Robman]

I think this is a bit like when we discovered there was a different way to read Panasonic and Sony signals where, even though the other way was probably "better", we have so many upgrades, etc using the JP1 method of reading the signals, that we didn't change anything.

Having said that, we only have 1 upgrade in the file section that uses the Apple protocol, so if we did change things, the impact wouldn't be that great.

[lynniemagoo]

Personally, I know the Wikipedia page does not list all the command pages but for sure 0 is the Pair Command Page, and 5 is the one we know as Device 229. However, the undocumented one (14) with Home and Play/Pause which we know as Device 238 also exists.

But I do defer to you guys and am happy using a custom AppleV2 protocol in scrutinizer locally.

[The Robman]

Hi Lyndel, what's the main change that you are suggesting, is it changing the first 2 bytes from being two 8-bit device codes, to one 11-bit "vendor code" and one 5-bit "command page" code? And are there any other sites that look at the codes this way?

What are the various codes, in both formats, that are known? And is there a complete code list of all the possibilities?

Looking at the Wiki page, I see that that code break down was introduced by Mfritze with this edit in April 2015 but he didn't cite any sources, and he's only edited 2 other articles.

[Barf]

From a decoding perspective, the difference is that bits 5,6,7 (starting count by 0) are fixed to 1 in the wiki version, free in the "Apple" version.

Mfrize appears to be active on the net, just google.

[lynniemagoo]

Hi Lyndel, what's the main change that you are suggesting, is it changing the first 2 bytes from being two 8-bit device codes, to one 11-bit "vendor code" and one 5-bit "command page" code? And are there any other sites that look at the codes this way?

What are the various codes, in both formats, that are known? And is there a complete code list of all the possibilities?

Using the previous protocol from scrutinizer, you can see all the known devices here.

With regard to other sites, I have not found any. I was happy to find this site as it narrows the Device (Command Page) down to 5 bits and has a fixed 11 bit Subdevice.

https://www.remotecentral.com/cgi-bin/f ... gi?1407322

Command Page 0 - Device 224

Command Page 5 - Device 229

Command Pager 14 (undocumented on Wiki) - Device 238

I'm OK with whatever you and Barf decide.

[The Robman]

I have taken the codes from that last page at RC and broken them down in the following spreadsheet. The Wiki pages confuses me because it doesn't seem to list the field types in the right order, regardless of whether I read the data left-to-right or right-to-left, and they don't list the Pairing device code.

They have them in the order:
Vendor, Command Page, Device ID, Command, Odd parity

Whereas I believe the correct order is:
Command Page, Vendor, Odd parity, Command, Paring device

Using your cross-reference of device codes to command page codes, I think I have figured out what you're asking for. I have also added the codes for command 00 from the Wiki page.

The following spreadsheet has 2 tabs, v1 for how we read the codes in JP1, and v2 for how I think you're asking us to read them. The only change that I made was to split the 11-bit vendor code into 2, as I don't like to have codes longer than 8-bits unless there's a good reason to. In this case, we get decimal codes of 63 and 16, rather than 1087.

http://www.hifi-remote.com/forums/dload ... e_id=26988

Please review the spreadsheet and tell me if I have got it right.

[The Robman]

Hi Lyndel, can you please review my spreadsheet and tell me if this is what you are looking for? If it is, I have no problem with us adopting it, if Graham and Bengt agree (as they'd have to do the actual work).

[Barf]

Hi Lyndel, can you please review my spreadsheet and tell me if this is what you are looking for? If it is, I have no problem with us adopting it, if Graham and Bengt agree (as they'd have to do the actual work).

While the Apple Remote uses the NEC IR protocol for the timing, the 32-bit data package is in a different format. It consists of two 16 bit LSB words.

For some reason, within those 16 bit words, the bit fields are listed in the wrong order in the table following. (Does "LSB" account for this??) So when he says that first 11 bit vendor, then 5 bits "Command page", it is the other way around, first the Command page (should be a shortened version of our [D]evice), then 11 bit vendor (corresponds to an extended version of our [S]ubdevice). Likewise, the content of the second 16 bit word should also be read in reverse order.

"Our classic" IRP reads {...}<...>(16,8,D:8,S:8,C,F,PairID,(...)*){S=135,C=...,....}, while Lyndels version reads {...}<...>(16,-8,D:5,S:11,C:1,F:7,PairID:8,1,^108m,(16,-4,1,^108m)*)
{C=...,S=1087}[...]

See also my previous post: there are three more hard "1"s in the Wiki version. I.e. every "Wiki-Apple" is an "Apple", but not the other way around.

Interestingly enough, the version preceeding Mfritze's edits was more-or-less identical to ours. Mfrize obviously changed it without citing valid sources. With this background, it does not feel justified to adopt the Wiki version as the more correct one.

So I tend to this alternative: In IrpProtocols.xml just add the Wiki version as an alternative version (like for example NEC-Shirrif). Apple should take preference over the new one, in the sense of prefer-overs. That way, no other changes are needed, in particular not to protocols.ini or Remotemaster. DecodeIR stays as relevant as possible, while rendering from Mfritze's parameters will be possible in IrScutinizer and IrpTransmogrifier.

[The Robman]

Whether to read IR stuff left-to-right or right-to-left is always confusing. I tend to read hex code left-to-right, but refer to the bits in a binary string right-to-left.

But regardless of how you read it, the Wiki page lists the components of the IR string in the wrong order, because it doesn't work L2R or R2L.

[lynniemagoo]

The bit ordering they state on that site is truly incorrect. I've tested the codes generated with an IP file that uses a fixed subdevice.

<irp:irp><![CDATA[
{38.4k,564}<1,-1|1,-3>(16,-8,D:5,S:11,C:1,F:7,PairID:8,1,^108m,(16,-4,1,^108m)*)
{C=1-(#D+#F+#S+#PairID)%2,S=1087}
[D:0..31=14,F:0..127,PairID:0..255]
]]></irp:irp>

Sorry for the fomatting.

Everything works perfectly.