Radio Shack 15-13x extender beta

[unclemiltie]

All

I uploaded this afternoon a beta of the 15-13x extender V0.03

This version should be pretty functional, it is a port of the atlas JP1.3 extender that I did several months ago with some minor changes to deal with supporting the Radio Shack remotes.

The extender supports the 15-133, 15-134 and 15-135 extender. There are slight differences in the extenders to deal with the different keysets so please make sure you use the right one for your remote.

This extender is very different from traditional extenders in that the activation/deactivation process is permanent and will survive a battery removal. To deactivate the extender you MUST use the deactivate keymove. See the readme for more information.

Note to the Atlas extender users: This version uses some additional free space in the E2 area to hold all of the special protocols so they don't take up the upgrade area. If I find that this works well for this extender, I'll probably back-port this to the Atlas family as well.

[unclemiltie]

I had a file sync issue between the mac at home and my laptop and a bug that I had already fixed found its way back in. (keys with value of $40 and above in the remote don't work)

Anyway, V 0.04 is on its way to the files folder, this should fix it.

AND this version does not have Xshift, so I've taken Xshift out of the RDF. Xshift is going to be a serious challenge in doing this remote, but more on that when I have time to explain.

The new version is here: http://www.hifi-remote.com/forums/dload ... le_id=5881

[unclemiltie]

The keymap for the 15-13x is a bit weird in that UEI used the same keymap for all three remotes and thus there are more than $40 keys defined in the remote.

In general, the way that the extenders work is that we take the normal keys in the $00-$3F block and the shifted keys in the $80-$BF block and leave them alone. Then we define a whole bunch of pseudo-keys for the HT modes (5 keys per device) and allocate them into a block and then take another whole block and use it for a second shift.

Now, in this remote, UEI has thrown us a curve. There are keys defined in the $40-$7F block that when shifted fall into the $C0-$FF block. This creates two problems:

First, there isn't a continuous block of keys to build the pseudo keys because of the sparse nature of the keys in the $40 block. This isn't a huge issue since we can prevent some keys from being shifted, which is what the extender does today, and use the $C0-$FF block for the pseudo keys.

Second, there isn't a block of keys that can do Xshift since Xshifted keys will land on top of some of the normal keys if you use the $40 block and the $C0 block has already been used. In addition, the extender can't tell if a key is an Xshift key or a normal key by just looking at bit <6>, it actually has to know which keys are real and not.

There are a few solutions to this problem, all of which have their issues:

1: don't do Xshift, which is what the current extender does. Takes away a piece of what the extender can do, but then again makes things simple. The only real issue is that some of the keys can't be shifted (as you see in the current extender) to deal with the range of pseudo keys.

2: Do Xshift but limit which keys can be Xshifted. A bit more of a challenge since the extender needs to become aware of which keys are real and which are Xshifted. Will require lists of keys in the extender that are searched on every keypress, or something like that.

3: move keys around. Fortunately there are not more than $40 physical keys on the remote, so I could reuse the keys that are defined in the remote firmware but not physical to move some keys around. This is not difficult since I've seen it done on the Kameleon's in the past, but this poses a different problem. The good news is that the keylists in the remote have all of these keys, so upgrades won't need to use lots of keymoves.

The downside is that people who upgrade from the non-extended remote to the extended remote would find different key values so any advance codes that they had defined may need to be redone. We lived with this with the difference between the advance code format on the 6131 and its extender for a while, but this one really has no way to be automatically fixed.

Right now the extender doesn't do Xshift since that was an easy way around the issues. I started working on the method to remap keys, but then thought more about it and stopped.


Thoughts from the forum and experts would be appreciated


-bill

[mdavej]

Bill,

You and I have discussed this before, but I'll go ahead post my thoughts for the group.

Personally, option 1 is fine with me. People who are new to extenders won't miss xshift anyway, and it's easy to work around. Option 2 sounds way too complex. If, on the other hand, option 3 isn't too difficult, xshift would be nice to have. I think the advanced codes problem is almost a non-issue, since you have to tweak all your device upgrades and just about start from scratch with your IR file when you go to the extender anyway.

Is it worth the effort? So far the 15-13x series appear to be about as popular as the Atlas, if you count RDF downloads (the download count has reset a couple of times as I've made updates, but it's a few hundred at least). So this could end up being a fairly popular extender.

I'm greatful for all the hard work you've put into this and am quite happy with it the way it is.

[gfb107]

I agree. To me, X-shifting is the least important feature of any extender.
The most important features for me are (more or less in most to least order):

1. Macros on any key (especially the device keys)
2. Flexible device selection
3. Fast macros
4. Long macros
5. Device Specific Macros
6. Long/Double Key Press

[The Robman]

How would option 3 work? Would you really be able to remap all the keys who's address is over $40 back to a value under $40? If so, this sounds like the way to go.

I wouldn't worry about people being able to convert their old configurations when installing the extender. First off, these are still fairly new remotes, so it's not like people have years worth of coding in there that they want to keep. And secondly, somebody could develop a version of the installer that could take care of this if it does become an issue.

[unclemiltie]

Rob

The way that I would do this is the way that the Kameleon's did this for some of their key remappings. (the kameleon's would remap keys based on which screen was active. So for example on the 9960, if you push the physical key that is "OK" on most of the screens but you are on the audio screen, it gets remapped to a new key value for "Surround") This would just not have to deal with the complexity of screen values, so is actually a bit easier.

In essence, every time a key is pressed, the extender would look in a table that has the key you want to remap and the new key value. If the key isn't in the table, things go on as they were. If the key is in the table, the extender swaps the key value with the new key value and moves on.

The reason that this can work in this remote is

1: each remote has "holes" left in the $00 block of keys becasue the remote does not have that physical key. Since I know that key will never be pressed, I can redefine it and all will be good. There is enough room in all of the remotes to do this, I already checked.

2: All of the keys, are in the device keylists so these new substituted key values would still be mapped into upgrades.

So, I *think* that this will work. I've actually coded into the current extender the part that intercepts the keypad scan, but all it does right now is a RET back. I've verified that this does work, so the rest is pretty easy.


What I'm thinking here is that I develop two versions of the extender. One that has no Xshift (i.e. the current one that is out there) which can be installed into a current configuration and then one that has Xshift but moves keys around with the associated issues. They'd need different signatures and RDF's for everything to work right, which is the only downside to doing two. hmmmm.

let's get the bugs shaken out of the one that is out there right now and then I'll see what happens.


-bill

[mr_d_p_gumby]

1: each remote has "holes" left in the $00 block of keys becasue the remote does not have that physical key. Since I know that key will never be pressed, I can redefine it and all will be good. There is enough room in all of the remotes to do this, I already checked.

Just my two cents... By doing this, you'd essentially be trading perfectly good phantom keys for xShift keys, right? In most of the remotes I've set up with extenders, the xShift keys end up being used as phantoms (because of running out of "real" phantom keys). If it were me, I would save myself a lot of work and just drop the xShifts in favor of having more phantom keys.

[vickyg2003]

Just my two cents... By doing this, you'd essentially be trading perfectly good phantom keys for xShift keys, right? In most of the remotes I've set up with extenders, the xShift keys end up being used as phantoms (because of running out of "real" phantom keys). If it were me, I would save myself a lot of work and just drop the xShifts in favor of having more phantom keys.

I got into extender writing, simply because I needed more pressable keys to handle some of my complicated equipment. Of course the Cinema 7 my family's favorite remote had far fewer keys than these Radio Shack models, so xShift was a necessity.

[mdavej]

If it were me, I would save myself a lot of work and just drop the xShifts in favor of having more phantom keys.

I like this idea. Bill, you've put a few phantoms at the beginning of the $C0 range, but couldn't you use the existing holes below $40 for more shiftable phantoms? Looks to me like we could add 4 more phantoms to the 135, 10 to the 134 and 15 to the 133 without the shifts stepping on any real keys. (I'm avoiding key $39, whose shift would step on $79, which is already in the button map but has no physical key). Would that work by just adding them to the RDF's, with no code changes to the extender?

[unclemiltie]

sure, you could fill in the holes with Phantoms and have a bunch of them

The only weird thing on this remote is that they'd be part of real upgrades and not keymoves. (since they are in the keylists) They all could be shifted as well. The only restrictions on shift are the ones that are in the $40 block.

[unclemiltie]

1: each remote has "holes" left in the $00 block of keys becasue the remote does not have that physical key. Since I know that key will never be pressed, I can redefine it and all will be good. There is enough room in all of the remotes to do this, I already checked.

Just my two cents... By doing this, you'd essentially be trading perfectly good phantom keys for xShift keys, right? In most of the remotes I've set up with extenders, the xShift keys end up being used as phantoms (because of running out of "real" phantom keys). If it were me, I would save myself a lot of work and just drop the xShifts in favor of having more phantom keys.

Mike

I'd be trading 4-8 perfectly good phantom keys for the ability to Xshift 64 keys. To some, I'm sure that this would be a good tradeoff, to others who don't care, who knows.

On the other hand, as I've pointed out before, this would be the first (I think) remote where the phantoms could be part of upgrades and not have to be always done with keymoves.

[unclemiltie]

V0.05 beta is on its way up to the extender area.

This one implements the key remapping and Xshift, but does it in a way that I now ship two versions (with two RDF's) for each remote. Thus, there are now 6 RDF's and 6 hex files in the distribution.

I've verified via key blinking that all of the remap tables do what they're supposed to do, now comes time for some real testing for those who are interested. The A/B/C versions of the extender should function as the V0.04 version did without key remapping. The E/F/G versions should enable Xshift and moved a few keys around to accomplish it.

let me know what you find in testing.


-bill

[mr_d_p_gumby]

Bill - I've put together a quick test of the 133-A extender based on an existing setup I had for an extended 6131, and it does seem to work quite well. (I guess that means you are getting good at this! )

So far, I've only noticed a couple of things:

1) It does seem to suffer from the same LKP issue as the Atlas extender.

2) Your RDF left off all of the phantom keys that are defined in the unextended RDF. I had created upgrades with discrete on & off commands on the DiscreteON & DiscreteOFF buttons (therefor no keymoves needed). The extender RDF has these buttons redefined (and not in the keymap), so of course it did not work.

I modified the RDF the way I think it should be to get things working for me. The modified RDF and test IR file are in this zip file. Also, there is a spreadsheet showing how all the keys are mapped in the RDFs.

I chose not to use the 133-D extender in this test, since it remaps several keys that are in the unextended keymap, and I didn't need the shifted buttons. You probably should advise users that they will need to re-create their upgrades when using the D/E/F extenders. I'd also see if you could assign the Input button to a different code (not $01) so that it could be in the keymap.

Mike

[unclemiltie]

Mike

Thanks for the feedack. mdavej and I have been discussing the Phantoms, where we should put them, etc. There are benefits for putting them back where dave had put them originally in the older RDF's. We've also agreed on the remapping to not use $01 as you have suggested.


I'm still trying to hunt down the LKP issues, they're sort of weird. Any simplified test cases you can give me would be helpful. (unfortunately, the issues seem to be around really complicated LKP configurations)


-bill