JP1 Remotes

After recently updating to X1, I was seeing what codes were available. My RCRP05 has the proper 1982 code and works fine. I was trying some things, and have another Comcast XR2 remote. That has a SEARCH button that works. The XMP code lists I have seen don't seem to have a code for that. I used one of my backup RCRP's to learn the code. But, it lists "MULTIPLE" as the protocol. I even tried some known keys, and got the same.

I put the file in the diagnostics area as XMPLearnTest.rmir. The learned code should be the XMP "OK" code EFC 235.

I did test with another remote for my Onkyo receiver, and that decoded properly.

This is with RMIR 2.11 Build 6.

Unfortunately the XMP protocol is too complicated for the UEI learning algorithm to learn correctly. I suggest you try changing the decoder in RMIR from IrpTransmogrifier to DecodeIR by using the menu item Options > Set IR Decoder. In almost all circumstances IrpTransmogrifier is a better decoder than DecodeIR, but for XMP you might find DecodeIR to be better. It includes some code that attempts to correct the errors in XMP signals (ONLY XMP, no other protocol) that the UEI learning algorithm can introduce. No guarantees, but it is worth trying. Do change back to IrpTransmogrifier afterwards, though.

Please post here to let me know if this helps.

As Andy didn't post a link to his file, I will post one for him:
https://www.hifi-remote.com/forums/dload ... e_id=26026

Using DecodeIR, your learn decodes as XMP, device code 62, sub-device 16, OBC 37

I have a XR2 v3-R remote. Its search button has a magnifying glass printed on the button surface with the word Search written underneath. Using a IRWidget Search decodes as XMP-1 62.16 OBC 207.

Ok, first some theory: That a particular IR signal has several decodes is a fact of life. Just like "table" can denote a piece of furniture just as well as a two dimensional array, or that the same tone can be called C-sharp or D-flat (equal tempered tuning assumed). Andy's signal decodes (with stand-alone IrpTransmogrifier wilth --all) as
that is, four different decodes. So the question is: which one of these do we select? In science, the "principle of the most powerful unfalsified model" is most often used, and I claim is also the natural choice for us. "Most powerful" means the model that prohibits most. Here, an inspection of the IRP forms reveals that XMPff-1 is clearly the most powerful model.

The configuration file IrpProtocols.xml for IrpTransmogrifier contains an attribute "prefer-over" which expresses a relation on the set of decodes, that declares that a particular decode should be preferred over another. This in general (there are some exceptions) boils down to that it constitutes a more powerful model than another.

Graham and myself (with some feedback from Rob) have put down a lot of effect in "tuning" the prefer-overs. But, as this thread shows, it is not perfect, and probably will never be. I personally think that RM should have a possibility for the user to "Highlander-ize" ("there can only be one...") the multiple decodes.

Also DecodeIR contains an elaborate system to prefer one decode over another. The login for this is instead hard coded in the C++-code- To change, the C++-code has to be changed and the library compiled anew.

Back to Andy's problem. Without the --all option, instead the decodes XMP-1 and XMPff-1 are returned, and this is exactly the original problem. What is needed is an element
<irp:parameter name="prefer-over">XMP-1</irp:parameter>
within the element <irp:protocol name="XMPff-1">. Instead of editing this file, RM also contains a "patch file" for the protocols. Here is such a file. Just replace the present rmProtocols.xml with this version, and the decode will be unique. This should solve Andy's problem.

I changed to DecodeIR and it worked. For Search, I got an OBC of 207, not 37. EFC5=27845.

Using another RCRP05 I also found a few extra codes. X1 doesn't use them, but they help to be complete.
Dash=93
PIP_On/Off=88
PIP_Move=90
PIP_Ch+=91
PIP_Ch-=92

I uploaded an updated RMIR file:
https://www.hifi-remote.com/forums/dload ... e_id=25834

Barf wrote:I personally think that RM should have a possibility for the user to "Highlander-ize" ("there can only be one...") the multiple decodes.

Sorry, I don't understand the reference. If you mean that the user should be able to list the decodes and select which one to display, so that (say) conversion to device upgrade uses that decode, then that facility is there. I haven't tested it for years and it may not work now, but if it does not then I will fix it. It is simply that there is a checkbox "ignore" against each decode when you list the multiple ones by double-clicking.