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
File SectionFile Section File SearchFile Search Lookup ToolLookup Tool WikiWiki

Comcast Keymover disabled?
Goto page Previous  1, 2, 3, 4
 
Post new topic   Reply to topic    JP1 Remotes Forum Index -> Non-JP1
View previous topic :: View next topic  
Author Message
3FG
Expert


Joined: 19 May 2009
Posts: 3367

                    
PostPosted: Sun Mar 06, 2011 2:33 pm    Post subject: Reply with quote
Quote:
I think if we did the math that there are duplicate Hex values in the first 66536 EFC's and that there are more EFC's beyond this 1000 range that we are talking about that are needed to get a complete set of the 65536 hex values.

In my opinion, the EFC versus Hex data situation is simpler than you think. To demonstrate that, here's a complicated long-winded explanation that introduces new terms and notation. Rolling Eyes Seriously, we tend to use the same term for related but different concepts, which I find impairs my understanding.

Let's start with Hex data, by which we mean the data that is accepted by protocol executors. Some executors take one byte of Hex data and some need two. One byte Hex data can span the range from $00-$FF, while two byte data can run from $00 to $FFFF. (I'll use numbers in hexadecimal notation to represent Hex data, H1 referring to one byte data and H2 for two byte data. I'll use decimal notation to represent EFCs.)

UEI wanted to hide the actual OBC values used by their remotes so they introduced a transform, which I'll call T3 (T5 came later). This transform doesn't yield EFC3 directly, but instead gives a number I'll call P3, where P might mean primitive. T3 converts the 256 possible H1 values to unique P3 numbers which are in the range 0-255. There is an inverse transform (T3') that converts P3 to H1. T3 was designed so that there are no duplicate values. Mathemeticians would say that there is a one-to-one mapping between the values H1 and P3.

EFC3 is almost the same as P3. UEI just randomly added 0, 256, or 512 to the P3 numbers to get EFC3. Remotes which use 3 digit EFCs can of course only accept values between 000 and 999. The process to convert these to H1 is to first calculate P3 (by subtracting 0, 256, 512, or 768 so that the remainder is in the range 0 to 255) and then apply T3' to P3.

So there are multiple EFC3 values (049, 305, 561, 817) which can give a particular H1 value (for this example, $6C), but only 1 P3 value (049) corresponds to $6C.

T5 is similar but the actual equation used in the transform is different because it works with two byte data. P5 can range from 0 to 65535, while EFC5 is either P5 or P5+65536. Again, there is one and only one value of H2 for a particular value of P5. To go from EFC5 to H2, first subtract 65536 if EFC5>65535, and then apply T5'.

It is worth noting that a P3 value of 49 corresponds to H1=$6C, but a P5 value of 49 corresponds to H2=$59F4. The lower byte of H2 is not the same as H1. So how does a 5 digit remote know if 00049 means $6C ($006C) or $59F4? By convention, EFCs of 00999 and less are treated as EFC3, meaning the EFC is converted to P3 and then transformed to H1. EFCs higher than 00999 are treated as EFC5, converted to P5, and then transformed via T5' to H2. The user can specify P5 values in the range 0 to 00999 by entering EFC5 values in the range 65536 to 66535.

For remotes designed after the dust associated with 5 digit remotes settled, keymoves are stored as Hex data, so the user interface of the remote and our tools chooses the appropriate conversion at the time of EFC entry.

Unfortunately, remotes like the Comcast 1067A or the URC-9960 store keymoves as EFC5 in the limited range from 0 to 65535. There is no way to denote P5 values between 0 and 00999, and so the H2 that corresponds to those P5 values can't be sent by the remote.
Back to top
View user's profile Send private message
vickyg2003
Site Admin


Joined: 20 Mar 2004
Posts: 7073
Location: Florida
                    
PostPosted: Sun Mar 06, 2011 3:38 pm    Post subject: Reply with quote
Well it sounds like its gelled for you, hopefully I'll come to grips with this soon, as I've come a long way since the beginning of this discussion. Confused

Then of course there are the other remotes, Atlas 1054 and the urc-6131? That can't do EFC style keymoves at all and require an upgrade so that we can do the keycode style keymoves
_________________
Remember to provide feedback to let us know how the problem was solved and share your upgrades.

Tip: When creating an upgrade, always include ALL functions from the oem remote, even if you never plan on assigning them to a button. Complete function lists makes an upgrade more helpful to others.
Back to top
View user's profile Send private message Visit poster's website
3FG
Expert


Joined: 19 May 2009
Posts: 3367

                    
PostPosted: Sun Mar 06, 2011 5:28 pm    Post subject: Reply with quote
I have one completely unmodded 6131 (no 6 pin header or EEPROM). It seems to accept EFC keymoves without difficulty. Of course, like other 3 digit EFC remotes, the keymoves only work with protocol executors that take one byte of Hex data. So Combo executors like Sony 12/15/20, or the default Audio 1023 (Pioneer 3Dev) typically won't work, because two bytes of Hex data are needed, and there is no way to specify the second byte. I suppose that other 3 digit EFC remotes work in the same way, and cannot do most keymoves for two byte executors.
Back to top
View user's profile Send private message
vickyg2003
Site Admin


Joined: 20 Mar 2004
Posts: 7073
Location: Florida
                    
PostPosted: Mon Mar 07, 2011 1:17 am    Post subject: Reply with quote
hmm, I went back and read all the posts that made me think that this was not working at all on the 6131 and the Atlas 1054, and it appears that I was reading something into them that wasn't there. These EFC keymoves use 2 bytes but can only handle 3 digit EFCs. People kept telling me I had to do an upgrade and then do keycode style keymoves, but those were all two byte hex, and I was in a state of total confusion back then. When combined with all the talk about the 6131 extender keymoves being a different format I can see how I got so confused.
_________________
Remember to provide feedback to let us know how the problem was solved and share your upgrades.

Tip: When creating an upgrade, always include ALL functions from the oem remote, even if you never plan on assigning them to a button. Complete function lists makes an upgrade more helpful to others.
Back to top
View user's profile Send private message Visit poster's website
Display posts from previous:   
Post new topic   Reply to topic       JP1 Remotes Forum Index -> Non-JP1 All times are GMT - 5 Hours
Goto page Previous  1, 2, 3, 4
Page 4 of 4

 
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