 |
JP1 Remotes
|
| View previous topic :: View next topic |
| Author |
Message |
ElizabethD
Advanced Member
Joined: 09 Feb 2004
Posts: 2348
|
 Posted: Mon May 22, 2006 8:24 pm Post subject: |
 |
|
I just reviewed the set of protocols Rob provided, Perhaps a protocol expert will put some meaning on it..
15-2104 needed "n" for COMP as opposed to 8910 and 2117 which need "y"
2104 did not have this line in the protocol, otherwise the protocols were identical.
COM DCBUF+2
This line is not in RCU810, so it might need "n" for COMP (making it similar to that Denon setting)
2104, 8910, 2117 have this code, but RCU 810 does not
CP R0D,#02H
JRNE LFF2A
LD R0D,#05H
I don't know what it does, suspect something about repeats. RCU810 does not have those three lines.
I suspect writing in a switch in RM, as Mark did in KM, might not be a bad idea.
Greg, I see you just posted a reply. There are 13 versions [edited from 8]. I have a composite in excel, side by side, do you need it, 'cause I sure can't read it.
_________________
Liz
Tweeking 8910, HTPro/9811, C7-7800, 6131o, 6131n, AtlasOCAP-1056B01, RCA-RCRP05B and enjoying the ride 
Last edited by ElizabethD on Mon May 22, 2006 9:16 pm; edited 2 times in total |
|
| Back to top |
|
 |
ElizabethD
Advanced Member
Joined: 09 Feb 2004
Posts: 2348
|
| Posted: Mon May 22, 2006 9:15 pm Post subject: |
|
|
I just put in Diagnosis Rob's IR file with all those protocols plus a composite that might help the experts
http://www.hifi-remote.com/forums/dload.php?action=file&file_id=3245
RCU810 occurs in two places.
I'm out of my league on this subject, but just trying to be helpful
_________________
Liz
Tweeking 8910, HTPro/9811, C7-7800, 6131o, 6131n, AtlasOCAP-1056B01, RCA-RCRP05B and enjoying the ride |
|
| Back to top |
|
|
The Robman
Site Owner
Joined: 01 Aug 2003
Posts: 21238
Location: Chicago, IL
|
| Posted: Tue May 23, 2006 1:08 pm Post subject: |
|
|
| johnsfine wrote: | | The Robman wrote: | | I'm trying to use any spare minutes to look at the Sharp/Denon combo issue |
I'm glad you're doing that investigation. I was thinking about trying to find time myself to do that, but I'm swamped.
When you get that info, I assume it will split a set of executors that we now treat as equal, into two or more variants.
For RM we will need to:
1) Select new variant name(s) for any pid variants that are no longer equal to the primary one. (variant names only must be different if the translation rules are different, not if the executor code differs in a trivial way).
2) Edit the rdf files for all models whose built-in executors are not the primary variant.
3) Edit protocols.ini to add entries for the new pid variants.
I expect your focus will be on KM, but will you post or tell the info so others can do the above steps for RM? |
From the brief bit of analysis that I did yesterday, I could see that UEI changed the way that they're handling the COMPing of the variables in some of the later executors, so I would not be surprised to find that they accidentally switched it at some point, and Liz's experiments certainly seem to point in that direction.
If it's feasible, I'd like to make this as invisible as possible to the user, but I do expect that the end result will be two KM/RM "Protocols". The trick will be to not do it in such a way as to prompt millions of "which version do I use?" questions.
_________________
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 |
|
|
gfb107
Expert
Joined: 03 Aug 2003
Posts: 3411
Location: Cary, NC
|
|
| Back to top |
|
|
johnsfine
Site Admin
Joined: 10 Aug 2003
Posts: 4766
Location: Bedford, MA
|
| Posted: Tue May 23, 2006 2:41 pm Post subject: |
|
|
| gfb107 wrote: | | RM will always choose the built-in variant if there is one. |
I didn't know that. I thought it picked the first usable entry in protocols.ini
| gfb107 wrote: | | We have to make an arbitrary decision as to which variant to use for remotes that don't have one built-in. We do this by excluding the protocol code from protocols.ini for all the other variants. |
That works by makes an entry unusable unless its variant is built-in. I thought we also had to put the one that includes protocol code last, so it won't use it unless all the ones without protocol code are unusable.
Whatever those details, we are able to provide transparent support for both multiple PIDs and multiple variants all with the same protocol name, as long as they take basically the same inputs (Subdevice, Unit, OBC, etc.) even if they have totally different rules for computing fixed data and hex commands from those inputs. |
|
| Back to top |
|
|
The Robman
Site Owner
Joined: 01 Aug 2003
Posts: 21238
Location: Chicago, IL
|
| Posted: Tue May 23, 2006 2:53 pm Post subject: |
|
|
| johnsfine wrote: | | Whatever those details, we are able to provide transparent support for both multiple PIDs and multiple variants all with the same protocol name, as long as they take basically the same inputs (Subdevice, Unit, OBC, etc.) even if they have totally different rules for computing fixed data and hex commands from those inputs. |
Actually, that brings up a good point. Isn't RM driven by hex codes rather than OBCs or EFCs? If it turns out that the button codes are COMP'd in one version of the code and not in another, while the OBCs will be consistant, the hex codes won't.
_________________
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 |
|
|
gfb107
Expert
Joined: 03 Aug 2003
Posts: 3411
Location: Cary, NC
|
| Posted: Tue May 23, 2006 3:04 pm Post subject: |
|
|
RM is driven by the hex code. This is the reason that the same change made to KM won't work in RM. Giving the user the ability to change whether or not to COMP causes the OBC to change instead of the hex cmd.
However, when switching protocols (or protocol variants) RM doesn't simply use the existing hex command with the new protocol. RM extracts the command parameters using the rules for the initial protocol, copies them to the parameters of the same name for the new protocol, and then regenerates the hex.
So, if you load an RM upgrade that uses one variant, then switch to a remote that has a different variant builtin, RM should correctly adjust the hex command so that the command parms are correct.
_________________
-- Greg
Original RemoteMaster developer
JP1 How-To's and Software Tools
The #1 Code Search FAQ and it's answer (PLEASE READ FIRST) |
|
| Back to top |
|
|
gfb107
Expert
Joined: 03 Aug 2003
Posts: 3411
Location: Cary, NC
|
|
| Back to top |
|
|
The Robman
Site Owner
Joined: 01 Aug 2003
Posts: 21238
Location: Chicago, IL
|
| Posted: Tue May 23, 2006 3:56 pm Post subject: |
|
|
| gfb107 wrote: | | However, when switching protocols (or protocol variants) RM doesn't simply use the existing hex command with the new protocol. RM extracts the command parameters using the rules for the initial protocol, copies them to the parameters of the same name for the new protocol, and then regenerates the hex. |
is that another way of saying that RM is driven by the OBC codes when you switch remotes? KM has the ability to force you to use OBCs for certain protocols, and if it doesn't already do that for this protocol, I think it should.
_________________
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 |
|
|
johnsfine
Site Admin
Joined: 10 Aug 2003
Posts: 4766
Location: Bedford, MA
|
| Posted: Tue May 23, 2006 4:34 pm Post subject: |
|
|
| The Robman wrote: | | is that another way of saying that RM is driven by the OBC codes when you switch remotes? |
Yes. Internally it is switching between entries in protocols.ini, but (at least for this discussion) that is a consequence of switching remotes.
| The Robman wrote: | | KM has the ability to force you to use OBCs for certain protocols, and if it doesn't already do that for this protocol, I think it should. |
I think that is a reasonable choice for KM.
I don't think RM ever does that and I personally don't think it should. But I think a warning is called for in the protocol notes: on any protocols.ini entry whose EFC numbering differs from DecodeIR's EFC numbering we should warn that EFC numbers from decodes should not be used. If the EFC numbering does match the decodes but doesn't match significant other variants, we should warn that EFC numbers from other models of remote may not match and use of OBC numbers is safer. |
|
| Back to top |
|
|
gfb107
Expert
Joined: 03 Aug 2003
Posts: 3411
Location: Cary, NC
|
| Posted: Tue May 23, 2006 5:11 pm Post subject: |
|
|
| johnsfine wrote: | | Yes. Internally it is switching between entries in protocols.ini, but (at least for this discussion) that is a consequence of switching remotes. |
It copies any command parameters that have matching names (e.g. Device, Protocol, and OBC for Sharp Combo). RM does not consider the EFC a command parameter.
| johnsfine wrote: | | But I think a warning is called for in the protocol notes: on any protocols.ini entry whose EFC numbering differs from DecodeIR's EFC numbering we should warn that EFC numbers from decodes should not be used. If the EFC numbering does match the decodes but doesn't match significant other variants, we should warn that EFC numbers from other models of remote may not match and use of OBC numbers is safer. |
Sounds like you are volunteering to figure out which variants those are, and to update their notes in protocols.ini 
_________________
-- Greg
Original RemoteMaster developer
JP1 How-To's and Software Tools
The #1 Code Search FAQ and it's answer (PLEASE READ FIRST) |
|
| Back to top |
|
|
|
|
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
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
File Section
Wiki
