Analyzing unknown IR sender

[dasphero]

Hello peeps,

to learn more about electronic reverse engineering I wanted to analyze and replicate the cheapo ir sender of our christmas lights.

The board looks like this

It looks like a multipurpose board with 21 Buttons, but only 2 are used by the device.
The controller ist an KXD-807F which seems to be a chinese, prupose programmed controller.

I tried to utilize the IRRemote to analyze the signal, but only got a garbled mess. Meaning the HEX codes changed every time I pressed the button. The same happens when I just dump the signal info.
As I didn't have IR receiver, I just connected the LED pin to the input pin, that would normally be used by the receiver, so I think it shouldn't make that big of a difference.

After that I tried to connect a logic analyzer to the LED output and got the following:

"That looks promising, doesn't it?" Well. It raised more questions than it cleared.
At least it consists of a 38kHz carrier freq and the timining correspond to the nec shema.
Alas, there is a huge block of straight 38kHz waves at the beginning, and after a pause a 33 (?) Bit long code.

So far so good. Loading the Simple IR Sender example I realized that my code won't fit there and it might be an old MSB NEC code.
Scrambling around with google and ChatGPT gave me this code:

#include <IRremote.h>

const int IR_LED_PIN = 1;  // Change this to the pin connected to the IR LED

IRsend irsend;

void setup() {
  Serial.begin(9600);
}

void loop() {
  // MSB NEC Protocol: 32-bit code (e.g., 0x03FCB14F)
  uint32_t necCode = 0x03FCB14F;

  Serial.println("Sending MSB NEC signal...");
  irsend.sendNEC(necCode, 32, 38);  // 32 bits, 38 kHz carrier frequency
  delay(5000);  // 5-second delay between signals
}

Looking at it in the signal analyzer gave me the following mess:

A 4kHz, seemingly random signal.

Thank you for reading up to this point

Does anyone have any idea how I might approach this or does anyone recognize or can tell me why the pattern of the sender looks so differerent than other codes?

[jremington]

@dasphero

why the pattern of the sender looks so differerent than other codes

Manufacturers are free to make up their own encoding scheme, and often do.

[6v6gt]

That first wave form does look like NEC protocol.
Around 38kHz, Header of 9ms marks, 4.5ms space then 32 data items plus a trailer. From NEC Infrared Transmission Protocol | Online Documentation for Altium Products

The second wave you have shown does not.

A cheap IR learning remote control may be able to duplicate the signals also.

[6v6gt]

@dasphero

const int IR_LED_PIN = 1; // Change this to the pin connected to the IR LED

That is a bad choice of pin if you are also using serial for debug output.

[ShermanP]

I believe IRRemote is looking for demodulated input. In other words, the IR receiver you would normally use detects the presence of the 38K carrier, not the individual 38K cycles, and IRRemote is looking for that kind of input. It's active low by the way, so the receiver idles high, then goes low when carrier is detected. It looks like the signal analyzer is demodulating the signal for you, but the result doesn't look like NEC to me.

[dasphero]

Looks like I didn't read enough into the NEC Protocol.

The code I grabbed fits perfectly to it.

The sender lib asks for an 8 bit address and 8 bit of command.

I didn't knew about the fact that the codes are inverted (I guess for error correction) and the trailing bit at the end.

[dasphero]

@6v6gt

@dasphero

const int IR_LED_PIN = 1; // Change this to the pin connected to the IR LED

That is a bad choice of pin if you are also using serial for debug output.

Good to know. Do you recommend any pin? Or shall I use any other D Pin (ESP8266) than D2 (internal LED)?

[dasphero]

@ShermanP

I believe IRRemote is looking for demodulated input. In other words, the IR receiver you would normally use detects the presence of the 38K carrier, not the individual 38K cycles, and IRRemote is looking for that kind of input. It's active low by the way, so the receiver idles high, then goes low when carrier is detected. It looks like the signal analyzer is demodulating the signal for you, but the result doesn't look like NEC to me.

Maybe I need to invest in a real IR Receiver

Nah, it actually is not demodulated, it just looks that way because it zoomed out. If you zoom in (in the software) you can see the 38kHz frequency.

[6v6gt]

@dasphero

shall I use any other D Pin (ESP8266) than D2 (internal LED)?

For an ESP8266 you have to be careful with the different pin numbering systems.
This is GPIO 1 which is also TX.

@dasphero

const int IR_LED_PIN = 1; // Change this to the pin connected to the IR LED

Try GPIO15 (which may be marked as D8 on Node MCUs etc.)

[ShermanP]

Well that's ok if your analyzer can capture the entire IR signal. You can zoom out and decode it manually into HEX. But notice in the digram that 6V6gt posted that the high segments of the signal are always the same width. That's characteristic of the NEC protocol.

But in your last picture it looks like NEC, and it looks like the analyzer is decoding it correctly. Does that not work? If not, it could be an LSB vs MSB order difference. So instead of 0x01FEA05F, try 0x807F05FA.

[6v6gt]

@dasphero

A 4kHz, seemingly random signal.

I suspect that this is generated by the message:

@dasphero

Serial.println("Sending MSB NEC signal...");

because it appears that the IR led is on the TX pin. NEC code has a distinctive bit pattern for 0s and 1s. It is not random (as has been said).

[dasphero]

Understanding the NEC protocol was the key part.

I just got the led to turn off the christmas lights using the example simpleSender code, the address 0x80 and the command 0x05.
Also changing the pin helped

Thanks all

[ShermanP]

Ok, so your analyzer decoded it correctly, but assumed it was sent MSB first. But simpleSender is sending it LSB first. Anyway, congratulations on getting it working.