Microsoft MCE Keyboard Remote

[vickyg2003]

Bummer, bummer, bummer, I have an executor that sends 37 bits of what I fed it, but apparently when I did my work, I shifted cells up, because what I have for A doesn't match what A sends. Back to feeding in the timings, rounding etc............yuck! bummer, bummer bummer.

[The Robman]

Like Rob has written, it would be so nice to have a tool to take the ICT file and produce what we need to work on.

I guess that is a request. Stay tuned...

Hi Barf, if you are taking that as a request, here's some info on what we're looking for. There are occasions where we need to manually decode a new protocol and to do that we need a way to round all the burst times to multiples of a fixed amount and, for bi-phase signals, we need to have the tool split double times into 2 and put a marker between the pairs. IR.exe does everything we need, so you can use that as an example. That's why I wrote the IRScope Decoder, which converts an IRScope file into a *.ir file, so I can use IR.exe to decode the signals.

[vickyg2003]

Barf, if you still have the files that you cleaned up to transmogrify, could you transmogrify them to the 5,32 format that I need to proceed.

[Barf]

@Vicky: here Forgot the --parameterwidth option?

[The Robman]

Bummer, bummer, bummer, I have an executor that sends 37 bits of what I fed it, but apparently when I did my work, I shifted cells up, because what I have for A doesn't match what A sends. Back to feeding in the timings, rounding etc............yuck! bummer, bummer bummer.

In case it helps, I used IR.exe to do the rounding, here's the results...
https://www.hifi-remote.com/forums/dload ... e_id=14675

[Barf]

...
There are occasions where we need to manually decode a new protocol and to do that we need a way to round all the burst times to multiples of a fixed amount and, for bi-phase signals, we need to have the tool split double times into 2 and put a marker between the pairs. IR.exe does everything we need, so you can use that as an example. That's why I wrote the IRScope Decoder, which converts an IRScope file into a *.ir file, so I can use IR.exe to decode the signals.

The Transmogrifier does all this, "better". First, it does not round the measured timings, but builds up a histogram, and then replaces all timings in one "bin" by the average of the entries in a particular bin. (I can probably prove (in the mathematical sense) that this in general gives better results.) We arrive at a small number of timings and on-off pairs. Let's do an example. Note that using the option --statistic makes the program print such stuff. We use Vicky's f8-f12.ict for the example:

Code: Select all

irptransmogrifier  analyze --statistics  --namedinput   f8-f12.ict
Gaps:
A:      300     = 1*300         450
B:      341     = 1*300         22
C:      603     = 2*300         97
E:      74349                   18

Flashes:
A:      300     = 1*300         472
C:      603     = 2*300         97
D:      2742    = 9*300         18

Pairs:
AA:     406
CC:     71
AC:     26
CA:     26
AB:     22
AE:     18
DA:     18

(output shortened.)
Hmmm, looks uncool: the A and B gaps are just too close to one another to make sense. We try to increase the absolute tolerance parameter to 150, to get wider bins, and lump the A and B together. (The default value is 100 (microseconds)).

Code: Select all

irptransmogrifier --absolutetolerance 150  analyze --statistics  --namedinput  f8-f12.ict 
Gaps:
A:      301     = 1*301         472
B:      603     = 2*301         97
D:      74349                   18

Flashes:
A:      301     = 1*301         472
B:      603     = 2*301         97
C:      2742    = 9*301         18

Pairs:
AA:     428
BB:     71
AB:     26
BA:     26
AD:     18
CA:     18

F8 Down  CA AA BB AA AA AA AA BA AB AA BB AA AA AA AA AA AA AA AA BB AA AA AA AA BB AA AA AA AA AA AA AA AD CA AA BB AA AA AA AA BA AB AA BB AA AA AA AA AA AA AA AA BB AA AA AA AA BB AA AA AA AA AA AA AA AD
...
...

f10 down CA AA BB AA AA AA AA BB BA AA AB AA AA AA AA AA AA AA AA BB AA AA AA BA AB AA AA AA AA AA AA AA AD CA AA BB AA AA AA AA BB BA AA AB AA AA AA AA AA AA AA AA BB AA AA AA BA AB AA AA AA AA AA AA AA AD CA AA BB AA AA AA AA BB BA AA AB AA AA AA AA AA AA AA AA BB AA AA AA BA AB AA AA AA AA AA AA AA AD CA AA BB AA AA AA AA BB BA AA AB AA AA AA AA AA AA AA AA BB AA AA AA BA AB AA AA AA AA AA AA AA AD CA AA BB AA AA AA AA BB BA AA AB AA AA AA AA AA AA AA AA BB AA AA AA BA AB AA AA AA AA AA AA AA AD CA AA BB AA AA AA AA BB BA AA AB AA AA AA AA AA AA AA AA BB AA AA AA BA AB AA AA AA AA AA AA AA AD CA AA BB AA AA AA AA BB BA AA AB AA AA AA AA AA AA AA AA BB AA AA AA BA AB AA AA AA AA AA AA AA AD
...
f11 Down CA AA BB AA AA AA AA BA AB BA AB AA AA AA AA AA AA AA AA BB AA AA BB AA AA AA AA AA AA AA AA AA AD
...
f12 Down CA AA BB AA AA AA AA BB BA AB AA AA AA AA AA AA AA AA AA BB AA AA BB BB AA AA AA AA AA AA AA AD CA AA BB AA AA AA AA BB BA AB AA AA AA AA AA AA AA AA AA BB AA AA BB BB AA AA AA AA AA AA AA AD CA AA BB AA AA AA AA BB BA AB AA AA AA AA AA AA AA AA AA BB AA AA BB BB AA AA AA AA AA AA AA AD CA AA BB AA AA AA AA BB BA AB AA AA AA AA AA AA AA AA AA BB AA AA BB BB AA AA AA AA AA AA AA AD CA AA BB AA AA AA AA BB BA AB AA AA AA AA AA AA AA AA AA BB AA AA BB BB AA AA AA AA AA AA AA AD CA AA BB AA AA AA AA BB BA AB AA AA AA AA AA AA AA AA AA BB AA AA BB BB AA AA AA AA AA AA AA AD CA AA BB AA AA AA AA BB BA AB AA AA AA AA AA AA AA AA AA BB AA AA BB BB AA AA AA AA AA AA AA AD

(also shortened.)
Looks much better! We now have only one gap of around 300 micros. Also note that the program has found a "least common denominator" for (most) of the durations (here 301). The sequences are now represented as a sequence of "Pairs", see "F8 down" above. First problem solved.

Next, we try to find a "model to fit to the data", namely to find a type of "meta protocol" that could have generated the actual data. These are called "decoders"; there are presently nine such (TrivialDecoder, Pwm2Decoder, Pwm4Decoder, Pwm4AltDecoder,
XmpDecoder, BiphaseDecoder, BiphaseWithStartbitDecoder, BiphaseWithDoubleToggleDecoder, SerialDecoder). (The almost identical decoders BipaseDecoder and BiphaseWithStartBitDecoder amonts to your "split double times into 2 and put a marker between the pairs") (This list is printed by --decoder list.) Every signal is tried with all decoder, if succeeding, presenting a a "protocol" in IRP format (with all parameters assigned). With the option --all, these are all printed. Again, with Vicky's data:

Code: Select all

irptransmogrifier --absolutetolerance 150  analyze  --all  --namedinput   f8-f12.ict 
F8 Down:        {36.3k,301,msb}<>(9,-1,1,-1,2,-2,1,-1,1,-1,1,-1,1,-1,2,-1,1,-2,1,-1,2,-2,1,-1,1,-1,1,
-1,1,-1,1,-1,1,-1,1,-1,1,-1,2,-2,1,-1,1,-1,1,-1,1,-1,2,-2,1,-1,1,-1,1,-1,1,-1,1,-1,1,-1,1,-1,1,-74m,
9,-1,1,-1,2,-2,1,-1,1,-1,1,-1,1,-1,2,-1,1,-2,1,-1,2,-2,1,-1,1,-1,1,-1,1,-1,1,-1,1,-1,1,-1,1,-1,2,-2,1,
-1,1,-1,1,-1,1,-1,2,-2,1,-1,1,-1,1,-1,1,-1,1,-1,1,-1,1,-1,1,-74m){}
weight = 132    TrivialDecoder
{36.3k,301,msb}<1,-1|2,-2>(9,-1,A:6,2,-1,1,-2,B:24,-74m,9,-1,C:6,2,-1,1,-2,D:24,-74m){A=0x10,B=0x402100,C=0x10,D=0x402100}
weight = 32     Pwm2Decoder
{36.3k,301,msb}<1,-1|1,-2|2,-1|2,-2>(9,-1,A:62,1,-74m,9,-1,B:62,1,-74m){A=0xc024c000300c000,B=0xc024c000300c000}
weight = 34     Pwm4AltDecoder
{36.3k,301,msb}<1,-1|1,-2|1,-3|1,-4|1,-5|1,-6|1,-7|1,-8|1,-9|1,-10|1,-11|1,-12|1,-13|1,-14|1,-15|1,-16>
(9,-1,A:4,2,-2,B:16,2,-1,C:8,2,-2,D:32,2,-2,E:16,2,-2,F:28,1,-74m,9,-1,G:4,2,-2,H:16,2,-1,I:8,2,-2,J:32,
2,-2,K:16,2,-2,L:28,1,-74m){A=0x0,B=0x0,C=0x10,D=0x0,E=0x0,F=0x0,G=0x0,H=0x0,I=0x10,J=0x0,K=0x0,L=0x0}
weight = 108    XmpDecoder
{36.3k,301,msb}<-1,1|1,-1>(9,A:37,-74m,9,B:37,-74m){A=0x419004100,B=0x419004100}
weight = 20     BiphaseDecoder
{36.3k,301,msb}<-1,1|1,-1>(9,-1,A:1,2,-2,B:4,2,C:1,-2,D:1,2,-2,E:8,2,-2,F:4,2,-2,G:8,-74m,9,H:37,-74m){A=0x1,B=0xf,C=0x0,D=0x1,E=0xff,F=0xf,G=0xff,H=0x419004100}
weight = 41     BiphaseWithStartbitDecoder
{36.3k,301,msb}<-1,1|1,-1>(9,A:37,-74m,9,B:37,-74m){A=0x419004100,B=0x419004100}
weight = 20     BiphaseWithDoubleToggleDecoder
{36.3k,301,msb}<-1|1>(A:63,B:20,-74m,C:63,D:20,-74m){A=0x7fd6556965555655,B=0x65555,C=0x7fd6556965555655,D=0x65555}
weight = 90     SerialDecoder
f9 Down:        {36.3k,301,msb}<>(9,-1,1,-1,2,-2,1,-1,1,-1,1,-1,1,-1,2,-1,1,-2,2,-2,1,-1,1,-1,1,-1,1,-1,1,-1,1,
-1,1,-1,1,-1,1,-1,2,-2,1,-1,1,-1,1,-1,2,-2,1,-1,1,-1,1,-1,1,-1,1,-1,1,-1,1,-1,1,-1,1,-74m){}
weight = 66     TrivialDecoder
{36.3k,301,msb}<1,-1|2,-2>(9,-1,A:6,2,-1,1,-2,B:24,-74m){A=0x10,B=0x802200}
weight = 18     Pwm2Decoder
{36.3k,301,msb}<1,-1|1,-2|2,-1|2,-2>(9,-1,A:62,1,-74m){A=0xc02700003030000}
weight = 21     Pwm4AltDecoder
{36.3k,301,msb}<1,-1|1,-2|1,-3|1,-4|1,-5|1,-6|1,-7|1,-8|1,-9|1,-10|1,-11|1,-12|1,-13|1,-14|1,-15|1,-16>
(9,-1,A:4,2,-2,B:16,2,-1,C:4,2,-2,D:36,2,-2,E:12,2,-2,F:32,1,-74m){A=0x0,B=0x0,C=0x1,D=0x0,E=0x0,F=0x0}
weight = 69     XmpDecoder
{36.3k,301,msb}<-1,1|1,-1>(9,A:37,-74m){A=0x41a004200}
weight = 12     BiphaseDecoder
{36.3k,301,msb}<-1,1|1,-1>(9,-1,A:1,2,-2,B:4,2,C:1,-2,2,-2,D:9,2,-2,E:3,2,-2,F:9,-74m){A=0x1,B=0xf,C=0x0,D=0x1ff,E=0x7,F=0x1ff}
weight = 31     BiphaseWithStartbitDecoder
{36.3k,301,msb}<-1,1|1,-1>(9,A:37,-74m){A=0x41a004200}
weight = 12     BiphaseWithDoubleToggleDecoder
{36.3k,301,msb}<-1|1>(A:63,B:20,-74m){A=0x7fd6556995555655,B=0x95555}
weight = 48     SerialDecoder

(output only from the first signal.) Which one of these is correct? Strictly speaking, they all are, since they could explain the measured data! To solve this problem (better, heuristically select the "nicest" solution), for every protocol, a "weight" is computed, and the protocol with the lowest weight is presented:

Code: Select all

/irptransmogrifier.sh --absolutetolerance 150  analyze  --namedinput   ~/jp1/mce_keyboard/f8-f12.ict 
F8 Down  {36.3k,301,msb}<-1,1|1,-1>(9,A:37,-74m,9,B:37,-74m){A=0x419004100,B=0x419004100}
f9 Down  {36.3k,301,msb}<-1,1|1,-1>(9,A:37,-74m){A=0x41a004200}
f10 down {36.3k,301,msb}<-1,1|1,-1>(9,A:37,-74m,9,B:37,-74m,9,C:37,-74m,9,D:37,-74m,9,E:37,-74m,9,F:37,-74m,9,
G:37,-74m){A=0x417004300,B=0x417004300,C=0x417004300,D=0x417004300,E=0x417004300,F=0x417004300,G=0x417004300}
f11 Down {36.3k,301,msb}<-1,1|1,-1>(9,A:37,-74m){A=0x41b004400}
f12 Down {36.3k,301,msb}<-1,1|1,-1>(9,A:37,-74m,9,B:37,-74m,9,C:37,-74m,9,D:37,-74m,9,E:37,-74m,9,F:37,-74m,9,
G:37,-74m){A=0x416004500,B=0x416004500,C=0x416004500,D=0x416004500,E=0x416004500,F=0x416004500,G=0x416004500}

(Compare with the above output, only the protocol with the lowest weight is now output.)

Next note that some of Vicky's are pretty long, because it contained repeats. For this, the repeatfinder can/should be invoked, using the option --repeatfinder, these are identified and taken care of.

Code: Select all

irptransmogrifier.sh --absolutetolerance 150  analyze --repeatfinder  --namedinput   ~/jp1/mce_keyboard/f8-f12.ict 
F8 Down  {36.3k,301,msb}<-1,1|1,-1>(9,A:37,-74m)2{A=0x419004100}
f9 Down  {36.3k,301,msb}<-1,1|1,-1>(9,A:37,-74m){A=0x41a004200}
f10 down {36.3k,301,msb}<-1,1|1,-1>(9,A:37,-74m)7{A=0x417004300}
f11 Down {36.3k,301,msb}<-1,1|1,-1>(9,A:37,-74m){A=0x41b004400}
f12 Down {36.3k,301,msb}<-1,1|1,-1>(9,A:37,-74m)7{A=0x416004500}

As a final word: Presently the program is command line only. This is not because I find it better than a GUI or such, but mainly because the GUI is not yet written. Likely the program (a large part of it) will be integrated into IrScrutinizer. (But, a good command line program is IMHO better than a bad GUI program ).

[The Robman]

Well, as the "user" I've told you what I want and what you described isn't it. Experts need the ability to do this by hand as tools won't always get it right.

[vickyg2003]

Bummer, bummer, bummer, I have an executor that sends 37 bits of what I fed it, but apparently when I did my work, I shifted cells up, because what I have for A doesn't match what A sends. Back to feeding in the timings, rounding etc............yuck! bummer, bummer bummer.

In case it helps, I used IR.exe to do the rounding, here's the results...
https://www.hifi-remote.com/forums/dload ... e_id=14675

THANK YOU ROB!!!!!! As you know this is just what I needed!!!!

[The Robman]

Bummer, bummer, bummer, I have an executor that sends 37 bits of what I fed it, but apparently when I did my work, I shifted cells up, because what I have for A doesn't match what A sends. Back to feeding in the timings, rounding etc............yuck! bummer, bummer bummer.

In case it helps, I used IR.exe to do the rounding, here's the results...
https://www.hifi-remote.com/forums/dload ... e_id=14675

THANK YOU ROB!!!!!! As you know this is just what I needed!!!!

You're welcome, and you know how I did it, right? It sounded like you were doing the rounding by hand. There are a few buttons missing, some got error messages when I tried exporting them to UEI format because they are longer than 128 bytes (f12 down, backslash, delete, F1 down, mouse down), some prevented IR.exe from opening (one, four, percentage) and some didn't translate into reasonable binary (C Down).

[vickyg2003]

Open a zillion programs and copy and paste until your eyes glaze over?


I followed your instruction here
https://www.hifi-remote.com/forums/viewt ... 926#p105926
But when I got to step 6, I was stymied by the math because IR didn't halve the 600's no matter what biphase I chose.


Here is the upgrade for the keyboard commands. it looks good to me, not sure if the timings need to be adjusted to make it work, but bumps are in the right place.
https://www.hifi-remote.com/forums/dload ... e_id=14676

Hope it will work for the OP

[The Robman]

I followed your instruction here
https://www.hifi-remote.com/forums/viewt ... 926#p105926
But when I got to step 6, I was stymied by the math because IR didn't halve the 600's no matter what biphase I chose.

Enter 300 and select "odd" as the biphase value.

[vickyg2003]

Enter 300

Ahh that's where I went wrong. I had merely rounded to 100's which didn't divide the 600's into 300 sections.


That worked for the mouse commands Just changed the trailing +300 with a 1. The last bit was a parity bit for this. It counted the 1's and added forced them to be an even number.

Code: Select all

1	36199	Repeat:	+2700; 00001000 00011000 00000000 00001111 00 -74400 RightClick
2	36529	Repeat:	+2700; 00001000 00101000 00000000 00010110 10 -74400 LeftClick

3	36529	Repeat:	+2700; 00001000 01111111 10100000 00000100 00 -10800 MouseUp	
4	36529	Repeat:	+2700; 00001000 00001000 00001111 01100111 10 -10800 MouseLeft
5	36529	Repeat:	+2700; 00001000 10000000 01111111 00000011 11 -11100; Mouse_L_Down
6	36529	Repeat:	+2700; 00001000 01000111 10101111 01000101 11 -11100; Mouse_L_Up
7	36529	Repeat:	+2700; 00001000 10000000 01010000 10100011 11 -11100; Mouse_R_Down	
8	36529	Repeat:	+2700; 00001000 01110111 10110000 10100100 01 -11100; Mouse_R_Up
9	36529	Repeat:	+2700; 00001000 01111000 00000000 10100100 00 -10800 MouseRight

[The Robman]

Enter 300

Ahh that's where I went wrong. I had merely rounded to 100's which didn't divide the 600's into 300 sections.

Yeah, for bi-phase the assumption is that there's only 1 burst time, so you enter that and it splits the doubles.

[vickyg2003]

Rob, is there a 2 byte imititation on function hex?

[The Robman]

Rob, is there a 2 byte limitation on function hex?

A limitation on who's part? But the answer is no, the designer of a protocol is free to do whatever they want and UEI executors can be written to handle almost anything. There would be a 2 byte limit if you intend to be able to use EFCs with it, I suppose.

If you think about A/C protocols, those often have many more than 2 variable bytes in them, as they encode almost all the settings (ie, temp, fan speed, etc) into each signal.

But for regular devices, if I find that there are several moving parts in the signal, I try to look for patterns (to see if there are checksum type things in there) and to see if I can reduce anything down, because at the end of the day, if I can write executor code that only needs 1 or 2 variable bytes, it makes the device upgrade smaller and more user-friendly.