JP1 Remotes

I just formatted the upgrade for the URC-6800 because that's the remote that I knew that you had. I actually formatted it for a URC-8910 for my testing purposes.

You don't normally need to re-write a protocol each time, the thing here was that the original protocol wasn't written very well and I think that it was dropping a bit from the end of the signal, which is probably why you couldn't get some of the buttons to work.

You don't need to learn the rest of the buttons, I found the CCF file that you linked to that has all the buttons, so I got the codes from there.

Here's an upgrade, formatted for the URC-8910, that has all of the buttons included...

Upgrade Code 0 = 6F D0 (Cable/2000) Keyspan DMR18B/REM17B (KM v8.31)
FF 00 72 F8 1E 81 1C 1A 23 2A 10 0B 3B 27 36 2C
31 2F 3E 06 19 0D 0E 05
End

Upgrade Protocol 0 = 01 FF (S3C8+) Custom Protocol for Cable/2000 Keyspan DMR18B/REM17B (KM v8.31)
43 8C 11 8B 12 85 04 07 08 01 63 02 8F 02 0D 01
40 00 00 04 B0 04 9C F6 01 46 C6 06 03 57 C6 08
65 36 1C 06 F6 01 4C F6 01 0A 7B EB AF
End

Here's the KM file...
http://www.hifi-remote.com/forums/dload ... le_id=2171

Your 6800 upgrade works!

Here's the dump from my unextended 8910, with all 17 codes:
8910 with Keyspan
I verified (with the Keyspan monitor) that all 17 worked before uploading, and they're all where I want them, so you'll get good data...or verify that the CCF file was good to begin with.

(tried out 8910 version, without extender)
No go...all 17 buttons, including the menu keys, say "unrecognized data". Clearly, there's either
(a) bad data in the CCF file (most likely);
(b) some difference between how the 6800 and 8910 interpret these protocols; or
(c) it has to be rewritten whenever a key is added, deleted, or moved, either because of some peculiarity with the protocol itself, or because KM mangles something.

I'm a dork, I gave you the old protocol again (which we already knew doesn't work). I have just edited my previous post to include an upgrade that should work.

I just re-read the original thread on the Keyspan, and I see that Jon discovered that the last bit is a toggle bit. So, could you do me a favor. Once you have the upgrade loaded and have confirmed that it works, could you see if you can use the same button twice in a row? This will tell me whether the toggle is actually required.

The Robman wrote: could you see if you can use the same button twice in a row?

Be sure to test that with some button that is normally non repeating, but should have an observable behavior when used twice in a row.

Buttons such as arrow keys that are normally repeating MAY work right even if the toggle bit is important and the executor doesn't implement it.

Buttons that are logically toggle (things like tv/vcr or menu on most VCRs and similar devices) are likely to show this problem.

It's often most serious in digit buttons (can't select channel 11, etc.)

I put the updated version in my (unextended) 8910, and, at last, it works!

Also, the buttons which are supposed to repeat (arrow keys, volume up/down) work correctly--again, without the extender. 8)

Now all I need is a USB-to-Toslink converter, and I'll be able to throw away the DVD player--well, almost. An ordinary TV looks awful when used as a monitor, and even my "big" (45cm) monitor is kinda small for movies, even with HD.

Did you also make sure that each button works if you press it 2 or 3 times in a row (which is different to checking whether they repeat properly). I ask this because the original signal has a toggle bit at the end, whereas the upgrade that I posted doesn't have a toggle bit.

Could you also try the following protocol, which does have a toggle bit...

Upgrade protocol 0 = 01 FF (S3C8+) KeySpan DMR (PB v3.11)
43 8C 11 8B 12 85 04 07 08 01 63 02 8F 02 0D 01
40 00 00 04 B0 04 9C 18 00 56 C1 01 B4 C1 04 F6
01 46 C6 06 03 57 C6 08 65 36 1C 06 F6 01 4C F6
01 0A 7B EB AF
End

Now that I'm allowing for the toggle bit, the new OBCs make alot more sense and it's easy to spot the gaps in the sequence, which could mean that there are additional functions that are supported. To that end, I have created a test upgrade that I'd like you to try out. I have assigned all the gap OBCs to the numeric buttons, plus the channel and volume buttons. Could you load this into your URC-8910 and see if any of those buttons do anything. If you get a response from the Keyspan, please list here what the response was and which button you were testing.

Upgrade Code 0 = 6F D1 (Cable/2001) Keyspan (KM v8.31)
FF 00 E1 1C 00 02 08 12 14 16 1C 1E 20 24 28 32
34 38 3C
End

I just sampled the signals myself and the toggle appears to be working just fine.

I tried your "toggling" protocol with the CBL_2000 device (the one with the standard Keyspan keys). It works just as well as before--maybe a bit better with quick successive presses.

I also tried the CBL_2001 device (with the "missing keys"). They didn't work, but that's to be expected--they weren't defined in the .REM file. This file describes the signals, and defines them as keys, to the Keyspan DMR application and kernel modules; the Keyspan application, in turn, allows the user to define which keys produce a given keystroke and/or mouse action for different applications; for example, if iTunes is active, its entry for the PLAY button would read "PLAY=space bar".

Interestingly, for the Finder (the Mac equivalent of the "Explorer" in Windows), the menu keys function as a mouse--you can even use them to pull down menus, drag icons around, and launch applications! 8) The 8910's "hat switch" makes this tricky though.

In order to add the new keys to the .REM file, you'll need the raw signal data (from dmrdump, presumably), as well as the existing .REM file for reference. Be warned--what dmrdump will tell you about a given signal (e.g., "val(lsb)=64ff") looks nothing like the .REM file entry defining that signal as a command (e.g., "CMD CYCLE 0101 0101 0101 0101 0101 0101 0101 0101 0103 0103 0101 0103 0103 0101 0101 0103 01ff").

I'll get both of these to you in a few days, if you wish. I'm going to be busy with lots of "non-JP1 related" stuff: at the moment I'm dealing with, as Mark Twain put it, "what happens when you've made other plans."

I might also surmise that "missing keys" could be completely arbitrary: you could try, if you were so inclined, to see what each of the 256 (or 64K!) possible OBCs would produce in terms of an IR signal, and put all of them into the .REM format.

But who has that many keys on a remote, even shifted and Xshifted? I suppose this might be of interest to those with IR keyboards though...256 codes would be enough to cover all 128 ASCII keys, plus macros, "mouse key" functions, etc...