RCA Combo pid 0114

johnsfine · Post by **johnsfine** » Fri Nov 24, 2006 4:17 pm

So far as I can tell there are two serious problems with the second variant of pid 0114.

1) It isn't identified in any of the rdf files, so RM thinks all remotes have the original variant (0 bytes of fixed data). The second variant uses two bytes of fixed data. KM seems to have correct knowledge of which remotes have the second variant.

2) It is comp. Both the 4 bit device and the 8 bit obc are non-comp in the old variant but comp in the new variant. KM doesn't have support for that, so the upgrades are all wrong (RM upgrades are of course even more wrong).

Before I fix protocols.ini and my 8820 rdf, do any of the other experts have comments or suggestions?

Hopefully someone else will fix KM and the other rdf files.

BTW, the fixed data and the low four bits of the first byte of the hex command are used for sending some sort of prefix sequence before the command. I haven't worked out the details yet. In order to not do that, the low bit of the first byte of the hex cmd must be clear.

It would be nice if Greg can think up a way to do better RM support for obscure features of new variants:

I'd like to have protocols.ini entries for both variants with the same protocol name, and has setup page fields for the obscure features in one variant and not in the other. We would need clear notes telling the user to leave those fields blank unless he really understands them. But more importantly we need RM to be better about switching protocols.ini entries when switching remote models. If the extra fields are blank it shouldn't be confused that they aren't there in the other entry. If they aren't blank, it should warn but let the user continue if he wants destroying them.

mr_d_p_gumby · Post by **mr_d_p_gumby** » Sat Nov 25, 2006 12:24 am

I'll correct the comp issue in KM for the next release.

Remotes with variant 2 are:
Atlas PVR, Comcast URC-1058, Comcast URC-1068, RS 15-2138, RS 15-2144, URC-6690, URC-6820/8820/10820, URC-6960, URC-7555, URC-7780, URC-8203, URC-8206, URC-9960b00, URC-9960b01.

johnsfine · Post by **johnsfine** » Sun Nov 26, 2006 12:29 pm

I added the :2 to pid 114 in my copy of the 8820 rdf file at
https://www.hifi-remote.com/forums/dload ... le_id=3801

and I added support for it to the protocols.ini file at
http://john.fine.home.comcast.net/ir/protocols.ini
and to the protocols.ini file at SourceForge (which will feed into the official protocols.ini the next time Greg does a release).

That still leaves all those other rdf files (that Mike listed above) to be corrected.

Post by **The Robman** » Sun Nov 26, 2006 12:49 pm

Here's something else to think about, and this always comes up when UEI changes the way an executor works. What if the user has a remote with the old version built in, but they need one of the features that have been added to the new version? There really needs to be a way for them to switch to the new version and accept the protocol upgrade. In the past, when we've built in support for this sort of thing, we've allowed the new variant to be selected using a different name and then we've added the protocol using a new pid also, this is just in case the user already has upgrades added using the built in variant of the executor.

mr_d_p_gumby · Post by **mr_d_p_gumby** » Sun Nov 26, 2006 4:05 pm

The Robman wrote:In the past, when we've built in support for this sort of thing, we've allowed the new variant to be selected using a different name and then we've added the protocol using a new pid also, this is just in case the user already has upgrades added using the built in variant of the executor.

I took this approach in KM for the RCA Combo (it's called RCA Combo 2), though I did not have it change the PID.

If I were to change KM to use an alternate PID for upgrades, what PID would you suggest?

Post by **The Robman** » Sun Nov 26, 2006 10:59 pm

Have we actually determines what extra powers the 2nd variant has? There's no need to break it out it in either KM or RM until we know what extra stuff it can do. As for the pid, I have no idea, use whatever comes to you, just pick something that isn't already in use.

johnsfine · Post by **johnsfine** » Mon Nov 27, 2006 5:47 am

The fixed data is two extra OBC numbers.

Setting the low bit of the first cmd byte makes it send at least one of them before the main obc (the second byte of the hex cmd).

It also looks at other low bits of the first byte, I think to decide which of the fixed byte to send and maybe there is a choice to send both. I haven't looked in detail.