Fixed the problem.. but why?

[Linenoise]

I'm a little confused here. Made the JP1 cable, got it to talk to my new URC-8810w remote. Added an upgrade for my receiver, it worked, feeling pretty good. Punch in the default code for my Samsung TiVo, noticed that some of the buttons weren't there. I set up the keymoves, and spend a few hours trying to map the Info button to the correct command. I use the Learn function on the remote to learn it from my tivo remote, and everything looks the same.. same hex code and everything. Learned key worked, keymoved key didn't. I thought I understood this, but I guess not.

Well, after some poking around, I find this forum post (classicsat's reply) that indicates that keymoves on the 8810w don't work with that device. I grab the device upgrade form the yahoo files section, and indeed it seems to be fine now.

The question I have is, why? Is it just an artifact of the code inside the remote itself, or was something being entered wrong on my end? I've keymoved other keys, and they seem to do fine, just not to the TiVo box. What changed by loading a new device upgrade?

[mr_d_p_gumby]

The question I have is, why? Is it just an artifact of the code inside the remote itself, or was something being entered wrong on my end?

While most setup codes only need one command byte per button, a few more recent setup codes (such as your built-in Tivo code) use what we refer to as "two-byte" commands. When you enter an EFC code for a keymove, it only generates one of the two required command bytes, leaving the other one to be supplied as some random value, and causing the keymove to malfunction. That's the simple explanation; there are usually ways around this using IR which we can explain if you are really curious.

[Linenoise]

Please do.. when I learned the command and checked out what the remote had learned with IR, I didn't see any difference between the command there, and what was in the keymove. What did I miss, or is IR not up to date here?

[gfb107]

The problem is that the URC-8810w has the TiVo (Official 2-byte) protocol built-in. This protocol does not accept EFC style keymoves. It uses a 2-byte format for the hex command, one byte of which comes from the EFC. IR doesn't keep track of what protocols are built into the remotes. If you tell it to create a keymove using an EFC, it will do it, but it creates a one-byte keymove, which won't work with that protocol.

Only the TiVo (Official) and TiVo (Hacked) protocols (which are identical but have different PIDs) allow single-byte kemoves, which IR knows how to create from an EFC.

RM and KM do know what protocols are built into each remote, so can be used to produce correct device upgrades and keymoves for each remote.

If you want to use keymoves instead of a device upgrade, you should use hex commands instead of EFCs to create the keymoves. We experts know that the first byte of the hex command should be 00, and the second byte should be the converted EFC value. To figure out what the converted EFC value is, use IR's EFC Calculator.

For example, if you want to map the display function (EFC 635), you would see that the converted hex value is 37. The correct hex command to use is 00 37.

Now do you see the problem? Entering EFC 635 would result in the hex command "37" but the correct hex command is "00 37".

Another choice would be to create the keymoves directly on the remote, using the Setup 994 procedure. If you then look at the resulting keymoves in IR you would see that they are 2 byte keymoves.

[Linenoise]

Ah, gotcha, makes perfect sense. Thanks alot!