JP1 Remotes

[DGG]

With a little difficulty, I've now programmed my extended 8911 to do just what I want. While some of the things I did are pretty routine, e.g., system set-up for each device mode, I used Toadtogs to record system mode so that I can momentarily use the full remote to "talk" to any device, but, with a single button push, restore the remote to the proper Home Theater configuration (which might not be unique but is pretty neat nonetheless).

As I noted, I had a couple of tool problems along the way. The first was an error in the latest RDF, which I previously reported. The second has to do with IR, and I'll leave it to the experts to decide whether it's a bug or a feature. In either case, upon changing my TV from device type=TV to device type=Cable, (in order to save a few keymoves), IR updated all the keymoves that had been configured automatically by KM (e.g., assignment to SHIFT keys). However, it neither updated nor warned me about keymoves for the previous TV device that had been entered from IR (e.g., assignment to xs keys) and which I still needed with Cable. That had me "chasing my tail" for a day or so.

Under the heading of "wouldn't it be nice to have", I'd like to suggest:
- KM be made extender-aware, so that all keymoves can be done from one place, perhaps even integrating KM and ExtendCodeCalc functionality
- button names in both KM and ExtendedCodeCalc be user- programmable, like function names in KM,
- combining the functions of the Calculator and Breakdown pages of ExtendedCodeCalc on one page to avoid having to copy/paste between them,
- replacing the hex data in the HexCmd column on the IR Keymove page with a list of the corresponding buttons; (since IR uses the RDF file, I wouldn't expect this translation to be difficult); the hex data would still be available form the Keymove Edit dialog; this would significantly assist debug activity;
- if the information is available within the remotes, create another special protocol that would issue one set of commands and start the shift timer, and then issue another set of commands upon expiry of the timer; this would allow for shifting/restoring of a whole keyset or, indeed, all the keysets; and finally
-allow optional entry of a second instance of the Toadtog protocol to allow another 8 bits to be managed.

But, even without these "nice-to-haves", you guys have done a terrific job in developing these tools.

Thanks,
Don

[The Robman]

Did we establish that the URC-8911 is the Canadian version of the URC-8910, and is otherwise identical? I forget.
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!

[DGG]

Following is the response I received from OFA when I asked them the question:

"There is no difference between the URC8910 and URC8911. Or between the URC8810 and URC8811. They are marked differently simply for marketing purposes. Instructions, technology, codes, etc. are the same. Please include all original messages when you reply. Thank you.

Stephanie Young
Ofasupport@ueic.com
E-Services"

[Mark Pierson]

[DGG]

Thanks for the quick comments, Mark.

Re KM being extender-aware, I was thinking mainly of being able to use KM to put pure keymoves on the XS keys, so that all keymoves could be defined in one place, i.e. in KM with its printable key map. (This suggestion is driven by the second problem I experienced.) I appreciate that going further, such a specifying ToadTogs in KM, etc., is a big step - though, it seems logical since DSM's, D/LKPs and ToadTogs are device specific, as is KM. The latter was what I was referring to by potentially "integrating KM and ExtendCodeCalc functionality".

Re button names, the 8910 Extender RDF largely defines (and hence IR displays) real button names - which can be modified in the RDF. KM and ExtenderCodeCalc use standard button names - though the standards sometimes differ, e.g. RDF="HOME_THEATER", KM="Home Theater", ExtendcodeCalc="HT". Allowing users to override standard button names in the latter two tools would allow for consistent naming across all tools. But, admittedly, it's not a big deal; I'm just a fan of "if you mean the same thing, say the same thing."

Re hex data in IR, I wasn't suggesting that keymoves be entered like macros, though, I agree, that would be nice. (If it could, what then would be the need for ExtendCodeCalc?) All I was suggesting is that using the button data in the RDF, it should be possible to translate button codes in the hex data (generated by ExtendCodeCalc) to button names, thus aiding debug activity (or am I the only one who doesn't always get it right the first time). The only alternative, unless one has memorized the button codes, seems to be to go back and forth between IR and ExtenderCodeCalc.

Thanks again,
Don

[Mark Pierson]

[mr_d_p_gumby]

[Mark Pierson]