Fact-checked by Grok 2 weeks ago

RC-5

RC-5 is an () communication protocol developed by in for use in such as televisions and VCRs. It employs bi-phase () encoding with a 36 kHz carrier frequency to transmit 14-bit messages, enabling reliable short-range wireless control of devices. The protocol's message structure includes two start bits (always logic 1), a toggle bit that inverts with each button press to distinguish repeated commands, five address bits for device selection (supporting up to 32 unique systems), and six command bits for up to 64 functions per device. Each bit has a duration of approximately 1.778 ms, resulting in a full message length of about 25 ms, with repetitions every 114 ms if a key is held. Philips predefined standard addresses (e.g., 0x00 for TV, 0x05 for VCR) and commands (e.g., 0x0C for power on/off, 0x35 for play) to ensure interoperability across its product line and compatible third-party devices. Widely adopted by European and North American manufacturers in the 1980s and 1990s, RC-5 became a for audio-visual equipment due to its simplicity and low cost, powering remotes for TVs, stereos, and set-top boxes. A variant called RC-5X reuses the second start bit as an inverted extension for a 7th command bit, supporting up to 128 commands in the same 14-bit format while maintaining . Despite the rise of more advanced protocols like RC-6 and proprietary RF-based systems, RC-5 remains in use for legacy devices and hobbyist projects owing to the availability of inexpensive compatible remotes. Its enduring legacy is evident in libraries and receiver implementations from manufacturers like Microchip and .

History and Development

Origins

The RC-5 protocol was developed by Electronics in the in 1982 as a semi-proprietary primarily intended for devices such as televisions and video cassette recorders. It was first introduced with the Philips K12Z television in 1981/82. This development occurred within Philips' consumer electronics division, though specific inventors or team members have not been publicly detailed in available technical literature. The protocol's design aimed to establish a standardized, efficient method for infrared signaling tailored to Philips products, offering a European alternative to the protocol, which dominated among Japanese manufacturers for similar applications. The initial purpose of RC-5 was to enable reliable, low-complexity remote operation across Philips' lineup of home entertainment equipment, addressing the growing demand for wireless control in the consumer market without requiring extensive proprietary hardware modifications. By employing bi-phase encoding on a 36 kHz carrier, it provided robustness against interference while supporting up to 2048 unique command combinations, sufficient for the era's device functionalities. First public documentation of the RC-5 protocol emerged in mid-1980s Philips technical papers, including a detailed description titled "Description About The RC-5 Universal Infra-Red Remote-Control System" dated June 19, 1985, which outlined its structure and implementation guidelines for internal and partner use. This marked the protocol's formal introduction as a within ' ecosystem, laying the groundwork for its broader European integration.

Adoption

Following its development by in 1982, the RC-5 protocol was rapidly integrated into the company's consumer electronics lineup, including televisions, VCRs, and audio equipment, by the mid-1980s. This internal adoption leveraged the protocol's simple bi-phase encoding to enable reliable communication for basic command transmission in home entertainment systems. Philips licensed RC-5 to other European manufacturers, fostering broad compatibility across devices. This proliferation established RC-5 as a in , where it powered a majority of remotes in televisions and related appliances during the late and . In contrast, the NEC protocol prevailed in , driven by adoption among Japanese electronics firms like and , while RC-5 faced limited uptake in the broader U.S. market amid competition from proprietary standards. By the 1990s, RC-5 evolved into a key component of controls, which incorporated support for the protocol alongside others like and SIRC to allow single-handset operation of multi-brand setups. These devices capitalized on RC-5's addressable structure—supporting 32 system addresses and 64 commands each—to simplify in increasingly complex home theaters. Post-2000s, new RC-5 implementations waned as (RF) and technologies offered greater range, multi-device pairing, and integration with smart home ecosystems, reducing reliance on line-of-sight . Nonetheless, RC-5 remains prevalent in legacy televisions, audio systems, and compatible universal remotes as of 2025, ensuring ongoing support for older equipment.

Protocol Fundamentals

Signal Characteristics

The RC-5 protocol utilizes transmission with a standard carrier frequency of 36 kHz to modulate the signal, enabling reliable communication over short distances typical of applications. Some implementations employ slight variations, such as 38 kHz or 40 kHz, to align with common receiver sensitivities and improve compatibility across devices. The signal is modulated using on the carrier, where bursts of the carrier occur during the "1" states of the bi-phase encoding scheme, with a of 25% or 33% during active bursts to optimize transmitter power efficiency. The carrier is modulated as a square wave during these bursts, ensuring consistent detection by receivers designed for such patterns. The emission is generated by light-emitting diodes (LEDs) with a peak of 940 , which falls within the near-infrared spectrum and minimizes visible light interference while maximizing transmission efficiency. Each bit duration measures 1.778 ms, equivalent to 64 cycles of the 36 kHz carrier and corresponding to a bit rate of approximately 562.5 bits per second; this timing derives from scaling the carrier period such that a half-bit aligns with 32 cycles for precise bi-phase transitions. For a standard 14-bit message, the total transmission duration is approximately 24.889 ms. When a key is held continuously, the message repeats every 113.778 ms to sustain the command without redundant processing.

Bit Encoding

The RC-5 protocol employs Manchester encoding, also known as bi-phase coding, to represent in a self-clocking manner that ensures reliable transmission over signals. In this scheme, each bit is encoded with a mandatory transition at the midpoint of the bit period, distinguishing it from other line codes by embedding clock information directly within the data stream. A logic 0 is represented by a low-to-high transition at the center of the bit period, while a logic 1 is represented by a high-to-low transition. The bit period in RC-5 is fixed at approximately 1.778 milliseconds, corresponding to a bit rate of about 562.5 bits per second, with the transition occurring precisely at t = \frac{\text{bit_time}}{2}. This timing is derived from a half-bit duration of 889 microseconds, during which the carrier is either on or off depending on the logic level. The encoding modulates a 36 kHz infrared carrier, where the presence of the carrier (a "pulse") typically inverts the signal polarity at the receiver, resulting in low voltage for carrier-on and high for carrier-off. For a logic 1, the carrier is off in the first half and on in the second half, producing a high-to-low transition; conversely, a logic 0 has the carrier on first and off second, yielding low-to-high. Synchronization in RC-5 relies on the inherent transitions of the Manchester code, eliminating the need for a separate synchronization pulse and allowing the receiver to extract the clock from the data edges. The message frame begins with two start bits, both encoded as logic 1s, which generate two consecutive high-to-low transitions to alert the receiver and establish initial timing alignment. These start bits ensure frame detection without additional overhead, as the bi-phase nature prevents long runs of identical levels that could cause clock drift. Following the start bits is the toggle bit, which is inverted with each new key press on the to differentiate between initial commands and repetitions from a held button. If the key remains pressed, the toggle bit retains its value in subsequent transmissions (repeated every approximately 114 milliseconds), enabling the to ignore duplicates while processing changes. This mechanism provides basic repeat detection without complex error-checking logic. Error detection in RC-5 bit encoding stems from the properties of Manchester coding, which maintains a balanced signal with no direct current (DC) component, reducing susceptibility to baseline wander and noise-induced errors. However, the protocol includes no cyclic redundancy check (CRC) or parity bits; reliability depends on the receiver's precise timing recovery from mid-bit transitions and tolerance for minor variations in pulse widths (typically 640–1140 microseconds per half-bit). Receivers often implement fault detection by monitoring for expected edge arrivals within 1.25 bit periods or by validating the start sequence after idle periods exceeding 88 milliseconds.

Message Format

Standard RC-5 Structure

The standard RC-5 message format consists of a fixed 14-bit codeword, transmitted most significant bit (MSB) first. The bits are structured as follows: bits 13 and 12 serve as start bits, both always set to logical 1 to synchronize the receiver; bit 11 is the toggle bit, which inverts its value with each new button press; bits 10 through 6 encode the 5-bit system address, supporting values from 0 to 31; and bits 5 through 0 encode the 6-bit command, supporting values from 0 to 63. These bits are encoded using bi-phase (Manchester) modulation before transmission. For repeated transmissions of the same command—such as during a button hold—the toggle bit remains unchanged across frames, which are sent at approximately 114 ms intervals, allowing the receiver to detect sustained presses without redundant processing. The toggle bit inverts only upon a new or different command press, enabling the receiver to distinguish between initial and repeated actions. This format limits the to 32 possible and 64 commands per system, yielding a total of 2048 unique codes. For instance, a TV power-on command might use system address 0 (binary 00000) and command 12 (binary 001100) with toggle bit 1, resulting in the full codeword binary 11100000001100. All devices supporting the RC-5X extension maintain full with this standard 14-bit format, ensuring with original RC-5 remotes.

RC-5X Extension

The RC-5X protocol represents an extension of the original RC-5 standard, developed by to accommodate devices requiring more than the commands supported by the base protocol's 6-bit command field, such as early DVD players and other advanced . Introduced in the late , it maintains the core bi-phase () encoding and 36 kHz carrier frequency of RC-5 while enhancing capacity without necessitating entirely new hardware designs. In terms of structure, RC-5X reassigns the second start bit () of the standard 14-bit RC-5 frame as the 7th command bit, effectively providing 7 bits for commands while preserving the single start bit, toggle bit, and 5-bit address fields. To enable detection of this extension by receivers, the duration of the second start bit position is stretched to two bit times (approximately 3.556 ms, compared to the standard 1.778 ms per bit), resulting in a total transmission length equivalent to 15 bit times. This modification allows RC-5X-capable decoders to recognize the extended format through the prolonged pulse in the S2 position, while the actual data bits follow the standard Manchester coding where a logical 1 is a high-to-low transition and a logical 0 is a low-to-high transition at the bit's midpoint. This extension expands the command space to 128 unique codes per address (2^7), doubling the capacity of standard RC-5 and enabling finer control granularity for complex devices. The first 64 commands (values 0–63) remain identical to those in the base protocol, ensuring seamless ; the additional commands occupy values 64–127, with the 7th bit derived by inverting the value placed in the S2 position to avoid confusion with standard start bits. Backward compatibility is a key design feature: receivers not equipped for RC-5X interpret the stretched S2 as either an additional start bit or extraneous data and process only the first 14 bits as a standard RC-5 message, successfully handling the lower 64 commands without error. Transmitters supporting both modes can dynamically fall back to the original RC-5 format for broader device support, typically by omitting the extension and using a single start bit. This dual-mode capability minimizes disruption in mixed environments. RC-5X found primary adoption in set-top boxes, DVD players, and high-end equipment starting around 2000, where the need for expanded command sets—such as navigation, chapter selection, and playback modes—outstripped the limits of the original protocol. Its use declined with the rise of more feature-rich successors like RC-6, but it remains implemented in legacy and compatible systems for reliable, low-overhead control. The extended transmission time for an RC-5X message is approximately 26.67 ms (15 bit times at 1.778 ms each), compared to 24.892 ms for standard RC-5, with repeats occurring every 114 ms while a key is held to prevent inadvertent multiple activations. This slight increase in duration supports the added functionality without significantly impacting responsiveness in typical scenarios.

Addressing and Commands

System Address Allocation

The RC-5 protocol utilizes a 5-bit system address field within its message structure to specify the target device type, supporting 32 possible addresses ranging from 0 to 31. This allocation allows for selective control of multiple devices in a home entertainment setup, such as televisions, VCRs, and audio components, without interference. The standard assignment of these addresses was established by in the early 1990s to promote among . The following table outlines the standard device type assignments based on the Philips specification:
Decimal AddressHex AddressDevice Type
00x00TV1
10x01TV2
20x02Teletext
30x03Video
40x04LV1 (LaserVision)
50x05VCR1
60x06VCR2
70x07Experimental
80x08Satellite 1
90x09Camera
100x0ASatellite 2
110x0BUnspecified
120x0CCDV (CD Video)
130x0DCamcorder
140x0EUnspecified
150x0FUnspecified
160x10Pre-amplifier
170x11Tuner
180x12Recorder 1
190x13Pre-amplifier 2
200x14CD Player
210x15Phone
220x16Satellite A
230x17Recorder 2
240x18Unspecified
250x19Unspecified
260x1ACDR (CD Recorder)
270x1BUnspecified
280x1CUnspecified
290x1DLighting
300x1ELighting
310x1FUnspecified
This allocation leaves several addresses unspecified, including 11, 14, 15, , 25, 27, 28, and 31, providing room for future expansions or proprietary uses. The original 1992 Philips standard predates widespread DVD adoption, so no dedicated address was assigned for DVD players; later implementations often repurpose address or employ custom addresses for them. Post-2000 device analyses indicate extensions such as address 25 for satellite receivers and for cable boxes in some systems. Manufacturer variations exist, with typically reserving addresses 0–15 for core devices like TVs and VCRs, while other vendors utilize higher addresses (16–31) for proprietary equipment such as auxiliary inputs or specialized recorders. Conflicts are rare due to the protocol's design, but universal remotes often map multiple device types to a single address, such as 16 for functions, to simplify programming. For optimal setup, address 0 is recommended for the primary TV, with careful selection to avoid overlaps in multi-device environments, ensuring reliable command routing.

Command Code Structure

The RC-5 employs a 6-bit within its 14-bit message structure, enabling 64 distinct commands numbered from 0 to 63, which are executed based on the associated system address to control device-specific functions. These commands are largely standardized by to promote among compatible , with many core operations—such as power control, volume adjustment, and channel selection—shared across device categories like televisions and VCRs, while playback and recording functions are tailored to video recorders. Command 0 typically serves no function or acts as a null operation, ensuring a baseline for unused codes. Representative standard commands include power toggling or standby (command 12), which is common across TV, VCR, and satellite systems to switch devices on or off; the protocol's toggle bit (the control bit in the message) facilitates distinction between on and off states in some implementations by alternating on each press. Volume control uses command 16 for increase and 17 for decrease, applicable to audio functions in TVs and VCRs. For televisions, channel or program selection employs commands 32 (up) and 33 (down), while numeric input is handled by commands 0 through 9 for digits and 10 for special modes like step page or double-digit entry. In VCR systems, transport controls are assigned to command 50 (rewind), 53 (play), 54 (stop), and 55 (record), providing essential playback management. Mute or demute is standardized as command 13 across multiple categories. The RC-5X extension modifies the by reassigning the second start bit as an inverted 7th command bit, expanding the command space to 128 values (0-127) while preserving with the original 64 commands when the extension bit is zero. This allows for additional functionality in later devices, particularly for advanced features like menu navigation, operations, and DVD-specific controls such as chapter skipping, selection (often in the 64-127 ), and subtitle toggling. For instance, higher commands enable interactions not covered in the base , including display adjustments and system status queries. However, the original 1992 command allocations primarily addressed analog and VCR needs, lacking native support for digital formats like Blu-ray; modern extensions and equivalents are frequently derived from reverse-engineering and compatible devices to accommodate evolving media players.

Implementation and Usage

Encoding and Transmission

The encoding and transmission of RC-5 signals involve generating a modulated using a microcontroller-driven circuit to emit pulses from an IR LED. The process begins with preparing the 14-bit message word, which includes start bits, a toggle bit, , and command fields, followed by Manchester encoding where each bit features a in the middle of its 1.778 ms duration—rising for logic 1 and falling for logic 0. The is modulated at 36 kHz during the "high" periods of the Manchester signal, with a typical producing bursts of approximately 889 µs per half-bit. For the hardware, a basic transmitter circuit uses an IR LED (e.g., 940 nm ) connected in series with a current-limiting , typically 100 Ω to limit peak current to around 50 mA when driven from a 5 V supply, and buffered by a such as an NPN (e.g., ) to handle the LED's forward of about 1.5 V. The base is driven via a 10 kΩ from a GPIO pin, ensuring the LED emits modulated IR pulses without overloading the MCU output. This setup allows for reliable short-range transmission while minimizing power consumption. Microcontroller implementation relies on timers to generate the precise timings: one timer (e.g., TIM2 on STM8L10x) produces the 36 kHz carrier via PWM, while another (e.g., TIM3) handles the 889 µs interrupts for Manchester transitions, either through bit-banging on a GPIO or dedicated PWM modulation. Bit-banging involves toggling the carrier enable signal mid-bit, whereas PWM can directly shape the envelope for efficiency on resource-constrained devices. In software, the flow starts by loading the 14-bit word into a , then iterating through each bit to encode the Manchester pattern—modulating the carrier for the first half-bit and switching the transition while keeping the total bit time fixed at 1.778 ms. The full frame transmission takes about 24.9 ms, after which an idle period follows before any repeats. Repeat handling ensures continuous transmission while a key is held: the initial message is sent once, followed by repeats every 114 ms without inverting the toggle bit, maintaining the same logical level to signal sustained input. The of RC-5 transmission is typically 5-10 meters in line-of-sight conditions, though it can be reduced by ambient interference from sources like or fluorescent lamps, which introduce noise in the 940 nm band. As of 2025, open-source libraries such as simplify encoding and transmission by providing functions like sendRC5() to handle Manchester modulation and generation on platforms like , supporting direct integration with GPIO or peripherals.

Decoding and Reception

Decoding RC-5 signals begins with an receiver module, such as the TSOP382 series from Vishay, which incorporates a PIN , , and demodulator tuned to the 36 kHz . These modules output a digital bi-phase stream by detecting modulated bursts and suppressing the carrier, producing active-low pulses corresponding to the Manchester-encoded . The output waveform consists of low pulses during bursts and high levels during absences, enabling direct interfacing with microcontrollers for further processing. Timing extraction relies on to interpret the Manchester coding, where each bit spans 1.778 ms, divided into two halves of 0.889 ms. A logic '0' features a low in the first half followed by a high level in the second half, while a '1' has a high level in the first half followed by a low . Decoding typically relies on detecting mid-bit transitions (low-to-high for '0', high-to-low for '1') with timing tolerances of ±25% to ensure reliability. The protocol's start sequence—two leading '1' bits—manifests as two initial high-to-low transitions after idle high, providing without a separate clock. A processes the signal, typically implemented in , to detect the start transitions, shift in the 12 bits (address, command, and toggle), and validate the toggle bit for repeat detection. States track idle, start validation, bit midpoints, and message completion; for instance, entering a 'mid-1' state on a low-to-high transition mid-bit captures a '1', while high-to-low captures a '0', with the machine resetting on invalid sequences. Error handling discards signals with timings deviating by more than 10-25%, ignoring noise-induced glitches, and debounces repeated messages (transmitted every ~114 ms) by checking the toggle bit flip only on new presses. Microcontroller implementations often use interrupt-driven sampling at rates like 100 kHz to capture edges precisely, minimizing CPU overhead; libraries such as Arduino-IRremote automate this, handling RC-5X extensions (e.g., longer messages) via auto-detection of bit patterns. Challenges include ambient from or fluorescent lights, which can mimic bursts, but integrated AGC and bandpass filters in receivers like TSOP382 suppress such noise, enabling robust operation in varied environments.

References

  1. [1]
    Philips TV Remote Controls, 1955-1985 - Quick Navigation
    RC5, the "world standard" remote control, 1982. The K12 chassis and its infrared RC4 remote control can be considered to be a major success, essentially ...
  2. [2]
    IR - Philips RC-5 Protocol - SB-Projects
    The Philips RC-5 protocol is widely used, with 5-bit address, 6-bit command, 36kHz carrier, bi-phase coding, and 1.778ms bit time. It uses 14 bits per message.
  3. [3]
    [PDF] RC5 IR Remote Control Receiver on tinyAVR and megaAVR devices
    The RC5 code is a 14-bit word bi-phase coded signal as seen in the figure below. The first two bits are start bits, always having the value “1”. The next bit is ...
  4. [4]
    [PDF] AN3174 Application note - STMicroelectronics
    Feb 1, 2012 · Example of software implementation is provided for RC5 and SIRC protocols, other protocols are supported and available upon request (for ...<|control11|><|separator|>
  5. [5]
    [PDF] Implemening the Infrared RC-5 Decoder on MC9RS08KA2
    RC-5 Coding Summary. Several standards exist for IR wireless communication for remote control applications. The widely used coding scheme is RC-5 from Philips.
  6. [6]
    [PDF] an2957-implementing-an-rc5-infrared-transmitter-using-the-ir-timer ...
    Apr 23, 2009 · The RC5 coding scheme from Philips is a standard in infrared wireless command transmission. The RC5 coding scheme can generate 2048 different ...
  7. [7]
    US20090028568A1 - Multi-protocol infrared receiver - Google Patents
    Each receiver channel is capable of receiving and decoding a particular CIR remote control protocol, such as an RC-5, RC-6 or NEC protocol. The host system ...
  8. [8]
  9. [9]
    RC-5 Protocol Overview & Details | PDF | Electronics - Scribd
    The RC-5 protocol was developed by Philips in the 1980s as a consumer infrared remote control protocol. It was adopted by many European and US manufacturers. ...
  10. [10]
    Understanding the Basics of Infrared Communications - DigiKey
    Jan 6, 2021 · The RC5 (Philips) protocol​​ Unlike the NEC protocol, Philips decided to utilize a Manchester encoding to distinguish between the logical bits in ...Missing: adoption | Show results with:adoption
  11. [11]
    A Multi-Protocol Infrared Remote Library for the Arduino
    ... protocol from the Phillips RC-5 Protocol page you reference above. @edward ... They're both manufactured by Thomson. Here's a dump of the TVs Vol+ ...
  12. [12]
    [PDF] HomeSpy: The Invisible Sniffer of Infrared Remote Control of Smart ...
    Aug 11, 2023 · The carrier frequency is different for different CIR protocol: e.g., NEC uses 38 kHz, Sony uses 40 kHz and RC-5 uses 36 kHz. As shown in Fig.8 ...
  13. [13]
    Remote Control Setups for Multi-room Systems - Crutchfield
    An RF remote is a great solution for folks who want to set up additional listening or viewing areas that are within 50-100 feet of their main system.
  14. [14]
    RC5 - What is it and what is it used for? - Botland.store
    Rating 5.0 (1) Sep 24, 2024 · RC5 is a wireless protocol for remote control of electronics using infrared, mainly used in universal remote controls for devices like TVs and ...
  15. [15]
    [PDF] TSAL6100 High Power Infrared Emitting Diode, 940 nm, GaAlAs, MQW
    FEATURES. • Package type: leaded. • Package form: T-1¾. • Dimensions (in mm): Ø 5. • Peak wavelength: λp = 940 nm. • High reliability. • High radiant power.
  16. [16]
    The Philips RC5 IR Remote Control Protocol - PCB Heaven
    Jul 30, 2012 · If for example you press the button "1" button and you keep it pressed, the remote control sends the RC5 protocol with 100mSec repetition ...Missing: patent | Show results with:patent
  17. [17]
    3. Remote Controller Protocols and Scancodes
    This is done to keep it compatible with plain rc-5 where there are two start bits. 3.2. rc-5-sz (RC_PROTO_RC5_SZ)¶. This is much like rc-5 but one bit longer.Missing: backward | Show results with:backward
  18. [18]
    None
    ### Extracted RC-5 Command Codes
  19. [19]
    IR Communication - SparkFun Learn
    4.4 583 · Free delivery over $100 · 30-day returnsThe current limiting resistor attached to the LED can have values down to 100Ω (40mA) for full power and longest range. If you use a larger value resistor, the ...
  20. [20]
  21. [21]
    IRremote | Arduino Documentation
    Sep 5, 2025 · Send and receive infrared signals with multiple protocols. Currently included protocols: Denon / Sharp, JVC, LG / LG2, NEC / Onkyo / Apple, Panasonic / ...
  22. [22]
    [PDF] TSOP382.., TSOP384.. IR Receiver Modules for Remote ... - Vishay
    This IR receiver series is optimized for long burst remote control systems in different environments. The customer can chose between different IC settings (AGC ...Missing: protocol | Show results with:protocol
  23. [23]
    An Efficient Algorithm for Decoding RC5 Remote Control Signals
    RC5 is an encoding standard used in infrared remote control signal transmission. RC5 was originally developed by Phillips, and uses Manchester encoding , a ...Rc5 · Decoding Example · Sample Code
  24. [24]
    RC-5 Decoder Software - SB-Projects
    Six bits of IR_SHIFT are the main part of the command. RC-5X uses the inverted bit 4 of IR_SHIFT+1 as the 7th command bit, so we have to add that to the command ...
  25. [25]
    Infrared remote library for Arduino: send and receive ... - GitHub
    Send function for Marantz version of the RC5x protocol. This protocol has an additional 6 bit command extension and adds a short pause after the address is sent ...