How Infrared Remote Controls Work: Modulation, Carrier Frequency, and Timing
Table of Contents
- What IR Communication Actually Is
- Why IR Uses a Carrier Frequency
- How Modulation Works
- The IR Receiver
- NEC Protocol in Detail
- Other Protocols
- Why IR Has No Security
- BLEShark Nano and IR
- Shiver Mesh: Distributed IR
What IR Communication Actually Is
Infrared is light. Specifically, it's electromagnetic radiation at wavelengths just beyond the red end of the visible spectrum - typically around 940nm for consumer remote controls. Your eyes can't see it, but smartphone cameras often can (point a TV remote at your phone's camera and press a button - you'll see the LED flash).
graph LR
subgraph NEC["NEC Protocol Frame"]
AGC["AGC Burst
9ms mark
4.5ms space"] --> ADDR["Address
8 bits"]
ADDR --> ADDR_INV["Address Inverse
8 bits"]
ADDR_INV --> CMD["Command
8 bits"]
CMD --> CMD_INV["Command Inverse
8 bits"]
CMD_INV --> STOP["Stop Bit
562us mark"]
end
subgraph ENCODING["Bit Encoding"]
ZERO["Logic 0:
562us mark
562us space"]
ONE["Logic 1:
562us mark
1687us space"]
end
NEC protocol frame structure - the 9ms AGC burst lets the receiver adjust its gain, followed by 32 bits of address and command data with inverse bytes for error checking
IR communication between remotes and receivers is one-way. The remote transmits; the receiver listens. There's no acknowledgment, no bidirectional negotiation, no connection setup. The transmitter fires photons at a target and hopes they arrive. This simplicity is what makes IR cheap and universal, and also what makes it completely insecure.
IR requires line-of-sight in practical terms, although reflections off walls and ceilings can extend range indirectly. The useful range for most consumer remotes is 5-10 meters. Beyond that, the signal attenuates enough that the receiver misses pulses and commands fail.
The emitter in a TV remote is typically a single IR LED, usually rated at 940nm. Some remotes use two or three LEDs for wider angle coverage. The receiver on your TV is a packaged module - a photodiode, a bandpass amplifier, and a demodulator all in one small component.
Why IR Uses a Carrier Frequency
If you shone a plain IR LED at an IR receiver, the receiver would reject it. The signal wouldn't get through. This seems counterintuitive - the receiver detects IR, you're sending IR, why doesn't it work?
The answer is noise rejection. The world is full of IR light. Sunlight is rich in IR. Incandescent bulbs emit IR as waste heat. Fluorescent and LED lights emit some IR. All of this is ambient noise to an IR receiver, and it's mostly constant or very low frequency - essentially DC from the receiver's perspective.
To distinguish intentional signals from ambient noise, IR remotes don't send raw DC light. They modulate the data signal onto a carrier frequency - typically 38kHz, though 36kHz, 40kHz, and 56kHz are also used by different manufacturers. The IR LED pulses at 38,000 times per second when transmitting a "mark" (a 1 in the communication sense).
The receiver has a bandpass filter tuned to 38kHz. Ambient IR noise at DC or audio frequencies gets filtered out. Only 38kHz modulated signals pass through. This is the same principle used in radio receivers - you tune to a frequency to reject everything else.
The result is a receiver that can cleanly detect intentional IR signals even in a brightly lit room, and ignores all the IR noise that would otherwise make the signal unusable.
graph LR
subgraph TX["Transmitter"]
DATA["Data bits
marks and spaces"] --> MOD["Modulator
38kHz carrier"]
MOD --> LED["IR LED
940nm"]
end
subgraph CHANNEL["Channel"]
LOS["Line-of-sight
IR light"]
end
subgraph RX["Receiver"]
DET["IR Photodetector
38kHz bandpass filter"] --> DEMOD["Demodulator
strips carrier"]
DEMOD --> LOGIC["Logic output
recovered data bits"]
LOGIC --> MCU["Microcontroller
decodes protocol"]
end
LED --> LOS
LOS --> DET
IR remote control signal path - data is modulated onto a 38kHz carrier for noise immunity, transmitted as infrared light, and demodulated by the receiver back to logic-level data
How Modulation Works
The IR communication scheme is a two-layer system. There's the carrier (38kHz), and there's the data signal modulated onto that carrier.
The terminology used in IR protocols comes from radio: a "mark" is a period where the carrier is active (the IR LED is pulsing at 38kHz), and a "space" is a period where the carrier is inactive (the IR LED is dark). Marks and spaces of different durations encode the binary data of the command being sent.
From the LED's perspective: during a mark, the LED switches on and off 38,000 times per second. During a space, the LED is off. The data is encoded in the timing of these marks and spaces, not in the raw IR level.
From the receiver's perspective: the TSOP-style receiver demodulates the 38kHz carrier and outputs a clean logic signal. When it sees 38kHz modulated IR, its output goes low (active low convention). When it sees no signal, its output stays high. The microcontroller reading this receiver sees a clean digital signal representing marks (low) and spaces (high), with the carrier frequency stripped away.
The IR Receiver
The TSOP series (Vishay) is the archetypal IR receiver component, though many manufacturers make equivalent parts. A TSOP1738 or similar component integrates three things in a 3-pin package: a photodiode that's sensitive to 940nm IR, an amplifier with automatic gain control, and a bandpass demodulator tuned to the carrier frequency (38kHz for the TSOP1738).
The output is a clean digital signal. When the receiver detects 38kHz modulated IR, the output pin goes low. When there's no signal or the signal stops, the output returns high. A microcontroller or dedicated IR decoder IC can read this digital output and measure the timing of mark/space transitions to decode the protocol.
The automatic gain control in TSOP-style receivers compensates for varying signal strength - so a remote at 1 meter and a remote at 5 meters produce roughly similar output signals, making the timing measurements consistent regardless of distance.
NEC Protocol in Detail
The NEC protocol is one of the most widely used IR protocols. It was developed by NEC Corporation and is used in countless TV remotes, set-top boxes, and other consumer electronics. Understanding it in detail gives you a clear picture of how IR protocols work in general.
An NEC frame starts with a leading burst: 9ms of mark (IR carrier active) followed by 4.5ms of space (IR carrier off). This preamble is the "start code" that tells the receiver a transmission is beginning. Its duration distinguishes it from a data bit - no data bit uses timing anywhere near 9ms.
After the preamble, the frame carries 32 bits of data in four 8-bit bytes:
- 8-bit device address
- 8-bit inverted device address (bitwise complement of the first byte)
- 8-bit command
- 8-bit inverted command (bitwise complement of the command byte)
The inverted bytes are for error detection. If the address and its inverse don't sum to 0xFF, the receiver knows something went wrong and discards the frame.
Individual bits are encoded using pulse-distance modulation. Every bit starts with a 562.5 microsecond mark. What follows determines the bit value:
- Logical 0: 562.5us mark + 562.5us space (total ~1.125ms)
- Logical 1: 562.5us mark + 1687.5us space (total ~2.25ms)
The mark duration is constant; the space duration varies. This makes it easy to decode: measure the total pulse period (mark + space), and you can determine the bit value without needing perfectly accurate timing.
A complete 32-bit NEC frame takes approximately 67.5ms to transmit. After the frame, a 562.5us final mark terminates the transmission. If the button is held down, NEC sends a repeat code instead of the full frame: 9ms mark, 2.25ms space, 562.5us mark.
Other Protocols
RC5 (Philips): Uses Manchester encoding rather than pulse-distance modulation. Every bit is the same duration (1.778ms), and the bit value is encoded in the transition direction: low-to-high = 1, high-to-low = 0. RC5 uses a 36kHz carrier and a 14-bit frame structure. It's less common now but was widely used in Philips and European electronics.
Sony SIRC: Uses pulse-width modulation with a 40kHz carrier. Marks vary in duration to encode bits: 600us mark = 0, 1200us mark = 1. Spaces are constant at 600us. SIRC comes in 12-bit, 15-bit, and 20-bit variants depending on the device. Sony remote controls have used this protocol for decades.
Samsung: Uses a protocol structurally similar to NEC but with different preamble timing - 4.5ms leading burst rather than NEC's 9ms, and slightly different bit timing. Samsung TVs and appliances use this variant, which is why a universal remote programmed for NEC won't work on a Samsung without specific Samsung codes.
Many devices use manufacturer-specific protocols or extended versions of these standards. The diversity is why universal remotes require code libraries, and why capture-then-replay is more reliable than protocol guessing.
Why IR Has No Security
IR has no authentication, no encryption, no handshake, and no device pairing. The protocol is entirely open: if you know the signal format, you can replay any command to any device.
This was a deliberate design choice. IR remotes need to be interoperable. If you lose a remote, a universal replacement should work. If a remote breaks, a spare from a similar device should work. Adding authentication would make this impossible without a registration infrastructure that doesn't exist for consumer electronics.
The practical consequence: capturing an IR signal is equivalent to owning the command. Record the IR transmission for "power off" on a specific TV, replay it, and the TV turns off. No pairing required. No authentication. The captured signal is the credential, and it never expires.
This extends to every IR-controlled device: TVs, air conditioners, projectors, audio receivers, set-top boxes, smart home IR bridges. Anything that accepts IR commands accepts them from any source that sends the right signal.
BLEShark Nano and IR
The BLEShark Nano includes full IR transmit and receive capability. This covers four main use cases:
Receive and decode: The BLEShark Nano can receive IR signals and decode them by protocol (NEC, RC5, Sony SIRC, Samsung, and others) or capture raw timing data for protocols it doesn't recognize. Raw capture stores the mark/space timing sequence for later replay without needing to understand the protocol structure.
Transmit stored codes: Captured or manually entered codes can be saved and replayed. The device stores IR codes in a remote library - up to 5 remotes with up to 8 buttons each. You can build a custom IR library of codes from multiple devices and access them from the BLEShark Nano's interface without carrying the original remotes.
TV-B-Gone: The BLEShark Nano includes a TV-B-Gone implementation - a brute-force power-off sequence that cycles through power codes for hundreds of TV brands in sequence. It's useful for AV/IT environments where you need to shut down displays without hunting for the right remote, and it's a classic IR demonstration of what capture-and-replay makes possible.
Custom IR transmission: Beyond the remote library, the BLEShark Nano can transmit arbitrary IR codes - useful for testing, for devices not in the library, or for research into IR protocol behavior.
Shiver Mesh: Distributed IR
Shiver is BLEShark Nano's mesh networking protocol. Multiple BLEShark Nano devices can form a Shiver mesh, communicating with each other to coordinate actions across physical space.
For IR, this means you can trigger IR transmissions from any node in the mesh remotely. The mesh supports CMD_IR_TVBGONE (trigger TV-B-Gone on a specific node) and CMD_IR_CUSTOM_TX (transmit a specific IR code from a specific node). This enables scenarios where an IR transmitter needs to be physically positioned near a target device while the operator is elsewhere - the operator sends the command through the mesh, the node closest to the target fires the IR.
In a professional AV or facilities management context, Shiver mesh IR nodes can be positioned throughout a venue to control IR-based equipment from a central point without running IR blasters or dealing with line-of-sight constraints from a single location. Each node handles its own line-of-sight requirement to local devices while the mesh handles the communication back to the operator.
The combination of capture-decode-replay and mesh distribution makes BLEShark Nano a practical IR management tool beyond its research applications - though understanding the underlying protocol is what makes it possible to use effectively.
BLEShark Nano is designed for authorized security research, penetration testing, and educational use. Always obtain proper authorization before using IR transmission capabilities in shared spaces or on devices you do not own.