Atlas 3000 & 3033 JP1.3 extender

[xnappo]

Thoughts?

Eh... Doesn't really do much for me. How about 3.00 with Vicki's new phantom device idea?

Or... 2.11 with the backlight fixed!

xnappo

[unclemiltie]

to tell you the truth, I never really understood the phantom device idea, but then again didn't pay much attention to it.

I've heard of the backlight toggle getting munged, but never really seen a series of steps (i.e. push this, do this, then that and the backlight toggle gets whacked) if you have done that, let me know and I'll be happy to look into it.

[mdavej]

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?

Thanks for taking this on Bill. I think it's a great idea. I don't know what 8900 style means exactly, but if it means xshifts without the key remapping you had to do before, I'm all for it. I assume the RCA will be able to do xshifts too in this scenario? And can you take advantage of the RCA's built-in mutiplexing and DSM's?

[vickyg2003]

I don't know what 8900 style means exactly

If you read the Capn's Begginners Extender FAQ, he discusses the two different device selection methods used by various extenders, and he does it very well as always.

[mdavej]

Doh! (slaps forehead)... that's what the 8910 extender uses. Makes sense now that it would save a lot of key codes. Works for me.

Thanks vicky, and Capn'.

[greenough1]

Hi Uncle,
I don't know how the backlighter gets munged. What I'll notice is that it no longer lights on a key press. I deactivate the extender and re-activate it and that'll fix it, until it gets munged again. Aside from the intermittent backlighter munging, this extender has made the Atlas 1056 OCAP remotes my favorite and the ones in every room.

Regarding simplifying keycodes, I say do what's easiest for you as the developer. I've used both the 8810 and 8910 extenders and had no problems programming with either syntax.

Best,
jeff

[Capn Trips]

Doh! (slaps forehead)... that's what the 8910 extender uses. Makes sense now that it would save a lot of key codes. Works for me.

Thanks vicky, and Capn'.

Ummm... "You're welcome"?

It's nice to be thanked for NO participation in this thread

But to be frank, I have used both styles of Device to Keygroup assignment in extenders with no big problem with either, and never really considered the pros & cons of either. As a non-programmer, I never really considered that each "command" (like X_CBL, Set_Keys_Vol, X_cancel, T_DVD, etc.) has to be DEFINED and occupies SPACE in the remote's memory.

I see now that the "Set_Keys_Vol" system requires the developer to define far fewer commands than the "V_AUD" system. However, the payment comes due when writing macros using these - a system setup macro setting (e.g) PIP to TV, Vol to AUD, Transport to DVD, and Other & Channel to CBL is MUCH longer in the former system, eating one's programming memory and complicating the programming by lengthening macros, possibly forcing macros calling other macros due to length restrictions.

Bottom line - I yield to the extender writer in all of these circumstances.

BottomER line - I am concerned that re-writing this extender will force me to re-write the IR setup for my OCAP. (And we all agree that's it's all about ME)

Is there any chance that it would be able to import/convert an existing extender 2.10 setup?

[vickyg2003]

Doh! (slaps forehead)... that's what the 8910 extender uses. Makes sense now that it would save a lot of key codes. Works for me.

Thanks vicky, and Capn'.

Ummm... "You're welcome"?

It's nice to be thanked for NO participation in this thread

Well your Beginners Extender FAQ is a post that just keeps on giving. I've read it many times, even after I started writing extenders.

But to be frank, I have used both styles of Device to Keygroup assignment in extenders with no big problem with either, and never really considered the pros & cons of either.

Its funny, your post forced me to consider the pros and cons.

I had a hard time with my first 10820 extender. With the 10 devices I had to consolidate the M_ and O_ groups in order to come up with enough keycodes.

When I did the 10820N extender, I had just read the beginners thread AGAIN, and saw there was a different HT method. I switched to the SET_ type and was able to separate the O and M groups and offer more phantoms.

Looking at the two keysets you can can see what a difference this makes.
10820 Keycodes

10820N Keycodes.htm

8910 type SET_
Pros
More phantoms available
You don't have to consolidate groups on remotes with 8 or more devices.
The SET_ commands can be reused with nesting reducing required Keymove/macro space if reused in a second macro..

Cons
A SET_ style macro will take an extra bytes.
If space is optimized by having the SET_ portion in a reuseable macro, its a little more difficult for the novice to follow.

[Capn Trips]

Well your Beginners Extender FAQ is a post that just keeps on giving. I've read it many times, even after I started writing extenders.

Thanks. You're too kind. As my only REAL contribution to this forum, I try to keep it updated. In fact I tweaked it a bit yesterday after this thread reminded me of it, since when I wrote it, JP1 (EEPROM) remotes ruled the day, whereas now they are becoming a rare bird and the JP1.X (Flash) remotes predominate, and they should no longer be referred to as the exception, but as the rule.

[ElizabethD]

Bottom line - I yield to the extender writer in all of these circumstances.

BottomER line - I am concerned that re-writing this extender will force me to re-write the IR setup for my OCAP. (And we all agree that's it's all about ME) ...

Is there any chance that it would be able to import/convert an existing extender 2.10 setup?

I second all the above. Especially red

I do prefer the 8910 style where all default macros use one phantom1 and then we tweak. I also like 6131 style with just 3 keygroups. And I like 7800ext5 with few more groups. So either way is ok.

But conversion of existing Atlas, Comcast and others of that sort will be brutal. Every single macro or DSM or LKP will have to be converted. And not just CapnTrips but perhaps all the ones in diagnosis and many examples.

unclemiltie,If you're opening up the Atlas extender 2.10, please don't forget that the FAV key is not working. While I'm still struggling with something else I'm doing wrong there in another thread, the FAV issue is an older one and it would be great to be able to use it just as in 8910, 15 5-button sequences, whatever they may be (not just channels).

[vickyg2003]

Please don't forget that the FAV key is not working. While I'm still struggling with something else I'm doing wrong there in another thread, the FAV issue is an older one and it would be great to be able to use it just as in 8910, 15 5-button sequences, whatever they may be (not just channels).

The Atlas didn't come with an OFA type FAV key where you could program a list. It did come with multi-macros that execute a different macro every time the key was pressed. The multimacro s allow up to 7 macros to be associated with a key. I think Bill told me that multimacros are not supported either. Personally I like the FAV keys. If I redo my Atlas, I'll be adding FAV support.

[unclemiltie]

Is there any chance that it would be able to import/convert an existing extender 2.10 setup?

Not possible

But there would be really no need to do it since there would be no new features. But I think I will do conditional assembly so that I maintain one source and it builds both extenders so that if I find a bug in one I can release both at the same time

That probably means a different signature (like 3B33) if I build it

Thanks all for the feedback

[Capn Trips]

If the new extender gets a new sig as you propose, then I agree that there is no compelling reason to convert. My concern was with RDF maintenance, as the tools evolve, and I keep my tools updated, if you used the same sig for the "new" extender, then users would be unable to open and edit their existing extender setups in the future. Incrementing the sig to 3B33, keeping 3A33 for the "original" style extender should work fine.

[unclemiltie]

If the new extender gets a new sig as you propose, then I agree that there is no compelling reason to convert. My concern was with RDF maintenance, as the tools evolve, and I keep my tools updated, if you used the same sig for the "new" extender, then users would be unable to open and edit their existing extender setups in the future. Incrementing the sig to 3B33, keeping 3A33 for the "original" style extender should work fine.

Actually if I change the version and the fixed data at $1FE then the tools will select the right rdf even if they have the same sig.

But I think a new sig is the way to go if I get around to this

[Capn Trips]

Actually if I change the version and the fixed data at $1FE then the tools will select the right rdf even if they have the same sig.

Yeah, but how many rdfs will be maintained in the rdf zip distribution with the same sig? I know that there are one-offs (3A33 for 1055 vs. 1056) but it would become a truly unwieldy management issue to maintain multiple RDFs for the same remote AND signature!