JP1 Remotes

I bought more of these and didn't check them out right away
All of them are the 369006 signature except for this one which is signature 370601
I haven't the time to compare if they are the same right now so I thought I would upload the Raw download

http://www.hifi-remote.com/forums/dload ... e_id=26574

Here's a starter RDF, which is just a clone of the original RDF with the signature changed. I will PM you for some additional information that I need.

http://www.hifi-remote.com/forums/dload ... e_id=26575

I did as requested Hope i did it correctly

Sorry i have not reported back lately.
I have not had time to do much with this yet
So far i have only tested things on the remote itself and have not done any uploads to the remote. I have only done a few tests and have not found any difference in the two versions.
When i actually have time i will do more tests
I find it weird that they would be the same.
The only difference so far is from an untouched remote is that this version did not have any upgrades added like the first version and that this version does not have a
Vendor setup ID segment

I also have more work that I need to do to the RDF but haven't gotten to it yet.

I just finished adding the final touches to the RDF, please put it through its paces and see if it works.

http://www.hifi-remote.com/forums/dload ... e_id=26575

From what I have tested these lines can be added

ZeroDigitMapByte=Y
RealTimeMacroData=$2D $2E $2F, $74 $75
MacroSupport=3
LearnedFormat=3

But not sure on ZeroDigitMapByte=Y
I need more testing and reading of the 3660 thread

I would need Graham to comment on those because I'm not familiar with them.

Yeah I know what you mean. I was waiting for his comments Too

"ZeroDigitMapByte=Y" means that the remote does not use the digit map byte in upgrades and needs that byte always to be 0. To test if it is needed, omit this entry then create an upgrade that sets a nonzero digit map byte and test if it works. If it does, fine. If not, reinstate the entry. This entry does no harm in any case, it just makes upgrades longer in those cases that could use a nonzero map byte.

To test "LearnedFormat=3", learn a signal and see if RMIR can decode it in the Learned Signals tab. If it can, the entry is needed.

The RealTimeMacroData and MacroSupport entries are needed if the remote has the same support for MultiMacros and Real-time Macros that were seen in the URC-3660 with its original signature. These entries were created specifically to support this behaviour.

All four entries were needed in the original URC-3660 and I think it almost certain that they will also be needed with the new signature.

Tested and all four entries should be added to RDF

I cloned the 3660 RDF to start with, but I guess I cloned an early version otherwise those would all have been in there. But regardless, I just added them.

It's interesting that this remote has a number table but doesn't use it.

Perhaps i tested incorrectly i actually did all tests yesterday maybe you can suggest an upgrade for me to test ZeroDigitMapByte

Here's some background info, most JP1 remotes have a built in table for frequently used button codes for the number buttons, where 0-9 on the 0-9 buttons is just one example of many. As a space saving device, if you assign codes to the number buttons that happen to match one of these table entries, rather than add the 10 button codes to the upgrade, they just add a reference to the correct table entry instead.

So to test, take that entry out of the RDF and save the RDF in the RDF folder. Then create an upgrade, preferably using NEC1, with functions assigned to the numeric buttons, where the OBCs are 0-9 on buttons 0-9. This assumes that OBCs 0-9 do something for at least one of your devices. While RMIR is in RM mode (device editor), if you switch to the Output tab, you should see that the 3rd byte of data is populated. If you then remove the function from one of the buttons, that 3rd byte should become 00 and a bunch of extra button codes will appear in the output.

If the number buttons work when the 3rd byte is 00 but do not work when it has a value, this shows that the remote isn't using the number table, but if they work in both cases, then it shows that the remote DOES use the table and that RDF entry is not required.

I had it correct ZeroDigitMapByte=Y is required
I think i tested it a few different ways yesterday too and came to the same conclusion
Thanks for the nice explanation Rob it helps understand more