DLKP in a macro only does the SKP if followed by x_tv ...

[MJ]

First of all, Thanks (to Rob i think) for the enhancements in IR5.15. i especially like the protocol builder and notes fields.

I have been using my JP1 connector for a year now and have enjoyed learning how to extend the urc8911 with dLKP & TOADTOG and even made friends with the device combiner. Now I have a project to enhance my girlfiends audio visual experience & was happy to find the urc 8811BOO at Walmart here in Canada. I've loaded the extender3 for 6012... remotes and added the DLKP protocol for URC-6012/8011/8811 with Extender 2/3.

As mentioned in the subject line, I cant get a DLKP in any Macro to use the LKP commands when it has entries following it in the macro.(i.e. ...DKLP, x_tv, 0, 4 or ... DKLP, a macro pointing to x_tv...)

As soon as I eliminate the entries after the DKLP, it works fine. That required a lot of headscratching. the workaround was to also add the entries to the both LKP and SKP and to leave the dklp as the last entry in my macros. Why did I suffer ?

I did notice that sometimes when I accesed the special protocol builder to edit an existing DKP keymove, the headings showed SKP and LKP until I re-selected DKP from the dropdown menu. Sometimes the builder required me to enter a couple of hex entries before it would allow me to create a new keymove. Has anyone else experienced this?

the last of my long wind ... I had experimented and removed any DKPs in my macros to avoid issues I read about in the forum, but the macro problem above persisted.

[johnsfine]

I don't know much about the LKP and similar protocols, but I think I can explain the symptom you're seeing.

Most keystrokes in a macro sequence run without any behavioral connection to the key that originally triggered the macro. That means that if the protocol makes a decision (such as a normal protocol deciding whether to keep repeating) based on whether the original key is still pressed, it will unconditionally act as if the original key is NOT still pressed.

BUT, the last keycode in the pending buffer (at any time) regains the association to the original key which started the macro, so its decision are based on whether that key is still pressed.

I'm a little confused why you would want that DKLP at the beginning of a macro.

[Mark Pierson]

I did notice that sometimes when I accesed the special protocol builder to edit an existing DKP keymove, the headings showed SKP and LKP until I re-selected DKP from the dropdown menu. Sometimes the builder required me to enter a couple of hex entries before it would allow me to create a new keymove. Has anyone else experienced this?

A few bugs exist in the current implementation of the SPP in IR 5.1x. A new version based on the 6.00 Alpha should fix those, but it isn't ready for release quite yet.

[MJ]

I'm a little confused why you would want that DKLP at the beginning of a macro.

Actually I do set the keys for the devices prior to the DLKP. They are all 7 or 8 entry macros. I have experimented both ways.

Thanks for the input.
MJ

[MJ]

BUT, the last keycode in the pending buffer (at any time) regains the association to the original key which started the macro, so its decision are based on whether that key is still pressed.

After my first readthrough I thought I understood what you meant by this... soo what is a last keycode in a pending buffer?

I thought that DLKP would make its decision based on the duration of the keypress regardless of the various devices protocols that are invoked during the macro. If I add any command after the DLKP in the macro, it simply does not seem to clock the keypress.

I tried IR6.00alpha and there was no difference to my problem. It looks IR6.00 is taking radical advantage of macro memory which is good for me. I seem to find no end of uses for keymoves. (not that I've ever run out of memory)

MJ

[mtakahar]

Well, David found this issue and a workaround long time ago, but I left it like that because I didn't (and still don't) think it was worth the 3 extra bytes.

John sort of already explained why LDKP wouldn't recognize a long key press in the middle of a macro, though, think it this way with a regular button code that sends an IR signal - the remote keeps sending the signal while you are holding the key if it's not in a macro, but you don't want this behavior for EACH key stroke in a macro as it gets stuck while you are holding the key, so the remote ignores the long key press until at the very end of the macro. (Repeating the signal of the last key stroke is a feature of the extender, and the workaround is to do the same thing within the LDKP to enable the long key press recognition.)

Try this one and let us know if you think this is really useful.

(For 6012ex2/3)

Code: Select all

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

Hal

[e34m5]

It's an issue with LDKP not IR 5.1x.

[Mark Pierson]

I tried IR6.00alpha and there was no difference to my problem.

Based on Hal's reply, the problem is in the protocol itself and not in IR, so ther version won't make a difference.

It looks IR6.00 is taking radical advantage of macro memory

I'm confused by this statement since the space available for key moves and macros is based on the remote itself (and the corresponding RDF) and has nothing to do with IR. That amount of space should be the same in every version of IR.

[MJ]

It looks IR6.00 is taking radical advantage of macro memory

I'm confused by this statement since the space available for key moves and macros is based on the remote itself (and the corresponding RDF) and has nothing to do with IR. That amount of space should be the same in every version of IR.[/quote]

It just looks like toadtog-keymoves that were in my upgrade were showing on the macro tab instead of the keymoves tab. if i have it right, keymoves are stored in upgrade memory. I typically underuse the memory allocated to macros compared to keymoves and upgrades.

I'll try the protocol above and see if i understand what's happening.

Thanks again for the input. I'll contribute what I can.

MJ

[Mark Pierson]

It just looks like toadtog-keymoves that were in my upgrade were showing on the macro tab instead of the keymoves tab.

The IR 6 Alpha did move some special protocols (i.e. ToadTog) to the Macros tab. That has nothing to do, however, with where they're stored in EEPROM.

if i have it right, keymoves are stored in upgrade memory. I typically underuse the memory allocated to macros compared to keymoves and upgrades.

You don't.

Key moves and macros are stored in the same area. Upgrades are stored in a seperate area by themselves, as well as learned signals occupying their own space.