Digital Larry wrote:#3 Furthermore, the manufacturer of the remote sent me some information confirming that this is an NEC protocol. Each button has what is called the "Custom code": 85 E3. Following that, each button has 2 more bytes, the first of which is always 27 and then the final one is unique per button.
I am going through the NEC protocols in Remote Master to see which one would possibly allow me to enter the data in such a way. I'm a "paint by numbers" guy as far as this IR stuff goes so I could easily be overlooking something the rest of you find incredibly obvious.
Remember what I said in the 4th post above:
The Robman wrote:The learns appear to be a variation of the NEC format, except that the first three bytes are fixed and the 4th byte varies.
These are not true NEC signals so you can't use any of the current NEC sections in RM. In a normal NEC signal the 3rd byte varies for each button and the 4th byte is the complement of the 3rd byte. That's not the case with these signals, that's why they don't decode properly and why Vicky had to write a custom executor to generate the signals.
Having said that, let's look at the data itself. Here's the data that I posted above for the POWER button:
10100001 11000111 11100100 10111000
NEC is a "LSB" protocol so you have to read the binary backwards. Here is the binary reversed:
10000101 11100011 00100111 00011101
Now let's convert each binary string into hex:
85 E3 27 1D
You'll see that the first 2 bytes are "85 E3" and the 3rd byte is "27", just like your contact said. I'm guessing that they list the code for POWER as "1D".