Page 1 of 2
Atlas OCAP 3033 w/extender and protocol 00 42
Posted: Thu Apr 15, 2010 6:15 am
by xnappo
Hello All,
I am in the process of moving from the Atlas extender 2.03 to 2.10. I decided to start from scratch using RM-IR.
I ran across an issue:
I am using this Panasonic XR57 upgrade:
https://www.hifi-remote.com/forums/dload ... le_id=4097
Here is the header:
Code: Select all
Description=Panasonic SA-XR57
Remote.name=RS 15-1994 6-in-1 Smart
Remote.signature=RSL6RSL0
DeviceType=Tuner
DeviceIndex=4
SetupCode=2019
Protocol=00 42
Protocol.name=Panasonic Multi-Device (Hacked)
ProtocolParms=160 null null null
FixedData=BF FB FA FF
All of the Atlas RDFs I can find indicate that protocol 00 42 is built-in. However this upgrade will not work unless I delete 0042 from the RDF list(is that a bad idea?) and add the one from RM.
Strangely, when I look at my old .IR files, I had 0042 in as a custom protocol, but I do not remember running into this and figuring it out before...
So - does the Atlas really have 00 42? Is the one in RM-IR somehow different/better than stock? If so do we need to have an 'override internal protocol' selector in RM?
Thanks,
xnappo
Posted: Thu Apr 15, 2010 6:56 am
by vickyg2003
Carl has run into this same issue in
this thread
Since the protocol says Hacked, I would imagine its a JP1 custom protocol. Apparently we had decided that since 0042 was an unused PID, we could saftely use that as our own PID. However in the last three years 12 remotes have used this PID for their own use. How DARE UEI take one of our pids and use it!
Posted: Thu Apr 15, 2010 7:36 am
by xnappo
Thanks Vicky,
So how do you think we should fix the tools? At a minimum seems like having an 'override internal protocol' checkbox out the output window..?
Thanks,
xnappo
Posted: Thu Apr 15, 2010 7:40 am
by vickyg2003
Actually I've got an open issue with that new RCA remote, that would make the "over-ride internal" a no-go if it proves to be true.
Posted: Thu Apr 15, 2010 7:42 am
by jimdunn
I'd say it probably makes more sense to change the PID for the "hacked" protocol.
After all - it isn't in the remote (UEIs 42 is) - so surely it should have a different PID.
edit:
However, It could be that PID numbers are in short supply, so the convention is to overwrite them in cases like this.
In that case I guess RM would need to know that this is a resident protocol, but it should still overwrite it.
KM does know that - it even says "042 is a resident protocol" and gives you the "upgraded" protocol to cut/paste.
Posted: Thu Apr 15, 2010 7:44 am
by xnappo
jimdunn wrote:I'd say it probably makes more sense to change the PID for the "hacked" protocol.
After all - it isn't in the remote (UEIs 42 is) - so surely it should have a different PID.
Makes sense - so we have the data somewhere of what the newer UEI remotes us in terms of protocols and need to remap the custom ones? Who owns that data?
xnappo
Posted: Thu Apr 15, 2010 7:47 am
by gfb107
A simple fix would be to change the RDFs that indicate they have this new variant of PID 0042.
Maybe we could call it the UEI variant, so the RDFs would include 0042:UEI in their protocols sections?
In the future, when someone clever figures out what this variant is used for and how it used fixed and variable data it can be added to protocols.ini and used for creating upgrades.
Posted: Thu Apr 15, 2010 7:59 am
by jimdunn
KM already says "042 is a resident protocol" but still gives you the "upgraded" protocol to cut/paste when you load the upgrade from the other thread Vicky linked, so it already "knows" somehow that this "hacked" protocol is not UEI:42.
Posted: Thu Apr 15, 2010 9:01 am
by vickyg2003
jimdunn wrote:KM already says "042 is a resident protocol" but still gives you the "upgraded" protocol to cut/paste when you load the upgrade from the other thread Vicky linked, so it already "knows" somehow that this "hacked" protocol is not UEI:42.
There is a basic difference in philosophy.
KM is hard coded. Mike analayzes each remote before he adds it. So you have to wait until Mike has the time to do the analysis.
RM is ready to handle any remote as soon as an RDF has been prepared. So you don't have to wait on any one person, although if there is a variant we still need to wait for Mike to identify that, and the the RDF Librarian to update the RDF.
Posted: Thu Apr 15, 2010 9:27 am
by jimdunn
Yes, I understood that.
So, as Greg said, altering the rdfs to say 0042:UEI or something similar would stop RM from thinking it didn't need to offer this protocol upgrade for these remotes by making the inbuilt UEI a "variant" that didn't match the "hacked" protocol ?
edit:
yup - it certainly works if I edit my copy of the rdf [protocols] section from 0042 to 0042:UEI
Posted: Thu Apr 15, 2010 9:56 am
by xnappo
jimdunn wrote:Yes, I understood that.
So, as Greg said, altering the rdfs to say 0042:UEI or something similar would stop RM from thinking it didn't need to offer this protocol upgrade for these remotes by making the inbuilt UEI a "variant" that didn't match the "hacked" protocol ?
edit:
yup - it certainly works if I edit my copy of the rdf [protocols] section from 0042 to 0042:UEI
How is this different from deleting it? Or is this a feature change to RM to detect that :UEI as a different animal?
Thanks!
xnappo
Posted: Thu Apr 15, 2010 10:10 am
by jimdunn
In the [protocols] section of the rdf is a comma separated list of protocols the remote contains.
It's currently 0042 in the Atlas rdf.
If you change it to 0042:UEI then RM doesn't think the atlas has a protocol 0042, but rather a protocol variant 0042:UEI.
So when you create an upgrade using 0042 (the "hacked" protocol) RM sees no match in the rdf and offers the upgrade.
It doesn't require changes to any tools - just the rdfs for the remotes that have 0042 in the rdf.
There are already variants like this in the rdfs, eg:
00F8:3 and
0027:new
look at
Code: Select all
30333033 (Atlas OCAP URC-1056 JP1.3 (Black)_(Silver)).rdf
to see.
As Greg says, when an expert works out what 0042:UEI does, and how it works, it can be added to protocols.ini, and it could then be used to build upgrades.
Posted: Thu Apr 15, 2010 10:20 am
by xnappo
jimdunn wrote:
As Greg says, when an expert works out what 0042:UEI does, and how it works, it can be added to protocols.ini, and it could then be used to build upgrades.
Ah - ok I see. The part I wasn't getting was that RM could already accept the format 0042:UEI as a lookup in protocols.ini.
Thanks. I also have another bug in the Atlas RDF - who exactly is the RDF librarian?
Thanks all!
xnappo
Posted: Thu Apr 15, 2010 10:32 am
by jimdunn
xnappo wrote:
Ah - ok I see. The part I wasn't getting was that RM could already accept the format 0042:UEI as a lookup in protocols.ini.
It seems to do it like this (using VariantName) in protocols.ini
Code: Select all
PID=00 27
AlternatePID=0127,none
VariantName=new
for 0027:new from my earlier example.
I don't know who the librarian is - it was Nils, way back when, I think - but I could be wrong, and I didn't check in here for a long while so I'm not sure, sorry....
Posted: Thu Apr 15, 2010 10:49 am
by gfb107
This presents another problem: the PID Conflict.
What happens when someone has a device upgrade that uses 0042 and also uses a built in setup code (or a second device upgrade) that uses 0042:UEI? If 0042 is installed as a protocol upgrade, that device upgrade WILL work, but the built in setup code (or second device upgrade) will NOT work. If 0042 is not installed, that device upgrade will NOT work, but the built in setup code (or second device upgrade) WILL work.
RM has a way to deal with this, the Alternate PID, which is the PID to use when installing a protocol variant when another variant is built into the remote.
I don't know what a good value would be for the alternate PID, but it looks like 01 47 isn't used for anything.(?)
To try it out, just add the following line to the protocols.ini entry for Panasonic Multi-Device (Hacked)