Electronics > Projects, Designs, and Technical Stuff

The Remote Cloner project

(1/2) > >>

This is still in the design phase, I don't have a full schematic yet. My next post will talk about technical details like what processor and enclosure I am going to use. By now, you can guess how it works and comment about it. That way I also learn alternatives to my design decisions. I want to manufacture this someday.

I am going to make an infrared remote control cloner. Why would anybody want to clone a remote control? For various reasons. Let's say I work in a hospital and I often have to turn off the various TVs and air conditioning units all along the hospital. Let's say there are many brands of both things. I don't want to bring 6 different remote controls with me or 2 universal remotes with functions I won't use. So I bring my Cloner and clone all the remotes used in the hospital into a single unit.

The Cloner will have 12 buttons, enough to turn two TVs on and off, change their volume and channels and even mute it. But that doesn't solve the problem. That's why it also has a switch to change the button's functions. It goes from page A to D. If you program your buttons to clone two TV remotes with the switch on A, you switch it to B and you can program in more devices, say some air conditioners. When you switch back to A, you can use the Cloner as the remote of those two TVs. If you switch to B, you can control the air conditioners.

That way the remote can learn 48 commands with just 12 buttons. It also allows you to organize them more into categories. The front of the remote will be textured so you can write with a marker (non-permanent is recommended), or you can print a sheet with the functions, if you like.

It also has potential as a prank device. Clone a friend's remote when he or she is not there and have fun!

Basically, programming works like this:
You set the switch to the right page (move the switch to the letter you want).
You press the program button and the button you want to program at the same time.
At this point your Cloner will wait for a command from a normal remote.
When it detects a command, it starts to memorize the pattern. The cloning LED light will blink red.
When the OK LED light goes green, the command has been is saved.
If you press the button you have just programmed, it should work just like the original remote.

I will continue with this. I want to try DipTrace, so this project will be my excuse. As I said on the top of this post, I will give more details later. So far I have a detailed block diagram and most key parts selected. This will be like Dave's power supply videos.


I bet you have seen this:



--- Quote from: DavidDLC on February 09, 2012, 08:25:37 pm ---I bet you have seen this:


--- End quote ---

I could base my project on it, but this is intended to be fully stand-alone with not even a serial port (although I may include one for hacking, this will be well documented half-open hardware). Decoding the commands at this point is a low priority task. I have used both WinLIRC and LIRC, so I know these programs can receive, decode, store, encode and transmit commands. I wish this little "toy" existed when I was building my media center. I ended up giving away the old computer.

Update: taking a look at this: http://dangerousprototypes.com/docs/USB_IR_Toy_v2

Allright, I think I like his approach. He's counting the carrier wave frequency with a CPP input (like I was doing). But also he has the carrier wave connected to a timer. That way he can tell how many carrier pulses are being sent. That's handy and only takes a pin I was going to use for I/O.

I hope I am not spamming by bumping this thread every 10 minutes. Here's a tutorial on how infrared remote controls work. The most used codes are RC-5, RC-6 and SIRC. For the rest of this project, I will assume you understand how this works.

Block diagram

This is the basic block diagram of the cloner.

Fot the IR input I'm using an infrared sensor IC designed for infrared remote control extenders. It works the same way as a normal receiver does, except for one thing: it also outputs the carrier wave. That way I can connect it directly to a CPP module.

Capture, Compare, PWM modules can be used in PICs for calculating frequency and do pulse-width modulation. Since we are internally storing values on the microcontroller to replicate the signal later instead of displaying them as a frequency counter would do, we don't need absolute accuracy in the microcontroller's timer. What we do need is stability over time. And since most remote controls only use a low-accuracy ceramic, it's not big deal either so I will stick to a cheap crystal or a decent ceramic resonator.

Now, we have calculated the carrier wave frequency and it's guaranteed to be relatively stable over time, but, how do we store the actual data? We do it by sampling a separate pin without the carrier wave on it. To remove the high-frequency carrier wave we use a low pass filter. To use a passive low pass filter we need to isolate the signal coming from the output of the IR receiver because it is an open collector output. I used an op-amp in the block diagram, but a push-pull buffer gate can do the job much better and cheaply.

With some software magic I haven't figured out yet, I will store everything into a 24LC512 EEPROM. It has a 128 byte buffer size and a 128 byte page size. 128 bytes worth of samples from the IR sensor will be loaded on the PIC's RAM. When it's done receiving this, the data is transferred to the EEPROM buffer, and at the same time another 128 bytes of samples will be recorded on a separate memory location.

When the PIC is done writing data to the EEPROM, buffer the EEPROM will move the data from its buffer to the corresponding address. The reason for this is because you cannot write 128 bytes one by one on the EEPROM without a relatively long pause. By the time you write that single byte, you will have missed several others. This doesn't happen when writing in 128 byte chunks, as long as they are all located on a single EEPROM page.

To store the frequency data I will use the PIC's built-in EEPROM, just to make development easier and to use a feature I am paying for. I will just store the value captured by the CPP module and then do some conversion to write that value into the PWM frequency register. I think one of them works with 10 bit resolution and the other with 8 bits.

I have two options for the IR LED driver. One is to have a PWM output working at the frequency I recorded for the button that is being pressed and have another pin changing according to the value of the bits I sampled at a fixed and known sampling rate. If I used an AND gate on the output of both, I could modulate the output at the carrier frequency and imitate the remote control.

The other way is to eliminate the AND gate and make the output an input to turn the output transistor off instead of using a separate pin to do this.

For driving the LED I could use a transistor current sink, which is not affected by changes in voltage like a voltage dropper resistor is.

For the next post I will tell you about the different IR sensors I can use and how parts selection will affect my choices on how to power this circuit. I may use a direct connection to the batteries with an extra boost regulator for certain ICs. Perhaps I could get away with using just the batteries and nothing else (minimum operating voltage would be 2 to 1.8V). Or maybe I will just make my life simple and have a boost regulator with 5V or 3.3V output. Maybe if the regulator used less than 20µA when the remote is idle it could last more than a year.

This is getting cool.

P.S.: I forgot to say why I chose the PIC18F23K20 and didn't tell you what enclosure I was going to use. I forgot to mention it. I will leave this for the next post.


[0] Message Index

[#] Next page

There was an error while thanking
Go to full version