JP1 Remotes

Hi 3FG,

Bitwise complement (aka one's complement) was the first thing I thought of, because I can definitely see the use of it in IR - it only takes one inverter or say open-drain IR LED driver - and all zeros become ones and vice versa.
Unfortunately, your assumption:

regarding the complement that Rob refers to, mathematicians typically call this operation as the "one's complement".

doesn't seem to be right, because Rob mentioned two times above:

what is the new OBC for the #2 button?
If it's 254 - you are viewing the hex as LSB-COMP

(for one's complement, it would've been 253)

To get the comp'd version subtract the OBC from 256.

(for one's complement, it would've been 255)

However, Rob's last post indirectly suggests that he possibly meant "bitwise inversion". But I don't want to speak for Rob. Rob, can you please clarify as to whether you meant bitwise (255-X) or two's (256-X) complement? Thanks.

Comp is bitwise inversion, one's complement. I am looking into your problem to see if there is a bug in RMIR that caused the .txt and .rmir files to give different OBCs.

There is no bug involved in the change of OBC between your .txt and .rmir files. It appears that you must have imported Vicky's .txt file, uploaded the setup to your remote and then downloaded it again, and the file you saved was the download. My experiments with your files show that had you saved the setup that you uploaded as a .rmir file, the OBC's would have remained unchanged.

What is happening is that Vicky has set the relationship between the OBC and Hex to be LSB (least significant bit first). This info does not get into the remote. The download process does not recognise your protocol (for standard protocols it would get the corresponding info from protocols.ini, not from the downloaded data) so it constructs a new one to represent the function data. The default for this constructed one is MSB, hence the problem.

Now, RMIR has the facility to change this in your .rmir file, but when I came to check this out, I found there was a bug in it. Since I only posted RMIR v2.03 build 6 yesterday, I don't want to post another one today so here is build 7 with this bug fixed, in the Diagnosis Area. Just replace the .jar file in your present RMIR installation with this one.

Here is how you use it, with commentary. You are about to change the protocol used by TV/2003. When you change a protocol, RMIR needs to know whether to keep the OBC or the Hex unchanged. The default is OBC, as this is the most common situation, so you need to tell it otherwise:

• Open RMIR, drop down the Options menu and check "Allow Preserve Control".
  Load your .rmir file, go to Devices, select TV/2003, press Edit. There is now a Preserve drop-down box. Change it to "EFC and function hex" and press OK.

You now need to change the protocol from MSB to LSB:

• Again select TV/2003 but this time press Edit Protocol.
  Select the Device Data tab in the table at the lower left of the panel that opens.
  In the Command Parameters table there is one entry, for OBC. Check the LSB box and press OK.

You can now select TV/2003 once again, press Edit and look at the Functions tab. You should find that the OBC's are now as you wish. Save the setup as a .rmir file and this setting will be preserved when you next open it. It will be lost, however, every time you download the remote into RMIR since, as I explained, the remote does not hold the MSB/LSB setting.

The more general situation is that the relationship between Hex and EFC is a fixed one, an encryption algorithm created by UEI, but the relationship between Hex and OBC is protocol-dependent and can be very complicated, especially in combo protocols where one executor can send signals of several protocols. This relationship, protocol by protocol, is part of the data in the protocols.ini file. This is a text file and well commented near the beginning with an explanation of the standard translator between Hex and device parameters such as OBC. Complicated protocols often need a non-standard translator for this, these are built into RMIR.

Thanks for the detailed and clear explanation, Graham.

Yes, that was an "omission" on my side to not mention that I uploaded and d/loaded the rmir image before saving rmdu.
I was under firm impression (perhaps misled by the term "image") that the rmir image is something similar to binary firmware images that you dload/upload to/from EEPROMs and/or microcontroller flashes - those never change in process, and are kept the same up to the last byte, as the verification of successful up/downloading relies on their CRC calculation.
OK, I could've guessed that was not the case with RMIR images, for the fact alone that the function names are not kept when you read back the image from the remote. But, as usually, you don't pay particular attention until you hit a particular problem.

OK, all clear now. Thanks for looking into that, and thanks for upreving the RMIR.