JP1 Remotes

Hi, I put together a protocol for screen / and start device specific protocol for the 9960 extender. The reason for this is to allow me to change a behavior of a key move depending which screen it is on or which device the original macro/key move started on.

The way the screen/orig dev index specific macro works is as follows (nearly identical to DKP/LKP protocol):
The Hex command in the key move consists of three component pieces:

{Control byte} {First command sequence} {Second command sequence}

Control byte:

The high nibble (the left hand side digit in hexadecimal) is the
screen number.

The low nibble (the right hand side digit in hexadecimal) is the
length of the {First command sequence}.

This special protocol recognizes a screen by default.
To make it a start device index Press, add '8' to the right hand side digit.

First and second command sequence:

The keystrokes expressed by keycodes in hexadecimal. The first
command sequence is for the true case, and
the second is for the false case. The first
sequence can be up to 7 keystrokes long, and total of the both
parts can be up to 13.

Note: Both Dev index and screen counts start from 0 not 1
Dev 0-CBL, 1-Tv etc
Scr 0 (start scr) ++

Failing any better suggestion, my protocol can be set as 01FE
Upgrade protocol 0 = 01 FE (S3C8+) SSD
00 00 01 E4 03 4A F0 4A 56 4A 0F 56 03 07 38 3A
26 C3 03 76 2D 08 EB 07 A4 4A 6A EB 0B 8B 05 A4
4A 68 EB 04 38 03 B0 03 A4 03 C3 2B 0D 87 43 2D
A6 9B 9C 3B 05 82 9B C4 3A EE AF
End


Upgrade code 0 = 14 53 (TV/1107)
FE 00 01
End

To easily set up the key move, I use IR5.15 and set it up a DKP/LKP. I then just change the device setup code to 1107 and edit the first hex value.

I would appreciate any comments.

I haven't got a 9960 but had a look at the code anyway.

Couple of comments, first on your post you seem to have copied a chunk out of the LKP/DKP readme and not updated it so it still referes to "a short press or a single press" etc.

Looking at the code you have the sequence
Which looks to be the part checking if this is device or screen specific, but It looks wrong to me since you are checking R2D which is the first keypress, not the first hex code which was in R03. (And you've previously 'and'ed R03 with #07H so it won't be there either at this point).

At least this is how it looks to me I could be wrong.

Thanks, I have now corrected the description of the command to read for the true and false cases.

R03 and R2D both start off referring to the same value, so the result is fine. (In fact this part of the code is directly copied from the LKP/DKP).

I have checked the 8060 extender asm, and this code will need to be only slightly modified to work with that device.

R03 and R2D both start off referring to the same value

Yes looking at the LKP code that should have been obvious.

The only other thing I notice is that you use R68 to check the device the macro/key move started on. In the extender source this is R_Dev, and just before L285 this gets set when changing the O_ device.

So it would appear that in fact you are checking the current O_ device?

(Again I could be well of the mark since I can't double check any of this).

Hi pgk. The concept of the original device is to allow for cases like:
I want macro 1 to behave one way if the device is a TV and another way for all other devices. I could do this by putting a keymove on all the devices but it is simpler to create a macro that just calls a keymove (for instance via xshift value eg X_CD,XShift_phantom1). The keymove is able to test that the current "device" is not CD in this case but instead is TV, and so it can do the appropriate if then else statement.

The use of R_Dev works in the above case. This allows you to use any key, shifted/x_shifted key for any device.

Nils, do you have any comments around this?

Since DSMs are invoked using a keymove, and since keymoves override macros, couldn't you just create a normal macro on the key in question, then program a DSM in TV mode onto the same key?

Previously, when I tested the 9960 extender, the macro seemed to override the keymove rather than the other way around. (I might be wrong and will need to retest to confirm this).
In any event, the ability to create a number of "if then else" chained scenarios based upon device index and screens (for multi-screen remotes) seemed interesting to me.

Haggis,

create a macro that just calls a keymove (for instance via xshift value eg X_CD,XShift_phantom1). The keymove is able to test that the current "device" is not CD in this case but instead is TV, and so it can do the appropriate if then else statement.

Surely the example you've given would work because your macro hasn't changed the O_ device already and the XShift_phantom1 button is part of the O_ group, for which I guess the current selected device is TV.

If you took another example, e.g. The key is XShift_Play, and we have O_TV, T_VCR previously set. Since XShift_Play is part of the T group the device in your protocol would still be considered to be TV, not VCR?

I wasn't questioning if it was useful, more that the function doesn't appear to match the description you've given, which if someone else tries to use it could be confusing.

Paul.

Hi Paul, I agree that it can be confusing in a case where you have set the O_,M_,T_ etc. at different devices and don't make use of X_ (which won't effect the dev value). If you tend like me to try to keep all the groups against the same device and use the X_ to initiate keymoves, then it is a lot simpler.

Based upon this discussion, I suppose the correct way to describe the protocol would be:
Screen Specific Macro (SSM)/Current O_group device specific macro (CODS) ie SSM/CODS keymove.

Please feel free to come up with a better description and instruction post.

Haggis, I think the concept and implementation you describe is correct and helpful. As indicated by others it is important to note in the documentation that the last O_ device is critical to the functionality.

Oh yeah, on the macro vs. keymoves I believe what I wrote will act on the first one it finds. The way around that is to move the one you want higher in IR.