JP1 Remotes

xaust wrote:I am a noob to all this stuff but let me throw out what I think is happening.
The protocol that Rob has created for us is a "single key/auto-break creation/with repeat capability" protocol. I made this name up but I think it is descriptive. Lets take an example.

The "A" key has a keycode associated with it. Lets say you assign it to the STOP button on your remote. Now when you press the STOP button the protocol will send the "A-make-code". The protocol will then wait for a bit and if the STOP button is still down the protocol will start to send the "A-make-code" over and over until the STOP button is released. At this point the protocol will send the "A-break-code". Think of "make" and "break" as the actions associated with pressing and releasing the key on the keyboard.

The problem as I see it is that your CNTL-X key combos are a more complicated sequence of "make-a make-b break-b break-a". This is beyond the capability of the current protocol. Sounds like we need a second protocol that can handle this?

I'm pretty inexperienced with this too, so can't really comment on your theory except to agree that there's a sequence of events going on with two key presses and two releases. Note that the releases have a different subdevice. What I was going to try next was to create a small upgrade to support subdevice 1 (not sure it's that simple) and then create a macro that sends the four events captured. I'm assuming that the RC6-8-13-1 event in the Cntl-1 learn is bogus, since the Cntl-C learn doesn't have a similar event.

Problem solved!!

Well, after a long absence (got busy hacking a CVS camcorder - but that is an entirely different forum), I got back to the task of getting the "stuck key" syndrome to go away. I used Digitrace to compare the keyboard output to what is programmed in remote. The two are virtually identical MOST of the time. I noticed that every once in awhile, at about the same frequency that I see the key appear to be stuck, the "break" character from the remote would be truncated. What I mean by this is that the break character which should be about 20ms long would be 15ms or less. I did not spend the time to try and determine what part of the character was being chopped. Another problem I noted with the protocol is that it was attempting to send the break character twice by setting up register 0D with 02H prior to the jump to XMITIR. This was not working on this remote with this particular protocol. I would only ever get one break character. I have two URC-6131 remotes and verified this squirrelly behavior on both remotes.

Here is the change I made to the protocol to address this issue: Here is the new protocol I am using:

Upgrade protocol 0 = 01 F1 (S3C8+) Solidtek ACK-571 IR Keyboard (PB v3.11)
43 8C 11 8B 16 89 C4 10 05 08 00 EA 01 24 00 EA
01 24 10 00 03 8E 01 13 FF FF 04 20 11 08 04 F6
FF 52 08 C1 F0 C0 02 01 F6 FF 52 19 05 F6 01 46
6C 06 F6 01 0A FB 0F C6 F8 88 88 F6 01 58 6A F2
46 29 01 F6 01 46 B6 04 01 B6 05 10 F6 01 46 8D
01 46 2C 08 10 C0 C0 C1 2A FA AF
End

One further note - even with this new protocol I still see the last character sent (which is now the 2nd break char) get mangled once in awhile. The good news is that there are now two break chars sent and the first one is always OK and does it's job.

Thanks Rob for all the work. You got me 99% of the way there.

Why not try sending 3 breaks for extra safety? Be sure to load both the KM file and the PB file when you're done.

OK, will do on all counts.

All set.

The updated PB file (Version 5) is here.
The update KM file (Version 6) that uses the new PB is here.

This is the updated PB:

Upgrade protocol 0 = 01 F1 (S3C8+) Solidtek ACK-571 IR Keyboard (PB v3.12)
43 8C 11 8B 16 89 C4 10 05 08 00 EA 01 24 00 EA
01 24 10 00 03 8E 01 13 FF FF 04 20 11 08 04 F6
FF 55 08 C1 F0 C0 02 01 F6 FF 55 19 05 F6 01 46
6C 06 F6 01 0A FB 0F C6 F8 88 88 F6 01 58 6A F2
46 29 01 F6 01 46 B6 04 01 B6 05 10 F6 01 46 F6
01 46 8D 01 46 2C 08 10 C0 C0 C1 2A FA AF
End