JP1 Remotes Forum Index JP1 Remotes


FAQFAQ SearchSearch 7 days of topics7 Days MemberlistMemberlist UsergroupsUsergroups RegisterRegister
ProfileProfile Log in to check your private messagesLog in to check your private messages Log inLog in

URC-7960
Goto page Previous  1, 2, 3, 4, 5, 6, 7, 8, 9, 10  Next
 
Post new topic   Reply to topic    JP1 Remotes Forum Index -> JP1 - New Remotes & RDFs
View previous topic :: View next topic  
Author Message
mathdon
Expert


Joined: 22 Jul 2008
Posts: 4508
Location: Cambridge, UK

                    
PostPosted: Fri Mar 02, 2012 3:51 pm    Post subject: Reply with quote

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.
_________________
Graham
Back to top
View user's profile Send private message
eferz
Expert


Joined: 03 Jun 2010
Posts: 1078
Location: Austin, Texas

                    
PostPosted: Fri Mar 02, 2012 6:39 pm    Post subject: Reply with quote

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.
_________________
Remotes; JP1.2: Comcast URC-1067, JP1.3: Insignia NS-RC02U-10A, JP1.4 OARI06G, JP2.1: Cox URC-8820-MOTO (still trying to figure out how to make them self-aware.)
Back to top
View user's profile Send private message
landolfi



Joined: 12 Apr 2006
Posts: 57
Location: Chicagoland

                    
PostPosted: Sat Mar 03, 2012 12:02 am    Post subject: Reply with quote

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?
Back to top
View user's profile Send private message
3FG
Expert


Joined: 19 May 2009
Posts: 3365

                    
PostPosted: Sat Mar 03, 2012 12:24 am    Post subject: Reply with quote

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)
Back to top
View user's profile Send private message
landolfi



Joined: 12 Apr 2006
Posts: 57
Location: Chicagoland

                    
PostPosted: Sat Mar 03, 2012 10:54 am    Post subject: Reply with quote

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. Smile

Many thanks!
Back to top
View user's profile Send private message
mathdon
Expert


Joined: 22 Jul 2008
Posts: 4508
Location: Cambridge, UK

                    
PostPosted: Tue Mar 06, 2012 4:48 pm    Post subject: Reply with quote

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:
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 Smile : the URC7960 still has a key labelled Magic, though the similar US remote, the OARI06G, has labelled it Setup.
_________________
Graham
Back to top
View user's profile Send private message
eferz
Expert


Joined: 03 Jun 2010
Posts: 1078
Location: Austin, Texas

                    
PostPosted: Tue Mar 06, 2012 9:19 pm    Post subject: Reply with quote

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:
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 Smile : 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?
_________________
Remotes; JP1.2: Comcast URC-1067, JP1.3: Insignia NS-RC02U-10A, JP1.4 OARI06G, JP2.1: Cox URC-8820-MOTO (still trying to figure out how to make them self-aware.)
Back to top
View user's profile Send private message
mathdon
Expert


Joined: 22 Jul 2008
Posts: 4508
Location: Cambridge, UK

                    
PostPosted: Wed Mar 07, 2012 3:53 am    Post subject: Reply with quote

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?
_________________
Graham
Back to top
View user's profile Send private message
eferz
Expert


Joined: 03 Jun 2010
Posts: 1078
Location: Austin, Texas

                    
PostPosted: Wed Mar 07, 2012 5:12 pm    Post subject: Reply with quote

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.
_________________
Remotes; JP1.2: Comcast URC-1067, JP1.3: Insignia NS-RC02U-10A, JP1.4 OARI06G, JP2.1: Cox URC-8820-MOTO (still trying to figure out how to make them self-aware.)
Back to top
View user's profile Send private message
3FG
Expert


Joined: 19 May 2009
Posts: 3365

                    
PostPosted: Wed Mar 07, 2012 10:48 pm    Post subject: Reply with quote

Done.
Back to top
View user's profile Send private message
regne v



Joined: 29 Oct 2004
Posts: 50
Location: Spain

                    
PostPosted: Thu Mar 08, 2012 4:36 pm    Post subject: Reply with quote

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:
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.
Back to top
View user's profile Send private message
mathdon
Expert


Joined: 22 Jul 2008
Posts: 4508
Location: Cambridge, UK

                    
PostPosted: Thu Mar 08, 2012 6:58 pm    Post subject: Reply with quote

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.
_________________
Graham
Back to top
View user's profile Send private message
mdavej
Expert


Joined: 08 Oct 2003
Posts: 4498

                    
PostPosted: Thu Mar 08, 2012 7:34 pm    Post subject: Reply with quote

^^^

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).
Back to top
View user's profile Send private message
regne v



Joined: 29 Oct 2004
Posts: 50
Location: Spain

                    
PostPosted: Fri Mar 09, 2012 8:51 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
mathdon
Expert


Joined: 22 Jul 2008
Posts: 4508
Location: Cambridge, UK

                    
PostPosted: Fri Mar 09, 2012 11:31 am    Post subject: Reply with quote

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.
_________________
Graham
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic       JP1 Remotes Forum Index -> JP1 - New Remotes & RDFs All times are GMT - 5 Hours
Goto page Previous  1, 2, 3, 4, 5, 6, 7, 8, 9, 10  Next
Page 8 of 10

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


 

Powered by phpBB © 2001, 2005 phpBB Group
Top 7 Advantages of Playing Online Slots The Evolution of Remote Control