Atlas 3000 & 3033 JP1.3 extender

mdavej · Post by **mdavej** » Sun Jan 04, 2009 9:14 pm

Cap'n,

Doesn't look like your extender is installed right. All the extender protocols should be just 3 lines of code. Your LDKP protocol is the wrong address and has old code in it.

It was painful, but I deactivated my old extender, 981 reset, and built a new IR file from scratch. Any shortcuts caused me problems.

I have several LKPs with lots of steps and they all play straight through with no stalls.

greenough1 · Post by **greenough1** » Sun Jan 04, 2009 9:45 pm

I agree with mdavej, it was a bit painful (actually starting all over with a virgin remote image), but extender v2.03 seems to work flawlessly.

I'm going to setup this remote for my main HT system tonight. I'll report back problems, but I don't anticipate any with the current version.

Best,
jeff

unclemiltie · Post by **unclemiltie** » Sun Jan 04, 2009 10:35 pm

Cap'n

you MUST deactivate and restart when you build the extender for V2.00 and above. This is because I moved the code for the special protocols into a hidden area in the remote and as mdavej says, the protocols should jsut be the header and a JP to the hidden address.

This saves a good bit of space in the upgrade area, but because of this, the extender is now very different and if you had the old protocols, you could really get weird result.

-bill

greenough1 · Post by **greenough1** » Mon Jan 05, 2009 12:28 am

I worked on the setup for the main HT. The only issue I ran into was with the pause.

Check my setup HERE . Look on the macro tab for shift+power. This turns on the tv and sets the aspect ratio to zoom, after the set comes on and is receptive to commands which is about 5-6 sec.

I tried a number of different values $04 and $F0 with no effect.

Thanks,
jeff

Capn Trips · Post by **Capn Trips** » Mon Jan 05, 2009 8:06 am

mdavej wrote: It was painful, but I deactivated my old extender, 981 reset, and built a new IR file from scratch.

unclemiltie wrote:you MUST deactivate and restart when you build the extender for V2.00 and above.

I assure you that I did PRECISELY that.

(1) deactivated extender;
(2) 981 reset;
(3) Uploaded bare image from remote to IR;
(4) ran extinstall on this image;
(4) re-built each upgrade in RM using the new RDFs;
(5) re-added each upgrade into the new IR image;
(6) re-built every SP function, Keymove and Macro from scratch.

I am 100% certain that I did that pretty meticulously.

I will do it again, but I distinctly remember doing this on Saturday. I'll do a detailed purge of my computer of any "stray" extender HEX and RDFs that may be lurking around in there, and then download them again to start afresh, but I'm pretty sure that I was REALLY careful.

P.S. Is there a problem opening up a RM file built using one RDF when that subject RDF has been altered? Or should it not just require re-assigning a few buttons? e.g. should I take my OLD extender device upgrades and open them in RM with the OLD extender RDF in the RDF directory, CHANGE the remote to the UNEXTENDED remote and save the file, and THEN change the RDF file in the RDF directory and (close and re-open RM) re-open the unextended device upgrade and alter the RDF? Seems like that should not be required, but I'm no longer sure.

greenough1 · Post by **greenough1** » Mon Jan 05, 2009 8:52 am

Hi Capn,
I can't answer your questions precisely since I use KM and not RM. One thing I did note from the change to the latest version of the extender and the new rdf's was that in IR, keys were scrambled.

To see what mdavej is talking about download and open the IR file I linked just above regarding PAUSE. Compare, on the protocol tabs, your LDKP and mine. You'll see somethings off.

Generally, upgrades don't know anything about extended or unextended, that's all in the remote. I would say that your step 4) is what probably went wrong. Maybe pointing to the wrong rdf's or wrong hex. I have found that it's best to put all the rdf's (extended and not) all in the same folder. going from V2.01 to V2.03, which had rdf updates, required culling out from my rdf folder, the v2.01 rdf's, to avoid confusion.

By the way, I forget if you used PAUSE. I'd like to know if it worked for you.

Best,
jeff

mdavej · Post by **mdavej** » Mon Jan 05, 2009 9:57 am

Jeff,

I think pause takes 2-bytes. Here are some values you can try:
0A 62«1 second pause»
14 72«2 second pause»
1E C2«3 second pause»
28 53«4 second pause»
32 A3«5 second pause»
3C B3«6 second pause»
46 00«7 second pause»
50 90«8 second pause»
5A E0«9 second pause»
64 F1«10 second pause»

If you look at a pause upgrade in RM, it's the last 2 bytes in each key move when you make a function for a certain duration and assign it to a key.

Capn Trips · Post by **Capn Trips** » Mon Jan 05, 2009 10:05 am

Well, studying my IR file (all I can do here at work), I notice that my LDKP protocol does INDEED match the one in jeff's uploaded file. My "protocol notes" entries in IR for LDKP/01F9 and Backlight control/01F8 are swapped, but the DATA in protocl 01F9 is EXACTLY the SAME!

My 01F8 (Backlight control) protocol is (expectedly) different since it uses the 'add-on' protocol produced by Mike before it was incorporated into the extender.

If my LDKP protocol is correct, as I believe that it is, can someone revisit my comments from last night and look a little bit deeper?

Although installed, I don't use the Backlight control protocol for anything (nor the Pause for that matter), so ultimately I will delete it, but it shouldn't make other stuff break, should it?

greenough1 · Post by **greenough1** » Mon Jan 05, 2009 10:25 am

Ah thanks mdavej. TWO bytes. I was entering 1 byte and the protocol took it happily. I did read that in the extender notes, but didn't follow the instructions - user error as I originally thought.

Under the heading of someone was thinking when they build the tool:

If I enter a keymove on say device TV, bound to phantom3 using the PAUSE protocol, and a hex command, IR auto-magically creates the entry in the special protocols tab. Very slick indeed.

Capn,
I'm puzzled by your comments that your and my LDKP protocols are the the same. Last night, after reading mdavej's comments about your uploaded file, I compared yours and mine and I thought I say big differences. I'm at work and don't have access to IR, so can't comment. I'll look again when I get home. If it is the same, then color me brain-dead.

Best,
jeff

Capn Trips · Post by **Capn Trips** » Mon Jan 05, 2009 10:44 am

If you look at the Protocols tab, the 01F9 protocols are identical. In MY file, that 01F9 protocol has the incorrect notes that say it is the Backlight protocol. Similarly, my Backlight protocol (01F8) has the incorrect notes that say it is the LDKP protocol.

The error is in the notes, which are immaterial to its function, but the actual data in the protocols (01F9) is identical.

Believe me, I'd be happy if what you had identified WAS correct, then I have something to go fix. Right now, the only difference I see is that my file has Mike's "aftermarket" Backlight toggle protocol, rather than the newest built-in one. (01F8).

Having said that, when I get home, I will rebuild from scratch (again) using the latest version. Maybe Mike's add-on backlight protocol doesn't play well with the extender and Bill's built-in one in 2.03 will indeed fix my problems.

Hey! a crazy thought just crossed my mind while I was typing. I re-ordered the extender-related protocol and device upgrades in IR to "make it look better".

i.e. after running extinstall, the SP upgrades are listed as follows:
TV:1800
DVD/VCR:1800
TV:1103
TV:1104
TV:1101
TV:1106
TV:1105

I re-ordered them to be in ascending order (after the two 1800 upgrades) to make it prettier (can YOU spell 'anally-retentive"?) and then moved around the protocol upgrades to match the order of the device upgrades.

Could THIS possibly have an impact on how the data are interpreted and used?

EDIT: One other thing, Bill. The keys.xls spreadsheet has something wrong, as I get a bunch of errors in boxes where DEC2HEX functions are supposed to calculate a value.

Capn Trips · Post by **Capn Trips** » Mon Jan 05, 2009 11:42 am

Another question (and I cannot find it discussed in the readme):

What are the X_PUSH and X_POP functions/buttons?

greenough1 · Post by **greenough1** » Mon Jan 05, 2009 12:04 pm

Capn Trips wrote:
The error is in the notes, which are immaterial to its function, but the actual data in the protocols (01F9) is identical.

Ah ha, that explains what I was seeing as a difference.

Unclemiltie or others will have to comment on the differences in ordering. (I didn't know one could do that - edit that tab. sounds dangerous

).

Best,
jeff

Capn Trips · Post by **Capn Trips** » Mon Jan 05, 2009 1:43 pm

greenough1 wrote: Unclemiltie or others will have to comment on the differences in ordering. (I didn't know one could do that - edit that tab. sounds dangerous ).

Sure, just like Keymoves, Macros and other stuff, just click and drag the number in the "#" column. I like using that capability to "clean up" my setups, especially bunching related keymoves, macros and SP functions, but if it harms the functioning, then of course I'd stop doing so in the Devices and Protocols tabs.

greenough1 · Post by **greenough1** » Mon Jan 05, 2009 2:16 pm

That capability will definite "clean-up" my setups. Thanks for the tip.

mr_d_p_gumby · Post by **mr_d_p_gumby** » Mon Jan 05, 2009 7:25 pm

Capn Trips wrote:Maybe Mike's add-on backlight protocol doesn't play well with the extender and Bill's built-in one in 2.03 will indeed fix my problems.

It shouldn't have any impact, especially if you are not using it. It only adds additonal ways of manipulating the same data as Bill's original protocol.