keymoves vs device upgrades

[wwwoholic]

I swear I did the search before asking this. Did not find anything although the question must have been fairly common.

I have VCR that can be controlled by built-in VCR/1062 code. About 20 keys available as is. I learned all the keys (37) from a remote and created the device upgrade (VCR/1063). Everything was fine until I run out of space.

So, I switched setup to ORIGINAL code, removed those 20 keys from my device and created 17 keymoves. This did not help much.

Later on yahoo group I found another code (VCR/0454) with some very useful advanced codes. Just for fun I created keymove to built-in 0454 and it worked! And then I realized, that I don't need my 17-keys device upgrade at all. I can just modify those 17 keymoves to point to the same device that is chosen for current mode.

If I'm not mistaken each keymove takes 6 bytes. In my case 17 x 6 = 102. Device upgrade that uses built-in protocol takes some 2 bytes per command. 37 x 2 = 74. Looks like upgrade is preferable way. But all over this forum I see advices to go with keymoves to save space.

What am I missing?

[Nils_Ekberg]

I don't think you are missing anything. The recommendation to go with keymoves is generaly based on the fact that a built in device may have most of the buttons you need so you can just do keymoves or learned codes for the remainder or build a small upgrade. I don't think anyone would suggest a doing a complete device with keymoves just supplement one with them.

[sfhub]

If I'm not mistaken each keymove takes 6 bytes. In my case 17 x 6 = 102. Device upgrade that uses built-in protocol takes some 2 bytes per command. 37 x 2 = 74. Looks like upgrade is preferable way. But all over this forum I see advices to go with keymoves to save space.

I think it is 5bytes/keymove and 1byte/command (but they come grouped
in sets) for 1-byte device upgrades and you add 1-byte to those numbers
for 2-byte protocols.

When you run an extender, you tend to have lots of keymove space left
over and feel a little cramped with the device/protocol upgrade area, so
many people suggest using keymoves vs device/protocol upgrades to
free up space in the upgrade area.

But you need to take with a grain of salt. If you can do the device
upgrade with 15-bytes, that clearly is better than 15x5=75 keymoves.
On the flipside, if you are doing a 74-byte device upgrade, with additional
space needed for the device combiner custom protocol, and there is a
builtin device/protocol which does mostly the same thing except for 5
functions, the builtin is superior, as the 5 keymoves will only be 30bytes
and the space is taken from the keymove area, freeing up lots of upgrade
area space.

A rule of thumb, 99% of the time, when someone new to JP1 whose
remote has 2k eeprom says they ran out of upgrade area memory,
there will exist methods to free up upgrade memory and have everything
fit.

Robman is a master at doing this.

[Mark Pierson]

If you can do the device upgrade with 15-bytes, that clearly is better than 15x5=75 keymoves.

You can't look at it that way (it's apples vs. oranges). Key moves/macros are stored separately from upgrades/protocols in the EEPROM. To make matters worse, in a normal EEPROM (2k), about half is allocated to learning. Hence, the reason extenders typically eliminate learning, and provide larger key move and upgrade areas.

[johnsfine]

In the 15-2116, VCR/1062 uses a rather badly designed protocol called "Panasonic VCR Combo" to combine Panasonic 144.0 signals with Panasonic 144.1 signals. With KeyMoves on that setup code you can also mix in Panasonic 128.0 and 128.1 signals, but you probably don't want to.

The 15-2116 has VCR/0162 and VCR/0454 built in, so if you want to use VCR/1062 as your base setup code and patch it with keymoves, you should use VCR/0162 as the source for the 144.0 keymoves and VCR/0454 as the base for the 144.1 keymoves. Each of those keymoves is 5 bytes. If you use VCR/1062 as a source for keymoves those keymoves are each 6 bytes and are harder to define than using 0162 and 0454.

If you define a new upgrade to mix 144.0 and 144.1 you can save upgrade space by using the stupid "Panasonic VCR Combo" protocol (which is built in) rather than a more sensible combo or combiner which isn't built in.

If that upgrade assigns functions to unmapped keys, so KM automatically generates 6 byte KeyMoves, you can save some space by deleting those and making the 5 byte keymoves using VCR/0162 and VCR/0454. RemoteMaster's external functions sheet allows you to include those in the upgrade definition. I don't think KM can do that, so you'd need to patch the KM keymoves in IR.

Most similar VCRs also have a function in 144.5. With a sensible combo protocol you could include that in with 144.0 and 144.1. But I think you'd save space overall even if you need a 144.5 function by using the built in stupid combo protocol and adding an extra no-buttons upgrade for 144.5 to use as the source of a keymove.

[wwwoholic]

Wow, thanks! At least now I understand what I was doing and why it worked. Before it was "push this red button and see what happens" method.

[sfhub]

If you can do the device upgrade with 15-bytes, that clearly is better than 15x5=75 keymoves.

You can't look at it that way (it's apples vs. oranges). Key moves/macros are stored separately from upgrades/protocols in the EEPROM.

Yes I can

I realize extender and keymove memory are separate but in my mind
I'm always balancing the two so I don't go to an extreme in any direction.

So instead of two separate buckets, I see two buckets with a tube
attached and memory being shifted back and forth depending on
where I need it. With a number of devices defined, I find I can always
find some that I can convert to builtin/keymove vs customer device
map. There are obviously some that are pure device/protocol upgrades
which are not builtin to the remote, and those I'm stuck with leaving in
upgrade area.

Beginners tend to go extreme on the keymove side leaving lots of upgrade
space available. As experience grows, people tend to go extreme on the
custom device/protocol direction and quickly start running out of upgrade
memory.

When you start running out of device/protocol upgrade memory, you start
to take a more balanced approach. In my experience 15bytes is pretty
light weight for a device upgrade. 36 bytes would be ok, 72 bytes for
a fully defined 2-byte protocol, I'd have to think twice before using,
especially if I need to add a custom protocol to make it work, gobbling
up more memory.

This is all with the understanding of extender being used. The base
remote memory conf is more restrictive and keymove area is more
limited so that could change my opinion.

[Mark Pierson]

If that upgrade assigns functions to unmapped keys, so KM automatically generates 6 byte KeyMoves, you can save some space by deleting those and making the 5 byte keymoves using VCR/0162 and VCR/0454. RemoteMaster's external functions sheet allows you to include those in the upgrade definition. I don't think KM can do that, so you'd need to patch the KM keymoves in IR.

For the 2nd time today , while not as elegant as RM's implementation, KM can do external functions on the Functions sheet.

[wwwoholic]

For the 2nd time today , while not as elegant as RM's implementation, KM can do external functions on the Functions sheet.

How?

I think I tried everything and could not find anything. (Ha! soon I'll be singing)

Can you, for example give me an idea what should I do to:
- use built-in VCR/1062 device for most commands, while
- keymove couple commands from built-in VCR/0162 to unused (by 1062) buttons in VCR mode.

[Mark Pierson]

Can you, for example give me an idea what should I do to:
- use built-in VCR/1062 device for most commands, while
- keymove couple commands from built-in VCR/0162 to unused (by 1062) buttons in VCR mode.

If you're using both bulit-in codes, KM really won't help you unless you build an upgrade file for VCR/1062 as John suggested above. IMHO, it would make more sense to do them directly in IR.

If you build an upgrade for VCR/1062 however, you can define the "external" VCR/0162 functions like this (as it's explained in the readme) on the Functions sheet.

Code: Select all

Functions                EFC
----------------------- -----
=vcr/0162 func1          h00
=vcr/0162 func2          h01

Replace the "func#" with a more descriptive entry, and substitute the proper hex cmd for "h00" and "h01" (the "h" is REQUIRED for single byte direct hex entry in KM).

Then on the Buttons sheet, you can assign those "external" functions to the buttons of your choosing and KM will create the appropriate key move code (bound to the KM upgrade device) as part of the Device Upgrade Code.

[wwwoholic]

Here is how I made it work:

- I created device upgrade using "Panasonic VCR Combo" protocol
- I put EFCs from VCR/0162 and VCR/0454 into this upgrade with corresponding 2nd byte for 144.0 and 144.1 signals. KM calculated 2-byte hex commands for me.
- In IR I put setup code VCR/1062 which uses the same "Panasonic VCR Combo" protocol.
- In keymoves tab I created keymoves in Hex Cmd mode using those two bytes from KM page.

After reading johnsfine's post I think it worked just by coincidence. I should have used keymoves in EFC mode, making sure I use "VCR/0162 as the source for the 144.0 keymoves and VCR/0454 as the base for the 144.1 keymoves".

[wwwoholic]

Hmm... You are typing faster than me.

Well, guess I should RTFM more intently next time.

[wwwoholic]

Just one more:

I just realized what you were talking about in some previous posts speaking of "dummy" device upgrades.

Now, would importing such upgrade into IR create just keymoves or a device as well? If there is a device I guess it should be safe to remove it?

[Mark Pierson]

Now, would importing such upgrade into IR create just keymoves or a device as well? If there is a device I guess it should be safe to remove it?

An upgrade with no buttons defined and using the same device type/setup code as a built-in code would effectively do nothing since the remote looks for the upgrade before the built-in.

You could do as you say, however, and delete the device from IR after pasting, or you could just use KM's Key Moves sheet (instead of Buttons) to create the key moves for the "external" commands.

[wwwoholic]

So instead of two separate buckets, I see two buckets with a tube attached and memory being shifted back and forth depending on where I need it.

I understand this is quite insolent of me to suggest anything to you guys, but I keep doing it again. It's probably my job field talking...

What if:
- extenders will support "configurable memory distribution"
- RDF for such extenders will have additional parameter allowing this functionality. This is backwards-compatible with old IR versions.
- IR will lookup for this parameter and if functionality is available it will display a single memory bar instead of two(three).
- This memory bar will have a slider(s) separating macro area from upgrades. Moving this slider will distribute memory proportionally (just like in those buckets).
- Before uploading IR will write the slider position into the memory slot specified by aforementioned parameter.
- extender will read that and distribute memory accordingly.