What new extender feature would you like?

xnappo · Post by **xnappo** » Sat Apr 17, 2010 9:55 am

xnappo wrote: Does it not do that? I think on my Atlas it did - but I no longer have the device/setup I used it with so I could be wrong... If it doesn't do it, unfortunately it is beyond my skill level to fix.

Try this for a version that executes the key that aborted the pause:

Code: Select all

RCA:
00 00 01 28 03 C6 C0 3B 0E F6 01 0D F6 40 09 A6
42 01 6B 03 2A EF AF F6 48 2D AF 

Atlas:
00 00 01 28 03 C6 C0 3B 0E F6 01 0D F6 40 09 A6
42 01 6B 03 2A EF AF F6 48 2A AF

This seemed to work on my Atlas and of course I don't have an RCA to test with. It did seem to take a fairly deliberate press vs. just a tap though...

I should note that while my original 'pause with abort' is solid, this one is a bit of a hack. If your remote starts acting weird, remember to remove this and see if it fixes it.

xnappo

R2-M0 · Post by **R2-M0** » Sun Apr 18, 2010 8:35 am

Thanks for the continued efforts, xnappo. Unfortunately, that latest RCA version doesn't appear to pause at all. That might have something to do with the

Code: Select all

CALL	4189H

instruction reverting back to

Code: Select all

CALL	4009H

between versions, since that appeared to be the adjustment you made to get your original Atlas version to work on the RCA in the first place.

Unfortunately, while correcting that subroutine call does restore the pause behavior, interrupting the pause with a button press seems to completely confuse the RCA, requiring a battery pull to get it responsive again. So I'm guessing the subsequent

Code: Select all

CALL	482DH

is sending the RCA off into someplace it has no business going. Presumably, if we can get the correct subroutine address in there, we might have something.

xnappo · Post by **xnappo** » Sun Apr 18, 2010 8:56 am

R2-M0 wrote:
Unfortunately, while correcting that subroutine call does restore the pause behavior, interrupting the pause with a button press seems to completely confuse the RCA, requiring a battery pull to get it responsive again. So I'm guessing the subsequent
Code: Select all
CALL	482DH
is sending the RCA off into someplace it has no business going. Presumably, if we can get the correct subroutine address in there, we might have something.

Thanks for the correction to the 4009 call. The problem is that there isn't a subroutine that does exactly what we need, so I am jumping into the middle of another routine. This means that some CPU registers may not have the data in them that they should and could be causing the crash.

Looking at it again though, you might try one more time with 482A instead of 482D.

xnappo

R2-M0 · Post by **R2-M0** » Sun Apr 18, 2010 9:27 am

xnappo wrote:Looking at it again though, you might try one more time with 482A instead of 482D.

Unfortunately, that doesn't appear to work any better.

Might I ask how you obtained these addresses in the first place? I'm assuming that there must be some tool (or combination of tools) that provides a disassembled view of the remote's built-in code. I'd be interested in poking around such a listing myself.

StephenR0 · Post by **StephenR0** » Tue May 11, 2010 11:59 am

I hope I'm not too late to request this, but I currently use the 6131 extender beta 2.0. This extender has an Input Select protocol that is able to operate the input selection menu on my (admittedly lame) tv. It's not the friendliest thing to use, but it works quite well for me. I'm interested in the Atlas remotes, but I'm going to need this function at least until I get a less lame tv. Is there any chance that this could be ported to the Atlas extender?

R2-M0 · Post by **R2-M0** » Wed Aug 25, 2010 6:12 pm

Apologies for resurrecting a comatose thread. But after several months of using my RCRP05B with the interruptible pause protocol, I believe I have a better grasp on the other half of my original feature request.

I previously wanted whatever button was used to interrupt the pause to then be "pressed" at the end of the macro. But I've realized that what I'm really looking for is a one-button typeahead whenever a macro is running, regardless of whether or not I happen to be in a pause at the time of the button press.

So if I kick off a macro, then press another button while the macro is running, I'd like the extender to remember that button and, when the macro ends, fire off the action associated with the remembered button. If it so happens that said button also interrupted a pause in the middle of the macro, that's just a bonus.

I think a single button typeahead queue should be more than sufficient. But I have no idea how difficult even that would be to implement.

Post by **ElizabethD** » Thu Dec 23, 2010 2:38 pm

xnappo wrote:
Code: Select all
00 00 01 28 03 C6 C0 3B 0E F6 01 0D F6 40 09 A6
42 01 6B 02 2A EF AF 
NOTE: this is for Atlas OCAP - it is very likely it will not work - if not I can probably get one to work for the RCA but will need to do some consulting with the experts.

I just need to confirm this is ok to use in the Atlas1056 extender and also, have you assigned an official protocol number to it or do I just invent my own?

Post by **ElizabethD** » Thu Dec 23, 2010 2:49 pm

Capn Trips wrote:Another vote for MORE DEVICES (I know I already voted - but like they say in Russia, "Vote early, vote often!"). Whatever amount of back-breaking, and mind-numbing effort it takes is absolutely a worthwhile investment of your time.

Haven't voted yet, so here's one more vote for the 10 devices. It's an enormous remote. Looking at the empty space makes me want to cry. 8-10 devices would make it great for me.

underquark · Post by **underquark** » Thu Dec 23, 2010 4:43 pm

If voting has be re-activated on this, I'd vote for a feature to select different groups of devices so that you could use the remote in different rooms, e.g. Group A has devices TV/0001, VCR0002, DVD0003, PVR004, SAT0101 etc., Group B maybe TV/1250, VCR/0800, DVD1103, PVR004, SAT0101. Group selection could be done by [SHift]-digit or [XShift]-digit or other suitable key. Since few seem to use the Fav key it could be turned into the Group selection (aka [XShift]) key.

Post by **ElizabethD** » Thu Dec 23, 2010 7:44 pm

2-3-4 groups here, but with only 5 devices is rough on Atlas, really rough, inspite of its enormous space.
On the 8910 I do know which "group" I'm in, but it does require to remember what you coded on which device button

Anyway, I'd rather not see anything too fixed to a FAV button, as I need unadulterated FAV and I'm serious about that need.

s**t-FAV or xshift-FAV trigger for groups (or on any other key really) would be cool but doesn't that take us back to the need for an excellent multidevice multiplexer that would not confuse keymoves and special keymoves, would handle 2-byte hex codes, etc.? And without an LCD screen how would we know which group the remote is currently thinking of using as you walk about the house with it hanging 'round your neck? Just thinking out loud.

unclemiltie · Post by **unclemiltie** » Tue Mar 01, 2011 9:43 am

To resurrect this somewhat dormant thread. I've been working on the RCA RCRP05B (3179) and the Insignia (3147) extenders lately and went back and re-read this entire thread. An update:

V1.01 of the 3179 and V0.01 of the 3147 extender now have two of the requested features built in to the extender:

1: a key press will interrupt the pause protocol and cause it to terminate. This does not execute the key that caused the keypress, it could but... more on that later

2: there is a user selectable value for delays between macro keys ranging between $00 and $FF. This is settable in the general settings in the IR tab

.

now, some questions:

First, on the key that caused the pause interruption. how would you prefer that I deal with it. It can either:

a: interrupt the pause and any macro that was playing and execute that key and that key alone

b: interrupt the pause and stuff the key that caused the interruption at the end of any currently playing macro

c: ignore the key (currently implemented)

Second, on the macro delays: Is a small delay between macro keys acceptable to most people? Right now, there is

Code: Select all


CLR    RC0
LD      RC1,#xx
CALL   DelayWW0 ($010D)

in between fetching the key from the macro and the execution of that key. If the DelayWW0 value is $00, I think it'll return pretty quickly. Will anyone even notice?

Third, I can probably put an interruptable macro into these things, but that will introduce more delay in between the processing of keys. A scankeypad to check to see if something was pressed in between each key process will be a pretty big penalty. I'm inclined to not do it. We'd have the same issue of what to do with the key as with the interruptable pause so think about that as well.

mdavej · Post by **mdavej** » Tue Mar 01, 2011 10:38 am

I vote for B. But I don't see myself ever using interruptible pause at all, especially not at the expense of performance.

On the other hand, user selectable macro delay will be very handy. Personally, I think the default delay is a bit too short, but if I can adjust it, it doesn't matter.

Post by **ElizabethD** » Tue Mar 01, 2011 11:04 am

The needs I see are:
1. Flexible delays between macro buttons. Would that need a device keymove or be a global type of thing? I don't care how. It's needed.
2. Interrupt a long pause within a macro and continue with the macro, i.e. go to the next command in a macro. useful for some sluggish devices. This might fall under a or b or some variant thereof.
3. Interrupt and kill a macro totally - useful when a macro contains several commands to do several 30-sec skips, and fewer might be needed. I think this falls under point c.

unclemiltie · Post by **unclemiltie** » Tue Mar 01, 2011 11:35 am

Actually the more that I thought about it last night, I'm not sure that option (a) is all that viable.

I many of the extenders, you will have a lot of temporary device settings and depending in the macro where you are, the temp device will be different and thus the key that is going to be substituted could have a different effect. (I'm somewhat cautious of Chris' protocol upgrade that executes the key pressed when in use with the extender by the way as it doesn't clean up things that the extender cleans up when it passes control back to the core remote, so I wouldn't recommend using it. I think it's safe with the unextended remote)

option (b) adding the key to the end would at least produce consistent results. (although not necessarily desirable since a temp-device cancellation may not have taken place)

ignoring the key seems like the right thing to do (which is what I implemented in the 3147 and 3179 extender)

re: Liz

Interrupting and killing a macro totally will introduce a pretty significant delay between each of the keys since I'm going to have to scan the keypad in between every key. I guess I could "skip" the scan with a flag setting but that's more code and some of the JP1.3 extenders are pretty tight as it is. (the RCA is one of them since it has so much configuration data there is less room for the extender)

When you say "flexible delay between macro keys" do you mean:

1: a delay that is used between all of the keys in every macro (easy)
2: a delay that is used between the keys in each macro, but can be different for each macro (much harder, would likely require support in IR and RMIR to do it)
3: a delay that is different between every key within a macro and different in different macros (makes my head hurt)

(1) is already implemented in the 3147 extender (not the one that is in private beta) and in V1.01 of the 3179 extender that I'm gonna need some testers for.

(2) and (3) would likely require a "new format" for storing macros that had the delay embedded into them and thus would require changes to IR and RMIR and Extinstall to deal with it. Again, not impossible but I'm not sure that it's really worth the effort.

Post by **ElizabethD** » Tue Mar 01, 2011 12:30 pm

My head hurts too even though I'm not the one writing the extender

unclemiltie wrote:When you say "flexible delay between macro keys" do you mean:...

Most flexible delays can now be handled by Pause keymoves. Your solution 1: seems like a good one.

Regarding

unclemiltie wrote:(2) and (3) would likely require a "new format" for storing macros that had the delay embedded into them and thus would require changes to IR and RMIR and Extinstall to deal with it. Again, not impossible but I'm not sure that it's really worth the effort.

Ok, skip my point 2. It can be adjusted while we setup the macros and test on the real gear, so no big problem, as I think about it
.
My point 3. So this one is the only one that I'd like to see. It's not a matter of delay. It's a matter of the need for early exit. People do like to skip commercials, and often make a macro of several skip steps or a forever looping macro (while the key is held) in order to skip a minute, 2 minutes ... would be nice to kill when fewer ads were broadcast than anticipated. Since the extender space it tight, it could just be an optional device and protocol we can load when needed and make a keymove to insert before all the SKIP commands or at the end. Yes? No?