Bug in KM 8.11

[unclemiltie]

In case you're not watching over in the general discussions forum, I was trying to build an upgrade for a DishPVR721 that uses two devices with the same protocol.

There's a bug in KM, at least for the Dishplayer(old) protocol in that it is not computing the "Fixed data" correctly that you need to build a combiner upgrade. The nibbles of the second byte are swapped (ie: Unit=16 should yield 80h and yields 08h in KM. Details are in the DishPVR721 thread.

Once I got the correct fixed data, the upgrade worked fine.

[Mark Pierson]

Unit=16 should yield 80h and yields 08h in KM.

Do you mean "Device=16"? The Unit Code determines the 1st Fixed Data byte while the Device determines the 2nd.

[unclemiltie]

well, it depends


the other thing that made this upgrade difficult for me was that the words used in KM (unit, device1) and in IR (device, sub-device) don't perfectly align.

Again, the details are in the General section, but whatever it is that determines the second byte is the part that isn't getting done correctly.

[gfb107]

This is the thread that discusses this.

[jon_armstrong]

Greg,

Does RM handle all the cases of $0002? I gave a fairly long (and probably dull) answer at the end of that thread that describes some of the the issues.

[gfb107]

I just took a look at protocols.ini, and it does have 3 different variants of $0002

It looks like when John added them, he intentionally made them different from KM, but compatible with DecodeIR.

Here's the notes (which are the same for all 3 variants):

Notes=Standard SAT/0775 is Unit 0 / Device 0

Device, Unit and OBC are all incompatible with KM (version 7.34)
They are compatible with DecodeIR.dll as Device.Unit:OBC
EFC values are compatible with KM within the same model remote.
EFC values are compatible across models of remote for the default unit number and in some cases for other unit numbers.