Does the library rely on IR decoder chips or does it also have a raw receive off IR photodiode/phototransistor?

[liudr]

Probably a noob question. I've tested the commonACControl.ino on one ESP32 with an IR LED, a 38KHz decoder IC on a receiver ESP32 running Tasmota. I realized that for those brands and protocols that the sender is sending at frequency other than 38KHz, the receiver is not able to decode (expected). So I poked around the library code and found that each brand-specific ac class definition has its own send() which calls sendGeneric(), with a hardcoded frequency such as 36 for Trotec, or 38 for LG/Samsung. So I am wondering, is there any way to use an IR photodiode/phototransistor to receive the modulated signals and decode without a decoder IC so that any frequency signal (i.e. any brand/model signal) can be read correctly. I would imagine that I can specify the frequency to decode and figure out which frequency it is after a few button presses. Thanks.

[NiKiZe]

38KHz modulation will be hard to capture reliable, not to mention save.

Actually many protocols will be detectable with a 38KHz demodulator.

[liudr]

Thanks for the straight forward response! Out of the 100+ protocols supported by the library, I see about 20 issues with either complete zero reception or only one of two, on or off commands were decoded. What I'm trying to make is a universal IR receiver, and a universal IR sender. The receiver will understand what frequency and protocol the remote control is sending, then tell the sender to send at that frequency and that protocol. This way if the user has any supported AC units I will be able to support that regardless of the protocol or the frequency. I am assuming that the user has no knowledge of the IR remote controls frequency or protocol. All they have to do is to press the button and be done. Afterwards, my program will send IR remote control commands to the AC unit according to a schedule. This sounds like a home automation system, but it is more specialized in only AC control, and it is also simpler to set up than most home assistant programs. It will be integrated into a much larger ecosystem that no home assistant programs are able to do at the moment.

[liudr]

I'm using TSOP38238 decoder, which is 38KHz.

https://www.digikey.com/en/products/detail/vishay-semiconductor-opto-division/TSOP38238/1681362

I'm trying to make a reliable device for the not-at-all tech-savvy users. They point their remote at my board and click, my board understands the frequency and protocol. They don't have to do more. Maybe I should get a 36K, 38K, and 40K. One of each. Ask the user to press a button 3 times while the board uses each decoder to determine the frequency and protocol. Another idea is to use pico state machine to decide. Or maybe an atmega328 to decide the remote.

[liudr]

Based on my data from CommonAcControl.ino and Tasmota, the TROTEC protocol uses 36KHz modulation and my TSOP38238 failed to detect it 3 out 3 times. PANASONIC_AC, PANASONIC_AC32, and DAIKIN2 use 36.7KHz modulation and had some success out of 3 times. I'll try more on those protocols to see if my 38KHz decode can do them reliably but I already bought 36KHz decodes as well.

I also bought an IR learning IC TSMP98000 so I could see what I can learn. It outputs the amplified carrier signals. I wonder if the library has any way to read in and confirm the frequency, without having to decode the message. Maybe I should look into some pin-change interrupts?

The above is a Samsung TV remote power button press. I've not read Samsung protocol yet but it looks like NEC that I did read through. Could hand-decode into 0xE0E040BF if MSB first or 0x70702FD if LSB first. Maybe I could help contribute if I encounter remotes not found in the library?

[liudr]

OK I used a TSOP38236, 36KHz decoder, and it was able to decode all the protocols except that TROTEC. Both 36KHz and 38KHz decoder decoded the same when receiving TROTEC:
06:07:41.178 RSL: RESULT = {"IrReceived":{"Protocol":"UNKNOWN","Bits":75,"Hash":"0x7B0C9C1D","Repeat":0}}
06:07:46.330 RSL: RESULT = {"IrReceived":{"Protocol":"UNKNOWN","Bits":75,"Hash":"0xAEF02725","Repeat":0}}
So I guess it wasn't the frequency issue, like you said 38KHz decoder can work on 36KHz signals. It's probably a software issue that causes the code to not interpret the data as TROTEC message, even though I bet the raw hash may be correct.