Atlas 3000 & 3033 JP1.3 extender

Post by **vickyg2003** » Tue Jun 30, 2009 7:57 am

Capn,

The double blink after pressing power is the indication of a Reset. The two main reasons for a Reset are

1) Faulty batteries,
2) an error occured, i.e. bad setup code, illegal instruction (which can happen if even one byte of the extender itself was disturbed.

After my experience this weekend, I'd make sure to check out the battery cause, but I'm assuming because of step 3a results, that something went horribly wrong with extinstall.

I'm not that familar with Unclemilties extenders, but if this was my extender, the first thing I'd do is a windiff with the last IR extender that did work.

Do you have another Ocap.IR file from the same extender build, that used to work. If you post the Zip the HEX file used in the merge, the RDF file and the last working IR file, I could take a look and see if I can detect a problem with the way the file was merged.

I suspect that the recent RDF changes are the culprit. If it were me, I'd be tempted to make such an "easy" change without testing, and these changes would have an impact on Extinstall.

Capn Trips · Post by **Capn Trips** » Tue Jun 30, 2009 10:18 am

Batteries are new.

And the symptom (double-blink) does not occur with a press of Power. It happens when I press TV or CBL. Both have only the default device-selection macros on them.

And a press of OK (to activate the extender) does NOTHING.

I'll change the batteries again, but I would hope that it's not THAT sensitive.

Post by **vickyg2003** » Tue Jun 30, 2009 12:45 pm

Capn, I downloaded the extender. At first I thought it didn't line up but then I realized I was looking at 2.04 and you were using 2.10. Back to the drawing board.

Capn Trips · Post by **Capn Trips** » Tue Jun 30, 2009 1:41 pm

Vicky, I appreciate your looking at this. WHat you are discussing is gibberish to me. I mean, I can find a locaation in the EEPROM and see what's written there, but it means nothing to me.

You mention 2.04. This file was created using 2.10. Is that the problem?

Post by **vickyg2003** » Tue Jun 30, 2009 2:33 pm

Well I was going on the theory that something was wrong with the way extinstall was running. I thought I'd be careful. The extender Hex aligns with your IR. So I took my only Ocap and uploaded the IR. Now my remote is sick too.

unclemiltie · Post by **unclemiltie** » Tue Jun 30, 2009 2:46 pm

Cap'n

sounds to me like you are in "failsafe mode" in the extender (described in the Readme) Since this extender is permanently activated and the remote is calling back into the extender, I had to devise a way to ensure that the extender code was actually there when control was passed. This remote does some bad things when it doesn't like what's going on, one of those is to erase the first page of the E2 area where the extender is kept.

So, when the extender is called from the remote, the first thing it does is check to see if the code is where it should be. The code to do this check is kept at the "end" of the extender space since that isn't impacted by an erase by the remote.

If this check passes, things process normally and control is passed to the real extender code.

If this check fails, the extender will flash the LED twice and then execute the key as if the extender wasn't there. (i.e. it calls right back into the remote where it came from) It will flash twice for every key press.

This can happen for a couple of reasons:

1: the remote is erasing the first page of the extender because it doesn't like something that is going on. The easiest way to check for this is to load your IR file, set a baseline in IR, upload it to the remote, press a button( watch it flash twice), download to IR and check the hex for any differences (in red)

If this is happening, the most likely suspect is that you have an invalid setup code. I added setup code validation in the 2.10 release to help with this issue.

2: you've got a mismatch of the extender code. This happened because in the early versions of the extender, I inserted a "check byte" before the extender code and did the compare against it. In the later versions, I think after I put the long-press deactivate code in, I ran out of space and set the check byte as the first instruction in the extender code. (this allowed the new features to fit) Because of this, if you have mismatches, this check will fail and you'll go into failsafe mode.

One thing you should be very careful with this extender is that you really need to deactivate the extender prior to upgrading. If you have a mismatch, the easiest thing to do is load up the IR file for the version of the extender that you used to activate and then deactivate.

unclemiltie · Post by **unclemiltie** » Tue Jun 30, 2009 3:25 pm

oh, just checked the code the failsafe on the ATlas is different than the other JP1.3's. it checks the signature, not the checkbyte. same impact though.

so, you can't get out of sync (2) in previous post with this extender. so you probably have something resetting settings and changing the signature back. do the upload/button/download test and let me know what you find.

-bill

Post by **vickyg2003** » Tue Jun 30, 2009 4:05 pm

On my copy, VPT device doesn't appear to be a valid device. I had a little trouble seeing that as that general tab doesn't want to scroll.

unclemiltie · Post by **unclemiltie** » Tue Jun 30, 2009 9:24 pm

Cap'n

I looked at the code for 2.04 and 2.10 since those were the versions that you were using. I will repeat that between these two you should first deactivate the extender using 2.04 and then reactivate with 2.10. I didn't see that in your post, so I don't know if you did that.

I looked at your IR file briefly and don't see anything out of the ordinary. Since you're using 2.10 you are using the code validation in the 2.10 RDF so you should not have an invalid code in any of the device setups. I'm not sure if the remote will reset if the VPT device isn't valid as Vicky mentioned, so you may want to check that.

The Atlas remotes are very picky about what is in the setup registers and will erase stuff if they don't like things. This is why the recommendation for all of the Atlas remotes is to start with a "virgin" Atlas IR file when you are building the extender IR file. There is a good bit of "stuff" in between the end of the setup codes and the beginning of the Advance Code area that if not right the remote will freak out and start erasing things. Again, load your IR, upload it, set that file as the baseline, push a button, and then download. Nothing should have changed in the HEX tab. If it has, can you report back to me what is different.

thanks

-bill

Post by **vickyg2003** » Wed Jul 01, 2009 6:03 am

Bill wrote:
Cap'n

I looked at the code for 2.04 and 2.10 since those were the versions that you were using. I will repeat that between these two you should first deactivate the extender using 2.04 and then reactivate with 2.10. I didn't see that in your post, so I don't know if you did that.

Yes, if you didn't deactivate, that could cause you major problems, but I'm assuming you couldn't do a 981 if the extender was active. Extender deactiviation wouldn't have accounted for my problem, since I was using a virgin Atlas Ocap.

I went through and checked that all of the setup codes, and pids were valid before I even tried to upload it, but I missed that VPT setting. I'd start there.[/b]

Capn Trips · Post by **Capn Trips** » Wed Jul 01, 2009 6:20 am

At this point, I have done so many 981 resets on the remote, and have no idea what the v.2.04 ir file was, that I cannot reproduce how I got here, but I would be unable to do a 981 reset if the old extender were still activated, would I?

The remote properly accepts a 981 reset.

Then I download from the remote into IR 8.01 Beta).

Then I run EXINSTALL (the v.2 that comes with the extender package) and convert to ext v 2.10;

Then I add that single device.

Then I upload to the remote - the first time, it alerted me to bad setup codes, so I selected random setup codes from the code selector. Is it possible that one of th setup codes listed in the rdf (and displayed in code selector) is really NOT in the remote, and this is causing the problem?

Then I cannot activate the extender - nor does the deactivate command do anything. Just the behaviour I described in my first post

I'll upload all of the files involved in the process shortly in a zip file.

so additionally, I will also do this on my second OCAP remote that has NEVER had any extender loaded.

Capn Trips · Post by **Capn Trips** » Wed Jul 01, 2009 7:45 am

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.

Since my Motorola cable boxes use 1877, I have been assigning this as the default.

I'll give it a shot with a DIFFERENT setup code assigned to CBL and see if that makes a difference.

Capn Trips · Post by **Capn Trips** » Wed Jul 01, 2009 9:01 am

No joy. No matter what combination of device upgrades I have, and I am being REALLY careful that each device is assigned an upgrade that is in fact in the remote - I get the same thing after uploading the extender. ONLY THE DEFAULT MACROS are assigned to the device buttons.
(1) it will not activate;
(2) when i press TV or CBL, I get 2 blinks
(3) when I press any other device button I get a single blink.

Also, when I press TV, in addition to the 2 blinks, it sends a TV Power toggle signal.

I am loathe to test on another remote fro fear of messing it up.

greenough1 · Post by **greenough1** » Wed Jul 01, 2009 9:32 am

Hi Capn,
I've been using v2.04 with three 3A333 remotes (backlite, black 1056 OCAP). I've been reluctant, because of time constraints to upgrade to v2.10, but in light of your issues, I'll do it. We've got company coming into town tonight, but I think I'll have time to do some simple v2.10 testing.

Best,
jeff

unclemiltie · Post by **unclemiltie** » Wed Jul 01, 2009 9:55 am

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