Atlas 3000 & 3033 JP1.3 extender

greenough1 · Post by **greenough1** » Thu Nov 13, 2008 11:05 am

Hi Uncle,
I'm 99% sure, but when I get home, I'll verify for sure.

When switching between CBL and TV, I can see when the input selection is changed by the OSM of the TV (0 is for Antenna 0, 4 is for HD cable box), relative to the keypress.

Best,
jeff

unclemiltie · Post by **unclemiltie** » Mon Dec 22, 2008 1:55 am

I'm getting back into the extender since I've decided to try the 1056 backlit again for my main remote. I wanted to update it with some of the features that I had built into the RS 15-13x extender, primarily moving the special protocol code out of the upgrade area to give more space.

I'm almost done with this code and will likely be testing it tomorrow. While I'm at it, there is one further enhancement that I could make before I release the new version and a question on versioning for the group

First, the current extender defines 6 phantoms and Don/Doff. These cannot be shifted or Xshifted because of the key layout. However, there is room for another 10 or so phantom keys (that also could not be shifted/xshifted) if I want to move things around. When I first built the extender, I figured 8 phantoms (6+discretes) was probably enough, but if we need more I can move things around. (if I do this, see next item)

Second, because I'm moving the code around a good bit, this is not an extender that you can use to upgrade current configurations with Extinstall. (It may work, but there is a lot of changing going on so I'm not going to even consider it. ) In addition, if I move keys around, this will make this issue worse. Right now, the released version is 1.01. Since this version of the extender really doesn't change that much in the code, I should name this 1.02, but to give the impression that this is a major upgrade, should I label it 2.00?

feedback welcome either here or via PM I'll probably finish up the work some time in the next couple of days.

-bill

BTW, there are some issues with the current RDF's for 1.01 in that the Phantom keys aren't defined right so that you can't Shift/Xshift them and it causes RM a bit of confusion. This is fixed in the next version.

Capn Trips · Post by **Capn Trips** » Mon Dec 22, 2008 5:08 am

Bill,

Eager to try a new and improved version. Although I have had precious little time to confirm (as others seem to have) that my issues with inconsistent device selection behaviour in earlier versions of the extender are really resolved, if you're making a major change, here's a niggle that I wonder if you could help correct.

In the current version of the extender, DicreteON is included in the button Map for some device modes (Can't check while at work, but I believe that in CBL device mode, D-ON is part of the KeyMap while D-OFF is not.) Therefore, D-OFF must be a KeyMove. My problem arises when I have to multiplex devices. I can only have ONE KeyMove assigned to a button per device mode and it doesn't change with multiplexing, so the multiplexer will switch the D-ON with it for the new device, but I have to come up with an awkward workaround to access D-OFF for multiplexed devices (in fact I HAVEN'T come up with a satisfactory workaround).

I see a couple of unused but defined Keys that are in the keymap (like Button41). Is it possible to define two of the phantoms to be included in the KeyMap for at least one device type (CBL is fine) so that I can have my D-ON and D-OFF switch along with the rest of the device when I multiplex?

As to numbering, if to the user the change will be substantial, I'd go with version 2.0 rather than 1.2 - imho.

mdavej · Post by **mdavej** » Mon Dec 22, 2008 8:48 am

Bill,

I vote for 2.0. If you are able to provide access to the backlight toggle somehow, that would be a nice enhancement as well.

greenough1 · Post by **greenough1** » Mon Dec 22, 2008 11:04 am

Capn,
The inconsistent device selection issue appears resolved. I'm using pause toadtog, and LKP in my current setup.

The only issue that seems to remain is that for LKP, the long side macro begins to execute after duration, but does not finish until you release the key.
I'm at work now, but when home I will upload a simpler setup (IR file) that shows this issue.

On the TV key, short side just does keyset selection for TV device. The long side, changes the television's input to ANT1. The TV's on-screen menu pops up while pressing the key, after duration, but the input doesn't change until I release the key. It would seem that the last instruction of the macro sequence is not executed until release.

Also, with major changes like you describe, I'd vote for v2.0 also.

Best and Merry Christmas,
jeff

unclemiltie · Post by **unclemiltie** » Mon Dec 22, 2008 11:21 am

Cap'n

I like the suggestion on putting the Don/Doff keys in the keymap, let me look into it. Using those keys in a multiplex environment coulid be a challenge the way that it is today. (I have to think about this for the RS extender as well)

Dave

I think I can do something with the backlight toggle. I did a protocol that allowed you to adjust the backlight brightness on the Kameleon extender, so let me look into it. I've not used the backlight but what I'm thinking is that you bind a key to a protocol that you push and then it looks for something like V+/V- to turn the backlight on/off and then exits. would that work?

Jeff

This is very weird, as I've said before. The way the extender works is once the protocol for LKP starts, it fills up the macro buffer with the right macro from the long/short side and the passes control to the macro processor. The macro processor plays all of the keys until the macro is empty and then goes back and then goes back to the wait for keypress loops. There's nothing in that loop that can even think would be waiting for a keypress to finish. Can you please simplify your config so that I can see this.

looks like this is going to be V 2.0 given the comments

mr_d_p_gumby · Post by **mr_d_p_gumby** » Mon Dec 22, 2008 2:24 pm

mdavej wrote:If you are able to provide access to the backlight toggle somehow, that would be a nice enhancement as well.

Being able to select (in IR) the backlight timeout period would be a nice enhancement, too.

unclemiltie · Post by **unclemiltie** » Mon Dec 22, 2008 6:08 pm

Dave

For the backlight toggle, I found a way to do it and its pretty simple. What I'm considering is that you bind a key to a special protocol and it will toggle the flag that controls the backlight. For example, you could bind the PIP Ch- key and each time you press it the backlight enable would be toggled.

will that do it for you?

gumby

Changing the timeout value is a bit more involved. Unlike the JP1 remotes where the main loop is recreated, these extenders use the main loop in the remote and then branch off into key processing after the remote has processed the key. That timeout value is deep in the loop that is in the remote.

If I ever decide to go back to the point of re-creating the main loop like the JP1 extenders do I could do this as I did in the Kameleon extenders that I did. This would have the negative effect of the extender activation not surviving a reset, which I kind of like with these extenders.

greenough1 · Post by **greenough1** » Mon Dec 22, 2008 8:28 pm

Here's the IR file . Look at the CBL and TV LKP long sides. These both show the "hang".

jeff

unclemiltie · Post by **unclemiltie** » Mon Dec 22, 2008 9:28 pm

OK, now I see it.

I received my IR widget from Today (thank you Tomy) so I was able to use that to capture what was going on .

Sure enough, if I hold the key during the entire capture period of the IR widget, all I see is the "Source" key being sent (and repeated by the way, that could be a clue)

If I release the key during the capture period, I see the Source and then the next key.

I have no idea how this is happening though. I'm going to have to really look at the code to see what is going on, but I suspect that it has something to do with the key being still down when I enter back into the remote to process the key. (the pseudo-keys like X_TV, etc don't get processed by the remote but get processed by the extender)

Darn, now I have to dig back into the remote, I though I was almost done with this thing!

-bill

greenough1 · Post by **greenough1** » Tue Dec 23, 2008 12:19 am

Sorry Bill...

jeff

mdavej · Post by **mdavej** » Tue Dec 23, 2008 12:42 pm

unclemiltie wrote:Dave

For the backlight toggle, I found a way to do it and its pretty simple. What I'm considering is that you bind a key to a special protocol and it will toggle the flag that controls the backlight. For example, you could bind the PIP Ch- key and each time you press it the backlight enable would be toggled.

will that do it for you?

The simpler the better. I assume you could use that key inside other special protocols, like LKPs. If so, that's fine. Are you saying you'd make a new dedicated key like you do with DeActivate? That would be perfect. You could just roll that into TV 1800.

xnappo · Post by **xnappo** » Tue Dec 23, 2008 12:48 pm

unclemiltie wrote:I'm getting back into the extender since I've decided to try the 1056 backlit again for my main remote. I wanted to update it with some of the features that I had built into the RS 15-13x extender, primarily moving the special protocol code out of the upgrade area to give more space.

Is it possible to add virtual devices? I know you can use the device multiplexer to achieve similar results, but it would be nice to have virtual devices like the 8910 extender. I am guessing this is not possible, or you would have already done it, but thought I would ask

Thanks,
xnappo

mr_d_p_gumby · Post by **mr_d_p_gumby** » Tue Dec 23, 2008 2:41 pm

unclemiltie wrote:Changing the timeout value is a bit more involved. Unlike the JP1 remotes where the main loop is recreated, these extenders use the main loop in the remote and then branch off into key processing after the remote has processed the key. That timeout value is deep in the loop that is in the remote.

I suspected that this would be the case; that's why I said "it would be nice"! Anyway, now that you've got to go digging back into the code again,

maybe you could keep it in mind in case something simple comes to mind. It would mean a considerable increase in WAF.

unclemiltie · Post by **unclemiltie** » Tue Dec 23, 2008 5:58 pm

Capn Trips wrote:
In the current version of the extender, DicreteON is included in the button Map for some device modes (Can't check while at work, but I believe that in CBL device mode, D-ON is part of the KeyMap while D-OFF is not.) Therefore, D-OFF must be a KeyMove. My problem arises when I have to multiplex devices. I can only have ONE KeyMove assigned to a button per device mode and it doesn't change with multiplexing, so the multiplexer will switch the D-ON with it for the new device, but I have to come up with an awkward workaround to access D-OFF for multiplexed devices (in fact I HAVEN'T come up with a satisfactory workaround).

Well..... I spoke too soon

The reason that the $40 code is in the button map for CBL (as is $F1) Those two keys are in the button map for CBL only.

It was by accident that I used $40 for DiscreteOn, which put it in the map for the CBL device. In general, most of the extenders and remotes out there have the discretes as keymoves. But that shouldn't stop me from trying.

Unfortuantely, the only other key that is in the list is $F1 and this can't be used. It's complicated and based in how the extender processes the pseudo-device selection keys, but there can't be any REAL key that has a higher value than the first pseudo-dev key. So, given that $F1 is pretty high up there and I can't fit all of the pseudo-dev selection keys above that, putting Doff on that key won't work.

Sorry