JP1 Remotes Forum Index JP1 Remotes


FAQFAQ SearchSearch 7 days of topics7 Days MemberlistMemberlist UsergroupsUsergroups RegisterRegister
ProfileProfile Log in to check your private messagesLog in to check your private messages Log inLog in

The Apple protocol revisited
Goto page 1, 2  Next
 
Post new topic   Reply to topic    JP1 Remotes Forum Index -> JP1 - Protocol Decodes
View previous topic :: View next topic  
Author Message
Barf
Expert


Joined: 24 Oct 2008
Posts: 1449
Location: Munich, Germany

                    
PostPosted: Sun Nov 29, 2020 5:57 am    Post subject: The Apple protocol revisited Reply with quote

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

Code:
{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:
{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?
Back to top
View user's profile Send private message Send e-mail Visit poster's website
The Robman
Site Owner


Joined: 01 Aug 2003
Posts: 21628
Location: Chicago, IL

                    
PostPosted: Sun Nov 29, 2020 2:26 pm    Post subject: Reply with quote

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!
Back to top
View user's profile Send private message Visit poster's website
3FG
Expert


Joined: 19 May 2009
Posts: 3407

                    
PostPosted: Sun Nov 29, 2020 3:11 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
The Robman
Site Owner


Joined: 01 Aug 2003
Posts: 21628
Location: Chicago, IL

                    
PostPosted: Sun Nov 29, 2020 4:19 pm    Post subject: Reply with quote

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!
Back to top
View user's profile Send private message Visit poster's website
Barf
Expert


Joined: 24 Oct 2008
Posts: 1449
Location: Munich, Germany

                    
PostPosted: Sun Nov 03, 2024 5:04 pm    Post subject: Apple protocol (re-)parametrization Reply with quote

Please have a look at this thread at RemoteCentral and give you view on the proposed re-parametrization, here or in that thead.
Back to top
View user's profile Send private message Send e-mail Visit poster's website
The Robman
Site Owner


Joined: 01 Aug 2003
Posts: 21628
Location: Chicago, IL

                    
PostPosted: Mon Nov 04, 2024 3:44 pm    Post subject: Reply with quote

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!
Back to top
View user's profile Send private message Visit poster's website
lynniemagoo



Joined: 24 Nov 2020
Posts: 5

                    
PostPosted: Mon Nov 04, 2024 8:28 pm    Post subject: I would vote for the Command Page approach. Reply with quote

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.
Back to top
View user's profile Send private message
The Robman
Site Owner


Joined: 01 Aug 2003
Posts: 21628
Location: Chicago, IL

                    
PostPosted: Tue Nov 05, 2024 9:11 am    Post subject: Reply with quote

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!
Back to top
View user's profile Send private message Visit poster's website
Barf
Expert


Joined: 24 Oct 2008
Posts: 1449
Location: Munich, Germany

                    
PostPosted: Wed Nov 06, 2024 6:51 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message Send e-mail Visit poster's website
lynniemagoo



Joined: 24 Nov 2020
Posts: 5

                    
PostPosted: Wed Nov 06, 2024 8:56 am    Post subject: Regarding Apple TV Reply with quote

The Robman wrote:
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/forums/viewpost.cgi?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.
Back to top
View user's profile Send private message
The Robman
Site Owner


Joined: 01 Aug 2003
Posts: 21628
Location: Chicago, IL

                    
PostPosted: Wed Nov 06, 2024 1:40 pm    Post subject: Reply with quote

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!


Last edited by The Robman on Sun Nov 10, 2024 9:40 am; edited 1 time in total
Back to top
View user's profile Send private message Visit poster's website
The Robman
Site Owner


Joined: 01 Aug 2003
Posts: 21628
Location: Chicago, IL

                    
PostPosted: Sun Nov 10, 2024 9:39 am    Post subject: Reply with quote

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!
Back to top
View user's profile Send private message Visit poster's website
Barf
Expert


Joined: 24 Oct 2008
Posts: 1449
Location: Munich, Germany

                    
PostPosted: Sun Nov 10, 2024 1:04 pm    Post subject: Reply with quote

The Robman wrote:
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).


Mfritze wrote:
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.
Back to top
View user's profile Send private message Send e-mail Visit poster's website
The Robman
Site Owner


Joined: 01 Aug 2003
Posts: 21628
Location: Chicago, IL

                    
PostPosted: Sun Nov 10, 2024 1:46 pm    Post subject: Reply with quote

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!
Back to top
View user's profile Send private message Visit poster's website
lynniemagoo



Joined: 24 Nov 2020
Posts: 5

                    
PostPosted: Thu Nov 14, 2024 8:22 pm    Post subject: Incorrect bit order Reply with quote

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.
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic       JP1 Remotes Forum Index -> JP1 - Protocol Decodes All times are GMT - 5 Hours
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


 

Powered by phpBB © 2001, 2005 phpBB Group
Top 7 Advantages of Playing Online Slots The Evolution of Remote Control