JP1 Remotes

[ek2116]

Hello,

I'm using using extender 2 with a 2116. Here's
my question.

1. Why are shift functions included in the key
moves table after adding a device upgrade? Is there
any way to include the shift functions as part of
the device upgrade without affecting the move/macro
memory?

2. In the key move tab of KM, what is the difference
between the Bound Device, the Device Button and the
Device Type?

3. Are protocols used to convert the electrical signal
generated by the button press into an IR signal that is
recognized by the receiving component?

Thanks for your help.

Eric (there are two Erics in here)

[The Robman]

[wwwoholic]

1. The term "shift functions" in KM means basically "function performed when shifted button is pressed". You have a set of "functions", each representing particular code to be sent to the device. Device recognizes this code and performs corresponding function. The whole point of JP1 software is to assign these functions to some buttons of the remote.
Controlled devices are grouped into "types". Some remote's buttons do not work with particular device types. This is design restriction, which does make some sense. e.g. PIP controls have nothing to do with CD players.
Extenders solve this problem, allowing you to assign functions to non-working or even non-existing (shifted, x-shifted) buttons. However this requires keymove to be introduced on that key. And no, there is no other way around. After all, you have to store something somwhere to let remote know what you want it to do.

2. Bound Device means this keymove is created for this device only; it will work when you select this "bound" device using "TV", "SAT" etc. buttons. Note, that extender2 broadens this definition a little.
Bound Key is the key to be pressed (when bound device is selected) in order to execute the function.
Device Button is one of those "TV", "SAT" ... buttons. Remote's manual calls them "modes"

3. Electrical signal generated by button press triggers execution of some software code in remote's MCU. This code finds corresponding data byte(s) first, using key maps, current selected device etc. Then it uses protocol associated with this device to encode and transmit data through IR.

[wwwoholic]

whoops... Sorry Rob, I'm a slow typist

[ek2116]

Thanks very much for your replies. Here's one more (I wish I could
promise there won't be any others, but I can't).

BTW, this is a ridiculous little hobby, but it sure is addictive.

[asinsh]

[The Robman]

[wwwoholic]

[ek2116]

Well, I'm trying to master the logic. What I'm saying is, I think,
within the context of ext2 DSMs. Maybe I don't understand DSMs.
The way I understood the ext2 DSM doc, it said I could include
several hex commands in a keymove as a DSM. So I was asking
if I could nest keymoves that are bound to different devices by
inserting the hex command for the keymove in the next level
up (don't know why I'd want to, I'm just trying to
see what strategies are available).

Example: Can a keymove (DSM), bound to Device X, that executes
a sequence of commands, include a keymove (DSM) for
Device Y if the keymove for Device X includes the hex command
DEV_Y and the hex command for the keymove that is
bound to Device Y?

Now I'm really confused. Did that make any sense?

Eric

[johnsfine]

[wwwoholic]

[wwwoholic]

Double whoops... With my rate of typing by the time I submit a post one of the experts is already there
I should stop typing and start reading...