JP1 Remotes

This is probably a dumb newbie question, but I searched and came up dry:

Why do some upgrades (created via RemoteMaster) use Key Moves instead of just directly assigning things to the button? It appears that any button in the button list that has an astrisk by it will be a keymove? But these buttons do not have an astrisk, depending on the protocol (or something?)

My remote is the ancient URC-8090B01, if it matters...

Thanks,
-Tim

I beleive it's defined by the remote and the device type. A tv type device is not likely to have the transport keys normally and would require keymoves. A VCR type device on the other hand is going to be expected to have these keys and wouldn't need to use a keymove.

If your trying to save keymove memory try changing the device type when your creating the upgrade to see which one includes the most keys. It doesn't really matter much when it comes to using it in the remote other than that you have to select the right device type and code.

Each remote has a specific keymap for each device that describes which keys are valid for each device type. The RDF that tells RM and the built-in support for the remotes in KM know about this keymap.

If the key that you are defining in this list, it goes in the the upgrade part. If the key is not in the keylist, then it is done as a keymove.


-bill

Thanks -- that makes sense.

-Tim

Why the restrictions?

Is it possible to create an extender for a remote, assign all upgrades to a new, arbitray device type (say, a QUARK) and create a keymap that has as many keys as possible defined such that no KeyMoves are created in everyday use? I ask because it would make using the Device Mulitplexer easier not to mention keeping the IR files a lot tidier and abolish having to remember device types etc.

The list of keys is in the ROM and the remote looks for that list in a lot of places. Especially on the JP1 remotes, since the EEPROM isn't really in the memory space of the processor this would be pretty much impossible.

This might be possible on the JP1x stuff but it's a pretty serious undertaking.

The keymaps for the Radio Shack 15-135 JP1.3 are almost identical for every device type. They may have done this so any device type can be assigned to any device button. It also uses 5 digit device codes, where the first digit is the device type, thus removing the dependency on specific device buttons. I don't know if this is a new trend or not, but I like it. Even the phantom keys are in every keymap, so keymoves are rarely needed.

I have the 9910, and I just use SAT for most upgrades, as it seems to have the most keys available.

Tried changing the 8910's RDF; no joy. Tried the 8820 with "interesting" results. KeyMoves changed to normal keys but order all scrambled. Has potential, though. Most (? all) of the 8820 devices seem to have the same set of buttons - i.e. darn near everything except Fav, M1, M2 are normal with those ones being KeyMoves.

underquark wrote:Tried changing the 8910's RDF; no joy. Tried the 8820 with "interesting" results. KeyMoves changed to normal keys but order all scrambled.

Tried what? You cannot simply change the buttons or button maps in the RDF. They MUST match what the remote has internally or all you'll get is scrambled button assignments.

As Mark says, the button maps (keylists) are defined in the ROM for the remote. There is a list of valid keycodes that has the valid keys AND a specific order of how those keys are put together in a "device" so that the remote will understand. If you look at the output from RM for an upgrade, those key values are ordered based on this list of keycodes.

If you change the RDF and it doesn't match the remote, there will be all kindss of issues since the remote will interpret the key values based on the internal list and RM will build the upgrade based on its list, whcih of course don't match.

The thing you can change is the device type when creating the upgrade in RM. Try the different types your remote supports and pick the one that generates the least key moves.

Some things will always generate key moves. Shifted and x-shifted for example have to be key moves I believe. They just aren't expected to be part of a normal device and so aren't part of any of the device maps.

unclemiltie wrote:If you change the RDF and it doesn't match the remote, there will be all kindss of issues

Yeah... just ask the Capn about it. He found out the hard way while playing with the Atlas RDF's!