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-7781 and URC-7780 Extenders available
Goto page 1, 2  Next
 
Post new topic   Reply to topic    JP1 Remotes Forum Index -> JP1 - Extenders
View previous topic :: View next topic  
Author Message
mathdon
Expert


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

PostPosted: Sun Dec 28, 2008 11:54 am    Post subject: URC-7781 and URC-7780 Extenders available Reply with quote

I have today posted two extenders, one for the URC-7781 and the other for the earlier model, URC-7780. The features are identical in the two extenders. Both are provided in versions for a clean installation (as a .ir file) and for upgrading an existing setup with ExtInstall (as a .hex file). They include the following Special Protocols: Device Specific Macro, Long and Double Key Press, Device Multiplexer, ToadTog and Pause. A detailed instruction manual is included.

The macro format used by these extenders is compatible with recent versions of IR.exe, which the macro format of the unextended remote is not. I believe that if the extender is installed and used with the RDF file included in the package then it is fully compatible with such versions of IR.exe.

The extender for the URC-7781 is unchanged from the one I posted on Oct 30, 2008 but then only the .ir file was available. The .hex file is new to this release, as is the post of the extender to the URC-7780.


Last edited by mathdon on Sun Aug 02, 2009 9:47 am; edited 1 time in total
Back to top
View user's profile Send private message
aberguerand
Advanced Member


Joined: 11 Aug 2003
Posts: 254
Location: Lausanne, VD, Switzerland

PostPosted: Wed Dec 31, 2008 6:21 am    Post subject: Reply with quote

Thanks Graham for your extensive extender !

I use the 7780 version on a daily basis and it works perfectly.
It has so many features that I am far from having tried all of them Laughing
_________________
Alain
Back to top
View user's profile Send private message
aberguerand
Advanced Member


Joined: 11 Aug 2003
Posts: 254
Location: Lausanne, VD, Switzerland

PostPosted: Fri Feb 13, 2009 10:45 am    Post subject: Reply with quote

Graham, I have noticed one problem (or misunderstanding from side) with the 7780 extender.

I have defined VPT to use the AMP device, so that normal presses on mute and vol+/- act on my amplifier, regardless of the currently selected device. This works OK.
I have then defined a SAT device (Dev2), for a receiver that also has its own mute and volume commands. As I do not intend to use the functions often, but would like to have them available just in case, my idea was to assign the corresponding codes to the shifted mute and vol+/- keys, defined as key moves. This works well in unextended mode, but not in extended mode.

a) The extender seems to assume that shift-vol+/- keys are part of the (A)spect group and it sends the Bright+/- codes of the TV device instead. This can be solved easily by adding A_DEV2 to the Dev2 selection macro. Technically, it could be argued whether in SAT mode, a shift-vol+/- corresponds to Bright+/- (available only in TV mode) or simply to shifted versions of the vol+/- keys.

b) The extender seems to assume that shift+mute key is part of the (V)olume group and sends the mute code of the AMP device instead. Here, I have no simple solution without losing VPT.

Would it be possible to consider that shifted keys belong by default to the (O)ther group or alternatively, that a key move always have precedence over the handling of button groups ?
_________________
Alain
Back to top
View user's profile Send private message
mathdon
Expert


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

PostPosted: Fri Feb 13, 2009 4:41 pm    Post subject: Reply with quote

Alain, there are two solutions to your problem. I'll give these first, then explain why the extender works as it does.

Solution 1. Keys are assigned to groups before key moves and macros are checked. Shift+Mute is in the (V)olume group, as you say, so if you create a Key move that maps Key=Shift+Mute, Device=AMP to Key=Mute, Device=Dev2 (SAT) then Shift+Mute will send the Mute signal to SAT when the selected device is any device (and in your case I think that is all devices) to which VPT applies.

Solution 2. Take Dev2 (SAT) out of VPT by including V_DEV2 in the Dev2 device selection macro. Then create Key Moves that map keys Vol+, Vol- and Mute for Dev2 to the same keys for AMP, so efffectively putting these keys, but only these, back in the (V)olume group. Shift+Mute will remain with the SAT device. The difference in behaviour from Solution 1 is that Shift+Mute will remain in the (V)olume group when any device other than SAT is selected. Solution 1 is simpler but it depends on what exactly you want to achieve.

The starting point for the extender was the behaviour of the unextended remote. There, shifted keys are in the same Home Theatre group as their unshifted versions. This places Shift with Vol+/- in the Volume group and Shift with Ch+/- in the Channel group, despite the special treatment of these combinations in non-Home Theatre, where they behave as Colour+/- and Brightness+/- keys that can be assigned to key codes by a setup code for the TV device. I felt that if I had a TV in which Shift+Ch+/- acted as Brightness+/-, then I would want them to act in this way whatever device was selected, just as VPT enables Vol+/- and Mute to act on a single device, regardless of which device is selected. So I gave these combinations special treatment in the assignment of keys to groups, and put them in the (A)spect group, assigned to TV by default. For all other keys, the Shifted version is in the same group as the unshifted one, as it is in the unextended remote. I felt that there was enough flexibility to over-ride default behaviour that this should not cause problems to those for whom it was not appropriate.

My two solutions are both theoretical, but that is what is supposed to happen. If they don't work, please let me know. It would be nice to know, too, if they DO work.

Graham
Back to top
View user's profile Send private message
mathdon
Expert


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

PostPosted: Sat Feb 14, 2009 7:28 am    Post subject: Reply with quote

I forgot to mention, in the previous post, that shifted (and Xshifted) keys need to be in the same group as their unshifted counterparts in order for Shift Cloaking to work. This is the property that shifted and Xshifted keys perform the same function as the unshifted key unless the shifted version is bound in a Key Move or Macro. If the unshifted key is itself bound in a Key Move or Macro, the shifted and Xshifted keys still perform the original function of the unshifted key. So in my Solution 2, you don't need a key move on the Shift+Mute key for SAT. It will automatically perform the function of the unbound Mute key for SAT even though Mute/SAT has been mapped to Mute/AMP.

Graham
Back to top
View user's profile Send private message
aberguerand
Advanced Member


Joined: 11 Aug 2003
Posts: 254
Location: Lausanne, VD, Switzerland

PostPosted: Tue Feb 17, 2009 3:24 am    Post subject: Reply with quote

Thanks for you answers Graham.

For my needs, solution 1 is not appropriate, because I would like to have the same behaviour for all devices that have their own volume settings (SAT, TV, MediaCenter). That is mute -> AMP mute, shift-mute -> current device mute. With solution 1, shift-mute would always trigger SAT mute.

Solution 2 works, but practically implies getting rid of VPT.

I find the VPT behaviour (also in unextended mode) not being very logical as regards key moves and macros. If the user explicitely defines a key move on a specific key, the remote should execute it regardless of VPT or should not accept it to be programmed if it is never to be executed. Would giving priority to key moves over xPT be difficult to implement in the extender ?
_________________
Alain
Back to top
View user's profile Send private message
mathdon
Expert


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

PostPosted: Tue Feb 17, 2009 8:05 am    Post subject: Reply with quote

Alain, giving key moves priority over VPT would not be possible without a substantial redesign of the extender. There really is no such thing, in the extender design, as "the selected device" even though I use the term in my Instruction Manual. I explain this below in more detail. However, I have another solution that I think should work and meet your needs.

Solution 3. Don't use VPT but achieve the same effect with three macros:

Vol+ = X_DEV2, XShift-Vol+
Vol- = X_DEV2, XShift-Vol-
Mute = X_DEV2, XShift-Mute

Since the keypresses XShift-Vol+ etc are not bound, by Shift Cloaking they will perform the action of the unshifted key, which will be applied to Device 2 because of the X_DEV2. This effectively gives VPT, but Shift-Mute will perform the Mute action for the V(olume) device, which without VPT set is the same as the O(ther) device. If you also set

Shift-Vol+ = XShift-Vol+
Shift-Vol- = XShift-Vol-

then the same will happen (it doesn't matter what the A(spect) group is, as a macro doesn't look at the device) but the unshifted action, i.e. Vol+/-, will be applied to the V(olume) device, which is the same as the O(ther) device, and I think you have achieved everything you want. You shouldn't need any device selection macros. Do post a message as to whether or not this works.

Now to why your suggestion would involve a substantial redesign. The unextended remote has a memory slot into which it puts the setup code for the device selected via the LCD screen. Its key processing checks to see whether your keypress is one that is within the scope of VPT, and if it is, and VPT is set for the selected device, then it uses the VPT device instead.

In the extender there is an array of slots, one for each button group. What is selected is a device for each of these slots. What you select via the LCD screen gives the device for the O(ther) group. The devices for the other slots are determined by the macros bound to the Devn "keys", subject to defaults. VPT (as set in the unextended remote) gives the default device for the V(olume) group, which is then treated in the same way as any other button group. When you press a key, it is processed for the device assigned to its button group. It is this combination of key and device that is checked for key moves, special protocols and macros.

You are effectively asking that every key is treated as being in the O(ther) group for key move and special protocol processing. (Put that way it doesn't seem as much of a redesign as I first thought.) I will think about this to see what are its advantages and disadvantages, for there are likely to be disadvantages as well. It is clearly possible but I will need to persuade myself that the advantages outweigh the disadvantages. I think my Solution 3 should meet your immediate need.

Graham
Back to top
View user's profile Send private message
aberguerand
Advanced Member


Joined: 11 Aug 2003
Posts: 254
Location: Lausanne, VD, Switzerland

PostPosted: Fri Feb 20, 2009 3:26 am    Post subject: Reply with quote

Thanks Graham, solution 3 (partially) works.

I have disabled VTP in IR.

My AMP being on DEV4, so I created the 3 macros :

Vol+ = X_DEV4, XShift-Vol+
Vol- = X_DEV4, XShift-Vol-
Mute = X_DEV4, XShift-Mute

that replace VPT.

For each other device, I have defined a selection macro :

Dev1 = V_DEV1, A_DEV1 (TV)
Dev2 = V_DEV2, A_DEV2 (Sat)
etc.

What works is that thanks to Shift cloaking, pressing shift-mute on each other device will trigger the device specific mute. This however does not work for Vol+/Vol-, I presume that the remote does not consider shift+Vol+/- as the shifted variants of Vol+/-, but rather as Color+/-.
So I have assigned the device specific shifted Vol+/- codes for each other device as key moves to Color+/- (actually done in RM), everything then works as I want.
_________________
Alain
Back to top
View user's profile Send private message
mathdon
Expert


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

PostPosted: Fri Feb 20, 2009 7:29 am    Post subject: Reply with quote

Alain, you wrote

Quote:
What works is that thanks to Shift cloaking, pressing shift-mute on each other device will trigger the device specific mute. This however does not work for Vol+/Vol-, I presume that the remote does not consider shift+Vol+/- as the shifted variants of Vol+/-, but rather as Color+/-.

Yes, you are right that Shift-Vol+/- will be interpreted as Color+/- and so act in the context of the A(spect) group. But the other two macros I suggested, namely

Shift-Vol+ = XShift-Vol+
Shift-Vol- = XShift-Vol-

should take care of that. Shift-Vol+/- (or equivalently Color+/-, they are synonyms for the same key code) should trigger these macros, whatever button group they are in, and Shift Cloaking should make the XShift-Vol+/- send the Vol+/- signals for the V(olume) group device which, without VPT, will be the "selected" device. (It's only Shift-Vol+/- that gets special treatment, XShift-Vol+/- is in the V(olume) group and Shift Cloaking should apply.)

Could you confirm that you have tried that and it doesn't work. I'll then look into my extender code to see what goes wrong.

BTW If you have VPT turned off then you shouldn't need the V_DEV1, V_DEV2 etc in the selection macros. With VPT off, these should be the defaults. Again, if that doesn't seem to be the case, please let me know.

What definitely comes out of this is that I should provide a setting to turn off the default assignment of the A(spect) group to TV (Device 1), just as one can turn off VPT.

Graham
Back to top
View user's profile Send private message
aberguerand
Advanced Member


Joined: 11 Aug 2003
Posts: 254
Location: Lausanne, VD, Switzerland

PostPosted: Fri Feb 20, 2009 1:25 pm    Post subject: Reply with quote

Graham,

of course you are right on both counts.
Defining the Shift-Vol+/- macros as indicated correctly handles the case (I didn't RTFM Embarassed ).
The V_DEVx in the device selection macros also are not necessary when VTP is off.

BTW, I have been using IR 8 beta since you made it public and it works perfectly with the 7780 provided RDFs. The only problem I have is backward compatibility of the new RDFs with IR < 8 and RM, but devices created with in RM with older versions of the RDF work in IR 8 beta.

I am eagerly for the next version of IR and its announced handling of clock settings Wink
_________________
Alain
Back to top
View user's profile Send private message
unclemiltie
Expert


Joined: 21 Jan 2004
Posts: 1769
Location: Pittsburgh, PA

PostPosted: Fri Feb 20, 2009 2:46 pm    Post subject: Reply with quote

Alain

The clock setting stuff is way cool...... I've tested for Graham IR8beta5 with the 15-100 extender and the clock set works perfectly. I know he's got it working on his extenders as well.


-bill
_________________
this JP1 stuff is a sickness!
Back to top
View user's profile Send private message
aberguerand
Advanced Member


Joined: 11 Aug 2003
Posts: 254
Location: Lausanne, VD, Switzerland

PostPosted: Thu Mar 05, 2009 12:54 pm    Post subject: Reply with quote

Graham,

I have tested extender A2 with IR 8.00 Beta 5, and so far it works as advertised.
Exclamation It is really convenient not to have to set the language/time after each upload. Exclamation
The installation of the upgrade is not what I would call trivial, but provided your extensive and precise documentation it went without problem, all the extender A1 settings were restored.

Thanks again for your great work !
_________________
Alain
Back to top
View user's profile Send private message
zulfi



Joined: 20 Mar 2008
Posts: 15
Location: Helsinge, Denmark

PostPosted: Sun May 17, 2009 3:17 pm    Post subject: Reply with quote

Hi Graham!

It's really nice work - thanks for that. You've really improved the 7781 with the extender. It's months since I first downloaded the extender, but not until now I've managed to setup my remote/your extender to perfection, but it was really worth the patience...

Nevertheless I have a couple of questions/suggestions...

1) Is it possible to "cancel" the assigment of the aspect group (or at least the 16:9 button), so these buttons can be used for the other devices? The reason for asking is, that I never use these functions on my TV, and I would really like the possibilty to use the buttons for other purposes.

2) In the special protocol section, is it possible to add an "any device"-option in the field where you choose the device for the bound key? The reason for this is, that I want a shortcut to the same macro no matter which unit is currently selected (for this particular case a "turn everything off"-macro), of course I have acchieved this by creating a LKP in every unit activating this macro - but it would be convenient with the possibility to choose "any device"...

3) more phantom keys - I guess this is impossible because of hardware limitations, right? Sad

4) How does this "automatic clock set" after upload work?

No matter what - thanks for the great job! Just the manual must have taken days to complete... Smile

Regards
Rasmus
Back to top
View user's profile Send private message
mathdon
Expert


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

PostPosted: Mon May 18, 2009 6:59 am    Post subject: Reply with quote

Hi, Zulfi

Glad you like my extender! About your questions:

1) You have to "cancel" the Aspect group separately on each of your devices, by adding A_DEVx to the selection macro for device x.

2) You can achieve your aim by creating your LKP for just one device and then creating a macro that runs this LKP for all devices. See section 10.8 of the manual (Global Use of Special Protocols).

3) Yes, I can't add more "real" phantom keys as there are no more useable keycodes, but unless you really need to use X-Shifted keys you can turn off access to X-Shift from the physical buttons so that all the X-Shifted buttons become additional phantom keys. I make great use of this for my own setup. See section 7.5 of the manual (Changing the Shift buttons and the Optional Nature of X-Shift). If you still need 3 functions on one key you can do what I do - put an LKP on the key to give two functions and use Shift to give the third.

4) Automatic clock set requires Extender A2. This was ready for release when it was found that the URC-7780 locks up if an invalid setup code is uploaded to it (a problem with the remote itself, not with the extender, and one that is not present in the URC-7781). This ultimately led to Code Validation being put into IR 8.00. I've never got back to the extenders since then. You've given me a prod and I will do so shortly. Alain has an advance copy of Extender A2 for the URC-7780 for testing, hence his message about it.

Don't worry about losing your careful setup! Extender A2 is an upgrade to A1 and all your settings are preserved. With extender A2 you need never leave the extender unless you want to abandon it. In addition to automatic clock setting, you can enter long magic keypress setup from within the extender, and when you change batteries you are returned to the extender automatically.

If you have any more questions, do please post them here.
__________________

Graham
Back to top
View user's profile Send private message
Paul419



Joined: 08 Nov 2008
Posts: 24
Location: Bristol, UK

PostPosted: Sun Aug 02, 2009 4:54 am    Post subject: Reply with quote

Graham

I am now using your extender with my 7781. I like it very much. Thank you for your work on it.

Regards
Paul
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 - Extenders All times are GMT - 5 Hours
Goto page 1, 2  Next
Page 1 of 2

 
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
Get Smart! the band's official homepage Rockabilly Central