Atlas OCAP extender 2.13 DSM problem

pH7_jp1 · Post by **pH7_jp1** » Sun Mar 11, 2012 8:57 am

https://www.hifi-remote.com/forums/dload ... e_id=10807

In troubleshooting a completely different problem, I broke things down to what should have been a simple test and found this problem with DSM.

I am using IR version 8.03, and the 2.13 verstion of the Atlas OCAP extender.

My zip file contains 2 IR files: DSMtest.ir and TOGtest.ir. The problem is that the DSM on PIP CH- that is invoked from each of the device macros, does not send any command. As a matter of fact, just pressing the PIP CH- button does not send any command either. Just as a something to try, I changed all 5 DSMs to TOADTOG with the same function on both sides of the TOADTOG. This worked fine! This file is TOGtest.ir in the same zip file.

Just in case it matters, I am using a Time Warner Atlas OCAP identified as 1056B01 on the back.

pH7_jp1 · Post by **pH7_jp1** » Tue Mar 13, 2012 12:01 pm

Additional information - I tried the same thing with a 15-100 and had the same results. So, either this is a bug for several extenders, or I am just making some stupid error in what I thought was a pretty straightforward test. Unfortunately, the latter seems more likely. So, I would appreciate it if someone to either point out my mistake, or confirm that there really is a bug.

unclemiltie · Post by **unclemiltie** » Tue Mar 13, 2012 4:01 pm

The source code for all of the JP1.3 extenders is the same for DSM so if this is a bug they will all behave the same way. (if its a feature it will as well!)

I'll try to take a look at this some time in the next day or so to see what is going on.

unclemiltie · Post by **unclemiltie** » Wed Mar 14, 2012 1:49 pm

This is going to have to be labeled as a "limitation" on the extenders since I can't figure out a way to fix this. The root cause is that the unextended remote thinks that your DSM that has only one key in it is a "key-style" key move and processes it different than it does the normal $04 length key move (actually any length that is not $03)

A work around is to put a second key in the DSM that does nothing

The details:

In the newer remotes based on the Samsung processor, UEI introduced a new key move style that does a key substitution instead of a direct substitution of a two-byte hex value. The remote determines which one you have by the length of the key move. $03 is the key-style (two bytes of setup code, one byte key) and $04 is the normal-style (two bytes of setup code, two bytes of hex data)

Since your single-key DSM shows up as a length $03, the remote tries to load the setup code for the DSM but when it does it finds that the DSM has no "keys mapped" and returns an error so the key move is ignored (you don't even see a blink) and the remote returns to the extender to go process the next key or wait for a new key press.

There really is no way that I can think of to fix this in the extender and I'm going to have to list this as a limitation on all of the JP1.3 extenders that the minimum length of any of the special protocols is $04 in order to be processed properly.

Anthony_Patrick · Post by **Anthony_Patrick** » Thu Mar 15, 2012 12:59 pm

Ditto - I had the same problem on the Comcast URC-1167 JP1.3 remote. My workaround was to prefix a key that really didn't do anything before the target key that I needed. I must confess that I never did trace the problem to its root. I now understand what is going on.

BTW: I use "single key" DSMs to reference phantom keys in device upgrades whenever I use the device multiplexor. This technique allows me to remap any key functions, that would normally generate a keymove, to a phantom key. With this technique, all my multiplexed devices co-exist in peace. The DSM simply redirects the keypress to the appropriate phantom key and depending on which device has been setup by the multiplexor, the appropriate IR code is transmitted - specific to the device as selected by the multiplexor.

My suggestion would be to embellish RMIR (and possibly IR if that is still being supported) to issue a warning/error whenever a DSM using a single key is attempted on a JP1.3 remote.

Post by **mathdon** » Thu Mar 15, 2012 5:33 pm

unclemiltie wrote:There really is no way that I can think of to fix this in the extender and I'm going to have to list this as a limitation on all of the JP1.3 extenders that the minimum length of any of the special protocols is $04 in order to be processed properly.

This isn't a new problem, nor is it confined to JP1.3 extenders. My 2008 manual for my URC-778x JP1.2 Extender includes the following:

There is one important proviso. A device specific macro must contain at least two keys or it will not take effect, If you only want one key in your macro you must add the Null key from the list of available keys.

If you don't have a Null key in the JP1.3 extenders, perhaps that might be a useful addition. I agree with you that there is no way round the issue other than to add into the macro a key that has no effect.

unclemiltie · Post by **unclemiltie** » Thu Mar 15, 2012 5:38 pm

I was wondering if other extenders suffered the same effect. Even as far back as the 6131 old style they had the key-style and normal-style key moves. I'll bet that this is an issue back on those extenders as well.