Long and double keypress IR requirements

Nils_Ekberg · Post by **Nils_Ekberg** » Tue Feb 15, 2005 10:10 am

While debugging a situation with the standalone version of LDKP protocol I noticed that the keymove gets created wrong for the standalone version in the SP tab.

The standalone version keymove uses only 3 hex values:

First # - Left digit is 1 for long and 2 for double keypress option. Right digit is the duration.

Second - Hex value of the button of the short or single action

Third - Hex value of the button for the long or double action

The extender version uses up to 14 hex values:

First - Left digit is the duration. Right is length of short key sequence or length of single press key sequence plus 8 to indicate double keypress option

The remainder are the key sequences.

So, we have 3 options.
1) Add a choice on the SP tab for whether it is the extender protocol or the standalone protocol and build the SP keymove accordingly.

2) Re-write the standalone protocols.

3) Don't let standalone users enter the keymove on the SP tab.

Nils_Ekberg · Post by **Nils_Ekberg** » Tue Feb 15, 2005 10:16 am

By the way, the only way to get the standalone versions to work correctly is to either:

1 - Enter them manually on the keymove tab

Or

2 - create them in the IR SP tab with just a LKP and a duration of 1. This option only allows you to do long keypress for a very short duration. Using Double keypress is out of the question using the IR SP tab.

e34m5 · Post by **e34m5** » Tue Feb 15, 2005 11:30 am

I vote for number 2

Nils_Ekberg · Post by **Nils_Ekberg** » Tue Feb 15, 2005 1:28 pm

e34m5 wrote:I vote for number 2

That was my first thought but realized that the problem is even bigger than that.

If we re-write the protocols the people that already have the old installed will be impacted since IR will grab the old keymove and make it necessary for the user to modify it to make it work if updated in the SP tab. I looked at the standalone versions and believe they are written the way they are because to make it work like the extended version requires extender functions like nested macros etc..

Even if I just reverse the parms in the first hex value IR will still have a problem with the LKP vs DKP function since IR wants to add 8 to the second half for DKP when the protocol is expecting a 2 for DKP. Either way IR would still need to be modified to only allow one parm for short/single and one parm for long/double for the standalone version

In other words I don't think option 2 will be viable so we are down to options 1 and 3. Personally I like option 1 but option 3 is easiest since all I have to do is take the LDKP protocol out of the non-extender RDF's to force it back to a manual 3 byte keymove. Also will need to make it clear in the standalone docs not to add the SP to the RDF and do it manually.

gfb107 · Post by **gfb107** » Tue Feb 15, 2005 1:50 pm

THere are different entries in the special protocols section of the RDF file for extender LDKP (LDKP) and the standalone LDKP (ULDKP). It seems to me IR is supposed to differentiate between the 2, and therefore has the information necessary to provide a UI that correctly shows the user what can be done, and correctly generates the keymove.

I'm sure you did, but I'll ask you anyway, Nils. In your testing, did you have the ULDKP entry in the RDF, or the LDKP entry?

Nils_Ekberg · Post by **Nils_Ekberg** » Tue Feb 15, 2005 2:07 pm

Greg, it does not look like ULDKP was implemented in IR but to tell you the truth I didn't even think about that. It is in the RDFSpecs but is not recognized by IR.

Nils_Ekberg · Post by **Nils_Ekberg** » Wed Feb 16, 2005 7:24 am

Mark, are you listening? I am just curious if ULDKP is implemented in 6.00 or will be later.

e34m5 · Post by **e34m5** » Wed Feb 16, 2005 11:01 am

I never heard of that when I did the IR5.xx work.

So I am gueesing it didn't make into IR6.00

I would recommend using a different device number to differentiate (1106 for LDKP and 1107 for UDLKP).

Post by **ElizabethD** » Wed Apr 13, 2005 8:01 pm

Is this thread about IR6.00? I so assume since IR date is January.
I probably don't understand the issue.

I just put this into the 8910 unextended RDF1[1]18 (oops! looks like I should get the update):
[SpecialProtocols]
DSM=01FC
LDKP+DSM=01F9
Pause=01FB

In IR, the standalone, unextended, LDKP+DSM protocol comes up on the Special functions tab (Misc:1106), but entering key names is not an option. The entire bottom section is greyed out. Only hex is allowed. That's consistent with what Nils is suggesting above, I think. I also checked Raw data. It is identical to what I entered.
So perhaps it's all fixed? Or is it at some other point that the bits get changed, like when it's all pushed to the remote? Just trying to understand

mtakahar · Post by **mtakahar** » Wed Apr 13, 2005 10:46 pm

I tried ULDKP just out of curiosity. It looks like implemented.

Add "ULDKP=01F9" under the [SpecialProtocols] section in the RDF, add the standalone LDKP and the device upgrade then IR 6.00 shows you DSM, LKP and DKP on the "Spcl Prot Fns" tab. It even knows you can have only one key stroke in each side.

Use "UDSM=1FC" for the standalone DSM.

Hal

mtakahar · Post by **mtakahar** » Wed Apr 13, 2005 10:54 pm

BTW, "Multiplex=1FE" enables Device Multiplexer on the "Spcl Prot Fns" tab.

Hal

Post by **ElizabethD** » Sat Apr 16, 2005 4:53 pm

mtakahar wrote:Add "ULDKP=01F9" under the [SpecialProtocols] section in the RDF, add the standalone LDKP and the device upgrade then IR 6.00 shows you DSM, LKP and DKP on the "Spcl Prot Fns" tab. It even knows you can have only one key stroke in each side.

IR6 with RDF120 is fabulous for the combined L/DKP+DSM.
Not only IR presents all 3 options and restricts the keys, it even lists the macro contents in the L/DKP/DSM keymove definitions. Cute

I noticed that the keymoves for this protocol are now all the same length. The DSM part had 1 less byte before. Now it has a final 00 byte. The change is transparent to the user.