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

EFC codes don't work across remotes?
Goto page 1, 2  Next
 
Post new topic   Reply to topic    JP1 Remotes Forum Index -> JP1 - Beginners
View previous topic :: View next topic  
Author Message
landolfi



Joined: 12 Apr 2006
Posts: 48
Location: Chicagoland

PostPosted: Mon Feb 20, 2012 8:17 pm    Post subject: EFC codes don't work across remotes? Reply with quote

At the risk of sounding very stupid, which is possible because a coughing dog kept me up a lot of last night, I can't for the life of me figure out why a device upgrade I downloaded from the files section and incorporated into a remote image works on my 8811 remote but not on the Atlas 1055 3033. Sleep and all the PIP keys work on the 8811 implementing the upgrade, but none of those other functions work on the 1055 no matter where I assign them. I compared EFCs for those functions between the setups and they are identical with the exception of course that there are 5-digit EFCs in the 1055 image. Any ideas what could be going on here? Could it be that I have the wrong 5-digit EFCs for the 1055?
Back to top
View user's profile Send private message
eferz
Expert


Joined: 03 Jun 2010
Posts: 1078
Location: Austin, Texas

PostPosted: Mon Feb 20, 2012 8:41 pm    Post subject: Re: EFC codes don't work across remotes? Reply with quote

landolfi wrote:
At the risk of sounding very stupid, which is possible because a coughing dog kept me up a lot of last night, I can't for the life of me figure out why a device upgrade I downloaded from the files section and incorporated into a remote image works on my 8811 remote but not on the Atlas 1055 3033. Sleep and all the PIP keys work on the 8811 implementing the upgrade, but none of those other functions work on the 1055 no matter where I assign them. I compared EFCs for those functions between the setups and they are identical with the exception of course that there are 5-digit EFCs in the 1055 image. Any ideas what could be going on here? Could it be that I have the wrong 5-digit EFCs for the 1055?

EFC's are dependent on two things; the protocol and its respective fixed data. It is possible that your remote either doesn't have a compatible setup code for it OR the parameters in the upgrade isn't in line with the built-in setup code. Check the lookup tool to verify either case with the respective upgrade and your remote.

Incidentally, none of this should matter if you're using your JP1 cable instead of EFCs.
_________________
Remotes; JP1.2: Comcast URC-1067, JP1.3: Insignia NS-RC02U-10A, JP1.4 OARI06G, JP2.1: Cox URC-8820-MOTO (still trying to figure out how to make them self-aware.)
Back to top
View user's profile Send private message
landolfi



Joined: 12 Apr 2006
Posts: 48
Location: Chicagoland

PostPosted: Mon Feb 20, 2012 9:22 pm    Post subject: Reply with quote

I am using protocol 007E, variant 2 on both remotes. The vast majority of the codes work on the 1055, just PIP and Sleep functions don't (at least that I know of). I used the lookup tool to see what EFCs were there for sleep and tried all of them but nothing worked.

I put the RMIR file here
Back to top
View user's profile Send private message
landolfi



Joined: 12 Apr 2006
Posts: 48
Location: Chicagoland

PostPosted: Mon Feb 20, 2012 9:31 pm    Post subject: Re: EFC codes don't work across remotes? Reply with quote

eferz wrote:
Incidentally, none of this should matter if you're using your JP1 cable instead of EFCs.


I am using my JP1 cable to download the update--it's only when it didn't work that I started looking at EFCs. Is that what you mean?
Back to top
View user's profile Send private message
eferz
Expert


Joined: 03 Jun 2010
Posts: 1078
Location: Austin, Texas

PostPosted: Mon Feb 20, 2012 9:40 pm    Post subject: Reply with quote

landolfi wrote:
I am using protocol 007E, variant 2 on both remotes. The vast majority of the codes work on the 1055, just PIP and Sleep functions don't (at least that I know of). I used the lookup tool to see what EFCs were there for sleep and tried all of them but nothing worked.

I put the RMIR file here

Okay, so looking at your upgrade, PID "00 7E" is associated with setup code "1111" in the RMDU. If you use the Lookup Tool by Setup Code, you'll see this is not valid for the Atlas 5 3033. Looking at the name of the protocol "Pioneer Mix" by Protocol with the Lookup Tool, there aren't that many available to you. In fact, none of them have the proper parameters "170", "175", "90", "91" which matches the respective upgrade. The fixed data "AA A5 0A 25" in the RMDU indicates the order and values of the protocol parameters. This value is not found in the Lookup Tool. So, you would not be able to program it via EFCs and should use your JP1 cable instead to upload it.
_________________
Remotes; JP1.2: Comcast URC-1067, JP1.3: Insignia NS-RC02U-10A, JP1.4 OARI06G, JP2.1: Cox URC-8820-MOTO (still trying to figure out how to make them self-aware.)
Back to top
View user's profile Send private message
eferz
Expert


Joined: 03 Jun 2010
Posts: 1078
Location: Austin, Texas

PostPosted: Mon Feb 20, 2012 10:22 pm    Post subject: Re: EFC codes don't work across remotes? Reply with quote

landolfi wrote:
I am using my JP1 cable to download the update--it's only when it didn't work that I started looking at EFCs. Is that what you mean?

Ah, okay. If you're uploading the upgrade to your remote with the JP1 cable then don't worry about the EFCs. Those are computed with a relationship of the protocol, fix data, and the OBC. You should only have to pay attention to them if you're trying to tediously reprogram your remote by pressing buttons on it.

As for the upgrade, I see this is one of those which makes RMDU barf if you don't rename the variant protocol that it isn't using. The first issue is that the Pioneer Mix has two variants #2 and #3, and for some reason, it appears that RM is loading the wrong variant with this upgrade thereby causing it to act wonky.

Apparently, the original upgrade, Pioneer PDP-5080HD says that it should be using variant three not two. This can be seen by opening up the RMDU with notepad.

Quote:
Description=Pioneer PDP-5080HD
Remote.name=Atlas 5 Day URC-1055 JP1.3 3033
Remote.signature=30333033
DeviceType=Cable
DeviceIndex=0
SetupCode=0
Protocol=00 7E
Protocol.name=Pioneer MIX

Protocol.variantName=3
ProtocolParms=170 175 90 91 94 null
FixedData=AA A5 25 85 00 0A

So, therefore to open up this protocol appropriately in RM, you'll need to go into its protocol.ini file and change the header of variant 2

Code:
[Pioneer MIX]
PID=00 7E
AlternatePID=01 7F
VariantName=2
DefaultCmd=00 00

to
Quote:
[Pioneer MIX2]
PID=00 7E
AlternatePID=01 7F
VariantName=2
DefaultCmd=00 00

and make sure the other entry for variant 3 is correct.
Code:
[Pioneer MIX]
PID=00 7E
VariantName=3
AlternatePID=01 7F

Otherwise, RMDU acts all wonky when opening up the Functions tab of the upgrade. The upgrade requires three prefix OBC's 90, 91, 94 this is addressed in variant 3 of Pioneer Mix, whereas variant 2 will only accept two; 90 and 91. Since the PIP and Sleep commands require OBC prefix 94, your remote is probably not sending the correct IR signals. I think it is because it is loading it with the incorrect protocol variant. Not sure whom to report this issue to because I'm not sure where the root cause of it the lies, i just know how to work around it.

Hopefully, one of the senior experts will read this and report the issue to the appropriate party.

Edit: Another way to get this to work is to place the entire section of Pioneer Mix variant 3 ahead of the variant 2's section. It appears that RM will default to the first parsed variant instead of opening whichever is listed in the RMDU file.
_________________
Remotes; JP1.2: Comcast URC-1067, JP1.3: Insignia NS-RC02U-10A, JP1.4 OARI06G, JP2.1: Cox URC-8820-MOTO (still trying to figure out how to make them self-aware.)
Back to top
View user's profile Send private message
vickyg2003
Site Admin


Joined: 20 Mar 2004
Posts: 7050
Location: Florida

PostPosted: Tue Feb 21, 2012 2:52 am    Post subject: Reply with quote

landolfi wrote:
I am using protocol 007E, variant 2 on both remotes. The vast majority of the codes work on the 1055, just PIP and Sleep functions don't (at least that I know of). I used the lookup tool to see what EFCs were there for sleep and tried all of them but nothing worked.

I put the RMIR file here



Since you are using 007e variant 2 on both upgrades, its odd that the buttons don't work on one of the two remotes.

I downloaded your RMIR file and tried to look at the tv/1111 but when I get to the functions page on the device I can't see the PIP functions and sleep function, even though I can see the PIP functions assigned to the buttons on the button sheet.

So I think that somehow your upgrade is corrupt, but it could be that my RMIR file is out of date, I am using my "traveling" laptop and don't have up to date tools.

One thing I can tell you is that RM HATES blank lines in your rm and km files, so a "cleanup" can help with many problems
Back to top
View user's profile Send private message Visit poster's website
eferz
Expert


Joined: 03 Jun 2010
Posts: 1078
Location: Austin, Texas

PostPosted: Tue Feb 21, 2012 3:38 am    Post subject: Reply with quote

vickyg2003 wrote:
I downloaded your RMIR file and tried to look at the tv/1111 but when I get to the functions page on the device I can't see the PIP functions and sleep function, even though I can see the PIP functions assigned to the buttons on the button sheet.

Vicky, try swapping the positions of Pioneer Mix variant 2 and 3 in your protocol.ini file. This will allow RMIR to register the correct variant for this protocol. The missing functions will be revealed. However the "prefix command" column will show "255" for all the values that should be "94" . To fix that, he just needs to add "94" to Cmd3 (OBC) in the setup tab.

Code:
Pdev-Pcmd|Dev-Obc  |Command
170-94   |175-112  |sleep    
170-94   |175-36   |pip freeze   
170-94   |175-32   |pip split   
170-94   |175-37   |pip swap   
170-94   |175-39   |pip swap

Btw, this quirkiness was already discovered earlier in this thread, "RM 2.0x & strange Function tab display problem." I suspect this will be a problem for all Pioneer Mix upgrades which requires more than two prefix commands. Since the default, variant #2, only address two possibilities. Whereas, variant #3 allows up to four.

vickyg2003 wrote:
So I think that somehow your upgrade is corrupt, but it could be that my RMIR file is out of date, I am using my "traveling" laptop and don't have up to date tools.

I also have a copy of Remote Master 1.98 and it still does it with that version. So, this issue was introduced prior. Just nobody has identified the problem till recently.
_________________
Remotes; JP1.2: Comcast URC-1067, JP1.3: Insignia NS-RC02U-10A, JP1.4 OARI06G, JP2.1: Cox URC-8820-MOTO (still trying to figure out how to make them self-aware.)
Back to top
View user's profile Send private message
vickyg2003
Site Admin


Joined: 20 Mar 2004
Posts: 7050
Location: Florida

PostPosted: Tue Feb 21, 2012 3:55 am    Post subject: Reply with quote

eferz wrote:
Btw, this quirkiness was already discovered earlier in this thread, "RM 2.0x & strange Function tab display problem." I suspect this will be a problem for all Pioneer Mix upgrades which requires more than two prefix commands. Since the default, variant #2, only address two of them.


I missed that. I haven't been reading the forum lately. I have limited internet connectivity, and everytime I log in, the number of new posts have been daunting with all those old threads being revived, so I haven't even been trying. to keep up.

I'm not quite sure what I'm seeing. It certainly appears the a protocol upgrade is being added. I didn't read the RAW Data to see if the variant 2 is actually being added or not.

I'll go back and read the thread. Thanks for the heads up.
Back to top
View user's profile Send private message Visit poster's website
eferz
Expert


Joined: 03 Jun 2010
Posts: 1078
Location: Austin, Texas

PostPosted: Tue Feb 21, 2012 4:13 am    Post subject: Reply with quote

vickyg2003 wrote:
I haven't been reading the forum lately. I have limited internet connectivity, and everytime I log in, the number of new posts have been daunting with all those old threads being revived, so I haven't even been trying. to keep up.

Sorry, that is my fault. I started addressing some of the older issues in the Code Search forum. Then Rob asked me to start moving threads into the Code Search (Close) which people have said the upgrade works. Only I sort of mistook that as "Let's start answering/closing all of the threads". Long story; short, the Code Search forum no longer has any threads older than 30 days and I learned quite a bit in the process.

vickyg2003 wrote:
I'll go back and read the thread. Thanks for the heads up.

You're welcome. Glad to help.
_________________
Remotes; JP1.2: Comcast URC-1067, JP1.3: Insignia NS-RC02U-10A, JP1.4 OARI06G, JP2.1: Cox URC-8820-MOTO (still trying to figure out how to make them self-aware.)
Back to top
View user's profile Send private message
vickyg2003
Site Admin


Joined: 20 Mar 2004
Posts: 7050
Location: Florida

PostPosted: Tue Feb 21, 2012 7:30 am    Post subject: Reply with quote

Sorry, didn't mean that to come out as sounding like a criticism. It was late and I wasn't thinking quite clearly. It was good of you to create all those upgrades. Thats a tremendous amount of work.

Again thanks for the link to the thread, I'm trying to get my head around the issue, the 007E protocol has always been confusing. I finally got my head around it, but apparently the RM software doesn't quite handle that protocol since all the code was added to allow protocol editing.
Back to top
View user's profile Send private message Visit poster's website
eferz
Expert


Joined: 03 Jun 2010
Posts: 1078
Location: Austin, Texas

PostPosted: Tue Feb 21, 2012 11:27 am    Post subject: Reply with quote

vickyg2003 wrote:
Sorry, didn't mean that to come out as sounding like a criticism. It was late and I wasn't thinking quite clearly. It was good of you to create all those upgrades. Thats a tremendous amount of work.

No, you're fine. I didn't acknowledge your response as criticism. That was me accepting responsibility for driving you away. Which was not intended.

vickyg2003 wrote:
Again thanks for the link to the thread, I'm trying to get my head around the issue, the 007E protocol has always been confusing. I finally got my head around it, but apparently the RM software doesn't quite handle that protocol since all the code was added to allow protocol editing.

With all due respect, I'm not quite sure you get it yet. So, without me trying to reiterate my previous posts, let me juxtapose a few pictures for you. The following will be the result of the two variants in the protocol.ini file before one another. On the left side (or top) the Pioneer Mix variant 2 is before 3 while the right side (or bottom) will be Pioneer Mix variant 3 before 2.

Quote:
This is what the DUE Setup tab from RMIR looks like while importing the RMDU file.

Quote:
This is what the DUE Functions tab from RMIR looks like while importing the RMDU file.


Quote:
This is what the Setup tab from RM looks like while opening the RMDU file.

Notice that the function tab is selected on the left/top, but RMDU refuses to draw it.

I personally believe the problem has nothing to do with the device upgrade or the protocol, but how RM/RMIR "decides" which variant to associate it. Here is the original RMDU file btw (http://www.hifi-remote.com/forums/dload.php?action=file&file_id=5416)
_________________
Remotes; JP1.2: Comcast URC-1067, JP1.3: Insignia NS-RC02U-10A, JP1.4 OARI06G, JP2.1: Cox URC-8820-MOTO (still trying to figure out how to make them self-aware.)
Back to top
View user's profile Send private message
landolfi



Joined: 12 Apr 2006
Posts: 48
Location: Chicagoland

PostPosted: Tue Feb 21, 2012 4:31 pm    Post subject: Reply with quote

You guys are amazing! Of course that was the problem. Good to know that for the time being, at least, I need to check the RMDU against what RMIR is showing. Thanks for your help!
Back to top
View user's profile Send private message
eferz
Expert


Joined: 03 Jun 2010
Posts: 1078
Location: Austin, Texas

PostPosted: Tue Feb 21, 2012 6:25 pm    Post subject: Reply with quote

landolfi wrote:
You guys are amazing! Of course that was the problem. Good to know that for the time being, at least, I need to check the RMDU against what RMIR is showing. Thanks for your help!

Heh, heh. When you say, "You guys...", whom are you referring to exactly? Because our assessments conflict with one another. So, both Vicky and I cannot be right.
_________________
Remotes; JP1.2: Comcast URC-1067, JP1.3: Insignia NS-RC02U-10A, JP1.4 OARI06G, JP2.1: Cox URC-8820-MOTO (still trying to figure out how to make them self-aware.)
Back to top
View user's profile Send private message
landolfi



Joined: 12 Apr 2006
Posts: 48
Location: Chicagoland

PostPosted: Tue Feb 21, 2012 9:55 pm    Post subject: Reply with quote

I am and was impressed with how thoroughly you both know this complex subject. I don't pretend to understand the particulars, but I think maybe the controversy centers on root cause? What worked was modifying protocols.ini as you said. I am still puzzled why this works with protocol variant 2 on the 8811.
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 - Beginners 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
Get Smart! the band's official homepage Rockabilly Central