losing buttons transferring from km to ir

[irv6744]

when i transfer the apex dvd device file from km to ir, i am losing the number keys and it says they are all not mapped.
but it transfers fine to my 7800 remote.
i am using an 8910 remote and km is 9.01 and ir is 7.01.
thanks

[gfb107]

Please upload your KM and IR files to the Diagnosis Area, and then post links to them.

[irv6744]

i have now posted the two files as follows:

https://www.hifi-remote.com/forums/dload ... le_id=3464

https://www.hifi-remote.com/forums/dload ... le_id=3465

thanks

[The Robman]

There is a bug in the way the digitmaps are being handled in KM, so try this upgrade instead...

Upgrade Code 0 = 2C 4C (DVD/1100) Apex 1100W (KM v9.00)
46 00 FE FE FE F1 DF 5F 6D 5D 9F DF FD BF 7F 7D
3F F7 B5 35 9D 37 AF 1D 8F EF 0F CD CF AD 6F 9E
3E FC 7E 1F 8F BD F5 0D 3D 5F 2D 4F DD
End

Note to Mark and/or Mike, the DM2 sheet goes to 335 but the main DM sheet only goes to 194.

[mr_d_p_gumby]

Note to Mark and/or Mike, the DM2 sheet goes to 335 but the main DM sheet only goes to 194.

Yeah, I caught that while working on multi-byte digitmaps on the upcoming v9.02, so it'll be fixed soon.

[irv6744]

do i still use the protocol code associated with dvd 1100

i guess i had no problem with my other remotes since they were set up with an older version of km

thanks for the help.

[gfb107]

Note to Mark and/or Mike, the DM2 sheet goes to 335 but the main DM sheet only goes to 194.

Yeah, I caught that while working on multi-byte digitmaps on the upcoming v9.02, so it'll be fixed soon.

What's the story with multi-byte digitmaps? I assume it is an issue for RM as well?

[mr_d_p_gumby]

What's the story with multi-byte digitmaps? I assume it is an issue for RM as well?

Yes, it will affect RM as well. Up until the URC-9960B01, whenever an upgrade indicated use of a digitmap, it was always associated with a 1-byte protocol. Now, UEI has expanded the use of digitmaps to 2-byte protocols (and beyond). It works similar to the old way, where the upgrade indicates the first digitmap byte, but it pulls 2 sequential bytes from the digitmap for each numeric button. This consumes two sequential 10-byte entries in the digitmaps. We have followed suit in the way we have incorporated digitmap support in our tools.

I am adding digitmap support in KM for up to 4-byte protocols. Each number button pulls 4 digitmap bytes, and it consumes four digitmap entries. Why, you may ask? Because some of the JP1.2 remotes have setup codes that use 4-byte protocols and digitmaps. 4-byte protocols? Yes! There goes our hope that, in the future, all setup codes could use 5-digit EFCs.

[gfb107]

I'm going to need some more details on this.
Let me see if I understand.

The digitmap table is just a big array of bytes.

The digitmap number is multiplied by 10 to give an index into the digitmap table to the first byte of that digitmap.

A 1-byte digitmap is 10 bytes long. An n-byte digitmap is n*10 bytes long.

So, if digitmap number 376 is a n-byte digitmap, the next useable digitmap number if 376+n. So digitmap numbers are going to grow rapidly.

On a different but related topic, isn't there only 1 byte in a device upgrade for the digitmap number? How do we handle digitmap numbers >255? We already have digitmap numbers up to 332, so we should already be having problems with these.

[The Robman]

Each remote can only hold up to 255 10-byte digitmap entries, but we (in KM and RM) can support much more than that. So, even though the total number of digitmaps that we support now exceeds 300, the hex code that the cross-reference tables return will be in the 0x01 thru 0xFF range.

[gfb107]

Ahh, I remember now. The [DigitMaps] section is positional by the remote digitmap number, but the values are the "global" digitmap number.