Zero vs null problem in KM? RM? IR?

[ElizabethD]

Some zero hex values in upgrade are not desirable. I suspect it's a feature of (KM and RM) or IR, or combination, and can be reproduced like this:

1. Assign any fake function values>0 (hex 50, D0, 30 here) on channel up, down and power
Upgrade Code 0 = 60 01 (Cable/0001) keymap-master Device Upgrade (KM v8.32)
5E 00 81 FF 00 50 D0 30 00 00 00 00 00 00 00
End
2. Blank out button assignment on channel down, assign instead to shift-channel down, leaving base code blank
Upgrade Code 0 = 60 01 (Cable/0001) keymap-master Device Upgrade (KM v8.32)
5E 00 31 F6 00 50 00 30
KeyMoves
87 F3 60 01 D0«channel down»
End
3. Now when this upgrade goes into IR, zero results, rather than "Not mapped" as for all other buttons. Consequently, since in this protocol (Aiwa) zero is a valid Power toggle code, hitting channel down does precisely what I told the remote to do but didn't mean to. Ouch

In case IR file needed which I doubt
https://www.hifi-remote.com/forums/dload ... le_id=2851

[Capn Trips]

I'm pretty sure it's related to keygroups in the remote definition. If you define a function for ch+, a function MUST BE DEFINED for ch-. If YOU DON'T define it, the software automatically adds a null function. Sorta like if you assign a handful of input select functions to several digits, the rest of the digits, evn if you didn't assign anything, will have 00's assigned.

[gfb107]

UEI, in their infinite wisdom, has laid out the keymaps so that certain keys are grouped in a device upgrade. A device upgrade must either include none of the keys in the group, or all of the keys in the group.

Common groups are:

• Digits
• Volume +, Volume -, Mute
• Ch+, Ch-

In this case, you have assigned a function to the CH+ key, but not the CH- key. Since these keys go together, KM/RM must include a function on the CH- button, but since you haven't assigned one, it assigns 0 (arbitrarily).

[The Robman]

Greg and the Capn are exactly right. The three groups that Greg listed are used in all remotes, and they are the only such groups. If you assign a function to at least one button in the group, you are committed to using all of the buttons in the group.

In case you're interested, the reason for these groupings is to conserve memory. Each group occupies just one bit in the keymap bytes, which means they all collectively use 3 bits, rather than the 15 bits they would otherwise have used. Multiply this by the thousand or so upgrades that they load into the ROM and you'll see that it's a significant saving.

[gfb107]

Would there be any value in showing these groups on RM's layout panel?
I'm thinking instead of using just one color to outline the buttons in the active keymap, I could use 4 colors (one for the digits, one for volume, one for ch+/-, and another for keys that aren't in any group, but are in the keymap.

[The Robman]

I don't think it's worth spending any time developing something like that, personally. The average user doesn't care that the buttons have groups and the average expert already knows.

[ElizabethD]

Ahhhhh!
This only affects upgrades which use zero for the command byte. This Aiwa thing is one, I know one more in the Panasonic group, and I suspect you guys know couple thousand more.

Greg and Rob, perhaps, if RM or KM encounters a function which is zero, a message to expect this might be a cool thing to do. I agree with Rob that fussing with groups and colors for all upgrades and all remotes (8910 has 6 or so groups) would be an overkill. Thanks for the lesson. I would have never thought of key groups as the answer, and everybody is now off the hook

Capn Trips, I saw how zeros on digits multiplied when I entered 4-5 input selections. I paid no attention, till the power thing hit.

The three groups that Greg listed are used in all remotes, and they are the only such groups

What do you mean the only? Is the meaning of groups in extenders jp1-experts-defined? I think in 8910 unextended I recall seeing about more groups in their manual. I'm missing something here.

[gfb107]

These key groups are not the same thing as the key sets that are exposed by the extenders.

[The Robman]

These groupings (and I'm using the word "group" loosely, it's not meant to correspond to any other "groups" that may or may not be in existence) exist in all remotes and are the same in all remotes.

The 10 numeric buttons are in the 1st group.
The 3 volume buttons are in the 2nd group.
The 2 channel buttons are in the 3rd group.

These are the only 3 groups of this kind in any JP1 remote.

All of the other buttons require their own bit in the keymap byte section of an upgrade, but each of these groups only requires a single bit in the keymap bytes (and these three groups always use the first 3 bits in the keymap bytes).

If the bit for the numeric-button group is set, the remote will assume that the first 10 button codes in the upgrade are for the numeric buttons. If we were to only supply 9 codes, it would grab the next button code and put it on the last numeric button and all the other buttons would be offset by one. So, to avoid this problem, both KM and RM insert zeroes for any buttons in a group that are un-assigned, when at least one button in the group has been programmed.

[ElizabethD]

Sometimes the most minor issues bring out great stuff out of here. Thanks to all.

[Capn Trips]

By the way, we went through a similar exercise with outlining different extender keygroups in different colors on the RM layout tab, as I recall, about a year ago, but it really became onerous and quite painful to view, so it was shelved, IIRC.

[Mark Pierson]

Would there be any value in showing these groups on RM's layout panel?

Just an FYI... KM has a very simple representation of the factory groupings on the Buttons and Layout sheets. The numeric, volume, and channel sets are seperated by bold border lines.

[Mark Pierson]

Some zero hex values in upgrade are not desirable.

Since we have now explained to Liz the science behind this phenomenon I'm wondering if the following would be more appropriate?

We (Rob actually) arbitrarily used "$00" as the pad in the various button sets. I believe his intentions were that "$00" was a null command. However, I think it's more appropriate to say that an OBC of "0" is better suited as the null command. Therefore, any COMP'd command protocols should probably use "$FF" as the pad command. Do any of the other experts agree?

[The Robman]

Does it really matter what code gets assigned to a button that the user didn't want to program? And regardless of what code you pick, there's always the chance that it will do something, and maybe not a good thing.

The UEI standard is to use 0x00 as filler when they have numeric buttons left un-assigned. When they have a device that lacks a MUTE button (which does happen) they repeat the VOL- function on the MUTE button.

[ElizabethD]

Would there be any value in showing these groups on RM's layout panel?

Just an FYI... KM has a very simple representation of the factory groupings on the Buttons and Layout sheets. The numeric, volume, and channel sets are seperated by bold border lines.

I always took it as a visual defect on that worksheet I should have known that in KM there is profound meaning behind every dot, line, and letter.