ElectronicsNerd.com

Expanding on my work with IR Repeaters, I wanted to control my air conditioner from another room without using the existing remote. I was sure that by moving my single remote control from room to room I would soon lose it.

There wasn't much available on the web about a Hampton Bay HBLG1203R, especially its remote control specifications, so I figured I'd just brute-force decode it.

This method is a great way to learn, but sure consumes a lot of time. This is my brain's favorite way of learning, incompatible as it may be with rapid progress. I've come to believe that simply following somebody else's instructions has a way of making myself unable to adapt to any changes to a given environment in the future, especially under pressure. I want to know the location of every bolt, the vagaries of every component, so that the machine becomes flexible in my grasp at any moment, especially under pressure. But I digress.. I did know that it would be easy enough to look at the remote's output on a scope, so that's what I did.



The infrared receiver IC that I used has three leads: +5V, Gnd, and Data. What could be simpler? After hooking the data lead up to my scope and powering the little guy up, I aimed the remote and captured my first trace. What a complicated-looking bunch of square waves... I set out right away measuring each negative-going width until I had filled a sheet of paper. (After stripping the 38KHz carrier, the receiver IC inverts what it sees at the input, so what I was seeing was negative logic.)

There were only a small number of measurement values for the entire message, with a couple of starting pulses that were different from anything else in the transmission. At this point, I had no idea about protocols, so I didn't recognize this for what it was: a common NEC data stream. If you are interested in learning about a few of the most common IR data formats, check out Vishay's Data Formats for IR Control.

In my specimen's case, the 9ms start pulse is followed by a pause of 4.5 ms, and then the goody follows. The goody consists of a 16-bit address. This address corresponds to the air conditioner. Good so far, but there's more goody.

Next comes the command byte, and then the command inverted. Each button on the remote control fires the infrared LED in different patterns that begin with the same "preamble," because each transmission sent by the remote is meant for the same air conditioner unit. This would be easy to recreate with a microcontroller, because I could create a subroutine called preamble: that would fire off everything but the command. Then each desired function could be mapped to a preamble+command block.

Why is there a byte (10000001) followed by that same byte inverted? (01111110)? The answer is error-checking. The NEC protocol is a protocol because it is reliable, and has error-checking built in. This stuff happens really fast, and the data involved are not locked to a clock common to both sender and receiver. Error-checking maintains data reliability. Asynchronous communication can take place because of another reason: a crystal oscillator maintains pretty decent time, and if both sender and receiver timing are based on one, short messages are transmitted faithfully.



In the NEC protocol, the initial start pulse prepares the receiver IC for a data transmission at a particular rate, adjusting its AGC circuitry for the signal level excursions of what is to follow. After the standard 9ms equalization pulse, there's a 4.5ms pause, and the receiver then accepts data at a predefined baud rate. If one weird spike were to occur at a particular moment during the transmission, the air conditioner might turn off instead of lower the setpoint temperature of the unit, without a means for detecting glitches in a transmission. Simple error checking like this provides for disallowing invalid input, while providing near-failsafe transmission of valid control data.

Building It

Now that I had a list of command blocks for each of the six buttons on the hand control, I knew the solution to replicating the signal from working with repeater circuits. Even without knowing I was dealing with an NEC data stream, the intelligence in the command table had to be modulated onto a carrier of 38KHz, and I knew I would do this using the CMOS 4011 as an astable multivibrator at the desired frequency, with a CD4066 as a gate, driven by one of the microcontroller's outputs. The rest was wiring.

A quick reworking of a Forrest M. Mims III-cookbook circuit gave me 38KHz; I eventually added a potentiometer trimpot in place of a fixed resistor to give me frequency-grooming capability, and added an NPN transistor output stage to drive the infrared LED.

Here's the schematic to a similar project, in which RS-232 data controls the firing of the sequences for a Sanyo projector. I'm a little surprised I can't find the original drawing for the air conditioner project, but this one is cool because it's even more advanced. It is currently installed in a large auditorium, interfacing with an AMX control system that I installed and programmed. The IR output goes straight into an IR - RF repeater, and then reaches the projector in the booth. Eventually I think I'll put the signal on a spare pair of wires for reliability, although the system has worked well for a couple of years now. See, radio is witchcraft, and I've learned that it's best to run wires. If, however, you should find that actual gremlins are cutting into your cabling and injecting spurious signals, you have a lot more to worry about than common-mode interference, and I urge you to visit another website to resolve your problems.

You may be wondering how the patterns were stored and how they are triggered. You'll notice a PIC chip in the schematic, and this is the "brains" of the operation. For most small projects, I use the PIC12F683 from Microchip. Why did I use a larger chip in the schematic? I left room for expansion, and the chip only costs $5.44, and it has a lot more pins. It also sports some sophisticated communications and PWM hardware on-board, but the 12F683 would be plenty for this project, and that's what I ended up using in the final build. This microcontroller is available in an 8-DIP package, runs at 5VDC, provides six configurable I/O ports, allows for TTL serial data transmission synchronously or asynchronously, has 128kb flash EEPROM for data, and costs $1.42, last I checked.

Please see my section on PIC microcontrollers for more information. Until I put that section together, check out Wikipedia's entry on microcontrollers, which you will discover are hidden throughout your home, in the lowliest of electronic devices. I can't say enough about microcontrollers, and I'm excited to show you when I write that page.

Here's a Sanyo projector controller adapted for Off/On control, designed for end-user simplicity. Because I have to maintain the projector that I mounted to the ceiling of a lecture room, I'd really rather not receive lots of phone calls about it. All the average user needs to do is toggle power, so I built the circuit I drew above and incorporated illuminated pushbuttons. The neat thing is that when the green button is pressed, the IR data stream is sent via two wires to an infrared LED mounted on the projector, and the button itself blinks slowly. After a delay sufficient for lamp warmup, the light burns steadily for five seconds. The red button has the same behavior. I think it's important to give the user feedback, which is why the buttons have this behavior. This is also a neat way of preventing an impatient user from punching the button; while the button is blinking, no further user input is possible.

The white button will eventually toggle a CCFL reading light; I just haven't gotten around to putting this part together yet. After ten years doing audiovisual stuff as a job, I've come to realize that timers on equipment are a good idea. All too often, people leave equipment on all weekend; a little coding is all it takes to avoid wasting lamps and so forth.

Here you can see what's in the box. Because I was pressed for time, I used a nifty board from MicroEngineering Labs that was made for the PIC16F877. The more mundane aspects of circuit building (wiring) are time consuming, and this board makes powering up the '877 and wiring the various connections really easy. This microcontroller is rather cool; I only use it for projects with a lot of inputs and outputs because I've found I can do a lot with the 8-pin micros. There's a 7805 regulator to provide the logic power, and the illuminated buttons really were wimpy at 12V, so I'm feeding them the 19V from a spare laptop computer adapter.

As shown here, here's my favorite bunch of chips for my IR projects. From left to right, a 4011 oscillator circuit is gated by a 4066 switch, then fed to one of the Darlingtons in the ULN2803. Plenty of room for expansion, no? The project is indeed messy; this was a board from a failed earlier project, and shows some of my early slipshod construction.

The box isn't complicated, but it's a good example of how you can build a custom remote interface from an existing remote. Nobody loses the remote control, it doesn't have batteries to go dead, and it prevents novices from jerking the projector around while it's warming up or cooling down. I also got to use those delicious Allen-Bradley buttons I took out of a big industrial control panel. You can feel the click of quality with each press.