I just have a few things to add (or reiterate) to this excellent description Eric gave you. The carrier frequency is pulsing the IR faster than you can see. The four flashes you see are probably the command repeated four times so increase reliability. You can get an IR receiver from Radio Shack (I think it's uses a 38khz carrier). Its filter is not very good though. It passes a lot of stray pulses so it is more tricky to debug your code and capture just the IR signal to look at and analyze and repeat. Vishay makes some good receivers and they are available at www.newark.com They are 1 to 2 dollars each. The easiest thing would be to buy one of each carrier frequency and see which responds to the IR remote. The receivers are easy to use. 3 pins -- +5v, GND, and signal. The signal has the carrier removed so it is coded pulse train that you need to decode. Connect this pin to an external interrupt input on the PIC. I use the 16F877 and 18Fxx2 PICs and with those I connect the IR signal to RC2 which is the CCP2 input. You can write a simple ISR that gets called when ever the signal has a falling edge edge or a rising edge. Its too bad that you can't make the ISR fire on both a falling and rising edge. Maybe your PIC allows that. If not, after the ISR is called, you can poll the pin to see when it changes back. If you know what protocol you are expecting you often only need the time between falling edges to decode the signal. If your PIC is not expected to do any other work (at least while it is learning a code), you could just poll the pin continuously and record the time between each transition. You have two ways to go from here. One would be to capture the signals from the remote in a way that you could look at them. A storage scope would be real easy - just apply power to the receiver and look at the signal pin on the scope. If you don't have one, though, hook up your PIC and write a test program to write out the time between each signal edge so that you could plot it manually. By studying the signals, you might be able to figure out the protocol, and decode them into their N-bit binary commands. Then to send out the signal, you would encode the bits of the command back into the IR pulse train. The other way is to ignore the protocol and just record the exact pulse train. For example, 9500us on, 4500us off, 600us on, 500us off ... (us=micro seconds) Then, to playback the IR command you just repeat what you recorded. The only disadvantage is that the pulse train requires a lot more storage space. A signal might require 60-80 bytes to store like this when the actual command that it represents is a mere 4 byte number. Since there are so many IR protocols out there, most learning remotes do it this way. You could use a cheap serial eeprom to store the signals if there is not enough room in your PIC. Once you have your signal, (either by calculating the on and off times from the command bits, or by just replaying what you recorded) you drive it out on a PIC output pin. That pin goes to one input a two input AND gate. The other input is connected to an oscillator that is continuously running at what ever carrier frequency the toy uses (example a 555 timer set to oscillate). The output of the AND gate drives an IR LED. When the PIC output is low, the AND output is low no matter what the state of the other input (the carrier clk) and the LED is off - solid. When the PIC output is high, the output follows the state of the other input, which is oscillating at the carrier frequency and the LED flashes on and off at the carrier frequency. There are other ways to do this, but this would work well for hobbiest purposes and illustrates how it works. Good luck. BTW, are these the small table top laser tanks that I see all over, or the larger, cheaper, scale looking tanks? My brother-in-law got the larger ones from some cheap holiday gift catalog and they are great. We had lots of fun trying to beat our nephew. --BobG -----Original Message----- From: pic microcontroller discussion list [mailto:PICLIST@MITVMA.MIT.EDU]On Behalf Of Eric T. Brewer Sent: Monday, January 13, 2003 9:30 PM To: PICLIST@MITVMA.MIT.EDU Subject: Re: [PIC]: Learning a single IR code IR is one of the consumer electronics dirty little messes. It seems, anytime an engineer designs an IR controlled device, they come up with their own protocol. (By protocol, I mean not only the data format, but the carrier frequency as well.) No kidding. Sony, for example, has 6 or so different IR protocols. Many manufacturers have several. And, the difference in protocols can be quite substantial (even for the same manufacturer). Some highlights. 1. Carrier frequency. Most IR protocols consist of turning an IR LED on/off at some frequency. Many are 40Kc (40,000 cycles per second). The range of common carrier frequencies is 25Kc to 56Kc. Although, there are some at 500Kc. Flourescent lights generate a lot of light noise at 16 to 18Kc. So, with a carrier freq substantially above 16-18Kc, you get rid of a major source of noise/interference. Many receivers have a narrow band pass filter (+/- 3Kc). This rejects noise and other IR devices not at the same frequency. The biggest concern is getting rid of flourescent lamp noise. Most of the IR formats use On-Off-Keying (OOK). That is, they turn the carrier ON and OFF. 2. Sync Pulse - Usually, at the beginning of a transmission, a long pulse is transmitted. The receiver uses the falling edge (when the signal goes away) to synchronize with the transmitter. This pulse is usually 5x-10x longer than any pulses in the rest of the data. Hence, it is difficult for any data bits to accidentally reset the receiver state. 3. Header - Some special sequence of bits are output to say a new data packet is coming. (Sync pulse is an example of this. Another example is sending out 1010_1010 [0xAA] and making sure there are no key codes which are 0xAA.) 3. Data format. Let your imagination run wild. The most common (which leads to enough variations all by themselves) are listed below. PWM - Pulse Width Modulation - The width of each pulse determines whether a bit is a 0 or 1. For examples, a 0 may be 100us ON and 100us OFF and a 1 may be 150us ON and 50us OFF. This would have each bit always be 200us in time. Another format may be, 0=100us ON and 100us OFF. A 1 bit is 150us ON and 100us OFF. Here, each bit time would be data dependent. PPM - Pulse Position Modulation - Where the pulse shows up determines whether it is a 1 or a 0. For example, assume each bit time is always 200us. A 0 could be 50us ON and 150us OFF. A 1 bit, can be 50us OFF, 50usON, and 100us OFF. Of course, any number of modulation methods can be used. AM/FM/QAM. You name it. But, for the most part, PPM and PWM are used. 4. Repeat. What to do when a key is held down (repeat the key). Most protocols use one of three solutions: Repeat Pulse - Every N milliseconds, output a short pulse. I think some of the Sony protocols output a 1ms pulse every 20ms (or 100ms) to indicate a key is being held down. Repeat Code - Every N milliseconds output a special key code which means repeat whatever was last received. Key Code - Every N milliseconds, output the same key code data again. This has the disadvantage of the receiver not being able to unambiguously distinguish a key being repeated from a new key press as repeated keys just look like new key presses. 5. Trailer - Some protocols need some special bit sequence to make sure the packet is valid. An example, would be to send a 0101_0101 [0x55] at the end of packet. And, make sure that 0x55 is not a valid key code. As you can see I have used some all over the place. There are just no standard protocols (data formats or bit timings). The closest thing there is to a standard is the carrier frequency. Many are 25Kc, 32Kc, 36Kc, 38Kc, or 40Kc. That said, you are lucky because you are dealing with just one device. What you need is a digital storage scope or logic analyzer to capture some signals from the toy. First you need to figure out the carrier frequency. This is best done with a photo diode. You need this so you can transmit your packets using the correct carrier frequency. Also, you can then order a IR receiver which has the correct band pass filter built in (you can build your own, just a bit more work to save yourself 10 cents.) Next, you need to figure out the data format. Capture several different key codes and compare them. You need to reverse engineer the format. Hopefully, the above give you some hints of what to look for. Once you know all of this, the schematics and the code are straight forward. I hope this helps. cheers, eric >Sorry if this is a waste of anyone's time. I looked through the archives and >found a lot of stuff on IR and learning IR codes but nothing particular >enough. > >I want a PIC to grab an IR signal from a toy's remote control, learn it, and >then be able to retransmit it when a button is pressed. I want it to stop >looking for IR signals when I have not put it in learning mode. The code is >a problem for me, but not so big a problem as the circuitry. I don't work >with IR much, and I don't know exactly what to do to it to make the PIC >properly interpret it and transmit it the same exact way. Is it as simple as >an IR LED and phototransistor going to pins on the PIC? I don't think so. > >Here's the data I can provide: >The PIC is a 16F628. >The IR signal may be on a carrier wave, because when I press any button on >the controller and put the IR LED really close to my eye, I see 4 >evenly-spaced dim red flashes. Last I checked, that meant carrier wave. >However, the flashes are kinda slow, about 1/4 of a second apart, and the >toy responds instantly when a button is pressed, so I'm not really sure. >The toy, in case anyone knows anything about them, is a Rumble Wars >remote-controlled "laser tag" vehicle. > >Can someone help me with code (in MicroBASIC or ASM) and/or a schematic, >and, most importantly, tell me how it works so I can learn? > >Don't get too complex, I'm kind of new at PIC, and still a little wobbly >with digital electronics. I can put stuff together from a schematic, and I >understand every schem. symbol there is (really, I mean every dang symbol >ever used, I put some serious time into that), but sometimes I won't know >why there's a capacitor here or a resistor there, etc. > >-- >http://www.piclist.com hint: The list server can filter out subtopics >(like ads or off topics) for you. See http://www.piclist.com/#topics -- -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.