JP1 Remotes

Having trouble with macros using the RS-1994 Extender 5. For each device button, I've created a DSM on 1s that selects the appropriate video input on the TV, and on 2s the appropriate audio input on my receiver — it's actually an outboard decoder. That part works just fine.

First issue, if I include a X_Cancel action as the last step of these macros, they don't work. This seems inconsistent with the readme file for the extender.

The bigger problem I'm having is that I am trying to create a macro that combines both the video and audio selection in one macro. When I do this, the macro exhibits odd behavior. If I make the audio selection the last step, that works, but I get no video selection. If I reverse the steps, nothing works.

I've tried about a dozen permutations, but can't make sense of what is going on. Any help would be appreciated. I've post my IR file at:
http://www.hifi-remote.com/forums/dload ... le_id=4372

TIA

The fact that the individual signals work means that you apparently have the correct signals being sent.

The fact that they do not work when embedded in a macro, but usually work when they are the last step of a macro suggests to me that you may be having a duration problem. Since the extender speeds up execution of macros, this is an occassional side effect. When you press the button, the macro races through the command sequence but for the command that is the last step, however long you hold down the button determines how long that LAST signal is sent (protocol-dependent) and that may be why they work in that postion (... in most cases, not sure about the video selection as last step not working ).

If you execute the shortest press you can, does the last step still work for Audio as you describe?

Since you are dealing with discrete signals, hopefully the simplest workaround would be to send the input selection commands multiple times in succession in the macros to see if that gets your equipment to respond.

The problem may alos be the short delay BETWEEN successive signals. Adding a short Pause between commands in the macros might help. There are various tricks for doing this, from inserting meaningless commands (like a few x-shift phantom 3s) to using the Pause Special Protocol and building a keymove that is a pause of duration you choose.

If that doesn't help, then you may need to have an expert tweak your executors for the TV and Switcher to extend the duration of the signals a bit.

Another way to extend duration for a device is to use the Device Combiner Protocol, but that only works for 1-byte protocols and is a very large protocol upgrade (i.e. memory-inefficient) and is probably not an efficient way to accomplish your goal, but would require careful implementation to have two device upgrade calling on that single Device Combiner protocol upgrade.

Thanks Capn Trips. Your assessment is dead on. The problem is with the TV input selection. Unless I hold that macro button (1s) down, it doesn't work. The audio selection (2s) does work — even with a short keypress. And the audio selection macro also works if X_Cancel is the last step.

So, despite what I stated in my original post, the workaround is to make the video selection the last thing I do *and* not to have an X_cancel as the last step, thus allowing the video selection command to repeat. (I probably didn't hold the button down long enough when I tested this originally.)

The ultimate fix, I suppose, would be to modify the protocol. I do have a "leg up", however, in that I am using the protocol Jon Armstrong wrote to correct timing issues for Mitsubishi televisions with NetCommand. The download includes the protocol builder file. I haven't explored this area of JP1 yet. Any tips?

Thanks again for the help.

Well, first of all, there is no reason to use X_Cancel for any of these issues. It is a useful command for other contingencies, but it only uses up memory in this case, so don't use it.

You don't say whether or not you have tried simply sending the same command twice consecutively. That is not a HUGE memory cost (1 extra byte per macro) and does not require re-engineering the protocol.

If the only signals that REALLY exhibit this problem are the ones from that custom protocol, then one of the experts (I've not explored the intricacies of Protocol Builder either) should be able to point out where to modify one of the bytes within that protocol upgrade to extend the duration. Unfortunately, Jon is no longer with us, so somebody else needs to jump in here.

If you post s link to that NetCommand Mits upgrade, it'll make it easier for a potential helper to .. uhhh ... help.

I was using X_Cancel because of the advice given in the readme file for the extender, which, paraphrased, states that if the above example were in a general purpose macro that might be called by other macros, you probably should make the last step X_Cancel. No biggie, if I don't need it, I don't need it.

I did try issuing the same command multiple times, but it didn't fix the problem. Sorry for omitting that fact.

The link to the Mitsubishi NetCommand protocol is:
http://www.hifi-remote.com/forums/dload ... ile_id=933. (Sorry, I assumed this was common knowledge.)

While I have your attention, there's one more thing I'm having trouble with. Ultimately, I would like to have a LKP macro on each device that selects the proper video and audio input when the device key is held down. I can get this to work on a regular button. I can even get this to work for the shifted version of the device key, but not for the device key, itself.

Thx.

TheBudMan wrote:Ultimately, I would like to have a LKP macro on each device that selects the proper video and audio input when the device key is held down

While you still have what you need on the shift-device button, test it out on LKP. If you're not using common code but one/device, the classic design would be something like this (I don't have 1994 so this is 7800 example)
(1) Macro on DVD/LD: V_RCV;M_DVD;C_DVD;O_DVD;T_DVD;P_DVD;Phantom4
(2) Special Protocol keymove on DVD/LD / Phantom4:LKP(3) [Short]:< Blank > [Long]:SHIFT-DVD/LD;VOL+
My Macro on SHIFT-DVD/LD contains one macro of two steps which just line up the TV and audio inputs.

What happens is this: you tap the DVD button there is nothing more to do in LKP keymove on phantom4. Your keysets have been given to DVD and that's it. When you hold the DVD button, the long side command(s) run in addition to the key sets. And if I hold it then the vol+ repeats (actually in 7800 currently it doesn't but it will as in other extenders)

TheBudMan wrote:I was using X_Cancel because of the advice given in the readme file for the extender, which, paraphrased, states that if the above example were in a general purpose macro that might be called by other macros, you probably should make the last step X_Cancel. No biggie, if I don't need it, I don't need it.

Use common code if you can. This from 8910. And it might help you sort out when Dev_Cancel, or X_Cancel in your remote, comes in handy
In the example below, Phantom1 and Shift-Phantom1 just do the keysets for me for any device, and x-shift-phantom1 is just some ToadTog related to device specific sound mode.

(1) Macro on VCR: DEV_VCR;Phantom1;XSHIFT-Phantom1;DEV_AUD;SHIFT-Phantom3
where shift-phantom3 coded for the receiver is reused for few other devices:
(2) Special protocol keymove on RCVR/AMP / SHIFT-Phantom3: LKP(3) [Short]:Dev_Cancel [Long]:Dev_Cancel;Phantom2;XSHIFT-M1
Here you do need Dev_Cancel. And on the long side, phantom2 will be a keymove which belongs to the calling device, VCR in this instance, rather than the receiver. Likewise, xshift-M1 which lines up TV and receiver inputs will go with VCR and not the receiver.

Thanks, Elizabeth. I blindly followed your instructions for how to do this for one device and it worked.

Analyzing your approach, I think I see how it works now — please correct me if I am wrong:

You assign a macro on Phantom 4. The only place it is referenced is from the macro for the device key. Because of this, I can only assume this means that this macro gets executed for both a SKP and a LKP of the device key, and that the appropriate version of Phantom 4 runs. That is, if the device key is a SKP, then the short version of Phantom 4 is used and if the device key is a LKP, then the long version of Phantom 4 is used.

So, when I had the LKP working on the shifted version of the device key (or the other key), I was halfway there. The piece I was missing was tieing the LKP macro to the "device selection macro" for the device key. It wasn't readily apparent to me that a LKP on a button with a macro assigned to it will use the LKP versions of any buttons referenced within that macro (should LKP versions of these buttons exist). This, even though I have read through the "The What and Why of JP1", the "Extender FAQ", and the readme for the LKP protocol several times. Might just be me, but I think this is important enough to spell out. Maybe it could be added to one of the tutorials.

Now for the topic of "common code". I think this is the same concept as what the readme for the LKP protocol refers to as a "Global" L/DKP:

You can include a Long (or Double) Press macro in a regular macro.
This would be useful if you want put two different actions on a
device button. In order to do that, just create an L/DKP macro on a
key move in any device mode and use the X_ temporary device
selection command for that device.

It's not that it's really global, it's just that it's defined in one place, i.e., one button on one device, and we get to it by temporarily selecting that device before calling the subroutine. Thus, the need for the X_Cancel, so as not to disrupt the original "call stack". (Assuming this to be true, I think the term "common" is more appropriate).

Thanks for the lessons.

[EDIT - Rob]The Dish Network ViP211 discussion split off to this thread:
http://www.hifi-remote.com/forums/viewtopic.php?t=8153