The Remote Cloner project - Page 1
Forum section: electronics / projects

author: ivan747
author_rank: Super Contributor
timestamp: February 09, 2012, 08:21:56 pm
content: 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.Ivan

author: DavidDLC
author_rank: Frequent Contributor
timestamp: February 09, 2012, 08:25:37 pm
content: I bet you have seen this:http://www.seeedstudio.com/depot/usb-infrared-toy-v2-p-831.html?cPath=174

author: ivan747
author_rank: Super Contributor
timestamp: February 09, 2012, 08:31:50 pm
content: Quote from: DavidDLC on February 09, 2012, 08:25:37 pmI 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_v2Allright, 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.

author: ivan747
author_rank: Super Contributor
timestamp: February 09, 2012, 08:57:15 pm
content: 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.http://www.sbprojects.com/knowledge/ir/index.php

author: ivan747
author_rank: Super Contributor
timestamp: February 11, 2012, 12:29:59 am
content: Block diagramThis 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 pinwithoutthe 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 saywhyI 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.Ivan

author: ciccio
author_rank: Frequent Contributor
timestamp: February 11, 2012, 10:22:40 am
content: Try do build something cool, as this one:http://www.bang-olufsen.com/beo6-remote-control] http://www.bang-olufsen.com/beo6-remote-control (obviously cheaper...).I'm joking, but I understand you are on the right way: the remote must clone the original by reading the transmitted informations.The cheap universal remotes you can buy must be programmed by keyboard codes, and they usually are more confusing than functional.I have an idea: use a graphical touch screen (illuminated) with programmable labels buttons, so you select the device with a switch and you have the correct buttons displayed.Keep on the good work: there are many possible customers out there.Best regards

author: GeoffS
author_rank: Unknown
timestamp: February 11, 2012, 10:47:49 am
content: Sounds very like a device I have sitting in the lounge room. Universal remote, supports up to 6 remotes and is programmed by learning from the originals. Cost about $60Perhaps I'm missing something?

author: ivan747
author_rank: Super Contributor
timestamp: February 11, 2012, 11:29:00 am
content: Quote from: GeoffS link=topic=6849.msg90197#msg90197 date=1328957269Yes. Instead of programming the remote to completely imitate other remotes in your living room and staying like that for the rest of its life, I want something you can carry around, just like those 90's Casio watches with IR remotes. It doesn't use codes because it is designed for quick and custom use.Now that I think about it, another good example is elderly people. Many of them can't undestand the concept of an universal remote, and many others don't understand the remote included with their set top box (was it called like that?). You could program this to only have the essential functions (it would need more buttons, though). The ABCD switch could select the different TVs in the house. I could distribute something like a Word document with a template so you can add labels and stick them. Or perhaps some blank stickers to write the labels in.

author: ivan747
author_rank: Super Contributor
timestamp: February 14, 2012, 12:38:13 am
content: Selecting the microcontroller, the sensor, and the enclosureThe microcontroller:The microcontroller I'm going to use is the PIC18F23K20. Why? Simple: it meets my requirements at the lowest cost possible. Also, it has an architecture optimized for C. And I am going to take advantage of arrays and C. Also I have a PIC18F4520 at home. This (I suppose) is the previous generation of the PIC above in its 40-pin package and with lots of memory.The PIC18F23K20 has 512 bytes of RAM. For learning codes we need 256. That's because we are going to fill a 128 byte buffer in RAM and while we store it on the EEPROM (which has a 128 byte buffer for itself too), another 128 byte buffer needs to be filled with data. Otherwise we will loose data from the IR sensor.That means the sampling rate needs to be as fast as possible, but slow enough so we can transfer the data on a buffer from the PIC to the EEPROM and at the same time fill a second buffer with new data so the process can be repeated with this second buffer. I have determined that a sampling rate of approximately 20ksps (that's kilo samples per second) should be enough to store an entire buffer on the EEPROM while the other one gets filled. This is roughly half the frequency of most carrier signals.A 28 pin PIC was selected to give enough extra pins for future expansion, debugging or modding.Another reason to select this PIC is the fact that it is and XLP part and it works down to 1.8V. The only problem to this is that I know it won't run full speed at 1.8V, so I will have to use a DC-DC converter anyway to get the voltage up to 3.3V. The IR sensor and the EEPROM work best at 3.3V.But I could do something to turn off the DC-DC converter (and, consequentially, the sensor and the EEPROM) and automatically switch the PIC and the button matrix to run directly from the batteries. I could turn the DC-DC converter back on when a key is pressed. This way the PIC uses less power because it runs on a lower voltage (I don't have to run it at full speed when waiting for a button press) and also the DC-DC converter is not switching therefore it only uses a fewµA. I could use ORing diodes to do this, but the forward voltage drop is too big for this sort of applications and Schottky diodes are relatively expensive, so this method is almost discarded unless any other option has a very bad battery life of less than a year on standby.The other option is to turn off all the unused things and have a DC-DC converter that is efficient at low loads, like the TPS61070. This is described in Microchip's Low Power Tips n Tricks:http://ww1.microchip.com/downloads/en/DeviceDoc/01146B_chapter%202.pdfTPS61070 efficiency graph. Notice the higher efficiency with TI's power safe mode when compared to the PIS61070TPS61070 datasheet:http://www.ti.com/lit/ds/symlink/tps61070.pdfThe sensorComing soonThe caseComing soon, because I'm tired.I'm using DipTrace for this one.Ivan