Atlas JP1.3 Extender beta - Topic CLOSED

[Capn Trips]

Finally spent some time with this extender this weekend. Still all sorts of problems with Device Keys and LKPs, as well as multiplexer.

Haven't time to accurately document and upload files right now, but I cannot get an LKP to work on a device button or the Power button to save my life. (It works on transport keys, for example).

Similarly, I have yet to get the device multiplexer to work at all.

A thought - should shift-cloaking work with this extender? If not, then it may be that what I am seeing is related to my traditional reliance on shift-cloaking when making these power macros and LKPs.

[unclemiltie]

shift cloaking should work, I think I debugged this part when I wrote it a long time ago.

I know that there are a lot of you guys out there hoping for this thing to get done but I have just not had any free time since moving to CA, and it isn't going to get any better soon. (I close on a house finally this week and then get into all of the painting/updating and moving that'll take a month or so to settle down)

[Capn Trips]

Recognizing everybody's limitations on the availability of time, I will try to get as complete a documentation of and examples of what works/does not work for me, anticipating that it will get addressed whenever it gets addressed.

As it is, I believe that there is enough in this extender that DOES WORK properly, that I should be able to set up the remote for my HT system, although not QUITE as intuitive and simply as I'd ultimately prefer.

As far as the new house goes, please accept my congratulations (or sympathies) as you deem appplicable.

[mdavej]

Forgive me if this is a dumb question, but since the radio shack 15-134/135 and atlas both have an S3F80 processor, would the extender run on it, with a little tweaking? If it's not trivial, forget I asked. It's not worth the effort.

[Evan_s]

It's hard to say at this point Mdavej. There is more to the remote than just the processor in it. It's possible this might run on those remotes also or at least serve as a good starting point but unclemiltie is busy at this point and unable to continue development on the existing remotes adding additional remotes that are supported are going take more time or someone else with skill and desire to try working on them. Off the top of my head the RS remotes have a HT mode which isn't present in the Atlases which would imply differences in what is running in the remote that might have to be dealt with.

[mdavej]

Thanks. I certainly don't want to dump more on unclemiltie's plate or impede progress on the atlas project in any way. Just curious.

[vickyg2003]

Evan_S summed it up pretty well with this statement.

There is more to the remote than just the processor in it. It's possible this might run on those remotes also or at least serve as a good starting point

Basically the processor determines the language, but the remote's feature has a huge impact too. For instance when I did my first JP1.2 extender, it was more or less a matter of translating the one I had adapted for a JP1 remote. But when I went to adapt my 8820 extender to the JP1.2 Atlas, it was harder than changing from a different processor! However, unclemilte has a better overall understanding of how the remotes function. I just play a guessing game, where he actually does research!

[Capn Trips]

Thanks. I certainly don't want to ... impede progress on the atlas project ...

Wow! When you put it that way, it sounds like some sort of secret cabal, or the Illuminati, planning to take over the world.

Perhaps it is the Pentavirate.

Stuart Mackenzie: Well, it's a well known fact, Sonny Jim, that there's a secret society of the five wealthiest people in the world, known as The Pentavirate, who run everything in the world, including the newspapers, and meet tri-annually at a secret country mansion in Colorado, known as The Meadows.
Tony Giardino: So who's in this Pentavirate?
Stuart Mackenzie: The Queen, The Vatican, The Gettys, The Rothschilds, *and* Colonel Sanders before he went tits up. Oh, I hated the Colonel with is wee *beady* eyes, and that smug look on his face. "Oh, you're gonna buy my chicken! Ohhhhh!"
Charlie Mackenzie: Dad, how can you hate "The Colonel"?
Stuart Mackenzie: Because he puts an addictive chemical in his chicken that makes ya crave it fortnightly, smartass!

"I see we have competition, Pinky!"

[mdavej]

I think you're onto something. Ever wonder why we're compelled to visit this board so often after using the extender...

[unclemiltie]

Forgive me if this is a dumb question, but since the radio shack 15-134/135 and atlas both have an S3F80 processor, would the extender run on it, with a little tweaking? If it's not trivial, forget I asked. It's not worth the effort.

Well...

I did try to build the atlas extender with a mind toward supporting more than one remote. The current incarnation works with the 3033 OCAP Atlas as well as the 3000 Atlas (and support is also in there for the 3032 and the 3039 Comcast DVR JP1.3 remote but I've never tested it since I don't have them)


The answer to mjdave's question lies in the amount of similarity between the remotes. The 3033 and 3000 remotes are very similar other than different register usage and entry point addresses. That's easily dealt with through conditional assembly in the extender.

The 3032 and 3039 is another matter. The key definitions are different, keylists are different, etc. That too can be dealt with (and is) in the conditional assembly but at some point the amount of conditional assembly gets cumbersome and in the way and it makes sense to "port" the extender to the new remote. Whether I decide to leave the conditional assembly in the extender or port remains to be seen. I'd like to get the 3000/3033 "stable" before I go any further with these.

[unclemiltie]

Recognizing everybody's limitations on the availability of time, I will try to get as complete a documentation of and examples of what works/does not work for me, anticipating that it will get addressed whenever it gets addressed.

As it is, I believe that there is enough in this extender that DOES WORK properly, that I should be able to set up the remote for my HT system, although not QUITE as intuitive and simply as I'd ultimately prefer.

As far as the new house goes, please accept my congratulations (or sympathies) as you deem appplicable. :wink:

Thanks, detailed (pressable keys from the keypad!) test senarios with expected results and acheived results would be very helpful. Especially if they deal with an RCA Television! For examples, macros that change to channel 20 on a long keypress and 30 on a short keypress, etc. That way, I can sit down in front of a TV that I actually own and see the results. IR files are always appreciated, sending them to me directly is better than uploading them. (PM me for a direct email address, some of you already know it)

[Capn Trips]

Well, I don't have an RCA TV any more (Finally killed that old 25" 1987 Colortrak. That baby ROCKED for its time.)

The list of my gear is in my sig below. If there's a particular one that helps you focus on testing, let me know and that's the piece of equipment I'll use as my primary test platform.

However, I note that since my last post, I have multiplexer working, and LKP works on regular keys. Need to flesh out whether there is a problem with LKP on Device keys because it's an LKP, or because it's calling OTHER SP functions.

I'll try to get something documented and analysed by the end of this weekend.

[unclemiltie]

CAp'n

if you at least do your test stuff on the TV device, I can change the TV setup code and make it work with my RCA. Use common stuff, like changing the volume, channel numbers, etc. Stuff that I can "see" what happens when I do some of my testing.

Some of the testing writes internal registers back to the EEPROM so I should be able to see what "should be" happening, but when all is said and done, I'd like to be able point the remote at some stuff and go.

[sriram]

hey guys,

I've uploaded a simple .ir file which exhibits a bug (which might be the same as I described earlier).

It seems that all the key moves are going with the O_Device. I have two macros in the .ir file which demonstrate this.

thanks

[Capn Trips]

After a pretty long hiatus, I have finally had some time to focus on testing this extender on my OCAP. I've spent a LOT of time on this this weekend and here's the problem.

The X_Dev temporary device selection is still acting squirrelly.

I'll try to describe what I am seeing as best I can.

It appears that the X_Dev selection works only on actual SIGNALS to be sent, but does NOT affect other keystrokes called after the X_Dev. And at that, only the FIRST X-DEV command in a sequence seems to work (but as caveated abve), but subsequent ones seemingly do nothing. Confused? Me too!

Some background:
I'm currently using the default Device Selection Macros on the Device Buttons - except for always assigning V-AUD.

Discrete ON and OFF are assigned to PIP Ch+ and PIP Ch-, respectively for all devices. For TV and AUD these are actual Discrete ON and OFF functions (see keymoves 3, 4, 11 & 12). For my VCR/DVD and CBL devices, they are created via ToadTogs (see Special Functions 1 through 6). Note: the VCR and DVD use the same toggle bit, as it's a combo unit.

Each of these functions works correctly from direct press of PIP Ch+ and PIP Ch- respectively.

I have assigned macros on buttons A, B, C, and D. A and B SHOULD turn ON/OFF the TV, while C and D should turn ON/OFF the DVD/VCR combo unit (by calling the DVD's ToadTog functions.

EXAMPLE 1: When I am ALREADY in TV mode (i.e. the keysets have been assigned to TV via the device selection macro on the TV button), the macros on A and B work correctly - that is, the TV Discrete ON and Discrete OFF are sent every time A or B is pressed. But the macros on C and D do NOT call the DVD's ON/OFF functions, but instead calls on the TV's ON/OFF functions, as if the X-DVD command was being ignored.

On the other hand, if I am in DVD mode (i.e. DVD button pressed beforehand), A and B operate really weirdly. the FIRST press sends the TV's power toggle signals, and seemingly SETS (or RESETS for B) the DVD's ToadTog flag! and subsequent presses send nothing.

So it acts like the DVD's ToadTog sequence is executing, but when the ToadTog tells the remote to send an actual signal, the TV signal is sent!

It appears as if the X-TV command does NOT execute the subsequent intended TV PIP Ch+ (-) command, but instead it seems to execute to the DVD PIP Ch+ (-) (goes to the ToadTog SP function) BUT THEN executes the TV's shift-cloaked POWER command called from within the ToadTog!?!

What I'm saying is that internally, it processes as if there had been no X_TV command, but the actual signal sent IS as if affected by the X_TV.

EXAMPLE 2:Sort of the reverse occurs with the Macros on C and D. When in DVD mode to start with, it works fine, but when in TV mode, it simply executes the TV's PIP Ch+ (-) functions instead of the DVD's, as if the X_DVD command was not there at all.

EXAMPLE 3: I have created an ALL OFF Macro on the OnDemand button. It will usually only turn off the active device, plus the FIRST (X_CBL) temporary device in the sequence, despite the sequence of X_DEV PIP Ch- commands. On the other hand, the similar macro on Power, which uses O-DEV commands in lieu of the X_DEV commands works correctly (sends all required PIP Ch- commands. The problem with this workaround, of course, is that at the end of the sequence, the O keyset is assigned to a different device than desired.

Can someone MUCH smarter than me help figure out what is going on with temporary device selection in this extender?

Here's my IR file.
Thanks.