Interfacing an IR Sensor Remote Control: Timing Math, Wiring, and ESP32 Code

An IR sensor remote control receiver (like the common VS1838B or Vishay TSOP38238) outputs a digital, active-LOW baseband signal representing demodulated 38kHz infrared pulses. It does not output an analog voltage proportional to light intensity, nor does it act as a simple proximity switch. Instead, it strips away the high-frequency carrier wave and passes the raw timing envelope of the remote's data packets directly to your microcontroller's GPIO pin. To use it reliably, you must understand the protocol timing math, supply voltage tolerances, and how to filter out modern LED lighting interference.

The 38kHz Demodulation Principle

At the heart of every standard IR remote receiver is a PIN photodiode paired with an integrated circuit (IC) tuned to a specific carrier frequency, almost always 38kHz. When you press a button on a remote, the remote's LED flashes on and off 38,000 times per second. The receiver's internal bandpass filter and Automatic Gain Control (AGC) amplifier isolate this exact frequency while rejecting ambient broadband infrared radiation from the sun or incandescent bulbs.

Once the 38kHz carrier is detected, the IC's demodulator strips it away, outputting the underlying data envelope as a clean digital logic signal. A burst of 38kHz light pulls the output pin LOW (0V), while the absence of the carrier wave allows the internal pull-up resistor to push the pin HIGH (Vcc). This means your microcontroller doesn't need to sample at 38kHz; it only needs to measure the microsecond durations of the HIGH and LOW states to decode the actual command.

Hardware Specs and Wiring Pinout

Not all IR receivers are created equal. The cheap, unbranded modules found in bulk sensor kits often use generic ICs that struggle with Automatic Gain Control (AGC) saturation, whereas name-brand silicon handles noisy environments much better. Below is a data-dense comparison of the most common modules you will encounter on the bench in 2026.

From Raw Microsecond Pulses to Decoded Commands

Because an IR remote sensor outputs digital timing intervals rather than a continuous physical measurement (like temperature or humidity), the 'raw-to-unit' math involves converting raw microsecond pulse widths into binary protocol data. The most ubiquitous protocol is the NEC IR protocol. Understanding this math is critical if you are writing bare-metal interrupt code instead of relying on the Arduino-IRremote library.

The NEC protocol transmits data using pulse-distance encoding. Every transmission begins with a 9,000µs (9ms) header burst, followed by a 4,500µs space. After the header, 32 bits of data are sent (Address, Inverse Address, Command, Inverse Command). The logic state of each bit is determined entirely by the duration of the space (the HIGH state) that follows a standard 562.5µs pulse (the LOW state).

The Raw-to-Bit Timing Math

Here is the exact mathematical mapping from raw GPIO readings to logical bits:

• Logic '0': 562.5µs pulse (LOW) + 562.5µs space (HIGH). Total bit time: 1.125ms.
• Logic '1': 562.5µs pulse (LOW) + 1,687.5µs space (HIGH). Total bit time: 2.25ms.

If you are using a microcontroller's pulseIn() function or a hardware timer capture, your scaling logic looks like this:

// Raw reading to physical unit (Logical Bit)
// Threshold is the midpoint between 562.5µs and 1687.5µs
const int SPACE_THRESHOLD_US = 1125; 

int raw_space_duration = pulseIn(IR_PIN, HIGH);
int decoded_bit = (raw_space_duration > SPACE_THRESHOLD_US) ? 1 : 0;

Interference, Debugging, and Protocol Selection

When an IR sensor remote control setup fails, it is almost never a wiring issue; it is an environmental interference or protocol mismatch issue. Modern environments are hostile to 38kHz IR receivers. Here are the primary interference sources and how to defeat them:

1. Direct Sunlight (DC Saturation): The sun emits massive amounts of broadband infrared. If sunlight hits the photodiode directly, it saturates the internal AGC amplifier. The receiver 'blinds' itself and outputs a constant HIGH or erratic noise. Fix: Use a receiver with a built-in metal shield (like the TSOP4838) or add a physical dark-red optical bandpass filter over the epoxy lens.
2. CFL and Cheap LED Bulbs (AC Flicker): Many dimmable LED drivers and CFL ballasts use Pulse Width Modulation (PWM) to regulate brightness. If the driver's switching frequency or its harmonics overlap the 38kHz bandpass filter, the receiver will interpret the light flicker as a valid remote signal, causing 'ghost' commands. Fix: Keep the receiver at least 1 meter away from LED fixtures, or switch to a 56kHz carrier system if designing a custom remote.
3. Protocol Mismatches: Assuming every remote uses the NEC protocol is a classic beginner trap. If your code decodes NEC but the remote uses RC5 or Sony SIRC, the raw timings will be completely misaligned.

For a comprehensive breakdown of protocol bit-streams and timing diagrams, the SB Projects IR Knowledge Base remains the definitive reference for embedded engineers. When debugging a new, unknown remote, always write a raw 'sniffer' sketch first that simply prints the microsecond durations of every HIGH and LOW state to the serial monitor. Once you map the header burst and bit spacings, you can identify the protocol and apply the correct decoding math.