Help with a very simple remote control.

Discussion in 'Homework Help' started by saml1337, Dec 15, 2012.

  1. saml1337

    Thread Starter New Member

    Dec 15, 2012
    Hey everyone, I just made an account on here because i'm completely stuck with my electronics work.

    For my school project I need to have a remote control module that can send a signal which is received by a detector elsewhere, and activate an LED, that's it! I am aware you can buy things called RF Receiver and Transmitters but I have no clue how to use them:(

    I am willing to buy any components that will get this job done:)

    If someone could point me in the right direction it would be greatly appreciated!
  2. #12


    Nov 30, 2010
    The typical method is to use a carrier frequency (38 kilohertz) so the receiver can tell the signal isn't background noise. Then design the receiver to respond to the carrier frequency.
    saml1337 likes this.
  3. JohnInTX


    Jun 26, 2012
    You want an IR receiver that has all the goodies built in like the ones on this page from the Mouser catalog. Look at some of the datasheets corresponding to figs. E and F. As #12 said, these use a carrier frequency of 36-56 KHz that is modulated with your digital data to make bursts of IR light that are immune to interference from most ambient light sources.

    The key to applying one is the Burst Length - Cycles per Burst spec which tells you how fast the data bits can be. For example if spec'ed at >=6, that means that each data bit-time must be long enough to contain 6 cycles of the carrier frequency. For 38KHz, 6 cycles is about 157us so your serial data bits cannot be shorter than that. But 157us min bittime is fine for a 4800 baud async link (bit time =208us) and I've used these for just that way.

    All you have to do is modulate the output of your UART with 38KHz and drive your IR LED with that. The receiver will provide a faithful reproduction of the transmitted signal. Nice.

    Here is a direct link to one of the datasheets which explains how they work. Its for a legacy device so click around to find a current one..

    For something this simple, use a 555 to generate the carrier, a button to connect the IR LED to the 555 output and some kind of driver off the receiver's output to turn on the LED when it sees the carrier signal. Done!
    Last edited: Dec 15, 2012
    #12 and saml1337 like this.
  4. saml1337

    Thread Starter New Member

    Dec 15, 2012
    Hey man, apologies for the late response!

    I understand on the most part what you are getting at, it's just this part completely lost me:

    Now i'm sure your sick of clueless people like me but can you break that down into simple terms for me? ;) You see i'm a high school student and we barely go into too much depth about components.

    Unfortunately it seems the vishay page about how the receivers work is missing.

    Thanks for the reply.
  5. JohnInTX


    Jun 26, 2012
    Sorry, missed your reply..

    With any light-sensitive receiver, the problem is what happens when ambient light (sunlight, flashlight, room lights etc.) shine on the detector. There are a couple of things to consider.

    A simple CdS cell, photo-transistor etc. will happily pick up any light and activate when shone upon. This makes for a poor remote control.

    Designers use a couple of ways to tackle the problem. First, make the detector sensitive only to IR (out of the visible spectrum) and then filter out all of the visible light. Second, since there may still be sources of IR light in the room (sun, fireplace, heater etc.) they require that the light source be modulated i.e. appear as a high-frequency light signal that isn't likely to be generated by natural sources. An IR receiver is the term used for a device that incorporates a sensor, light spectrum and modulation filters in one package. When it 'sees' light in the IR spectrum, modulated at its design frequency, it responds by changing its output (we'll say to low for this discussion). The output will stay low as long as long as it sees its modulated IR light. Turn off the light source and the output returns high.

    While interesting, the foregoing is not a very good remote control. It can only control one thing and requires that the IR source be on continuously. One solution is to switch the IR source on and off in some recognizable pattern add some logic to decode the pattern. A toggle flip/flop connected to the output of the receiver is enough for a simple push-on push-again off control. The f/f remembers the state of the system so you don't have to keep the IR source on all the time.

    More control can be had by more involved patterns (two long + one short = ON, two short + one long = change channel etc). These patterns can be almost anything.. morse code even, all generated by turning the modulated IR source on and off in some known pattern.

    Be sure to understand the difference between the pattern pulse width and the modulated frequency. The pattern pulses consist of bursts of modulated IR light. A single 1 second pattern pulse is generated by switching the IR LED on and off rapidly for 1 second (1 pattern pulse = many on/off switches of the IR LED). Its similar to what you would have if you blew a whistle for one long burst to tell your little brother to turn on the light and two short bursts to turn it off. Its one burst of sound but that sound is created by many cycles in the air.

    So if we've agreed that turning on/off in a pattern is the way to go, how fast can we do it i.e. what's the shortest time that we can detect the modulated IR? Shorter is better (more data per time) but we run up against the requirements of the filtering circuitry incorporated in the particular IR receiver. For the Vishays, the minimum time is specified in cycles. A modulation frequency of 38KHz means that the modulated signal has a period of 1/38000 ~= 26.3 microseconds (uS) per cycle. Vishay wants at least 6 cycles to detect so that's 158.8 uS worth of 38KHz modulated IR to switch the output of the receiver. Once switched, the output will stay ON (low in our discussion) for as long as it sees the modulated IR light.

    For simple systems (your finger on a button) this is not an issue since you physically can't press and release the button that fast (1/5 of a second is typical if you try). But when communicating data generated by a microcontroller etc, it can become an issue so they tell you the shortest pulse width that can be detected so that you don't go too fast. In the UART example, how short the bursts of modulated IR can be becomes an issue. As noted, 9600 baud means a minimum bit time of 104 uS (1/9600). This is too short for our IR receiver (it requires at least 158.8uS of modulated IR per pulse). But 4800 baud (208us/bit) fits nicely. This means that you could replace that $2 cable between two computers with $40 of IR hardware and send data in one direction using hyperterminal at 4800 baud. Not too practical that one but your robot can now receive commands at 4800 baud... you get the idea.

    As a starting point, use one of Bill Marsden's 555 circuits to make a 38KHz (or whatever the IR receiver wants) astable oscillator (or whatever the IR receiver wants). Connect the output to an IR LED (through a resistor-use one of his values) and a pushbutton in series with the LED. Pressing the button causes the IR LED to emit light modulated at 38KHz, just what the receiver wants. You can put another LED+resistor in parallel as a monitor if you like. Point the IR LED at the IR receiver and push the button. When the receiver sees the modulated light, its output should change.

    Have fun!
    saml1337 likes this.
  6. saml1337

    Thread Starter New Member

    Dec 15, 2012
    Wow, thank you SO much for the thorough reply!

    I totally understand how the IR detectors work now. I decided to do some testing with real products to see in real situations, after using my camera and pointing it at my remote whilst pressing the buttons, I saw the clear patterened 'codes' from the infrared LED inside. Next i took apart my freeview tuner box and found an infrared detector which is exactly like you showed me. I've always been mystified by how that worked and now I know, brilliant!:)

    Now, for my project in school, my brief states it must be a remote control. I was thinking of having a small remote which has an on/off button, a 'next' and a 'previous' button which would cycle through different LEDs to light a room in various colors (perhaps a nightlight sorta thing). If I do this, how do I make my receiver detect 3 different buttons? Could I make it so the on/off button produces 1 burst of patterned light, 'previous' button produces 2 bursts etc. and the receiver counts this and produces an output? Or is there an easy way around this?

    I have done some research into circuits etc and came across this 555 Timer Circuit. If I used this to drive my IR LED and used this detector, would that work? Apologies if i'm being an idiot:(

    I'm going to use everything you've told me in my final write up, your help has been really appreciated!
  7. JohnInTX


    Jun 26, 2012
    Yup. Each button causes the IR bursts to be emitted in a unique way that the logic connected to the receiver decodes to do your job. It can be as simple as you describe i.e. emit a different number of pulses for each button or more involved like RC5 . It depends on how robust you need it. For a school project, keep it simple.

    I'm not sure where you are in logic and/or microcontroller design capabilities ((I'd use a couple of PICs) so I hesitate to go off on a specific recommendation but you are on the right track.

    When thinking about a solution, you really only have a couple of things to work with 1) the presence of the modulated IR signal ON/OFF and 2) how long its ON/OFF and 3) the timings between the ON/OFF condition.

    One simple possibility might be to count pulses with the last one being much longer than the others. An RC network feeding a Schmidt trigger (CD4016) charges when IR is being received but its time constant is longer than a normal count pulse so it ignores them. On the long terminal pulse, the RC charges up, trips the Schmidt which latches the count in a separate latch. When the button is released, the IR turns off and the 'decoder' count resets leaving the latched bit to do its job. The resulting bits in the latch can be used to set/reset flip/flops to drive LEDs etc.

    A CD4017 counter with decoded outputs looks promising for the transmitter control and receiver counter. On the TX side, each button releases the counter from Reset AND picks one of the decoded outputs for the number of bursts to emit. On the RX side, the decoded outputs are buffered with the latch so that intermediate counts don't drive the LEDs until the terminal count.

    In this scheme, signalling number 3 would go buzz buzz buzzzzzzzzzzzzzzzz.

    You'll need two 555s for this, one to generate the 38KHz IR bursts and a second to run much slower (100ms period or so) to generate the bursts- buzz buzz buzz.... The second 555 is also the clock source for the TX counter.

    There are many potential problems with a simple scheme like this (what happens if it misses one of the counts for starters). Protocols like RC5 have things built in to take care of problems (checksums, repeat transmissions etc). All of that makes for more logic.

    Give it some thought and see what you come up with.

    Hardly. You've shown considerable talent and moxie. If that's an idiot, send me more idiots.

    Best regards.
    Last edited: Dec 27, 2012
    saml1337 likes this.
  8. saml1337

    Thread Starter New Member

    Dec 15, 2012
    Ahhh.. Before you posted this I actually built a breadboard circuit with a 4017B that counted 2 pulses to generate outputs. However we are allowed to use PIC Chips so I just wrote some code to try and counts pulses, here it is:
    Code ( (Unknown Language)):
    2. start:
    3. if pin2 = 1 then reset1
    4. if pin1 = 1 then test
    5. goto start
    7. reset1:
    8. low 1
    9. low 2
    10. low 3
    11. goto start
    13. test:
    14. if pin1 = 0 then test2
    15. goto test
    17. test2:
    18. wait 1
    19. if pin1 = 1 then test3
    20. if pin1 = 0 then firstoutput
    22. firstoutput:
    23. high 1
    24. wait 1
    25. goto start
    27. test3:
    28. if pin1 = 0 then test4
    29. goto test3
    31. test4:
    32. wait 1
    33. if pin1 = 1 then thirdoutput
    34. if pin1 = 0 then secondoutput
    36. secondoutput:
    37. high 2
    38. wait 1
    39. goto start
    41. thirdoutput:
    42. high 3
    43. wait 1
    44. goto start
    I just wonder if this is completely reliable, it requires relatively precise timings from the IR LED in order to count accurately. Perhaps there is an easier way to count using PIC?

    I have never actually heard of a Schmidt Trigger and I think it might be beyond my specification. However I guess I must take everything I can into consideration! I will research these components tomorrow to try and get a better understanding.

    Thanks again.
    Last edited: Dec 27, 2012
  9. JohnInTX


    Jun 26, 2012
    Sorry, I wrote that I wouldn't offer suggestions until I knew more about your technical level then went right on and offered suggestions.. So, forget about all of that.

    You can lick this thing in a jiffy if you use 2 PICs (TX and RX side). Pick one with a 1)USART and 2)ECCP module. Something in the 18F4520 family would be great but many others would work, too. Avoid the 16F stuff if you can. Others here will differ in opinion but the 18F is way easier to deal with, even though its a bit more complex at the start.

    So.. imagine you have these two PICs set up with TXD of the remote control connected by WIRE (for now) to the RXD of the slave unit. Since transmission is one way, just pull up the RXD of the transmitter for now. Magically, you have set up the USARTS in both to 1200 baud and enabled them (We can work on the magic later if need be...) So.. whatever byte you send (by writing it to TXBUF) will be sent along the wire and appear in RXBUF of the slave unit along with the RXIF flag. When you read RXBUF, you'll have an exact image of what you wrote to TXBUF.

    As a first crude step, you can periodically read the port that the buttons are connected to and send the button image to the slave. Read what you get and write it to a port. Now the slave has an image of the buttons on the remote. By periodically reading then sending the button image, you get a continuous update.

    This is not much of a protocol but it has the advantage of being dirt-simple. Once you establish the serial link though, you can make the protocol whatever you want i.e. send an 'A' to turn on output 1 and 'a' to turn it off. A little more decoding but more flexible and still only one byte. Later, you can implement a more robust protocol but you get the idea..

    WIRE?? Sure, until you get the coding worked out. Once you do, remove the wire and insert your IR link. Its simpler than you think. On the receive side, connect the output of the IR receiver to the RX pin of the UART. Make sure that when its seeing no IR, its output is high (a MARK in USART-speak).

    The burst transmitter is simple! First, configure the ECCP to PWM mode and set it up to output a 38KHz 50% duty cycle wave. This takes the place of your 555. Now, connect your IR LED (with resistor) anode to the CCP output (38KHz square wave) and cathode to the TX pin of the USART. When the TX pin is high (USART idle) it will sink no LED current and even though the PWM is running, the LED won't light. When you write a byte to TXBUF, the USART will send it by shifting it out on the TX pin. Whenever the pin is low, the LED will output IR modulated at 38KHz from its PWM source. No other intervention is necessary as the peripherials do the heavy lifting for you. Nice!

    Code: I didn't pay too much to yours because I don't like timing with delays and a bunch of if/thens etc. particularly when I have spiffy peripherals just ready to do my bidding. A real simple outline of the above could be:

    Code ( (Unknown Language)):
    1. #declare all of the PIC stuff, fuzes, clock speed etc suitable for your assembler/compiler.
    4. main()
    5. {
    6.  initIO() // init ALL of the ports in/out etc.
    8.  initUSART() // set up the USART for 1200baud,8 bits, no parity, enable TX etc.
    10.  init38KHz() // set up ECCP to emit the 38KHz square wave
    12.  // for the transmitter PIC
    13.  while(1){
    14.   TXBUF = PORTB;  // write current buttons to USART
    15.   delay(100msec); // give it time to send
    16. } // while
    18. // In the receiver PIC (after init)
    19.  do{
    20.   while(!RXIF); // wait for a transmission
    21.   PORTB = RXBUF;  // read data (the pin image), write to PORT
    22.  } while (1)  // do
    This is a bit TOO simple (it transmits continuously instead of waiting for buttons, no error checking or button debouncing etc.) but you get the idea. A simple expansion would be to debounce and decode the buttons then send a number or ASCII character corresponding to what the slave should do. When the slave receives it, it decodes it using a switch statement to see what to do.. Lots of possibilities. Start simple. Once you have a serial link that works, expand away!

    As for the inits, hit the old databook and init away. If you post your PIC P/N and osc speed, I can help you with the specific setups. Many C compilers have libraries that do it as well.

    Finally, an approach like this requires a bit more thinking on the front end and requires some learning about the USART and ECCP but that investment will pay off better than all time you spend making some ad-hoc timing gizmo work. You don't seem to shy away from new things so have at it!

    There is lots on this board about UARTs and PWMs as well but hit the databook first. Here's something on communication by UART.

    Have fun!
    Last edited: Dec 27, 2012
    saml1337 and absf like this.
  10. saml1337

    Thread Starter New Member

    Dec 15, 2012
    Okayyy i'm going to start off by saying a lot of that went straight over my head. The most we have ever done in PIC is 'if then' 'wait' 'high' and 'low' So i'm extremely confused right now! By the way we use 14M2 if that means anything to you.

    I have a few questions:
    1) What is USART and ECCP.
    2) What is the 'BUF' part in TXBUF + RXBUF?

    The problem here is that if I use complicated PIC codes (at least for GCSE standards) the examiner will be suspicious that I'm cheating, or I could lose marks for my actual circuits not being complex enough since i'm only using a PIC Chip. If I can get a better understanding of what you mean maybe I can write all the code myself and explain it all in my write up.

    I'm sorry about this but, can you help me understand what you said in a straightforward way because I have no clue what you mean:(
  11. axzen

    New Member

    Dec 28, 2012
    If allowed why not just hack into something that turns on an LED using IR already? For example, go buy a remote controlled toy (i.e. car, helicopter) and be done. For a complete beginner a 'complete from scratch solution' would probably be overwhelming. Good luck.
  12. JohnInTX


    Jun 26, 2012
    EDIT: The first part of this post is musings about how to revise our approach, not knowing what a 14M2 PIC was. After I figured out that it was a PICAXE and checked it out, I like it a lot for your problem.

    I expect that you'll design your own logic or write your own code to solve your problem. Our goal here is to offer help and advice to foster the learning process which is not unlike reading a textbook or asking a more experienced team member. We don't do your work for you. But if you are concerned, you should check with your professors. On to your cool project..

    We've been entertaining some interesting ideas but now, it would be a good idea to sit down and write a specification describing what your remote needs to do. Your original post indicated that just turning on an LED when you activated the remote would be sufficient. If that's still the case, you are practically there. But, as frequently is the case, getting some basics down led to more thinking and added features that may or may not be achievable in the time we have. This 'creeping featurism' is common with imaginative engineers (and the marketing dept. after one of those 3-martini lunches).. So let's decide what we need and go after that.

    Anything beyond the simple LED indicating the presence of IR will require some logic of some sort. A simple toggle flip-flop on the output of the IR receiver will provide a push on - push off control. Controlling multiple things will require more logic so the question is.. how far do you want to go and more importantly, what do you think you can handle? Give it some thought, jot it down in a spec or project proposal and let us know.

    About your PIC, I don't know what a 14m2 is. Is it some kind of project board based on a PIC? EDIT: I see its a PICAXE, see below.

    As for the UART/ECCP, sorry to confuse you. A UART (or USART) is simply a module built into the microcontroller that allows you to take a data byte (8 bit parallel data) and send it serially over a single wire (or IR link, or whatever). The RX part receives this serial stream and reconstructs the original byte. TXBUF and RXBUF refer to internal registers (BUFfers) in the microcontroller. Writing a byte of data to TXBUF causes the UART to send the data serially. That data is received by the UART at the other end of the link and appears in the receive buffer (RXBUF). EDIT: The PICAXE takes care of all of this for you.

    The ECCP is Microchip's name for a functional block that allows you to generate a continuous signal (among other things) automatically. You configure it and it does the work so that the program can do other things. EDIT: PICAXE ditto.

    But all of that sounds like it may be too much for right now. Think about it and jot down your minimum spec and we can go from there.

    Don't worry if you don't know some of this stuff. We all had to learn it sometime.

    EDIT: Ahhh.. I see now that the 14m2 is a PICAXE setup. I'm not real up on those but will check it out when able. The PIC its based on may not have the low level access to the kind of peripherals I was referring to (no wonder you were confused, sorry!) but at first glance, should be able to handle some basic IR send/receive. What do you think?

    EDIT EDIT: I looked at the PICAXE manual, the instruction reference, the hardware interfacing reference and everything you need is right there! If you are allowed to use it, you are golden. It even has irin and irout (IR input/output) instructions that speak Sony Remote Control at a modulated 38KHz. Nice.

    If that is too easy, it looks like it would support an IR datalink using the PICAXE's UART (at 4800 baud-nice again) and ECCP/PWM module to generate the 38KHz modulation signal like I was suggesting earlier.
    If you go that route, check out these instructions to do it:

    For the 38KHz IR carrier (ECCP stuff):

    For serial data (UART stuff)

    For decoding either way, use the select case statement.

    This might be more than you want to consider but if you can pull it off, you'll be well on your way towards understanding the basics of developing embedded control systems.
    Last edited: Dec 29, 2012
  13. saml1337

    Thread Starter New Member

    Dec 15, 2012
    Hey man I only just realised it had moved on to page 2, good thing I saw..

    It's probably my fault for not mentioning about PICAXE, I didn't know there was a difference:(

    Yeah I totally understand that and I think it's great you help people like that, what I meant was if I used all crazy peripherals the examiner won't believe I did it.

    Well now that I know it's possible to achieve various features, why the hell not?:) the more the better in my opinion.

    By the way I really have to thank you for taking the time to research my situation, I can't express my gratitude, you are a great guy.

    Okay so basically we are allowed to use anything in PICAXE as long as it is 14M2. So I guess I can pull this one off! I've been having a read through the instructions and it all seems good, I will try to code something tomorrow when I can get onto my pc. If I go the easy route to make the signals then I will just have to make it do something complicated at the receiver end to compensate, maybe a game? Just for the extra marks you know;)

    Perhaps a reaction game where 4 people have remotes, a light activates randomly on a box in the middle, first person to react wins, then I could include 555 timers with flashing LEDs and buzzers, simple thing like this gets you marks!
  14. saml1337

    Thread Starter New Member

    Dec 15, 2012
    We are allowed but you don't get marks for it, it has to be your own work to get marks unfortunately.
  15. JohnInTX


    Jun 26, 2012
    Sounds like a plan.

    If I may offer some advice, be sure to take the time to decide specifically what the first cut is going to do and make that a limit. You can add functionality later.

    Work out your design with best guess hardware and a flow chart of what the code will look like to execute your design. Identify things that might make future added functionality easier. For example, you might start with only one command. You could implement the command decoder with a simple test or, thinking ahead, use the select case statement with only one case. Overkill for one command but ready to expand when you want it. These things will show up on when you have your design sketched out on paper.

    Desk-check your design by running through the various operations on paper before you try to code it. You'll be able to identify all of the bits that the code needs to do. You'll also find gaps in your thinking that you can fill in on paper. When you can run through all of the functions and it makes sense to you, then you can implement your design in code.

    As you code the project, the design becomes a guide and will answer many questions that will pop up during implementation. If you run into trouble, you have a ready guide to begin troubleshooting. Each code module has its function. When one doesn't work, you just look there, not through an ad-hoc mess of spaghetti.

    If you start by banging away on the keyboard without having worked out all of the details, you'll find yourself banging into the wall, making patchy code and doing lots of rewrites. That's frustrating, time consuming hard to debug and results in inferior code. More than one project has failed because it nobody could debug it.

    I like working with smart people and you're welcome. Besides, I also got the opportunity to check out PICAXE. I think I'll get one to mess around with myself. One more thing for the bag of tricks!

    Go have fun.
    Last edited: Dec 30, 2012