Hold Time with 2116 Extender 2

[chasman1964]

Since I installed Extender 2 on my 2116, I have occasional problems with keys in macros not being recognized by my satellite receiver (SAT/0855). I have attributed this to the reduced hold time of the extender, but I do not know for sure that that is the problem.

The documentation for the extender says that hold time has been reduced and that no provision has been made for adding any back in. If, for the sake of argument, I want to increase the hold time permanently (for all keys), is there anything I could do to do so? Can any of the protocols be tweaked?

Thanks.

Chasman

[Nils_Ekberg]

There are typically two reasons why commands are not recognized by a device when using an extender.

First, it could be that the macro is processing too fast. You could use the pause protocol between commands to see if that cures it. Or you could rearrange the commands in the macro so other commands cause a slight delay.

The second is less common but happens and that is what you quoted regarding the "hold time" or duration of the signal. You can use device combiner in either KM or RM to create an upgrade and increase the signal duration. Instructions are available within the products on how to use it.

[chasman1964]

Let me be certain I understand what "hold time" is. From what I've read it is the time during which the IR signal is actually transmitted, which is why shortening it might have an adverse affect on the receiving device. Is that correct?

That being the case, if the extender shortens the hold time, then why can't I modify the extender to lengthen it somewhat, knowing that the change will impact all transmissions?

The bottom line is that I do not object to a somewhat increased hold time given the kinds of macros I am using. It seems much more straightforward to fix the "problem" at its source than to try to compensate for it after the fact.

Chasman

[Nils_Ekberg]

Truthfully, even after writing a few extenders I am not even sure where to point you in the code. My guess is that it would require a series of delays in the code somewhere around where it passes the signal to the remote. My second guess is that it would take a lot of code that may not even fit in the size available for the extender code.

That is why we always suggest using the device combiner to add the duration to the signal. With device combiner you don't actually have to combine multiple devices and for that matter you can even just use it for the signals that are a problem. I have actually created one with just one button.

If you decide to take on the effort to add the duration back to the extender I would be interested in how you did it.

[johnsfine]

That being the case, if the extender shortens the hold time, then why can't I modify the extender to lengthen it somewhat, knowing that the change will impact all transmissions?

Because the extender doesn't DIRECTLY shorten the hold time. It is an indirect consequence of other things the extender does that are related to features such as allowing macros to be nested.

It would be a rather complex change to undo the shortening of hold times.

The bottom line is that I do not object to a somewhat increased hold time given the kinds of macros I am using. It seems much more straightforward to fix the "problem" at its source than to try to compensate for it after the fact.

Despite a few inconveniences, I still view the faster macro execution as a major benefit of the extender, rather than a "problem".

If the problem is really hold time, then I think that is a flaw in the protocol executor, or an incompatibility between your device and the protocol executor. In theory, a really short press of a key outside a macro could be just as short. A protocol executor can and should specify a minimum hold time, when the receiving device requires one. We can (and occasionally do) create new protocol executors that differ from built in ones only in specifying a longer hold.

If the problem is really delay between commands (which is more often the problem than hold time) that is best addressed by rearranging or delaying just the steps that have the problem rather than making all steps of all macros slower.

[chasman1964]

Thanks for clarifying the bit about how hold times were reduced. The documentation makes it seem as if reducing hold time was a specific goal rather than a side effect of the design of the extender. Don't get me wrong: I'm delighted with the faster macro speeds, as long as I understand how to correct the side effects.

I am open to the idea that the problem might be with the delays between commands, but if that is the case, I am confused. What I am doing is setting up my device keys so that a long key press sets up all devices required for use of the selected device (a common approach, from what I have read). Here is how I have the pertinent items programmed for my satellite receiver:

Macro XSHIFT-phantom1 = SET_CHAN_KEYS; SET_MENU_KEYS; SET_PIP_KEYS; SET_OTHER_KEYS; SET_LCD

Macro SAT = DEV_SAT; XSHIFT-SAT

Key Move XSHIFT-SAT = LKP (Duration = 4; Short = XSHIFT-phantom1; Long = XSHIFT-phantom1; DiscreteON; DEV_AUD; DiscreteON; Delay(FF); 1 [select SAT input]; DEV_TV; Power)

As you can see, the only signal I send to the satellite receiver is DiscreteON. How would adding delays between commands make a difference in this case?

Thanks.

[johnsfine]

A device requires some delay before or after a command even if the adjacent commands are for other devices. But the required delay is usually so short that the remote couldn't ever get to the next command too fast. If I'm reading your macro right you have extreeme delay before the SAT DiscreteOn and enough delay after it. So you're right. It's so unlikely that you need more delay there that the problem must be hold time.

Extending hold time with the device combiner is moderately well documented in KM and various threads. Extending hold time by hand editing a protocol executor or by reinventing it in PB is less well described in the various threads on those subjects.

[chasman1964]

It became obvious pretty quickly that modifying the extender to do what I wanted was beyond my level of expertise. I was able to get things working using the Device Combiner. Thanks to all for your help.