Atlas 3000 & 3033 JP1.3 extender

greenough1 · Post by **greenough1** » Wed Jul 01, 2009 12:11 pm

Roger that, standing by...

mr_d_p_gumby · Post by **mr_d_p_gumby** » Wed Jul 01, 2009 1:49 pm

Capn Trips wrote:Hey guys and gals, perhaps I have discovered a problem? I just downloaded a virgin - never touched by a JP1-er's hands Atlas OCAP, and it has pre-loaded four device uprgrades: CBL/0476, 0877, 1376 and 1877

That would lead me to believe that these setup codes are NOT resident in the OCAP's ROM, yet the RDF lists all four of these as resident in the ROM.

They are indeed resident in the ROM. Cable companies often pre-install upgrades like these to override the resident setup codes with versions that more closely match the cable boxes they use.

Capn Trips · Post by **Capn Trips** » Wed Jul 01, 2009 7:34 pm

unclemiltie wrote:jeff

hold on it for a couple of days. I sent Cap'n some stuff to do some diagnostics for me so that I can figure out what happened. I should know more soon.

-bill

I'll probably not get to it before Friday - Saturday at the latest.

greenough1 · Post by **greenough1** » Wed Jul 01, 2009 7:42 pm

Maybe I'll still test if I get some time. Best, jeff

unclemiltie · Post by **unclemiltie** » Thu Jul 02, 2009 4:32 pm

OK, I had Cap'n run some diagnostics and send me the results, I just sent him this email but figured I'd close the loop here to close out this part of this topic.

The results of the diagnostic info he sent me is:

1: the extender is was not activated in the remote. This is good since I know that the activate code didn't break things and I don't have to go hunt down where I caused problems. The remote is pretty much in the state that it should be in when deactivated, except....

2: the data from the IR file starting at $614 and going to the point where the keymove to activate the extender is all wrong. This is generally caused by someone not using a "virgin" IR file to start the build of their IR configuration but doing a "new" from within IR and starting there. Everything from $614 through $626 is $FF (which is the default on a IR NEW command)

The atlas remotes prior to the extender being activated are very picky about what is in some of those memory locations and I've never really figured out what they do, I just always start with them "correct".

I don't remember if a 981 reset sets everything up right, it might. I sent cap'n a virgin 1056BC1 IR file of mine, It's pretty much standard practice for me to extract a virgin file on any new remote I get before doing ANYTHING to it!

So, I think that this problem is solved, hopefully Cap'n will report back that his remote is alive and well now that we have this one out of the way!

-bill

Capn Trips · Post by **Capn Trips** » Fri Jul 03, 2009 5:44 pm

No joy, Bill!

I ran you program to clean the OCAP, uploaded your "virgin" OCAP IR file, ,and the remote was fine, as soon as I ran extinstall on that IR file and uploaded it, the same behaviour manifested:

(1) cannot activate the extender;
(2) double0-blink on press of TV or CBL, single blinks everywhere else;
(3) since I used just a built-in device code, I couldn't re-verify that on pressing "TV" during th double-blink the toggle POWER command was sent, but I see no reason to suspect behaviour any different than I had before.

Do you really believe that it's something in the remote?

I am convinced that it's something in either the extender or in extinstall.

Have you attempted the same steps that I am describing on your OCAP?

Post by **vickyg2003** » Fri Jul 03, 2009 7:18 pm

No its not something in the remote, its something to do with extinstall. You noted that early on when you saw the remote go to all 0000's. Extinstall is wiping out all the setup codes and the flags. Its not filling with FF's its filling with 00's.

Post by **vickyg2003** » Fri Jul 03, 2009 9:26 pm

I found two problems. The first one is the flags are all changing when you merge. So I tweaked the HEX file to give you a valid setupcodes and flags when you start. I think I've seen this problem with extinstall before. I think it has to do with there being FF's in the setup codes, making Extinstall think its found a section terminator. I think thats why I was having problems with Extinstall on the 1067A, but all of my testers were not having the problem.

http://www.hifi-remote.com/forums/dload ... le_id=6911

The second problem is in the RDF.
AdvCodeAddr=$0C00..$19FF is incorrect.
The E2 area is only 1400 so this should read
AdvCodeAddr=$0C00..$13FF

You should also check the learned section on the base remote. There are so many Atlas RDF's that I'm not sure what you are going to find there, but it can't be bigger than the e2 size either.

Now, how do I remove the extender?

Capn Trips · Post by **Capn Trips** » Sat Jul 04, 2009 3:08 am

Thank you so much for you efforts, vicky. I'll give your modified hex file a try.

Not sure what rdf you're looking at, vicky, but mine (v.2.10 of the extender) has the advanced code area ending at 13FF. (Similarly, the learned area of the unextended rdf ends at 13FF. I recall an earlier discussion in this thread about that mistake, but it has since been corrected.

As for the hex file - hopefully what you have found is the fix - I know nothing, although I pointed out in my first post on this topic that when I run extinstall, all of the setup codes get reset to 0000. If that was a/the problem, I would have hoped that would trigger a closer look.

Capn Trips · Post by **Capn Trips** » Sat Jul 04, 2009 3:12 am

vicky! With your fix, the extender activates! Hooray!

Now I'd really like Bill to cofirm your fix.

Meanwhile I'll build my setup and see if it works correctly.

Thanks!

Post by **vickyg2003** » Sat Jul 04, 2009 4:29 am

Not sure what rdf you're looking at, vicky, but mine (v.2.10 of the extender) has the advanced code area ending at 13FF. (Similarly, the learned area of the unextended rdf ends at 13FF. I recall an earlier discussion in this thread about that mistake, but it has since been corrected

.

I downloaded the extender from the file section, and that RDF included in the zip file has that bad RDF.

As for the hex file - hopefully what you have found is the fix - I know nothing, although I pointed out in my first post on this topic that when I run extinstall, all of the setup codes get reset to 0000. If that was a/the problem, I would have hoped that would trigger a closer look.

In my own way, I had tried to convey that something had gone haywire, because of the VPT device being full of junk after you do the merge. This could have been caused by starting with a File->New instead of from a downloaded ir file. But when I did the merge myself, and saw all those invalid codes coming up, I knew that there was junk in the extender hex. So I replaced everything between the first checksum and the advanced code area with information from my virgin.ir file.

Capn Trips · Post by **Capn Trips** » Sat Jul 04, 2009 4:48 am

vickyg2003 wrote:
Not sure what rdf you're looking at, vicky, but mine (v.2.10 of the extender) has the advanced code area ending at 13FF. (Similarly, the learned area of the unextended rdf ends at 13FF. I recall an earlier discussion in this thread about that mistake, but it has since been corrected
.

I downloaded the extender from the file section, and that RDF included in the zip file has that bad RDF.

The first post of this thread has a link to version 2.10, which has the corrected rdf, but as you point out, the faulty hex file.

unclemiltie · Post by **unclemiltie** » Sat Jul 04, 2009 12:03 pm

Mea culpa!

I have a bunch of debug flags in the builds for the extender source and had rearranged a few things. With the debug flags on, the default values for those flags were built into the extender, with the debug flags off the rearranged code doesn't build in the flags.

To fix, the edits that Vicky put in will work, I'll have to re-issue the extender build after I fix up the source to include the right flags in the 3033 remote.

next time, I guess I should load up the extender with something other than the debug builds.

Look for a re-issue of 2.10 this afternoon some time. All I have to do is move a couple of ifdef statements in the source, recompile and load into a remote to make sure I didn't break anything!

unclemiltie · Post by **unclemiltie** » Sun Jul 05, 2009 8:59 pm

I just re-issued V2.10 with the fix that includes the right flags in the setup area to ensure that the remote works properly. I did upload the "non-debug" version of the extender to my test OCAP and all is well. The atlas extender activates, deactivates on long-press and toggles the backlight on long-press.

If you grabbed 2.10 before Sunday at 8:00 PDT you need to get it again!

-bill

unclemiltie · Post by **unclemiltie** » Mon Nov 29, 2010 9:37 pm

It's been a long time since I touched the JP1.3 extenders. But my work on a new extender for the RCA RCRP05 brings me to an interesting question.

The RCA has more than 64 keys on it (hard to believe) and I had to change the way that it does HT setup from the x_device setup that I used in the Atlas (and all other JP1.3 remotes) to the 8900 style Dev_device,Set_key. The advantage of this style is that it uses a LOT less keycodes (i.e. one for each device and one for each keyset versus keys*devices on the other style)

Anyway, once I'm done with that remote, back-porting the JP1.3 code to the other JP1.3 extenders would be trivial.

Since this is a highly used extender, would people be interested in me doing this work and issuing a V3.00 of the extender with this new setup?

This would include the

Comcast JP1.3
Radio Shack 15-100
Radio Shack 15-13x
Atlas remotes

A side effect is that the 15-13x would probably not have to have two variants of each remote since keycodes was one of the reasons for having two.

Thoughts?