JP1 Remotes

[Barf]

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

[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.php?action=file&file_id=26180
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!

[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.
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!

[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.
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!

[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.
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!

[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]

[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.php?action=file&file_id=26988

Please review the spreadsheet and tell me if I have got it right.
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!

[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).
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!

[Barf]

[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.
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!

[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.