JP1 Remotes

Anthony_Patrick · Joined: 13 Oct 2006 Posts: 104 Location: Burnaby, Canada

Sorry for the confusion, I should have been referring to device specific macros (ie: DSMs / LKPs / DKPs) in my prior posts in this thread rather than referring to these as keymoves (which they are really not). Indeed "both" types of macros are checked for a "fit" before any "keymoves are checked. I'll go back and edit my posts accordingly.

The behavior I am seeing on the extender for my Comcast 1167 JP1.3 is that it executes the "first fit" macro that it finds before checking for keymoves and then checking for upgrades. If a device specific macro precedes the non-specific macro as stored within the remote's memory it will execute the DSM / ToadTog / LKP / DKP before it finds the non-specific macro. This is a very useful behavior and I have made many good uses of it.

... Tony

pH7_jp1 · Posted: Sat Apr 16, 2011 7:00 pm Post subject:

Once I thought I might need to solve this problem, but I found the CH+, CH- would put my Insignia into the Antenna mode.

If that had not worked, the next possibility I intended to investigate was to see if it were possible to write a special protocol that could calculate the number of input change commands and issue them. I never even got far enough to investigate the issues. Is is possible for a special protocol to maybe use 3 of the toadtog bits to track the current state? Other than storage of the current state, I think the rest is possible.

vickyg2003 · Posted: Sat Apr 16, 2011 9:07 pm Post subject:

Anthony_Patrick · Joined: 13 Oct 2006 Posts: 104 Location: Burnaby, Canada

IR 8.03 has an option on the "Advanced Menu" to prioritize macros. When you select this, IR sorts the non-device-specific macros ahead of the device specific macros (ie: ahead of the simple DSMs, ToadTogs, LKPs, DKPs). I tried this once and it "broke" all my remote programming; I can't imagine any reason to use this.

In any case, I would argue against searching for keymoves before searching for device specific macros, this would break many things. Most keymoves are "inserted" by KM or RM when mapping keys to functions. The ability to program a device specific macro (ie: simple DSM, ToadTog DSM, LKP DSM, DKP DSM) to intercept a keypress and then using a shift cloak to "press" the underlying key is a very powerful technique to get the remote to control a system of multiple devices.

The best type of search would be from most specific to least specific searching for potential overrides first. IE:

1. Device specific macros (simple DSMs, ToadTogs, LKPs, DKPs)
2. Device specific keymoves
3. "Non device specific" macros (the old vanilla UEI style of Macro)
4. Fav
5. Upgrade setup devices
6. Internal UEI setup devices

The current extenders seem to switch 2 and 3 - probably so the macro area doesn't have to be searched twice. I think this is better than switching 1 and 2 which would make programming the remote for a system of devices almost impossible. Most of my DSMs intercept the keypress, do what they need to do, and then do a shift-function (shift cloaking) to "press" the underlying key and I don't need to worry if the underlying key was set by a keymove, an upgrade, or is simply builtin.

... Tony

Anthony_Patrick · Joined: 13 Oct 2006 Posts: 104 Location: Burnaby, Canada

Based on the suggestions that I received from all you kind folks, I have worked out a mechanism that I think may work which uses toadtogs to track and switch the input states of my TV (going back to my very original post on this thread). Details follow - please tell me if I am totally "out-to-lunch" or if this is a sensible approach:

1. Assign one toadtog bit for every state to be tracked. The "on" toadtog is used to identify the "active" input state.

2. Assign four families of keypresses to track and toggle states and to send the actual IR commands.

3. Assign the four keypresses for every toadtog bit (or state to be tracked) as follows:

3.1 Keypress is: shift-<number> on device=TV which means "Switch TV to Input <number>"
3.1.1 underlying toadtog is ForceOn(bit<number>)
3.1.2 if originally off do:<family 2 keypress for input <number+1>> to start search for previous input state.
3.1.3 if originally on do: nothing (the correct input state is already setup)

3.2 Keypress is: <family 2 keypress for input <n>> device=TV which is used to search for the previous input state.
3.2.1 underlying toadtog is TestOnly(bit<n>)
3.2.2 if off: <family 2 keypress for input <n+1>> to continue searching for previous input state
3.2.3 if on do: <family 3 keypress for input <n>>

3.3 Keypress is: <family 3 keypress for input <n>> device=TV which is used to deactivate previous input state.
3.3.1 underlying toadtog is ForceOff(bit<n>))
3.3.2 if originally off: nothing (this should never happen but if it does the processing simply stops)
3.3.3 if originally on: <switch to this device and send keypresses (such as discrete power-off) to deactive this input>, <switch back to TV>, <send family 4 keypress for input<n>>

3.4 Keypress is: <family 4 keypress for input <n>> device=TV which is used to send "next video-input" IR command to TV until selected input state is reached
3.4.1 underlying toadtog is TestOnly(bit<n>))
3.4.2 if originally off: <next video-input keypress>, <pause keypress>, <family 4 keypress for input<n+1>>
3.4.3 if originally on: <switch to this device and send keypresses (such as discrete power-on) to activate this input> (end of processing)

My assumption is that the new toadtog state is set before any of the toadtog selected keypresses are executed. Can someone verify this?

This technique requires that one of the toadtogs must initially be switched on otherwise it goes into a loop. Something like shift-0 could be used to set a default state (toadtog bit) for the TV tuner input without doing anything else. The remote can synchronized to whatever TV input happens to be active by cupping your hand over the IR transmitter and pressing shift-<number> where the number corresponds to the active input.

To make this technique work for me, two things are needed:

- an additional 7 toadtog bits (I have already used four for discrete power on / off for each of four devices). This would bring the required number of toadtog bits to 11 and the documentation I have says I can only use 8. If I add another ToadTog device, do I get another 8 bits? How do I set this up in IR?

- more macro memory. The 28 DSMs for this program will exceed the amount of free macro memory. I have "scads" of upgrade memory available but only 224 bytes of keymove/macro memory left. Can the "partition" between keymove/macro memory and upgrade memory be moved?

I'm still open to other ideas as this technique consumes gobs of remote memory, and does not follow the KISS (Keep It Sweet and Simple) principle.

... Tony

Anthony_Patrick · Joined: 13 Oct 2006 Posts: 104 Location: Burnaby, Canada

pH7_jp1 · Posted: Mon Apr 18, 2011 2:49 pm Post subject:

I have a Magnavox that behaves similar to yours and this works:

Hit "1", "OK", and then "Source" a fixed number of times get the desired input. The first 2 buttons put it in TV(Antenna) mode and then it is a known number of hits on "Source" to get to the one you want.

Anthony_Patrick · Joined: 13 Oct 2006 Posts: 104 Location: Burnaby, Canada

cauer29 · Joined: 03 Feb 2010 Posts: 236

pH7_jp1 · Posted: Thu Apr 21, 2011 2:25 pm Post subject:

The very last post on the Harmony site says:

Anthony_Patrick · Joined: 13 Oct 2006 Posts: 104 Location: Burnaby, Canada

I finally gave up on trying to outsmart the N3260W TV input selection. There are no discrete codes for input selection and there is no reliable way to pin down the current input selection - so you don't have a starting point.

I ended up by front-ending the HDMI input with a multi-port HDMI input selector that supports discrete input codes from its remote. These HDMI switchers have gotten really cheap (see: http://enjoygadgets.com). I simply incorporated the appropriate input selection when I do device selection and that completely solved the problem. I posted the KMs for controlling the "EnjoyGadgets" HDMI switchers in the "File Section" - "Device Upgrades" - "Audio/Video Selectors" under "EnjoyGadgets xxxxx" (there are two upgrades - one for a 3 port switcher and the other for a 5 port switcher).

... Tony

eferz · Posted: Sat Oct 15, 2011 2:19 am Post subject:

vickyg2003 · Posted: Sat Oct 15, 2011 6:28 am Post subject:

gfb107 · Expert Joined: 03 Aug 2003 Posts: 3411 Location: Cary, NC

Discrete means separate, distinct, or individual. So a discrete code just means there is an individual code to perform a particular function, as opposed to a code that toggles a state (POWER,MUTE)) or cycles through a sequence of states (INPUT) . It makes no difference whether they are present or not on the OEM remote, although they frequently are not.
_________________
-- Greg
Original RemoteMaster developer
JP1 How-To's and Software Tools
The #1 Code Search FAQ and it's answer (PLEASE READ FIRST)