JP1 Remotes

[Anthony_Patrick]

I am in the process of setting up the extender for my Shaw CableSystems branded Atlas 11055BC2 remote. I am using the Atlas JP1.3 Extender V2.12 and I have it *mostly* working, however I have discovered that the physical keys on this remote do not correspond to the "KEY SETS" documentation in the read-me file. Through trial-and-error, I discovered that some of the physical keys are placed in rather strange key sets. For example: The "Skip", "On Demand", "Music" keys (otherwise known as TuneIn1, TuneIn2, TuneIn3) are in the P_CBL set (rather than in the O_CBL set). I don't think any of the device keys is in any key set. (I like to use a LKP of a device key to toggle power to the specific device because I reserve the master power key to toggle power to my system as a whole. I can't make a LKP work with any device keys on this remote - something I have successfully done on other remotes.)

I don't know how/where the physical keys are assigned to their respective key sets. I would have thought this might be in the RDF (where I could have fixed things.) I suspect this mapping is hidden away in the extender or within the OEM code of the remote.

Anyone have any ideas on this?

BTW: I tripped across an interesting issue with this extender/RDF/remote. I needed to turn Off all the volume punch throughs (VPTs) and Channel Locks before loading the extender to the remote. Unless I first did this, I had issues with the channel key sets and volume key sets (these key sets wouldn't work properly).

[mdavej]

It sounds like you didn't actually activate the extender. When you first uploaded, did you press OK and get 4 blinks?

[Anthony_Patrick]

Yes, I did activate the extender - I got the four blinks. I use the "Special Protocols" for other things and these other things work. All the device selection stuff also works as expected. However, if I try to use any of the device keys or the "Settings" key within a "Special Protocol" as the "Target Key" - it is simply ignored just as if the key was not mapped to any key set.

What follows is the current setup that I have working: (BTW: I coerced IR into sorting the Special Protocols before the Macros and I also tried sorting the Macros before the Special Protocols - within the remote's memory. It didn't help. I currently have the Special Protocols sorted before the Macros - so they should have precedence.)

GENERAL NOTES:
Shaw CableSystems branded Atlas 11055BC2 remote with extender version 2.12

EDIT: I have posted my IR file to: http://www.hifi-remote.com/forums/dload.php?action=file&file_id=9758

[mdavej]

Check your PMs.

[vickyg2003]

Anthony, For future reference please post your files in the diagnosis area, and then post a link.
it really makes it hard when you post the contents of your file. If you had posted the actual file, we could have loaded it up and tested it.
_________________
Remember to provide feedback to let us know how the problem was solved and share your upgrades.

Tip: When creating an upgrade, always include ALL functions from the oem remote, even if you never plan on assigning them to a button. Complete function lists makes an upgrade more helpful to others.

[Anthony_Patrick]

Thanks for the tip. I have posted my IR file to: http://www.hifi-remote.com/forums/dload.php?action=file&file_id=9758

I did a bit more research (guess, then test-and-try) on the key set issue. Turns out that all the device keys as well at the "Settings" key and possibly some others are in the "P" set rather than the "O" set (where they should be).

Thankfully the TV I am using does not have PIP - so I was able to do a workaround - for each device type I added the corresponding "P" group in order to get the "device key" LKP power toggle working. The way it works is:
1. Switch to the device you want to toggle power for using the corresponding "device key".
2. Press and hold-down the "device key" until the power toggles on the corresponding device.

My next step for this file is to implement a master power on/off (now that I know how to easily power toggle specific devices with this remote). Unfortunately I will not be able to use this remote with a TV that really does PIP (because my workaround misplaces the "P" key set). I have another setup using the Comcast 1067B remote where I do have a TV with PIP and the 1067B works just fine using the LKP power toggle (without the workaround)!

Hopefully the key set issue can be fixed. The local cable company (Shaw) includes these remotes with every cable box they sell and it would be great if this remote could be made to work properly.

[Anthony_Patrick]

Just a quick thought: Is it possible that the virtual keys for the "O" sets and the "P" sets are switched in the RDF file that ships with the extender?

EDIT: I've done more research (using guess, trial and test) and it seems that the PIP keys are also in the "P" key set (which is where I would expect them to be). However, I can't seem to find any keys in the "O" set (I removed "CBL_O" from my device setup for cable but all the keys still seemed to work). Looks like all the keys from what should be the "O" set as well as all the keys in the "P" (PIP) set both map to the "P" set. Go figure!

[Anthony_Patrick]

The specific model number for the Shaw branded Atlas 5-device "Day" remote referenced in this thread is:
11055BC2-XXX-0001-1014 C102001

You can find a picture and some instructions for its operation at:
http://www.shaw.ca/uploadedFiles/Support/Television/Email/Setup/Shaw_TV_Remote_Quick_Guide.pdf

You can see that this remote "looks" identical to the Atlas 5-device "Day" remote other than some of the labels on the keys. Instead of having a "VCR" device key and the TuneIn 1-3 (or macro 1-3) keys, the Shaw branded remote has an "AUX" key and the macro keys are labelled: "Skip", "Shaw on Demand", "Music". The AUX key uses the same keycode as the Atlas "VCR" key. The Shaw "Skip", "Shaw on Demand", and "Music" keys use the same keycodes as the Atlas TuneIn 1-3 keys.

[Anthony_Patrick]

Just a quick thought: Is it possible that the virtual keys for the "O" sets and the "P" sets are somehow switched or merged in the RDF file that ships with the extender?

EDIT: I've done more research (using guess, trial and test) and it seems that the PIP keys are also in the "P" key set (which is where I would expect them to be). However, I can't seem to find any keys in the "O" set (I removed "CBL_O" from my device setup for cable but all the keys still seemed to work). So it seems like the "O" key set has been somehow merged into the "P" key set. Go figure!

[mdavej]

Looking at your IR file, you have 2 macros assigned to each device button. That's generally a bad idea. I don't see how your global key set or LKP macros work at all. I don't see any macros that could even test O versus P key sets. If you are going to use LKP macros, you need to get rid of the global macros and call your key set macros on the short side. Either that or call your LKP macros at the end of your global macros (which is what I typically do).

From your description I initially though the key map for your remote could be different from others we've seen, but I now see this isn't the case. Bottom line is your key set issues appear to be due to your macros, not any errors in the extender.

EDIT: I see after a little more digging that multiple macros on the same button do work, but I don't fully understand how. Still seems safest to stick with a single entry point.

[Anthony_Patrick]

The macros work this way:
1. When a device is first selected, the "normal" Macro executes and assigns the appropriate device functions to the device (an HT style assignment).
2. After a device has been selected and an LKP is made using that same device button (ie: on the currently selected device), the "Special Protocols" macro executes (which I use to toggle the power on only the selected device).

This leaves the POWER button available for handling HT style power-up and power-down sequences.

As long as I am careful about sorting the "Special Protocols" section before the normal macros section in the remote's memory (IR can be coerced into doing this), this technique works fine. I have done this with a couple of other remotes without any problems. For this remote, as long as I include the "xxx_P" keyset for each "xxx" device; things also work fine - which led me to believe something was wrong with the keyset mapping.

I have placed the following file for the Comcast URC-1067B remote into the diagnosis area that demonstrates how this works:
http://www.hifi-remote.com/forums/dload.php?action=file&file_id=9762

I have had absolutely no problems with this setup for the 1067B.

EDIT: I have updated both IR files (for the Shaw-Atlas 11055 and the Comcast URC 1067B) in the diagnosis area to refect the most current version I have - I added lots of notes. Both IR files are working as expected (however the IR file for the Shaw-Atlas remote has the "xxx_P" keyset mapped for every "xxx" device so it can work - this is a workaround). The Comcast-URC 1067B works as expected without any workarounds.

[unclemiltie]

I apologize for being away for so long, I've been busy with (1) work, (2) kids and (3) a new (to me) 45-year old car that is getting a good bit of my attention.

There was a bug in the Atlas, I don't remember which version, but there is a posting here from me on it, that had to do with one of the key sets not working. There is a patch in that topic that fixes this bug. I don't remember if I released a new version or I was going to roll that fix into the next version, which I did build and some of my usual testers have tried out.

let me see if I can dig this stuff up in the next few days and look at what is going on. hopefully you've discovered the bug that I already fixed!


-bill
_________________
this JP1 stuff is a sickness!

[unclemiltie]

I mis-spoke earlier. I checked the code for the extenders and found that the bug in processing keysets was for the newer RCA and Insignia remotes that use the 8900 style HT setup and not the original extenders including the Atlas.


Now,to the issue.

I am looking at the code and think I found what is going on. For "most" of the keylists, I build a list of keys that I use to search against to find what device I should be using when the key is processed. If you look in the raw data, you will find the lists starting at $810, they are a list of keys terminated by a $FF.

After that list of keys, you will see a bunch of addresses that list the starting address of each of the key lists. $810 is a null list (has no keys in it), $811 is the transport keys, $81A is the channel keys, $82B is the menu keys.

Now here is where it gets interesting. In order to try to save space, I used a couple of key lists that looked like they were right in the base remote, this was for Volume and PIP. However, after looking closely on the 3033 remote, I realized that the list wasn't terminated after the PIP keys and that there were a few other values after that. the keys in the list after are all of the "macro keys" (Tunein1, 2, and 3; all of the device keys; and $40 and $F1)

You should never see this on the keys above $40 since those are either keymoves and macros and those would be executed long before this stage in the extender. You will certainly see this on the "macro" keys and possibly if you've done some unusual mapping on to the device keys.

What makes this more complicated is that the search routine goes through Trans, Vol, Chan, then PIP, Menu and other. So if those random key values are in the menu or other sets, they're going to be swept up in the PIP search.

This doesn't impact the Comcast remote since I didn't find a list in the remote that I could use so I built my own.

I'm going to have to build a 2.13 version to build my own PIP key list. It's a trivial fix because I've built in conditional assembly that builds the lists if I don't specify a spot where I found the list in the remote. The only question is will it fit in the allotted space.
_________________
this JP1 stuff is a sickness!

[unclemiltie]

Drop me a PM with your email address if you want to try out 2.13 to see if it solves the problem. I'll email you a new RDF and a new HEX file. Include which signature remote you are using (3000 or 3033)
_________________
this JP1 stuff is a sickness!

[unclemiltie]

I sent a new version to Tony this morning for him to try. If all goes well, I'll post it in the next few days.
_________________
this JP1 stuff is a sickness!