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

Pioneer MIX with more than 2 possible prefix commands?
Goto page 1, 2  Next
 
Post new topic   Reply to topic    JP1 Remotes Forum Index -> JP1 - General Forum
View previous topic :: View next topic  
Author Message
Vyrolan



Joined: 24 Aug 2012
Posts: 168
Location: Chicago, IL

                    
PostPosted: Thu Sep 20, 2012 11:11 pm    Post subject: Pioneer MIX with more than 2 possible prefix commands? Reply with quote

My Pioneer plasma uses more than 2 prefix commands for its Pioneer MIX. All but two buttons uses only two prefix commands, but the final two buttons use a third prefix. The buttons are more specialized ones that accomplish stuff also possible in the menus (they select the screen size and the video preset).

I saw mention in this ancient thread of a Pioneer MIX with support for up to 4 prefix commands, but that thread mentions it was not supported in RMIR. I'm guessing this never changed, since I still don't see it in the latest build.

Does anyone know what needs to be done to support this protocol in RMIR? I don't particularly care if I lose those two buttons since I never use them, but for completeness sake I'd like to see them work. (Yes, I know I could do another small upgrade and use key moves and that may even end up smaller than a huge protocol upgrade. This is more of a theoretical exercise than a practical problem.)

(Sorry I don't have a file to post with the learns, but I think most of the experts would understand what I'm talking about... If you care for more details, I've dev1=170 and dev2=171. The dev1 OBCs seen as prefix are mostly 90 and 91, but those final two buttons have 94 as prefix.)
Back to top
View user's profile Send private message
Vyrolan



Joined: 24 Aug 2012
Posts: 168
Location: Chicago, IL

                    
PostPosted: Sat Sep 22, 2012 9:45 pm    Post subject: Reply with quote

Bumpity bump.
Back to top
View user's profile Send private message
vickyg2003
Site Admin


Joined: 20 Mar 2004
Posts: 7073
Location: Florida

                    
PostPosted: Sun Sep 23, 2012 5:53 am    Post subject: Reply with quote

There are a few ways to make this work.


1) The easiet way is to create a helper upgrade. A helper upgrade is a small setup code that has the extra functions. These can then be used with keymoves, to access the additional functions. Keymoves "remember" the setup code, so the setup code doesn't have to be assigned to a device key. The setup code needs to set up the fixed data for the keymove, and in some of the transitional remotes (when UEI was transitioning between 3 digit and 5 digit EFCs) you may need to assign the functions to buttons to do "key" style keymoves. This seems to confuse novice users.

2) In IR I'd just create a KM sheet for use. But RMIR can't open the Pioneer Mix 4x4x4 upgrade, because its an "unknown" protocol. So I'd create a RM "Manual protocol" upgrade from the km data. Its more or less a copy and paste operation.
*You copy the Protocol upgrade from KM
* In RM,, Create a new manual protocol.and import the clipboard
* On the "Devices Data" tab setup simple translators (LSB-Comp) for all the devices and command bytes. Set the Command index to 0. Then click OK.
* Copy the functions, from KM to RM
* Copy the functions hex, from KM to RM
* Assign the functions to the buttons.


3) The best option is to modify protocols.ini with translaters and set up a Pioneer mix 4x4x4 protocol. This is above my "pay grade". I don't understand protocols.ini well enough to set up a translater. If you do it this way, the protocols.ini modifications must be available to other users for the setup code to be able to use the RM file. So this translator needs to be submitted to 3FG or whoever is maintaining protocols ini. for inclusion in the next release.
Back to top
View user's profile Send private message Visit poster's website
The Robman
Site Owner


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

                    
PostPosted: Mon Sep 24, 2012 10:51 am    Post subject: Reply with quote

Which remote are you trying to program? If your remote already has variant:3 of the Pioneer MIX protocol instealled, RM should automatically present you with the 4-CMD version (even though it doesn't call it that). If you see Cmd3 and Cmd4 as an option, you've got the right version.

That being said, I do think we should add "Pioneer MIX 4-Cmd" as an option to match the option that's already in KM. I also think the 4-Cmd version should be the one that's presented when MIX is selected for a remote that doesn't have any version of the $007E protocol installed.

To make the latter happen, variant:3 needs to be moved before variant:2 in protocols.ini One side affect of doing this, however, is that if a remote has variant:2 of $007E but doesn't have it labeled as such in the RDF, RM will always supply a protocol upgrade. I just verified this by selecting the 15-1994 remote. I then edited the RDF for the 15-1994 and replaced the 007E entry in [Protocols] with 007E:2 and verified that RM now presents the old version with no protocol upgrade when MIX is selected and it does provide a protocol upgrade when 4-Cmd is selected.

To add 4-Cmd as an option, you would need to clone the variant:3 entry in protocols.ini and rename it "Pioneer MIX 4-Cmd".
_________________
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
Vyrolan



Joined: 24 Aug 2012
Posts: 168
Location: Chicago, IL

                    
PostPosted: Mon Sep 24, 2012 1:50 pm    Post subject: Reply with quote

The Robman wrote:
Which remote are you trying to program?

Well I'll want to do it for a few, but this time it was a RCA RCRP05B.

The Robman wrote:
If your remote already has variant:3 of the Pioneer MIX protocol instealled, RM should automatically present you with the 4-CMD version (even though it doesn't call it that). If you see Cmd3 and Cmd4 as an option, you've got the right version.

Here's the only Pioneer options I have:


If I pick Pioneer MIX, then it only shows me two possible prefix commands:


The Robman wrote:
To make the latter happen, variant:3 needs to be moved before variant:2 in protocols.ini One side affect of doing this, however, is that if a remote has variant:2 of $007E but doesn't have it labeled as such in the RDF, RM will always supply a protocol upgrade. I just verified this by selecting the 15-1994 remote. I then edited the RDF for the 15-1994 and replaced the 007E entry in [Protocols] with 007E:2 and verified that RM now presents the old version with no protocol upgrade when MIX is selected and it does provide a protocol upgrade when 4-Cmd is selected.

To add 4-Cmd as an option, you would need to clone the variant:3 entry in protocols.ini and rename it "Pioneer MIX 4-Cmd".


If I change the protocols.ini as you suggest, then it does change to the 4-Cmd version with I pick Pioneer MIX. I guess the RCA RCRP05B has only the 2-cmd preinstalled and so it was presenting me with that version? (...or the RDF is inaccurate indicating it only has the 2-cmd.) It seems like I should have the option to override as you suggest. If there had been another one called "Pioneer MIX 4-Cmd", I would have easily figure it out on my own.

I guess in this situation I have to weigh the value of those two buttons versus the value of the bytes required to include the 4-cmd protocol as an upgrade. Thanks for the insight Rob.
Back to top
View user's profile Send private message
3FG
Expert


Joined: 19 May 2009
Posts: 3365

                    
PostPosted: Mon Sep 24, 2012 2:06 pm    Post subject: Reply with quote

For newer JP1.3 remotes, there is definitely a problem with the entries regarding the 006A executor in RDF files and protocols.ini. The executor is evidently a new variant, but the RDFs don't reflect that, and of course protocols.ini doesn't have an entry for that as yet undescribed variant of the executor.
The older 006A takes 3 fixed bytes, while the new one takes 4 fixed bytes, IIRC. Seems likely that it could handle the 3 prefixes, but I haven't experimented with it.

Anyway, possibly the 006A executor will work if for some reason the 007E executor is not suited to the problem.

Vroylan, use the Lookup Tool to see the Pioneer executors which are known to be in the RCRP05B. Both 007E and 006A are present.
Back to top
View user's profile Send private message
Vyrolan



Joined: 24 Aug 2012
Posts: 168
Location: Chicago, IL

                    
PostPosted: Mon Sep 24, 2012 3:08 pm    Post subject: Reply with quote

3FG wrote:
Vroylan, use the Lookup Tool to see the Pioneer executors which are known to be in the RCRP05B. Both 007E and 006A are present.

If I am interpreting the Lookup Tool correctly, then it has the 4-cmd variant built-in. If that's true, then why does the RDF not indicate it as such? As an end user, I'm left with the RDF saying one thing and the Lookup Tool saying something else with no way to know which is correct.

Also, regardless of whether I am using the 2-cmd or the 4-cmd, RMIR includes a protocol upgrade as required whenever I pick Pioneer MIX. So it doesn't think it has either. Looking at the RDF, it has "007E:5" listed, but there's no variant 5 of 007E in the protocols.ini. It's also weird that protocols.ini lists both [Pioneer MIX] and [Pioneer DVD2] as 007E variant 2.
Back to top
View user's profile Send private message
Vyrolan



Joined: 24 Aug 2012
Posts: 168
Location: Chicago, IL

                    
PostPosted: Mon Sep 24, 2012 3:12 pm    Post subject: Reply with quote

3FG wrote:
Anyway, possibly the 006A executor will work if for some reason the 007E executor is not suited to the problem.


But I have no way to setup what I need to do with 006A...I saw that one but it's basically saying "pick one of these 3 devices, and then send this OBC" or if it's two-part command, it's "pick one of these 3 devices, and then send these two OBCs". I really need to "pick a prefix device, send one of these 3 prefix OBCs, then pick a second device, and send a OBC". That's what Pioneer MIX does, but it only does it for 2 OBCs as prefix commands.
Back to top
View user's profile Send private message
3FG
Expert


Joined: 19 May 2009
Posts: 3365

                    
PostPosted: Mon Sep 24, 2012 4:12 pm    Post subject: Reply with quote

Sorry, I haven't looked at these executors recently-- I just know that protocols.ini doesn't have correct entries. To fix protocols.ini, we need to 1) understand the behavior of these newer variants, and 2) understand how RMIR parses among the various variants. I haven't done #1, and I'm not aware of any document or thread that describes #2.
Back to top
View user's profile Send private message
The Robman
Site Owner


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

                    
PostPosted: Mon Sep 24, 2012 4:16 pm    Post subject: Reply with quote

006A is not relevant here, we're talking about 007E.

The RDF for the RCA remote has variant:5 specified. I don't know how that variant differs from variant:3, but RM has no knowledge of it, which is why you're getting the results that you found.
_________________
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
The Robman
Site Owner


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

                    
PostPosted: Mon Sep 24, 2012 4:25 pm    Post subject: Reply with quote

I don't think there's any logical difference between variant:3 and variant:5, so I think if you change 007E:5 to 007E:3 in the RDF, you should be good to go.
_________________
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
Vyrolan



Joined: 24 Aug 2012
Posts: 168
Location: Chicago, IL

                    
PostPosted: Mon Sep 24, 2012 5:01 pm    Post subject: Reply with quote

The Robman wrote:
I don't think there's any logical difference between variant:3 and variant:5, so I think if you change 007E:5 to 007E:3 in the RDF, you should be good to go.

I'll do that, but I'm left with lots of deep questions around how/if we verify protocols.ini or any of the RDFs...everything is so dependent on them. To the average end user, all of this would be dark magic that we're supposed to have gotten right for them. =p
Back to top
View user's profile Send private message
The Robman
Site Owner


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

                    
PostPosted: Mon Sep 24, 2012 6:06 pm    Post subject: Reply with quote

Vyrolan wrote:
The Robman wrote:
I don't think there's any logical difference between variant:3 and variant:5, so I think if you change 007E:5 to 007E:3 in the RDF, you should be good to go.

I'll do that, but I'm left with lots of deep questions around how/if we verify protocols.ini or any of the RDFs...everything is so dependent on them. To the average end user, all of this would be dark magic that we're supposed to have gotten right for them. =p

Agreed. I'm hoping the right people notice this and offer some thoughts.
_________________
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
vickyg2003
Site Admin


Joined: 20 Mar 2004
Posts: 7073
Location: Florida

                    
PostPosted: Tue Oct 09, 2012 9:34 am    Post subject: Reply with quote

Vyrolan wrote:
The Robman wrote:
I don't think there's any logical difference between variant:3 and variant:5, so I think if you change 007E:5 to 007E:3 in the RDF, you should be good to go.

I'll do that, but I'm left with lots of deep questions around how/if we verify protocols.ini or any of the RDFs...everything is so dependent on them. To the average end user, all of this would be dark magic that we're supposed to have gotten right for them. =p


We do have a system in place.

This used to be much more of a problem than it is today. It used to be that the protocol variant issue raised its ugly head about once a week. Since the process was automated, it has come down to something we see about every three months or so.

Mike England (mr_d_p_gumby) analyzes the protocols and provides a sheet of protocol sections to the RDF librarian (xnappo) and then the RDF Librarian can do an automated edit of the protocol sections of all the base remotes RDFs. The extenders RDFs have a new section in them to identify the original signature, and if the extender RDF's have been submitted to the librarian, these are automatically updated too.

The RDF files that are submitted for change are also now in source forge, so there is some version control. It used to be that there were multiple people submitting individual changes, and then the RDF Librarian would take the latest date, without reguard to the contents. So someone would fix a button issue on an oblsolete RDF, and it would have a later date, and the protocols section would get clobbered over and over. It was a manual process that has been semi-automated.

Having the RDF's in source forge has created its own problems. Often the new RDFs don't make it into the forum, because some of us are afraid of source forge (like me).

So even though this is still an issue, its minor today in comparison to what it was when the RDFs were hand edited.

P.S. oldabe, I responded to you too, and that is on the prior page.
_________________
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
The Robman
Site Owner


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

                    
PostPosted: Tue Oct 09, 2012 12:17 pm    Post subject: Reply with quote

So Vicky, can you make sure that whoever needs to handle the $007E variants is aware of what needs to be done please?
_________________
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
Display posts from previous:   
Post new topic   Reply to topic       JP1 Remotes Forum Index -> JP1 - General Forum 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