JP1 Remotes

I have now posted Extender 0.02 for the URC-6440. This fixes the bug in version 0.01 that prevented shifted digit keys from working. It also fixes what I believe to be a bug in the UEI software for the 993 command, the one that sets up Volume Punchthrough. Certainly that command did not give the full control over VPT settings that it does in other recent UEI remotes, as documented in this spreadsheet in the Help Files of the File Section.

With my fix it does now work as described there for newer remotes. However, there is one thing to be aware of in following certain of the spreadsheet instructions. Where an instruction tells you to press a device key BEFORE pressing and holding Setup, on the URC-6440 you need to press the device key AFTER pressing and holding setup but BEFORE entering the 9xx command. I have given full instructions for the 993 command, as well as the installation instructions for the extender, in the ReadMe file in the zip package.

Pressing shift twice then a digit now works fine, thank you very much.

Apart from trying things out, I have just applied favourite channel numbers using DSMs [each consisting of sh-digit (+sh-digit etc.) +ok], on OK and the buttons around it, given that the TV digits had been allocated to the shifted Tv's digit buttons .

The impression is that when the individual shifted macro has completed e.g. 1, 9, ok, that the shift function is cancelled, just as with any other function, and that the 10 sec clock has also been truncated so pressing a different type of button can immediately have its usual effect. All good, and in practice using the list button to implement shift is convenient.

Understanding that unless shift is pressed twice the remote thinks an EFC will follow, it is not clear if the ability to send an EFC is essential or, if some considered it redundant, if that two-press hurdle could somehow (perhaps optionally) be removed.

Given all the options for configuration, while the principle of individual devices is central, for a while I have not needed to use the the device buttons themselves, or the combi buttons, for their intended purposes, equally when the extender is used.

If feasible, it might add flexibilty, with the extender, for the current special functions of the device and the combi buttons to be removed, so that they would become just a set of 5 spare ordinary buttons in each of the four device modes. After all the option would remain for the user to restore the current functions by the usual methods, if required, while they might instead be configured for other purposes.

The special functions of the device and combo buttons are deeply ingrained in the operating system of the remote, so removing them is not a practical possibility.

It would probably be possible to remove the double-press action needed for shifted digit keys, but the ability to send any EFC by pressing Setup then the EFC has been present in UEI remotes ever since they started. I have not actually implemented this, or even Shift action, in my extender. There was a keycode for a standard Setup button (one that is Shift on a short press and enters Setup mode on a long press) already in the remote in addition to the separate WatchTV/Setup key, even though there was no physical button to generate that keycode. All I have done is make a short press of List send that keycode, a longer press send the usual List keycode. In view of it being an almost universal feature until these Simpleset remotes came along without it, I am not inclined to remove it.

Interesting info, which all makes sense. Thank you for explaining.

Found that with the extender:-

An ordinary command or keymove placed on a shifted device button works in the same device mode or in the corresponding combi-mode.

A DSM macro placed on a shifted device button works in the designated device mode.

A global macro placed on a shifted device button works in any device mode (and as usual it can change the device mode).

Mathdon,

Rather than use an extender, couldn't the Setup keycode simply be added to the RDF and used in a keymove so it could be assigned to any key?

mdavej wrote:Mathdon,

Rather than use an extender, couldn't the Setup keycode simply be added to the RDF and used in a keymove so it could be assigned to any key?

I haven't tried it with a keymove, but with macro it doesn't work because remote clears shift flag as soon as the macro ends.

mdavej wrote:Rather than use an extender, couldn't the Setup keycode simply be added to the RDF and used in a keymove so it could be assigned to any key?

It doesn't work, neither does a macro (as Marcin says). I thought of both before writing the extender. A macro does indeed change the current key at each step of the macro, so you can put "Shift, Mute" into a macro and it will send the shifted Mute signal. However, it cancels the shift flags on exit so a macro with just "Shift" has no effect. A key-style keymove in this remote does not change the current key, it looks up the IR signal for the new key and sends it. If there is no IR signal, it does nothing. You are welcome to try it. Just add "Shift=$DD" to the [Buttons] section of the RDF.

I am thinking of turning this remote into an 8-device one by making shifted device keys provide extra devices. I haven't thought it all through yet but I think it should be possible without too much effort. What do you think of this idea?

mathdon wrote:...I am thinking of turning this remote into an 8-device one by making shifted device keys provide extra devices. I haven't thought it all through yet but I think it should be possible without too much effort. What do you think of this idea?

Reckon that would be another substantial enhancement and, as noted, with the extender each of the shifted device keys can already address the current four devices in a DSM or a macro. Then, when the the macro completes, the remote remains in whichever of the current device modes is still current.

Forgive my ignorance but I might earlier have guessed it would only be un-shifted buttons which could be set up as 'device buttons', but would be glad to learn that is wrong.

If so:-
a.) At first sight it might seem that four extra 'device slots' would first need to be made available, so that more devices could be added in [Devices> New> Open], in the 'assigned' device button drop downs, also in the bound key dropdowns in [Special Function (DSM)> New page], and in the [Macro> New page] of RMIR,

b.) then the shifted device keys could either change devices, or do something else, instead or as well, if preferred.

c.) the snag is that the drop-downs show only those Devices which have actually been assigned to a device button, such as the proposed shifted device buttons themselves, so in that case b.) could not work

d.) If b.) were to be considered worthwhile, perhaps a different set of 4 buttons, such as the shifted colour buttons, could carry the new devices?

e.) - but I see that d.) provides no advantage over having the extra devices on the shifted device buttons, as originally proposed!

f.) although perhaps x-shifted buttons, if they exist, whether accessible outside macros (through an X-shift selection button) or not, could could carry the extra devices?

Hi Tranx. At present, you cannot put devices on shifted device buttons. As you say, I will need to create four new device slots and make them available in Macros and for DSMs. That is just a question of amending the RDF. The bigger job is creating the slots in the remote itself and making it recognise them. If I do it, the shifted device buttons will have the same properties and limitations as the existing ones. I haven't tried putting a macro or keymove on them but guess that this would not work. If you can put a macro or keymove on the shifted device buttons at present, that ability would be lost. I think the gain of extra device buttons would be well worth it, though.

If shifted buttons don't give you enough extra button capability, I also have in mind to investigate adding LKP (Long Key Press) capability. Like DSM, this is a Special Function that is available with most extenders for JP1.3 and earlier remotes. No promises, though .

mathdon wrote:...if you can put a macro or keymove on the shifted device buttons at present...

yes it does work now

..., that ability would be lost. I think the gain of extra device buttons would be well worth it, though...

I agree, very much so

...If shifted buttons don't give you enough extra button capability, I also have in mind to investigate adding LKP (Long Key Press) capability. Like DSM, this is a Special Function that is available with most extenders for JP1.3 and earlier remotes. No promises, though

- hope you will be doing that too!

I think we need to be careful with the LKP. Many keys are not suited for such usage, like volume and channed +/- keys and direction keys. I also have usage for long pressing color buttons (I have on screen menu in EventGhost configured to show up on 3 second hold of red button), but I could live without it :).

There is also a slight delay for buttons with LKP as they execute their normal function on key release instead on press.

I have discrete input selection for my TV on shifted device buttons, but I can always use other keys for this. I just set it up as a test.

LKP in other extenders is set up for individual buttons as the user wishes. It isn't a case of making all buttons have a short and long keypress, just the ones the user wishes to use. In those remotes, the delay is also configurable for individual buttons. Whether I can do all that for these remotes remains to be seen, though.

Ah, I thought that they would be available in the same way as the skip buttons (as a separate buttons in RDF). I'm not familiar with pre-simpleset remotes. If this could work like you described then this would be very nice. Also if current skip buttons could be modified to use the new LKP model then it would be even better.

I have now posted RMIR v2.03 Alpha 24g. The changes made do not affect Simpleset remotes but I am mentioning it here just to keep this thread up to date.