JP1 Remotes

[WagonMaster]

Sorry for the delay in this report. I finally found some time to get back to JP1 testing.

NOTE: For brevity, I will use the terms "DSM/978" for a device-specific macro, i.e. one programmed with the 978 code and "DIM/995" for a device-independent macro, i.e. one programmed with the 995 code.

I ran the new RMIR v1.98-beta4. I still see what I consider corruption of the flash memory, specifically the 2nd byte of every macro definition, when a '.rmir' file with macros is loaded (but, curiously, not when such data was first downloaded from a manually programmed remote).

I realize that this memory alteration was probably expected, given the earlier discussion.

At first, I believed that this was merely a philosophical issue. In other words, I thought that it really should not work that way but that it would be harmless in practice.

I'd even done some testing with my RS 15-135 remote. Although the 15-135 oddly creates DIM/995 macros that look like they were made as DSM/978 macros, the 15-135 does not appear to even support DSM/978 macros. But it encodes the 2nd byte with a lower nybble that matches the code of whatever device was active when the DIM/995 macro was programmed!

Nevertheless, I was able to demonstrate that such macros worked both as originally programmed (manually) and after corrupting the low nybble to 0xF (in other words, making the byte 0x8F as RMIR was doing).

Based on that, I was planning to say that since making it work "correctly" might be more bother than it was worth, I'd learn to live with the data corruption if that was the case.

I'd also done some testing with my URC-10820 remote and found that it creates DIM/995 macros with the code 0x80 as the 2nd byte. So, basically, I have 2 remotes that each act differently with respect to how they encode the 2nd byte of a DIM/995! But this point is moot given what I explain below.

Since the 15-135 and URC-10820 tests, I finally did some testing with my RCA RCRP05B remote. It seems to be the most logical of the 3 remote types I own with respect to how it encodes the DIM/995 macro. It sets a DIM/995 macro's 2nd definition byte to 0x8F. It really has to do that since it actually supports DSM/978 macros, though.

The problem with RMIR (and, to a seemingly lesser extent with 'IR.exe') is that corruption of those bytes in an RCA RCRP05B remote won't be tolerable. Changing those bytes will actually change the meaning of a user's (hand-entered) macros!

I'm not sure, but this might even require a new entry (or entries) in the RDF specification (as Greg has mentioned earlier) to accommodate these oddities.

I've decided to start a new thread documenting the behavior of the RCA RCRP05B remote, since there was apparently some mis-information in this thread about that remote and since that remote seems to be the one which will actually require changes to RMIR and 'IR.exe'.

I'd hoped this macro issue was over but unfortunately it seems to need some more discussion and attention.

Should we start a new thread to discuss this?

Bill

[gfb107]

Wow, that's a bunch of really detailed, useful information. Thanks for that.
_________________
-- Greg
Original RemoteMaster developer
JP1 How-To's and Software Tools
The #1 Code Search FAQ and it's answer (PLEASE READ FIRST)