Have you ever thought of a great solution for a problem that doesn’t exist? In a way that’s what most of these PIC projects have been about. As I said in the first one, most of these are just potential building blocks to help spark ideas for your projects. Recently I finally found a real need for one of the “blocks” I built previously. I volunteer at the local recycling center fixing computers so they can be sold to help raise funds. The best part, though, is when we go out in the yard to see what sort of electronic treasures have been dropped off. One thing I found was a home theatre subwoofer/amplifier that could be operated by remote control. Unfortunately, the remote wasn’t there. Even more unfortunate is that it is an off brand so an original remote is rather expensive and universal remotes don’t have a code for it. What is fortunate is that it has a front panel full of momentary contact switches for controlling things. That meant that I could wire into the switches where they connected to the controller PC board to bring access to them outside the box. And once I had access I could easily wire up a PIC to perform just like the front panel switches. And because I had already built a PIC “block” to do IR decoding it was a simple matter to select the codes I wanted and use them to replace the missing remote. While this application is specific to my needs, the hardware and software are highly applicable to any number of applications where you want to add an IR remote and have existing switches that you can wire to.
In an earlier post we built an IR decoding circuit using a simple, inexpensive, 3-pin IR receiver. That circuit was connected to a 1602 LCD module so we could view the codes from various remotes. In this post we do away with the LCD and change from a 12F683 PIC to a 16F688 in order to have enough I/O pins to connect to the various switches in the amplifier box.
The switches inside the amplifier box are normally open, momentary contact and provide a connection to ground when closed. That is pretty typical in front panel controls for various pieces of electronics. What is also typical is that the connection from the switch to the controller board has a pull up resistor. That’s what I found so I made sure to isolate my PIC circuit from the amplifier box circuit by using a diode in each control line. The amplifier box uses a microprocessor that is run from +5VDC so I was able to tap into that as well and eliminate the need for a separate power supply for the PIC.
Because I have the IR decoder that was built in an earlier post, I could choose most any remote for this application. But if you don’t have that decoder, then you need a remote with known codes and one that doesn’t interfere with other things like your TV. The remote I actually ended up using is one that is really cheap on eBay. It has 21 keys and, although the key markings may vary, the codes for the key locations are usually the same. A typical example is shown above. The address for this remote is 00 FF (bytes 1 and 2 respectively). The key codes for byte 3 (in hex values) are also shown above. Byte 4 is just the XOR of the byte 3 so I ignored the value of byte 4 in the software.
After I decided which keys to use on the 21-key remote, I copied them into the Chunghop learning remote shown above. I did this because I found it easier to use and more intuitive as far as key assignments are concerned. The power and volume keys are obvious while the A/V key is assigned to do the input source selection and the channel keys are both assigned to toggle the 2.1/5.1 speaker channels selection. The mute key is unassigned in my application.
The software link is listed below. While it is targeted for the 16F688, it is easily ported to other versions of the PIC. You will need to change the line that identifies the PIC version (LIST=) and the INCLUDE file but those are intuitive changes. The __CONFIG line may also need tweaking just because one or two of the labels used are spelled differently in some of the INCLUDE files. Just make sure that the PIC you use has a pin that allows an External Interrupt input (usually labeled EXT or INT).
The baseline software was copied directly from what was used in the IR Remote Decoder with the LCD routines deleted and the minor changes made for the 16F688 to replace the 12F683. The new software that was added saves all four bytes of the IR code received and then runs through a simple set of logic to determine if it is a valid command. Each “key press” routine toggles an output line from high to low for 50ms to simulate a front panel key press. The delay time of 50ms was arbitrarily picked because most microprocessors will decide that it is a valid key press if the input hasn’t changed value (bounced) for that long. You can lengthen that time, if needed, but I wouldn’t shorten it.
In the IR Remote Decoder post we simply sent each byte received to the LCD and had no need to save the entire four byte sequence. In this application, however, we save all four and then parse them for valid data. You will see in the variable declaration section that I have defined Byte1, Byte2, Byte3, and Byte4. While we could just add code to determine which byte we have received and then write to the appropriate variable, it is more code efficient to address the four bytes like an array in C. The PIC allows us to do this by providing a couple of registers (FSR and INDF) to perform indirect addressing. You can see how that is done in the “Save_Byte” routine. In this case we know that we will not be crossing a page boundary (256 bytes) so we only need to worry about setting up the lower 8-bits of the data address. One other thing to note in this routine is that we wait to increment “Byte_Count” until after we use it as an address index. That’s because the index needs to be 0-3 for our data while “Byte_Count” goes from 1-4 while counting received IR bytes.
As I mentioned earlier, the amplifier box has a microprocessor in it that determines what to do for each key press. I found that it does a couple of quirky things that I didn’t like so part of the software was added to “correct” those quirks. One of the things it does is to power on from the Standby mode when any key is pressed, not just the power key. That might seem like an ok thing but it actually caused some complications when I was writing the software. To simplify things, I added a check of the “Power_Up” flag in the decoding routine in order to skip all command decoding other than the power on key if the amplifier box is still in Standby mode.
The amplifier box can also be set for either 2.1 (stereo) mode or 5.1 (surround) mode. I’m using it to drive a single set of speakers so I always want it in the 2.1 mode. Unfortunately, the microprocessor in the amplifier box sets the mode as 5.1 every time that the box goes from Standby to On or any time that the audio input source is changed. Routine “Mode_2_1” gets called on the transition from Standby to On and toggles the speaker channels back to 2.1. I found that I needed about a 1 second delay after power on before the speaker channels command would take effect. I also added code to “Source_Sw” to toggle back to the 2.1 mode after changing the audio input source but that required a shorter delay before the second command could be issued. That’s it for this post. Check out my other electronics projects.