Changing modes after a timeout

[ElizabethD]

Thanks, Don. Looks like all the pieces of your thing are here.
Some 8910 feedback: I reassembled. I can now see why the signature in the IR file was "...xx", and BTW it does require rewriting the RDF for maintenance and therefore a whole new zip package. I haven't used it yet because my design needs a slightly different approach in IR.

Re previous vcr/xhift4:

The $24 inserted by VCR/xs-3 is the keycode for callabck of the HT button which, when short pressed, restores the last HT mode. I can't comment on VCR/xs-4 because it doesn't appear to be a used keymove in my IR file. However, somewhere in my code I will reset to 0 the keycode to be called back and perhaps VCR/xs-4 is involved - but its not obvious to me now how I did it.

It appears to occur, inside the extender, as soon as is used. I like that. I like the whole callback idea

We haven't helped Mark, though, have we?

[pH7_jp1]

Liz,

Are you looking at implementing the "timed callback" for the HTPro/9811? If you (or anyone else) are already looking at that, I will just wait. But if you are not, I am hot on the trail of something that may work.

[ElizabethD]

Thanks much. But, thanks to Capn's pointers and Don's so patient explanations, it's been working for a while now. But it's only on the 8910/9910/HTPro, not 6011. I also made a version for controlling the backlight itself from the light button only, but both of those just won't fit in one package (3 bytes short grumble, grumble). So I'm still toying with it, with little hope of success of fitting both in. The whole thing is non-standard extender of course.

Is 9811=8910?

[pH7_jp1]

it's only on the 8910/9910/HTPro

That's the one I am interested in. Is it available anywhere?

Is 9811=8910?

I think so, 9811 is what it says on the back of my HTPro (and HTPro/9811 in your sig).

[ElizabethD]

I forgot to read my signature

The package is not anywhere except on my computer and 8910 or HTPro. I just found it. Give me a little time to get it together - I have to include instructions how to merge the new extender without using Extinstall (which clobbers notes) and then how to put all the pieces together. Tomorrow or over the weekend.

In the meantime, make sure you have 5 bytes for a keymove, one byte for each use of that keymove in your device selection (LKP or shift) macros, and 18 for the device upgrade and protocol the same size as Don's above.

[pH7_jp1]

Thanks a lot. I think this is a really great feature.

[ElizabethD]

Try this - see the readme file
http://www.hifi-remote.com/forums/dload ... le_id=3638

[Capn Trips]

Cool! Thanks for doing all of the work on this, Liz!

Might I suggest that a more appropriate location would be the 8910 Extender Files folder rather than the diagnosis area? You have certainly included enough caveats to protect an unwitting user from him/herself.

[ElizabethD]

Capn Trips, Don did all the work, my role was janitorial

It's in Diagnosis because of these excuses:
1. Version confusion - not sure what's on what computer. I knew it was close and wanted to give something to pH7_jp1
2. While it doesn't crash, I had my doubts about the way light button works, and due to #1 just found out a change is needed so I updated the file
3. Timeback call is a feature change, not really an extender 1 extension. Not sure people want it with the official stuff to avoid confusion.

The change from yesterday's version is simple if you already used it on existing IR file:
On the Raw Data sheet, line 00E0 at E6 swap two calls by replacing
F6 38 1E F6 41 DE
by
F6 41 DE F6 38 1E
Click "Apply" and upload.

Readme file is now up to date as are .asm, and .hex.
I also included my IR file made from the readme instructions so you can see how it works in your 8910 - I put a comment up front on the General tab how to use and what to expect.

8910_ex6.IR is untested. The intent is to start with empty 8910ext, typical initial setup, plus the callback device and protocol.

[pH7_jp1]

Thanks for posting this, Liz. I will try it sometime later today.

[pH7_jp1]

Hi Liz,

I loaded your file (MyIR-8910-usingNotepadMerge.IR) into my HTPro to see the timed callback in action. Things don’t work as I expected, so lets see if I wasn’t even on the same page with what you intended…

I have mine set up so that a LKP of any device button will: 1) turn ON all devices needed for that device mode, 2) turn OFF all devices that are of no use while in that device mode, 3) select the correct video input on my TV and select the correct audio input on my receiver, and 4) do the SET_xxx_KEYS and SET_LCD for that device mode. This is a “permanent” switch to a device mode – I think of it as LKP of DVD means “I want to watch a DVD now”. A SKP of any device button will only do step 4) of the above. This is a “temporary” switch to control a specific hardware device - I think of as SKP of VCR means “I want to send the following command(s) to the VCR." After doing one of these temporary switches, I want it to revert to the “permanent” device mode.

So, here is a scenario: a) LKP – DVD to start watching a DVD. b) Maybe 5 minutes later, I notice my VCR is ON, so I do – SKP – VCR, Power. c) Without the timed callback I now do a SKP-DVD to put the remote back in the right mode. What I expected with the timed callback was to revert to DVD a short time after I quit pushing buttons.

Instead, what I observe is: If I select another device and push other buttons within about 20 seconds of doing the LKP then the remote will revert to the device established by the LKP. But the SKP of another device button is after that 20 seconds, then there is no reverting.

Looking at your readme.txt file, I suspect that you implemented what you expected, but not what I expected. To do what I hoped, would require 2 different functions: 1) save the current device as “permanent” (this would be done with any device button LKP) and 2) start a timed callback to revert to the “permanent” device (this would be done with any device button SKP). Also, any keypress while the countdown was in effect would reset the counter to the full value, so that 20 seconds after the last keypress the remote would then revert to the “permanent” device.

If you have what you want and that is different from what I expected, then I will go back to looking at a way to implement what I wanted. I really do appreciate all your effort to make this available. If I end up doing something, I’ll be sure to pass it along as well.

[DGG]

At the risk of confusing the issue further, "timed callback" is a general purpose function (despite its "special protocol" moniker) that causes a specified keystroke to be issued automatically upon the next expiry of the backlight timer. It has no knowledge of the purpose of that keystroke, the currently selected HT mode or anything else.

pH7_jp1, in order to have "timed callback" do what it appears you appear to want it to do, you've got to be able to determine the currently selected HT mode so that you can specify to timed callback the LKP to reselect that mode. In my implementation, I use only 5 physical devices. Hence, I need only 5 Toadtog bits for power status, leaving 3 for other uses. I use those 3 bits to save the currently selected HT mode as one of 8 possible bit patterns. The coding to encode/decode these bits, while tedious, is straightforward. If you don't have three spare bits in your Toadtog register, you may wish to consider inplementing my Toadtog 2 protocol, which makes avaiable another 8 bits - unless someone has used the register for some other purpose. (Elizabeth should be able to help you there.)

My HT selection method is identical to yours, i.e., LKP selects the HT mode, SKP allows communication with a specific device. My system works as follows:

- During processing of a HT mode LKP, the appropriate bit pattern for the newly selected mode is stored in the 3 Toadtog bits.

- During processing of a HT Mode SKP, the keycode for the currently selected HT mode (based on bit patttern currently stored in the 3 Toadtog bits) is "sent" to Timed Callback.

You can have any number of HT mode SKPs in series; each such press will re-specify the appropriate timed callback keystroke. However, each such keypress, in fact any keypress, restarts the backlight timer, so the callback will be delayed until 10 seconds after the last keypress.

Hope this helps,
Don

[pH7_jp1]

Thanks, Don.

I will dig into the implementation a bit more and set it up as you suggest.

I was looking into an alternate implementation for the HTPro. It already has a timed callback capability. They called it "commercial skip" and as they implemented it, it was pretty useless, but there were 7 bytes dedicated to it: keycode of the device to use when the callback executes, number of seconds to delay, and a 5 keycode macro to execute. The user interface only allowed 30, 60, 90, 120, 150, and 180 seconds and only digits 0-9 and enter in the macro. In fact, any number of seconds (up to 255) and any keycode worked. I tested this by just editing the raw hex and pushing the com/skip key. One nice thing, the time was independent of the backlight timer value.

That is as far as I had investigated, but it seems that doing something pretty general should be simple when this much of the code is already there. Taking advantage of this would work on this remote, but not be transportable to other remotes as is your solution.

[ElizabethD]

lets see if I wasn’t even on the same page with what you intended

I never really specified whatI intended. I wanted to gather the tools Don provided in the first place, to learn from and play with.

What I want is for the LKP device button to be remembered forever until another LKP device is pressed. The only way I could do it is fiddling with Don's code in the extender - by NOT clearing his register (that change described at the end of readme file). I think it'll kill the battery blinking every N seconds all day long.

What it does is remember it for the duration of timeout.

Instead, what I observe is: If I select another device and push other buttons within about 20 seconds of doing the LKP then the remote will revert to the device established by the LKP. But [if?] the SKP of another device button is after that 20 seconds, then there is no reverting.

If you're refering here to my file. I can confirm that that's precisely what I see. And I doubt very much that the remote cares whether we force HT key or whatever triggered the macro. In my file I don't do any power commands in the device macros, all I do is SET...SET and line'm up (your steps 4, 3). So your design is closer to Don's than mine. But I don't think that makes any difference in the timing thing.

I just read Don's answer as I'm writing this. Continuously forcing the 'permanent' device via a keymove of some sort is likely the way to do it.

Also, any keypress while the countdown was in effect would reset the counter to the full value,

Yeah. That's worth looking into. But the code is so tight there, little can be done even when you know what you're doing. I tried comSkip once before but didn't get very far.

you may wish to consider inplementing my Toadtog 2 protocol, which makes avaiable another 8 bits - unless someone has used the register for some other purpose

Callback uses the same register. Is there another free one that you know of?

you've got to be able to determine the currently selected HT mode so that you can specify to timed callback the LKP to reselect that mode

Don, since I don't use HT mode, I did this by watching the button that starts the macro and push that for reselection. But I don't want it forgotten when othe rbuttons are pushed. Incidentally, while I want more out of it, it's an improvement over any previous setup. So I'm not complaining. It's now possible to adjust sound or picture and still revert to the watching mode.

Are we all on the same page? I hope so.

[pH7_jp1]

ElizabethD wrote:

Are we all on the same page? I hope so.

Yes, I believe so. I obviously need to study and experiment some more. Thanks to both of you.