JP1 Remotes

Mathdon, thank you. Very helpful in several ways: I dimly perceive that Multiplex might solve our problem, and that toasted toads might not be so impenetrable. Such a pity that will be it, but a lot more to play with and more to look out for

tranx wrote:Such a pity that will be it

Did you have anything else in mind? I am still open to suggestions, but this will complete everything I can think of doing. I am doing final testing on it now, and expect to post it tomorrow for you to try.

Thanks for the offer, but I can't think what else might be useful, unless the presentation of ToadTogs could be improved/dumbed down in RMIR as an alternative to the format of the (standard?) set of options for setting up the four pairs of macros (for each of the 8 ToadTogs). I have assumed that you would have done this anyway, if you considered it worthwhile, but may I explain why I am, at this stage, still puzzled?

You have explained ToadTogs as follows:

...ToadTogs (there are 8 separate ToadTogs available) maintain a state (On or Off) in the remote. Again there are two macros for a ToadTog key. Which is sent depends on whether the current state is On or Off. You also specify whether you want the state to change when the key is pressed. So if you have a power function that is a toggle, you can construct discrete power actions as follows...

So far so good! But this was not quite clear:-

For the ON key, if current state is Off, change it to On and send the toggle function, but if the current state is On, do nothing. Similarly for the OFF key, if current state is Off, do nothing but if it is On then change it to Off and send the toggle function....

By the 'ON key' and 'OFF key', I believe that in the case of a '...power function which is a toggle' (from the first part of the explanation, above), this might mean the current actual/real state which cannot otherwise be registered on the remote, so it needs to be specified in the options for the ToadTog (and also synchronised with the real device itself). Also, by 'if the current state is (on/off)' I think I understand that you refer to the same real 'current states', being thus registered as either on or off. Is that off beam?

The set of ToadTog options may usually be as follows, with my comments and queries about them:-

"Special Function"; "Device"; "key" [i.e. DSM]
e.g. (type) ToadTog [i.e. 'ToadTog key']; "Toggle #" e.g. (0-7) n; "Condition" e.g. (Toggle/ForceOff/TestOnly/ForceOn)
---------------------------------------------------------------
The Conditions (of each 'ToadTog key'):-
1. Re. "Toggle" [is this the way the e.g. Power Toggle function is 'registered'] :-
"Available key" e.g. (key) x [is this the key which carries e.g. the 'Power toggle Function'?]
"On->Off" e.g. (macro): (key) a; (key) b; (key) c......etc.
[in the case of the e.g. Power toggle Function, would this not be the key which carries a single command for that function, rather than a series of keys?]
"Off->On" e.g. (macro): (key) m; (key) n; (key) o; (key) p.....etc.
[in the case of the e.g. Power toggle Function, would this not be the same key which carries a single command for that function, rather than a series of keys?]
------------------------------------------------------------------------------
2. Re. "ForceOff" :-
"Available key" e.g. (key) x
"On->Off" e.g. (macro): (key) a; (key) b; (key) c......etc.
[in the case of the e.g. Power toggle Function, would this not be the key which carries a single command for that function, rather than a series of keys?]
"Already Off" e.g. (macro): (key) m; (key) n; (key) o; (key) p.....etc.
[in the case of the e.g. Power toggle Function, 1.) would this not need to be a key key which did nothing, and 2.) could it be an empty key, rather than a macro?]
----------------------------------------------------------------------------------
3. Re. "TestOnly" :-
"Available key" e.g. (key) x
"On" e.g. (macro): (key) a; (key) b; (key) c......etc.
"Off" e.g. (macro): (key) m; (key) n; (key) o; (key) p.....etc.
[what is the purpose of these options, or would the term 'only' seem to be an obfuscation?
i.e. if the purpose were really to be as stated: 'test only', it would not make too much sense for macro options, being dependent upon such a test, to be provided]
------------------------------------------------------------------------
4. Re. "ForceOn" :-
"Available key" e.g. (key) x
"Already On" e.g. (macro): (key) a; (key) b; (key) c......etc.
[in the case of the e.g. Power toggle Function, would this not need to be a key key which did nothing, and could it be an empty key, rather than a macro?]
"Off->On" e.g. (macro): (key) m; (key) n; (key) o; (key) p.....etc.
[in the case of the e.g. Power toggle Function, would this not be the key which carries a single command for that function, rather than a series of keys?]
------------------------------------------------------------------------------
I am not sure how else to take account of my own bafflements in order to clarify the options though , unless my current understanding is close, in which case it might be better at least to have the explicit option to 'do nothing' where appropriate, in addition to the 'standard' options.

In the same way I can only suppose that the text for the options could better represent what the options might be for, and ask for them to be changed to that end, as you see fit....

Thanks again.

PS I think I see how the option for macros, rather than the single commands which might apply for a PowerToggle function, might suit e.g. to construct discrete input functions in the form of ToadTog macros, where no discrete inputs are provided by a standard device.

PPS After sleeping on it, perhaps the meaning intended for for the word "only" was based on an archaic form, or upon a literal translation of a foreign language, resulting in "one-ly"

Mathdon, still just concerning the format in RMIR for the ToadTogs, which are usually just called 'ToadTog#n' (1-8): might user-editable (i.e. more recognisable) titles be worthwhile instead?

ToadTogs have been around for many years, for many remotes, with the present functionality in RMIR without complaint so I am not inclined to change it. I think your problem is just that I have not got round to writing a manual, as the description is normally in documentation for the extender.

I hope the following will help to clarify it. Either or both macros may be empty, and often will consist of only a single key, or a device key followed by an action key. ON and OFF refer to the state of the ToadTog. Except for Power actions, this will not usually be the state of a real device. Test Only means that the ON/OFF state is not changed, merely tested. There are still two macros. Which will be performed depends on the current state, which will not change. Consider the following. TV/Phantom1 is a Multiplex that switches TV device to the code for one TV, TV/Phantom2 is another Multiplex which switches it to the code for a second TV. You set up the following, both for Toggle #1:

TV/Red: Action=Toggle. Off->On = TV, Phantom2; On->Off = TV, Phantom1
TV/Blue: Action=Test. Already Off = some function you want Blue to do for TV 1; Already On = the function you want Blue to do for TV 2.

The On/Off state of the toggle then represents which TV is active (On=TV 2, Off=TV 1). Pressing Red will switch the remote between the two TVs, and Blue will always do what you want for the selected TV. You can set further keys up similarly to do actions dependent on the active TV.

You speak of four pairs of macros for each ToadTog. Maybe that is the confusion. You use whatever conditions you want for a particular purpose. This may only be one, say Toggle, or a pair, say ForceOn and ForceOff, or many, say Toggle together with several TestOnlys, as in the above example. In ForceOn and ForceOff, the Already On/Off macro will usually be empty.

The setup differs little from setting up any macro, it is just that there are now two macros and which is performed depends on the On/Off state. Separately, the Condition (Toggle, Force On, etc) determines whether the state changes or stays the same.

I think that it will soon become clear when you have the extender to experiment with.

Thanks very much for all that especially:

...in the above example. In ForceOn and ForceOff, the Already On/Off macro will usually be empty.

The setup differs little from setting up any macro, it is just that there are now two macros and which is performed depends on the On/Off state. Separately, the Condition (Toggle, Force On, etc) determines whether the state changes or stays the same.

and this makes sense too:

I think that it will soon become clear when you have the extender to experiment with.

Here is URC-6440 Extender v0.08. This now includes all the Special Functions of traditional extenders, namely DSM, LKP, DKP, ToadTog, Multiplex and Pause. As before, macros can be nested. Note in particular that this allows macros to be nested inside LKP, DKP and ToadTog macros and even for a ToadTog to be nested in another macro. You can't nest an LKP or DKP in another macro, however, as it would make little sense. If you do do so, it will simply have no effect.

For more info on these special functions, see the above posts and the notes at the start of the ReadMe in the zip package.

Pending possible bugfixes, I expect this to be the final version of the extender, simply because it now does everything I can think of adding to its capabilities. I intend to write a better manual for it than the present ReadMe, and when I have done so I will post an announcement also in the Extenders section of this forum.

Mathdon, this is a wonderful Swan Song for the Extender's development. The readme is very clear and concise and helps even more with Multiplex and ToadTog, but will certainly look out for the Manual.

Thank you very much for the ride, and for all the brilliant work, which makes the 6440 a potent weapon indeed!
.

My problem with changing TV tuners Freesat<>Freeview by using two Tv devices was simple to cure with a toadtog. Very useful because it had seemed tricky to return to the right Tv device after resorting to a pvr, but that seemed to be the answer with enough slots for 2 Tv devices, rather than multiplex, which is neatly implemented and a nice extra when device slots run out. In the main devices the shift button already gets plenty of use so LKP DKP haven't featured yet, perhaps because they might seem to be alternatives for doing the same sorts of things. Perhaps it would have all been different if started from scratch with the latest full version.

I have now announced URC-6440 Extender v1.00 in the Extenders section of this forum. It includes a 20-page manual in PDF form that gives details of all the setup procedures available without the use of RMIR, as well as installation instructions and details about the Special Functions.

It differs only slightly from the pre-release version 0.08. The changes only affect macro creation without RMIR. However, this is the official release version and I would be pleased if users of any of the pre-release versions would upgrade to it so that all are using the same version.

I have now posted RMIR v2.03 Alpha 26. This deals with several matters left outstanding while I was developing the extender for the URC-6440.

There is a new entry in the Options menu of RM (not RMIR) for "Separate Save folder". When selected, an Open operation opens in the last folder used to load a .rmdu file and a Save As operation in the last one used to save a .rmdu file. When deleselected, both operations open in the last folder used for either of them. The setting and folders are preserved between instances of RM and the Save As folder is preserved when this option is deselected, so when re-selected, Save As returns to the last folder used before deselection. This option also affects the default Load and Save folders in the RMIR Device Editor, though the option can only be changed within RM. This feature was requested by vicky2003g here and xnappo here.

This version includes an improvement suggested by mdavej concerning macros in XSight remotes. It also fixes the bug reported by CyberSimian concerning the Clean Up button in the RMIR Device Editor.

I have a USB receiver from an MCR remote (VRC-1100) that I used successfully with older URC remotes. I am trying to do an upgrade for my newly purchased OARUSB04G (shows up as OARUSB04G 4000 in RM). However when I load an old upgrade, and try to choose this remote, I get the error that the protocol is manual and it will not work for this remote.

So I choose MCE for protocol, and build the upgrade. The key names match my remote. I add the device to RMIR and then map it to DVD or STB and upload to remote. But it does not work with the USB receiver. The remote works fine with my TV through a code.

What am I doing wrong?

Any help is greatly appreciated.

So I learned the codes from the MCE remote instead. They show up as OrtekMCE protocol after I download from the remote. However, I cannot find such a protocol in RM IR, so I can build an upgrade. Any ideas?

Thanks.

There is no need. Just use our Ortek VRC-1100 upgrade.
https://www.hifi-remote.com/forums/dload ... e_id=10469