JP1 Remotes

eferz wrote:Well, I'm wasn't sure how the RDF's work. So, I wasn't sure what was acceptable. About the only thing I've reliably understood is that each button definition is comma separated. One thing confuses me is why some buttons have a $# associations while others just list the name or why some names have quotes around them while others don't. The other thing, I was able to figure out is that the auto-assign relies on the "<string>": prior to the button name.

I think that this is all explained in the RDF Spec that is distributed with IR.exe. It probably should also be distributed with RemoteMaster too, but so far it hasn't been. It is version 4 of the spec and the JP1.4/JP2 remotes need extra features that will be in a version 5, but you should find your questions about the [Buttons] section answered. BTW All the JP1.4/JP2 RDFs should have an entry "RDFSync=5" in the [General] section to specify that they need version 5 support.

mathdon wrote:I think that this is all explained in the RDF Spec that is distributed with IR.exe. It probably should also be distributed with RemoteMaster too, but so far it hasn't been. It is version 4 of the spec and the JP1.4/JP2 remotes need extra features that will be in a version 5, but you should find your questions about the [Buttons] section answered. BTW All the JP1.4/JP2 RDFs should have an entry "RDFSync=5" in the [General] section to specify that they need version 5 support.

Awesome, thanks! I'll try and see if I can also transcribe that document into our wiki.

Hi,

I was really excited to hear that the URC7960/OARI06G is supported in the latest beta version of RMIR. My Tommy Tyler USB cable fits very loosely on the 6 pins and won't seat completely, but I think I've gotten it to work. I get a 3298 signature error when I try to download from the remote in RMIR 2.02 beta. A 983 blink back shows 3298 also. Where do I go from here?

Download 2.02Beta 1.5q. That distribution has RDF and image files which are outdated (I believe) and JP12Serial.dll also has a new version.
The two remotes are not at all the same internally, so you'll need the correct RDF file.
OARI06G RDF
URC-7960 RDF
JP12Serial.dll (goes in Windows folder)

I had already installed 1.5q, but it looks like RMIR was looking for files in several places since I had installed 2.00, then 2.02 beta, then 1.5q, then updated the DLL, etc. It now successfully reads the device. I also discovered that with the correct software, the cable connection is not finicky, though still loose. The part of About where it tells where the app is getting the various files proved very helpful.

Many thanks!

For spalter3 and regne_v in particular

I have just done some experiments with shifted key moves on my URC7960 and think I may have the solution to the issues with them. First of all, it seems that the RDF needs an entry added to the [General] section, as the remote seems to store the EFC rather than the hex value. Second, and this was driving me crazy before I dug something out of the depths of my memory, if you put a key move on a shifted digit key then you have to press Magic twice and then the digit key in order to access it. Please post here whether or not this solves the problems you were having.

A note for our US colleagues : the URC7960 still has a key labelled Magic, though the similar US remote, the OARI06G, has labelled it Setup.

mathdon wrote:For spalter3 and regne_v in particular

I have just done some experiments with shifted key moves on my URC7960 and think I may have the solution to the issues with them. First of all, it seems that the RDF needs an entry

Code: Select all

AdvCodeFormat=EFC

added to the [General] section, as the remote seems to store the EFC rather than the hex value. Second, and this was driving me crazy before I dug something out of the depths of my memory, if you put a key move on a shifted digit key then you have to press Magic twice and then the digit key in order to access it. Please post here whether or not this solves the problems you were having.

A note for our US colleagues : the URC7960 still has a key labelled Magic, though the similar US remote, the OARI06G, has labelled it Setup.

Just for clarification sake, does both URC-7960 and OARI06G store keymoves with EFCs, or is this another one of those unique features which separates the two remotes?

eferz wrote:Just for clarification sake, does both URC-7960 and OARI06G store keymoves with EFCs, or is this another one of those unique features which separates the two remotes?

I hadn't actually checked the OARI06G when I wrote the previous message, as I hadn't much time, but I have checked it now and it seems that it too stores keymoves as EFCs. I'm puzzled, as I thought that when I was adding JP1.4 keymove facility to RMIR, my testing had shown them to be storing hex. I suppose I can't have actually tested what signals were being generated and just made an assumption. So it seems that all the JP1.4 remotes store keymoves as EFCs, and as far as I know, none of the JP2 remotes we know about support keymoves at all. Is this right?

mathdon wrote:I hadn't actually checked the OARI06G when I wrote the previous message, as I hadn't much time, but I have checked it now and it seems that it too stores keymoves as EFCs. I'm puzzled, as I thought that when I was adding JP1.4 keymove facility to RMIR, my testing had shown them to be storing hex. I suppose I can't have actually tested what signals were being generated and just made an assumption. So it seems that all the JP1.4 remotes store keymoves as EFCs, and as far as I know, none of the JP2 remotes we know about support keymoves at all. Is this right?

Thanks, mathdon. I added the "AdvCodeFormat=EFC" into the [General] section of my personal copy of the "329801 (OARI06G One For All 6+3)" RDF. And can now confirm that it makes keymoves work as expected. Though, I hadn't tested it prior to today, it was in fact shooting the wrong signals without the entry. Hopefully, 3FG will update his version of the RDFs in the development file section.

Done.

mathdon wrote:For spalter3 and regne_v in particular

I have just done some experiments with shifted key moves on my URC7960 and think I may have the solution to the issues with them. First of all, it seems that the RDF needs an entry

Code: Select all

AdvCodeFormat=EFC

I've added this but I think that the rdf still has a minor issue.

I've uploaded this file with six keymoves done through RM IR. Three are referencing the move with the function and three with the key: the keymove through the "shift-5" key it's not working but the keymove using the "AV5" function does.

The non-shifted keymoves all work properly referenced through functions and through keys.

regne_v wrote:the "shift-5" key it's not working

It works when I try it, and sends OBC=72 which appears to be correct from your file. Remember, you have to press Magic twice, i.e. Magic Magic 5, to access the function.

^^^

Right, the rule is shifted numbers require two shifts from the keypad, otherwise the remote thinks you're trying to enter an advanced code (EFC).

mathdon wrote:

regne_v wrote:the "shift-5" key it's not working

It works when I try it, and sends OBC=72 which appears to be correct from your file. Remember, you have to press Magic twice, i.e. Magic Magic 5, to access the function.

Sorry, I did not express it clearly. TV/Shift-5 is working properly if I press shift/magic twice and then "5". The problem is within a macro.

If I set a keymove to a shifted key to use within a macro the shifted key is not working.

If instead of the shifted key I use the function name of the shifted key the macro works OK.

In the file there's a macro that "pressess" two buttons. If the buttons are keymoves of non-shifted keys or functions everything works OK, but if the keymove is a shifted key it doesn't work.

Thanks, now I understand your problem. It isn't an issue with RMIR or the RDF, the problem lies with the remote. It is nothing to do with macros, if you could press the phantom buttons in the macro directly you would get the same result.

The problem is that you can't "chain" keymoves. When you create the keymove with the function name, it copies the function to create an "EFC-style keymove", i.e. the hex code to send is in the keymove itself. When you create it with a key name, it creates a "keycode-style keymove" in which it is the button code of the key that is stored in the keymove. When you access that keymove then the remote looks up the hex code for that button code and the setup code concerned, it does not look to see if that button itself has a keymove on it. So you will need to use function names to get the effect you want.