URC-6960B00 Extender Beta2 available

unclemiltie · Post by **unclemiltie** » Thu Feb 01, 2007 10:53 am

I've got my first extender to a point where I need more people trying to use it and debug things. This is significantly more work than I ever thought it would be, almost 6 months in the making. This is still BETA CODE, although I have done some testing. But I'm not a big user of DSM, Pause or LDKP so I haven't done enough.

I've uploaded a ZIP file with the extended IR file and the RDF here:

Update: 3/8/07

The Beta 2 extender is now available, I've removed Beta1. The file is here:

https://www.hifi-remote.com/forums/dload ... le_id=4329

Please post here if you download so that I know if it's getting used and obviously if you find bugs, please let me know.

unclemiltie · Post by **unclemiltie** » Thu Feb 01, 2007 10:55 am

Oh, and before anyone asks....

Yes, this remote is very similar to the 9960B01, but I don't have one of those, so I haven't tried to even port this extender (yet!)

Post by **vickyg2003** » Thu Feb 01, 2007 1:57 pm

Congratulations on getting your extender up and running. I've seen a few 6960's on Ebay. Are they JP1 out of the box or do they need to be soldered? I thought I'd pick one up to check out your extender.

Elizabeth just tested the 7800 extender 4 with Xshift. Thank you very much for your contribution. I can't believe how fast you were at coming up with that source code for the older version. I'd be struggling forever without your help.

unclemiltie · Post by **unclemiltie** » Thu Feb 01, 2007 1:59 pm

The 6960 does not have pins and does not have thru-holes. You have to either get the connector pins with the "L" shaped legs or bend them yourself. not too hard.

I'm sure I'm not done with this extender, I know something is broken that I just haven't found yet. But thanks!

Post by **The Robman** » Thu Feb 01, 2007 2:26 pm

If the URC-6960 has the same 6-pad arrangement as most other Kameleons, you can use a regular 6-pin if you like. When I modify remotes like this, I put a little flux on the pads then I solder a 6-pin in place, just having it stand on the pads. Then I put a bunch of hot glue around the base of the 6-pin, just for safe keeping.

Nils_Ekberg · Post by **Nils_Ekberg** » Thu Feb 01, 2007 2:39 pm

The Robman wrote:If the URC-6960 has the same 6-pad arrangement as most other Kameleons, you can use a regular 6-pin if you like. When I modify remotes like this, I put a little flux on the pads then I solder a 6-pin in place, just having it stand on the pads. Then I put a bunch of hot glue around the base of the 6-pin, just for safe keeping.

And I have not busted off one of his mods yet.

Post by **The Robman** » Thu Feb 01, 2007 2:54 pm

Nils_Ekberg wrote:And I have not busted off one of his mods yet.

And coming from Nils that means something, because I've seen what happens to remotes in the Ekberg household (and it ain't pretty)!

unclemiltie · Post by **unclemiltie** » Thu Feb 01, 2007 2:56 pm

The Robman wrote:If the URC-6960 has the same 6-pad arrangement as most other Kameleons, you can use a regular 6-pin if you like. When I modify remotes like this, I put a little flux on the pads then I solder a 6-pin in place, just having it stand on the pads. Then I put a bunch of hot glue around the base of the 6-pin, just for safe keeping.

yea, the pads are there and you could just stand the 6-pin connector on there and solder it.

I found, somewhere that I can't remember, an off-the-shelf 6-pin header that has the legs on the bottom half bent out at 90-degrees. Sits perfectly on the pads and makes it easier to solder them. (I think I still have a couple around if you'd like one) Gives it a bit more contact area. [you can also take a pair of needle-nose pliars and bend the bottom of a standard header, did that as well!]

unclemiltie · Post by **unclemiltie** » Tue Feb 20, 2007 7:16 pm

an updated version has been uploaded here:

https://www.hifi-remote.com/forums/dload ... le_id=4248

Note: this extender source supports both the 6960B00 and 9960B01 so the new upload is in the 9960B01 area. Sorry for any confusion

unclemiltie · Post by **unclemiltie** » Thu Mar 08, 2007 8:02 pm

The Beta2 version has been posted, the link in the root of this string has the new link

This extender has fixed a number of bugs, implemented the remap feature that the unextended remote has and is smaller.

Special Note:

To implement remapping I had to move the keys around and thus if you did use the previous version all of the keycodes for Xshift and Pseudo-device keys will be wrong with this extender. You will have to recreate macros, keymoves, etc. I do not intend to move the keys again but this was necessary to get the last piece of the unextended remote into this extender.

unclemiltie · Post by **unclemiltie** » Sat Mar 10, 2007 3:37 pm

Yesterday I found a conflict between the newly enabled remapped keys and the ability for the remote to Shift-cloak. Because of this, remapped keys work only by coincidence and are broken.

I have a fix running in my remote today, I hopefully will be able to wring out the fix tonight and get a new version of the extender posted tomorrow

I know of no other impact of this bug on any other portion of the extender

unclemiltie · Post by **unclemiltie** » Sun Mar 11, 2007 7:50 pm

The conflict between shift-cloaking and remapped keys has been fixed in the latest file in the files area. To see if you are using the latest version, look at byte $FF in the EEPROM, if this is not $36 you are not using the latest

unclemiltie · Post by **unclemiltie** » Mon Mar 19, 2007 6:02 pm

Question:

jsevinsk (in another topic) figured out that we can change the start of the advance code area to give more upgrade space. Given that the 9960B01 has nearly unlimited advance code area, I was going to make this change in the 9960B01 extender on my next version. How much extra upgrade area is good enough? I can see adding either 256 bytes or 512 bytes

the version that is out there (Beta2a) has 331 bytes of upgrade memory and 2775 bytes of advance code memory when all of the upgrade special protocols and the default macros are built in.

I can see adding 256 bytes to the upgrade area since there is another hard limitation that the number of upgrades is limited to 64 (limited by RAM of 256 bytes with 4-bytes per upgrade when the upgrade table is loaded into RAM for searching)

the 6960 is a different issue in that it has 344 bytes of upgrade and 742 bytes of advance code memory available. I haven't tested if I can start the adv codes on a non-natural boundry so taking 256 bytes from advance code is probably not a good tradeoff.

thoughts on either one would be appreciated, either here or PM