Sharp/Denon Combo (Official) Protocol issues

Post by **ElizabethD** » Mon May 22, 2006 7:24 pm

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.

Post by **ElizabethD** » Mon May 22, 2006 8:15 pm

I just put in Diagnosis Rob's IR file with all those protocols plus a composite that might help the experts
https://www.hifi-remote.com/forums/dload ... le_id=3245
RCU810 occurs in two places.
I'm out of my league on this subject, but just trying to be helpful

Post by **The Robman** » Tue May 23, 2006 12:08 pm

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.

gfb107 · Post by **gfb107** » Tue May 23, 2006 12:21 pm

RM will always choose the built-in variant if there is one. 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.

johnsfine · Post by **johnsfine** » Tue May 23, 2006 1:41 pm

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.

Post by **The Robman** » Tue May 23, 2006 1:53 pm

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.

gfb107 · Post by **gfb107** » Tue May 23, 2006 2:04 pm

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.

gfb107 · Post by **gfb107** » Tue May 23, 2006 2:13 pm

johnsfine wrote:I thought it picked the first usable entry in protocols.ini

At one point that was the case, but there were issues, so I added code to give preference to the built-in variant. If there isn't a builtin variant, the first entry with protocol code for the remote's processor will be used.

Post by **The Robman** » Tue May 23, 2006 2:56 pm

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.

johnsfine · Post by **johnsfine** » Tue May 23, 2006 3:34 pm

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.

gfb107 · Post by **gfb107** » Tue May 23, 2006 4:11 pm

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