Atlas OCAP 3033 w/extender and protocol 00 42

[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

[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!

[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

[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.

[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.

[xnappo]

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

[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.

[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.

[vickyg2003]

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.

[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

[xnappo]

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

[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.

[xnappo]

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

[jimdunn]

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....

[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)

Code: Select all

AlternatePID=01 47