JP1 Remotes

The scenario I am trying to solve is:

Pressing the “power” button for a short period behaves like it normally does (i.e. switches the selected device on/off)
Pressing the “power” button for a longer period executes a “power down all devices” macro
Double pressing the “power” button executes a “power up all devices” macro

The “power down all devices” & “power up all devices” macros have been tested on there own and work perfectly. (Makes use of discrete codes)

I am currently using a URC 9960 with extender 2 which has the LKP & DKP protocols / special devices installed.

I have tested the following two methods:

1) Macro on “power” key
This is my preferred method (as it works for all the devices without needing to create a lot more key moves) but for some reason often fails (ie. ignores either long press or double press commands)

Created a macro on the power key: X_DVD,XShift_phantom1

Created a key move on DVD for XShift_phantom1. This is a duration 2 DKP with 1 press:XShift_power; 2:Press:XShift_Macro1 (where xshift macro 1 is the all power on macro)

Created a key Move on DVD for XShift_power. This is a duration 3 LKP with short:X_Cancel,Shift_power long:XShift_Macro2 (where xshift macro 2 is the all off macro). The reason for the X_Cancel is to make sure that the original device (not DVD) gets the shift cloaked power command.

2) Key Move on all “power” key / device combinations (eg. DVD/Power)
For each device, the following set of key moves are defined (eg. Below DVD). This usually works.

Created a key move on DVD for power. This is a duration 2 DKP with 1 press:XShift_power; 2:Press:XShift_Macro1 (where xshift macro 1 is the all power on macro)

Created a key Move on DVD for XShift_power. This is a duration 3 LKP with short:Shift_power; long:XShift_Macro2 (where xshift macro 2 is the all off macro)


What I would like to know is why I am having stability problems on method 1 and not so much on method2? Is there an alternative device & protocol that will give me a direct 3 way LKP/DKP command?

A zip diagnosis file is in:
IR files

You probably need to expand a bit on what you mean by "Stability Issues". Does you remote reset? Certain combinations harder to get? (if so which ones)...

Have you tried turning this around, so the LKP is first and then the DKP is off the short part of that?

By stability, I mean getting consistent results each time I double or long key press. What happens in a "fail" is that (particularly with the long key press) I just get the selected device behaving as normal i.e the long key press is ignored.

I have tried out the alternative combination: a LKP and then DKP and that is even worse.

That does seem odd, I've setup something similar on a different remote (LKP first) and it does seem to behave consistently for me, all be it with simpler macros.

I guess you've fiddled with the timing values, since that's the only thing I can think of right now.

I'll take another look at the protocol and see if anything jumps out.

Nothing immediately obvious, except the timing.
If the readme is anything to go by, 0 to 4 seconds will be the a short press of the lkp, over 4 seconds a long press of the lkp, but double key press needs to be within about 1.5 seconds.

The 4 seconds overall seems a bit long to me (esp since the other LKPs you've got setup are for 1.5 seconds), try changing the timing on the LKP part from 3 to 1. This will make the long keypress about 2.3 seconds.

My guess is it's the way the DKP is implemented that is causing problems.

The thing to keep in mind is that the Single Press action on the DKP needs to wait for the timeout before before it executes the Single press event.

Essentially it does the following:
1. Get first press.
2. Wait until a second press OR until a timeout
3. If you stopped waiting because of a second press, execute the double press macro.
4. If you stopped waiting because of the timeout (that means you didn't press a second button in the time you specified), execute the single press macro.

In your case, you are hitting the button once and waiting so that you go to step 4. Step 4 begins the execution of the LKP code. One of the first things the LKP does is to check if the button is still pressed. Sometimes, you are lucky and you repress the button at exactly the right time (the right time has to be AFTER the DKP times out but BEFORE the LKP checks to see if the button is still pressed) and the LKP works as you intended. Sometimes you press it too soon and it executes the DKP code. Sometimes you press it too late and it's either out or somewhere in the middle of the DKP code. In either case, it doesn't do what you want.

If you change your macro so that the LKP is triggered on the second button press, I think it should take away the problem. The second key press will immediately trigger the LKP code, not wait for a timeout. That way you know the key is pressed when it is triggered. Then you just adjust the timing that you need to hold it down.

It seems like you will have more luck if you do something like the following:

DKP
Single press - Do macro 1
Double press - Call LKP
Short - Call Macro 2
Long Call Macro 3

This would give you the following
Short press - Executes macro 1
Short press, Short Press - Executes macro 2
Short press, Long Press - Executes macro 3

I hope this makes sense.

If that doesn't work, it may make sense to post your file so we can take a look at it.

David

Sorry, I didn't realize that you posted your file already. If my earlier comments don't work, I'll take a look at it.

As for why you are having more luck w/ the keymoves instead of the macro, IR stores the macros first in memory and keymoves second. That means that the extender will find the macro faster than it finds the keymoves. With the keymoves, this essentially gives you more time after the timeout on the single press event and before the DKP checks for a pressed key for you to press the button again.

You're still getting lucky, you just have a wider window of time to get lucky. My guess is that you would also be able to impact this by moving these keymoves to the top or bottom of you keymove list, depending on how many you have.

David

David,

Can you clarify, for the first part of your answer in the single keypress I was assuming that you don't actually have to release the key. So you press and hold the key. The DKP code runs and ends up in 4 in your explanation, since the code has timed out without a second keypress. The LKP then starts and you keep holding till that times out? Or am I missing something.

So essentially he's doing a quick double press, a long press (at least as long as your first delay), and an even longer press (at least as long as the sum of your first and second delay). You're right. If that's what he is doing, it seems to me like that should work too.

But my explanation just seemed to fit what he was describing so well.

David

David,

Thanks for the response, I was just stuck working through the logic and thought maybe I was missing something subtle. (Like the interupt for keypress getting set regardless of the key not being released.)

Hopefully Haggis will let us know which it is and how he gets on with it.

Hi David, pgk,

As the scenario stated, I wanted a tri-state scenario in which a single short key press performed the original "power", a single long key press was all off, and 2 short key presses was all on.

I tried fiddling with the timing and the best appears to be setting the DKP & LKP both at duration 2 (This seems to normally work). The alternative (of having a short key, 2 short keys, 1 short + 1 long) method suggested above seems to be a lot better than the original, but is still not 100%

I think you are onto something David when you are talking about the timer. I don't know the underlying microcontroller and how many timers it has, but it seems to me that the extender is only making use of one timer for the LKP/DKP (and even perhaps for the Kameleon's backlight setting). I would have thought that the timer would start counting from the instance of the key depression until either a time out or I released the key. I had assumed that once it had timed out (for DKP or LKP) or I had released the key it would immediately reset the counter and continue timing as it was in another LKP/DKP. What it sort of seems to do is not reset the timer but waits until it has timed out before allowing it to start counting again (interrupt driven?). The theory being by setting the durations the same, by the time it has timed out a counter has either picked up or not the dual press and hence it usually working.

Hopefully one of you experts understands the way that the timers, DKP/LKP protocol really works and can give me a good solution. The only way might be to have a special version of the protocol that would be purposely designed for this tri-state option.

The same timer is used for LKP, DKP and the backlight (and possibly more). So if there was a problem reseting the already running timer to another value your normally LKP's could also be a problem since they would be tied to the backlight timer.

The code for the protocol works roughly like this (in my reading of this anyway)

(1) Start timer according to value

(2) If LKP then
(a) repeatedly scan keyboard until no keypressed.
(b) Check interrupt flag if timer expired, then do Long press
(c) If timer not expire do short press.

(3) If DKP then
(a) pause for a bit (not sure how long)
(b) Wait for an interrupt.
(c) If interrupt was for a keypress, then do the double.
(d) If it was for timeout do the single.

Because of 3a if you double press too quickly, then it will behave like a single press since it doesn't see the keypress occuring during the pause. This may explain some of your problems, in which case decreasing the time in (3a) might help

This also might explain why my original suggestion of trying it the other way around with the LKP as the first part seemed worse, since you would have to be slower on the DKP. Though in general I think this would be the better way around to do this, since it makes the timings slightly easier (total long press time = LKP + DKP time, whereas other way around LKP time = LKP time, and doesn't change the single and double time significantly since the timer for these starts as soon as you release the key for the Short key press).

What I can't immediately see though is why you'd get better results with your version (2).

So no promises but you could try editing the 1f9 protocol, I can't test this so make sure you keep a backup of your original:

Upgrade protocol 0 = 01 F9 (S3C8+) LDKP
00 00 01 E4 03 4A F0 4A 56 4A 0F F6 35 DF 56 03
07 38 3A 26 C3 03 76 2D 08 EB 0C F6 30 0B FB 1F
76 73 20 6B F6 8B 1C C6 C0 10 00 F6 01 0D 56 73
7F E6 F1 FF 6F 76 73 80 EB 09 76 73 20 6B F5 38
03 B0 03 A4 03 C3 2B 0D 87 43 2D A6 9B 9C 3B 05
82 9B C4 3A EE AF
End

The bolded digits are the ones which have changed, this is the short pause time for (3a) above. It started as 25 00 so I have decreased it, you may actually need to increase it (Note in the source code for the extender this is labelled "Change this value to adjust sensitivity")

Let me know if this helps or not.

Thanks pgk.

I believe the sensitivity sets an idle period in order to debounce the keys. I tried changing it and it made no real difference. However, I did retry (changing the timings) of using LKP and then DKP and I agree that it make mores sense in terms of waiting. With the LKP being duration 3 and DKP being 2, the stability was as good as I have got. I also had a look at the assembler listing, and the LKP/DKP protocol doesn't reset the interrupt flags or clear pending interrupts directly.
More interestingly, I have noticed that if I hold a key down that is defined as a LKP key move, after about 3 seconds, the remote's backlight goes off (it looks like it dies) until I release the button. On equivalent buttons without the protocol, the backlight stays on without a problem. This is even true if they execute a macro. Could this be caused by ScanKeypad?

I think I have it working reliably now.
I edited the assember, made sure that the timeout flag bit was reset and recompiled to

Upgrade protocol 0 = 01 F9 (S3C8+) LDKP
00 00 01 E4 03 4A F0 4A 56 4A 0F 56 73 DF F6 35
DF 56 03 07 38 3A 26 C3 03 76 2D 08 EB 0C F6 30
0B FB 1F 76 73 20 6B F6 8B 1C C6 C0 10 00 F6 01
0D 56 73 7F E6 F1 FF 6F 76 73 80 EB 09 76 73 20
6B F5 38 03 B0 03 A4 03 C3 2B 0D 87 43 2D A6 9B
9C 3B 05 82 9B C4 3A EE AF
End

Well, it looks like the one packaged with the 9960 extender is an old version that has a timing issue with DKP.

Newer version should work better for standalone DKP uses, but I am not sure if that's also the case when it's combined with LKP.

Anyway, here's the LDKP v1.3 for 9960ex2:

Upgrade protocol 0 = 01 F9 (S3C8+) LDKP
00 00 01 00 00 F0 2D E4 2D 4A 56 4A 0F F6 35 DF
56 03 07 38 3A 26 C3 03 90 2D 7B 11 F6 30 0B FB
18 76 73 20 6B F6 8B 15 F6 30 0B 7B 10 B0 73 E6
F1 FF 6F 90 73 7B F1 6B F9 38 03 B0 03 A4 03 C3
2B 0D 87 43 2D A6 9B 9C 3B 05 82 9B C4 3A EE AF
End

(The source code is in http://groups.yahoo.com/group/jp1/files ... kp-1.3.zip)


Hal