How-to: USB Remote Control Receiver

Now that we listen to MP3s, and watch XVIDs or x264s, a computer is the entertainment center in at least one room of most homes. Unless you have a special HTPC, though, you’re probably stuck using the keyboard to pause, change the volume, and fast-forward through annoying Mythbusters recaps. PC remote control receivers range from ancient serial port designs (who has one?) to USB devices not supported by popular software. In this how-to we design a USB infrared receiver that imitates a common protocol supported by software for Windows, Linux, and Mac. We’ve got a full guide to the protocol plus schematics and a parts list.

Design overview


Remote controls transmit data on an modulated infrared beam. An infrared receiver IC separates the modulated beam into a clean stream of 0s and 1s. The data stream is decoded by a microcontroller and sent to a computer over a USB connection. Software processes the codes and triggers actions on the computer.

Background

Computer infrared receivers

The oldest PC infrared receiver design uses a receiver IC to toggle a serial port pin, usually DCD. This design probably originated on Usenet, and it’s still the most popular on the web: Engadget, Instructables, etc. These aren’t true serial devices because they don’t send data to the PC. Instead, a computer program times pulses on the serial port and demodulates the signal. This is a super simple design, but it depends on direct interrupt access and timing precision that’s no longer available in Windows. Linux or Mac users can try this receiver, if you still have a serial port. We couldn’t get this type of receiver to work with the serial port on a modern Windows XP PC, and don’t expect the precise timing to transfer through a USB->serial converter.

Some more advanced infrared receivers are true serial port devices that measure or decoding infrared signals before sending data to the computer. The UIR/IRMan and UIR2 incorporate a classic PIC 16F84, but don’t provide firmware and/or source code. These devices should work on a modern computer, through a USB->serial converter if necessary. The USBTINY and USBIRBOY are native USB devices, but lack wide support.

Receiver software

Regardless of receiver type, the computer needs a program to listen for incoming remote commands and convert them to actions on the computer. Linux and Mac users have LIRC, which supports a bunch of different receiver types. Windows users are a bit less fortunate. WinLIRC is an abandoned Windows port of LIRC for simple interrupt-based serial port receivers; WinLIRC was last developed in 2003. Girder was originally a freeware PC automation utility, but has become expensive bloatware with a 30 day trial. Fortunately, the last freeware version of Girder (3.2.9b) is still available for download.

Working with IR remote protocols

Decoding IR signals

Remote controls encode commands in the spacing or timing of a 38KHz carrier pulse, [San Bergmans] has an explanation of the principals involved. An infrared receiver IC separates the data stream from the carrier. Our job is to decode the data stream with a microcontroller. There are dozens of remote control protocols, but Phillips’ RC5 is widespread and commonly used by hobbyists.

RC5 is stream of 14 equal length bits of exactly 1.778ms per bit time. A pulse during the first half of the bit time represents 0, a pulse in the second half represents 1. This scheme is called Manchester coding.

We used a logic analyzer to examine the output of a Happauge WinTV remote control, a known RC5 remote. The diagram shows two presses of the 1 button, and two presses of the 2 button; note that the output is inversed and the Manchester coding is backwards from the above description.

The first two bit times are start bits, followed by a toggle bit. The toggle bit inverses each time a button is pressed so the receiver can tell the difference between a hold and a repeated press. The next 5 bits are the address (0b11110=0x1E), followed by the command (0b000001=0x01, 0b000010=0x02). A backwards compatible extension to RC5 uses the second start bit as command bit 7.

Representing remote codes to the computer

Looking at previous designs, we saw three general methods of communicating remote commands to a computer:

  • Protocol specific receivers decode one protocol, and send actual decoded commands to the PC
  • A more general type of receiver measures the timing and spacing of each pulse and sends the full waveform to the PC for analysis.
  • Some receivers create a unique hash for a signal, but don’t actually include enough data to fully recreate the waveform.

While our preference is towards the general hash method, our only remote uses RC5 and it was more interesting to build an RC5 specific decoder. We describe modifications for a more general version in the firmware section.

Computer interface protocol

We didn’t want to write our own receiver software or driver, so we looked for an existing, well established communication protocol to imitate. The UIR/IRMAN/IRA/CTInfra/Hollywood+ type receiver is supported by Girder and LIRC, and uses a simple serial protocol with handshake:

  • The device is initialized by the DTS and DTR pins of the serial port. We don’t have these and don’t care.
  • The computer sends “IR”, with an optional delay. The device replies “OK”. We’ll just send “OK” on every “R”
  • Remote control codes are sent as a unique six byte hash. We’ll decode an RC5 signal and send the actual values, but a generic hash could be used instead.

This protocol is for a serial port device, but our USB receiver will appear as a virtual serial port and the program won’t know the difference.

Hardware

Click here for a full size schematic (png). Our receiver is based on a USB enabled PIC 18F2455 microcontroller, the smaller, cheaper version of the 18F2550. The 18F family is programmable with the hobbyist favorite JDM-style programmers if a diode is used to drop VPP to a safe level. The PIC gets one decoupling capacitor (C1), and a diode (D1) and resistor(R1) on the ICSP programming header. We exposed the serial port on a pin header for debugging or a mixed USB/serial port version using a MAX RS232 transceiver IC.

The USB peripheral requires a 20MHz external clock (Q1, C5,6), and a .220uF capacitor. We faked the capacitor using 2 x .1uF decoupling capacitors (C2,3). A 3mm LED (LED1) and a 330ohm current limiting resistor (R2) show USB connection status.

We used a TSOP-1738 infrared receiver IC which calls for a 4.7uF decoupling capacitor (C4). If you can’t find this particular IC, any receiver listed here should work. The TSOP-1738 output is the inverse of the received signal, it pulls to ground when a pulse is detected, so a pull-up resistor (R3) holds the pin high when no signal is present. Check if you use a different receiver, you may need to use a pull-down resistor and reverse the Manchester decoding routine in the firmware.

The circuit draws power from the USB bus, so we don’t need an additional power supply.

Parts list

Click here for a full size placement diagram (png). The PCB design is 100% through-hole and single sided. The schematic and PCB were made with Cadsoft Eagle, freeware versions are available for most platforms. All the files are included in the project archive (zip).

Part
Description
IC1
C1,2,3
C4
C5,6
27pF capacitor (15pF might be better)
D1
Q1
R1,3
R2
TSOP
TSOP1738 (obsolete, try TSOP1138)
USB
SER
ICSP

Firmware

The firmware is written in C using Microchip’s free demonstration C18 compiler. Firmware and source are included in the project archive (zip).

We used version 2.3 of Microchip’s USB stack to create a USB serial port using the default drivers already available on most systems. The USB stack has simple functions to enumerate the USB device and transfer data between device and host. It only took a few pin changes to get the CDC demonstration working on our custom hardware.

Our implementation of the UIR/IRMAN/IRA/CTInfra/Hollywood+ protocol simply responds to the letter ‘R’ with ‘OK’. This should satisfy the handshake requirements of any implementation of this protocol.

We chose to specifically decode RC5 (and RC5x) because it’s a widely used protocol, and the only type of remote we have to work with. Most of the decoding is done in the interrupt handler:

  • The first signal change triggers an interrupt that starts a 889us (one-half bit period) timer.
  • On each timer interrupt, one-half of a Manchester coded bit is sampled.
  • Every other interrupt the measurements are compared, and the bit value is calculated to be 0, 1, or an error. Errors reset the decoding routing.
  • At the end of each transmission the address and command bytes are decoded, and sent to the host with 4 buffer bytes(0). We discard the toggle bit because it would confuse the PC software into thinking every other press was a unique code. We append the second start bit to the command bit for RC5x compliance; this just adds 0x40 to non RC5x remote codes.

A more general version can be made by removing the Manchester coding step (3), and sending 48 sample bits (all 6 bytes) to the computer.

Installing the USB infrared receiver

Most operating systems already have drivers that support a virtual serial port device like the receiver. Windows XP has the required drivers, but needs help from an .inf file to properly associate them with our device.

Windows will show the new hardware dialog the first time you plug in the receiver. Choose to use a custom driver and point it to the .inf file included in the project archive (zip). This links the device to a driver already included in Windows, and adds the receiver as a COM port. You can check the COM port number in the control panel.

Mac and Linux users can use the receiver with LIRC, but Windows users will be faced with the choice of the old, freeware Girder, or the new, 30-day trial shareware version. We used the freeware version of Girder, but hope you guys can suggest a great, open source alternative that we overlooked.

Regardless of the computer-side control software you use, configure it for a UIR/IRMAN/IRA/CTInfra/Hollywood+ style receiver, and enter the COM port or serial address assigned to it. Our receiver is also compatible with any protocol options like ‘Fast UIR Init’ and ‘Skip UIR Init Check’, which shorten or eliminate the “IR”->”OK” handshake. Now test the receiver and add a remote according to the documentation for your software.

Manual terminal interface and debugging

If you have a problem with the receiver, or you’re just curious, try to interface it from a serial terminal. We really like the serial terminal on Hercules. Set the correct COM port, but the speed and configuration settings are ignored by the USB serial port driver.

A capital ‘R’ will prompt the receiver to reply ‘OK’. RC5 codes are returned as raw bytes, so be sure to set your terminal to show HEX values rather than interpret it as ASCII text. The first byte is the RC5 address byte (0x1E), followed by the command byte (0x41), and then four buffer 0s to comply with the UIR/IRman protocol. The image shows the handshake, and the output of a short press on the 1,2, and 3 buttons.

A free utility called Portmon logs COM port activity for review. This is helpful for spying on existing receiver protocols, and debugging the interaction of our custom hardware and closed/proprietary software. The image shows Girder sending the initialization string ‘IR’ (0x49,0x52), and the receiver reply ‘OK’ (0x4F,0x4B).

Taking it further

Our RC5x compliant receiver follows a widely used interface protocol. There’s a ton of possibilities for additional features in an open source infrared receiver:

  • Support all remotes through a generic hash generator, like the original UIR/IRman hardware.
  • Add additional remote protocol decoders, like RC6.
  • Support multiple, configurable interface protocols.
  • Implement the serial port I/O.
  • Store configuration options in EEPROM, including protocol, interface mode, timing options, serial port, etc.

126 thoughts on “How-to: USB Remote Control Receiver

  1. HS0038A2 has an internal pull-up on OUT pin. Try disconnecting R3 from the circuit. Apart from that, and assuming the code is ok, you would have to check the HS0038 / TSP1738 output waveform with a scope to make sure it is receiving the IR signal, and double-check that the remote you are using transmits using the RC5 protocol.

  2. I have remote for Media Center for my laptop. When running on battery, it works fine, but when plugged into AC power, the IR receiver become flashing and if a key pressed in the remote, the laptop behave strangely (e.g. laptop execute twice, dll). Can anyone help? Thank you

  3. @Jeff:
    IRDA is different from the many media center remote control protocol. Most media remotes modulate a pulsing signal around 40KHz. The way they do it is where you get all the different formats (like RC5). IRDA is more like a bunch of really quick pulses. You will find IRDA in hand held devices like Printers, Palm Pilots and Phones. It’s quick enough to send lots of information like a picture or a document. To do that with a media remote would take forever – if possible. Also, where you can use a remote across the room, you can only go 1 maybe 2 meters using IRDA. That commercial where two people exchange phone number from different train cars is a bunch of phoowie.

  4. Hi…

    Does anyone know where the Eagle ZIP file is for this project? The download from the Mahalo page comes up empty.

    I want to add some stuff and am just starting with Eagle. Thought it would be better to start with something that works (“smoke hasn’t been let out yet :)”).

    -thanks

  5. Thanks st2000 for the advise.
    I have a laptop with no IrDA conn. I intend to build a serial IrDA to do printing thro’ another host PC with IrDA conn. Can you advice me on a suitable circuit for this project?
    Thanks

  6. @Jeff:
    Go to Amazon and use “usb to irda”. You will find a bunch of products ranging from in the $10s to several times that. Not sure why the spread.

    I would suggest not to build one: 1) Where you can find loads of IRASK parts, it is difficult to find IRDA parts. 2) Bluetooth appears to be replacing IRDA. 3) As with Bluetooth, IRDA has several protocols that require hardware and complex software to implement.

  7. @Francirius
    Agreed, please re-post the project’s files. However, in the mean time, Francirius, google for the project’s zip file: “USBIRr.v1a.zip”. I think you will find it here and there on the web. I suggest getting it from multiple sources. Once you’ve hit a match, consider what you have more likely to be the real thing. However, as with everything found on the web, you should take care it is clean.

  8. “We chose to specifically decode RC5 (and RC5x) because it’s a widely used protocol, and the only type of remote we have to work with. Most of the decoding is done in the interrupt handler:

    The first signal change triggers an interrupt that starts a 889us (one-half bit period) timer.
    On each timer interrupt, one-half of a Manchester coded bit is sampled.
    Every other interrupt the measurements are compared, and the bit value is calculated to be 0, 1, or an error. Errors reset the decoding routing.
    At the end of each transmission the address and command bytes are decoded, and sent to the host with 4 buffer bytes(0). We discard the toggle bit because it would confuse the PC software into thinking every other press was a unique code. We append the second start bit to the command bit for RC5x compliance; this just adds 0×40 to non RC5x remote codes.

    A more general version can be made by removing the Manchester coding step (3), and sending 48 sample bits (all 6 bytes) to the computer.”

    someone has done this?
    remove the manchester decoding function and set as irman to decode any remote control?
    thx

  9. Hi Guys,

    Can you help me as I have built curcit the and have plugged it into my PC and am getting USB device not recognized.

    I have tried to install a number of drivers and am getting the same issue as ljudsko I have tried the official driver, the one in the package and the one sugguested by argento all give the same error.

  10. If there’ll be just one person using the tools, you can go for a single-person
    license. However, further analysis shows we can learn
    specific lessons from looking at these tips. Domain searching capabilities
    are built into Jaaxy and it truly will help you find domains that
    are high value and can be resold for much more than you
    buy them for.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.