JP1 Remotes

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.

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.

MJ wrote: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.

johnsfine wrote: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

johnsfine wrote: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

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) Hal

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

MJ wrote: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.

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

MJ wrote: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.