It’s been a long time since I worked on “computer stuff” at so low level. This time, it’s about figuring out the Infrared (IR) remote control protocol used by my aircon, and then building an IR blaster with a Raspberry Pi that can control multiple devices from a single unit. Unlike most IR remotes, aircon ones are a bit more complex.
TV remotes, for example, send a simple IR code for each button you press. Basically, each button has a code associated with it. This is the same for DVD players, set top boxes, fans, and most other appliances. It’s not the case with aircons, or at least most of them.
Aircon remotes store some state information. When you set the temperature, or adjust fan speed, your settings are reflected on the remote’s LCD screen. Since their IR communication protocol is still quite rudimentary, it’s important that what you see on the remote is what actually gets set on the aircon unit, even if some of your button presses were missed by the aircon.
For example, if you press the up button twice to increase your temperature set point from 22°C to 24°C, and for some reason the first button press was missed because you pointed the remote in the wrong direction, you want your aircon to actually know it’s 24°C you want, when it beeps its “acknowledgement” to your second button press.
Aircon remotes communicate to the aircon unit itself by transferring its complete configuration setting. Every button you press will send the entire configuration set to the aircon unit. Even if you only pressed the fan speed button, for example, the aircon remote will transmit temperature, mode, timer, and other information. Each button press results in a somewhat longish, at least when compared with other conventional remotes, stream of IR pulses.
This is what makes aircon remotes a bit more complex.
My Panasonic aircon, for example, transmits 27 bytes of information, excluding some header and separator marks, with every button press.
Decoding it is one part of the story. The next is with transmitting.
I think the last time I did something so low-level, at the communication signalling level, was on the Apple ][, where I was working with direct disk I/O. At that time, I needed to read/write registers at a very precise timing, as bits were transferred in/out from the spinning floppy disk drive. Yeah, I was doing stuff pretty much at the hardware level. You had to control the stepper motors yourself to move the read/write heads.
With that experience, of course, IR signals were not unfamiliar territory for me. What turned out to be a bigger challenge for me was building a working IR blaster. Without EE background, I was like working in the dark. I’d have thought there would be plenty of tutorials online. Alas, whatever I found helped a little, but also confused me a little.
I did get a working IR LED to blast IR signals easily. The problem was I had to hold the IR LED like 30cm from the receiver. Yes, yes, I just need more power. But I did have a “high power” LED, and I thought I had all the transistors and resistors to give it enough current.
30cm won’t do for me. My use case is to have a single Raspberry Pi blasting IR signals to multiple receivers. For example, I could have one installed in my living room to control the aircon, TV, and cable set top box. I need the IR LED to blast at least 3m away, and powerful enough to “scatter” around the room.
So if anyone’s interested, I’m now using a Vishay TSAL6400 IR LED, its anode powered directly from the Raspberry Pi’s 3V3 pin, the cathode connected to the collector of a Multicomp 2N2222 NPN transistor. A GPIO from the Raspberry Pi connects via a 200 ohm resistor to the transistor’s base, and the transistor’s emitter connects to ground. That’s right, I’ve no current resistor on the IR LED like everyone seems to say it’s needed. We’ll see if my IR LED lasts.
I know, a drawing will help a lot. I’ll do that another day. The parts are sourced from Element14. Just about a dollar or so.
View Comment Policy