3
\$\begingroup\$

I am want to design a remote control. All I need is the appropriate IR LED and the Receiver to use, that will yield optimal performance. i need real practical experience here.

  1. What is the best receiver to use. Photo diode or a Photo transistor.
  2. As regards the distance. This remote control ought to work like that if the Indoor AC,radio or TV sets, where at a distance of about 10-12 Feet maximum. Also I am considering a good reception angle for the receiver.

I have know about the modulation method, which I believe is the best. So how do I possibly go about it.

Circuits diagrams, components data sheets, and detailed analysis will be greatly appriciated.

Thank you all.

\$\endgroup\$
2
  • \$\begingroup\$ @starblue - that's a strange link. You have to select a country, but despite over 20 European countries on the list there are only 2 western-European countries (Iceland and Malta). A strange list indeed. \$\endgroup\$
    – stevenvh
    Commented Nov 13, 2011 at 10:57
  • \$\begingroup\$ Strange indeed. It looked different yesterday, it did a search for infrared. The reason the countries are missing is probably because this is the default "Export" site for countries that don't have a dedicated one. I chose it because I didn't want to use the german site. \$\endgroup\$
    – starblue
    Commented Nov 13, 2011 at 11:22

3 Answers 3

Reset to default
1
\$\begingroup\$

As starblue says, standard recievers are available for this. Here are some options for recievers. Another list of emitters.
Using a ready made reciever is a lot easier than making your own. They contain filtering and adapt for ambient light conditions. Matching this performance is difficult and not really worth it given the cheap price you can buy them for.

You need to choose an emitter/reciever pair with matched wavelength. Then you will need to modulate your emitter in burst for 1's and 0's at the stated frequency of the reciever.

You can choose which protocol you wish you use - RC5 is a simple and popular one. I hacked a little PIC based remote to work the sky box using RC5. This link helped a bit.
On the same site there is more useful info on other protocols and basic Remote Control theory.

\$\endgroup\$
1
  • \$\begingroup\$ One caveat with the ready-made receivers I've seen: when they are receiving a nicely-modulated IR signal they'll generally output a fairly clean waveform, except that the rising and falling edges may be delayed by different amounts. When they are not receiving a modulated signal, however, many of them will output a lot of junk. This has two notable effects: (1) You should check to ensure all the rising and falling edges are as expected, rather than simply checking the input level periodically; (2) If you want to sleep but use the IR to 'wake up', you'll get many extraneous wake-up events. \$\endgroup\$
    – supercat
    Commented Nov 14, 2011 at 15:53
2
\$\begingroup\$

Like Olin and Oli already mentioned there are parts which do just that. In my opinion Vishay has the most complete offering, regarding frequency, package and protocol.

You can build a receiver yourself, but despite their appearance — a simple three-legger —

enter image description here

they contain quite some electronics, which you may find hard to reproduce yourself using discrete components:

enter image description here

  • The input stage converts the photodiode's current to a voltage.
  • The AGC adapts the sensitivity so that code appears at the right level.
  • The bandpass filter suppresses unwanted frequencies, like from fluorescent lamps.
  • And the demodulator removes the carrier and recovers the baseband signal.

It's not impossible to build this yourself, but it's a silly exercise really, given the low price and the reliability of readily available parts.

\$\endgroup\$
4
  • \$\begingroup\$ thanks. With this receivers, will I still implement the Manchester Encoding?. i really do not intend using the RC5 protocol. I am thinking on working on a self-designed protocol. \$\endgroup\$
    – Paul A.
    Commented Nov 14, 2011 at 10:30
  • \$\begingroup\$ @Paul - check the Vishay website, and look for a protocol which matches yours most closely, especially regarding the pulse/pause ratio in your baseband signal. \$\endgroup\$
    – stevenvh
    Commented Nov 14, 2011 at 10:58
  • \$\begingroup\$ "pulse/pause ratio in your baseband signal".....meaning? \$\endgroup\$
    – Paul A.
    Commented Nov 14, 2011 at 11:37
  • \$\begingroup\$ @Paul - your baseband signal is the unmodulated signal, the bottom traces in the screenshots here. The pulse/pause ratio is the ratio between the time the signal is high and the time the signal is low. \$\endgroup\$
    – stevenvh
    Commented Nov 14, 2011 at 11:58
1
\$\begingroup\$

There are off the shelf chips that do most of the receiving part for you. Check out the Vishay TSOP line. I know Sony and others have similar things.

Because of ambient light, you need to modulate your data on a carrier so that the receiver can ignore the steady light level and work on rapid changes only. The integrated receivers come in a variety of fixed carrier frequencies roughly in the 35-50 kHz range. They put out a single signal that indicates that carrier was detected or not.

Data is encoded in the timing of the carrier bursts. If I was doing this from scratch, I'd probably use manchester encoding of the data, with a short level being 15 carrier cycles and a long one 30. This fits well with what the integrated receiver modules are designed to detect. Once you have the manchester data stream, on the transmitter side you emit carrier when it is high and nothing when it is low. On the receiver side, the manchester data stream comes out of the integrated receiver module directly.

\$\endgroup\$
9
  • \$\begingroup\$ The manchester data may come out directly, but it may make sense to still "examine" it rather than blindly accepting it - I once spent a few days re-writing someone else's receiver code to tolerate occasional noise pulses we were getting out of the receivers sourced in asia by our factory, unlike the domestically sourced ones used in the prototypes. It occurs to me now this could have been a case of counterfeit components, but still software improvements solved it. Was also fun to capture specific noise occurances on a DSO, transfer to a waveform generator and fix the software to understand. \$\endgroup\$
    – Chris Stratton
    Commented Nov 11, 2011 at 15:28
  • \$\begingroup\$ @Chris: Yes, any time you transmit data over the air, whether by radio or light, you have to assume some finite probability of error. This is typically handled by sending data in packets with checksums. There are also some clever tricks to make manchester more reliable. In the end though, you can never count on any one packet getting thru, so you send multiple packets with the same data. Ultimately however, you can't guarantee delivery without the ability to talk back. \$\endgroup\$
    – Olin Lathrop
    Commented Nov 11, 2011 at 15:33
  • \$\begingroup\$ Checksum and repetition gets particularly complicated in the case of something like the channel up/down buttons - you want one reliable increment per push, but you can have many pushes in sequence - though it still can be done by numbering the messages to be repeated. In this case the transmitters were already manufactured with a simple data format, so we were limited to making the receivers ignore "implausible" pulses to recover otherwise valid frames. \$\endgroup\$
    – Chris Stratton
    Commented Nov 11, 2011 at 15:38
  • \$\begingroup\$ @Chris: in the case of channel up/down, don't forget the human in the loop. If you press channel up and nothing happens, you'll just press it again. As long as it does work most of the time, you probably don't give it much attention. The system is reliable because there is a backwards channel, which is the human looking at the TV set to see if the requested action was performed. \$\endgroup\$
    – Olin Lathrop
    Commented Nov 11, 2011 at 15:53
  • \$\begingroup\$ Actually it turns out that unreliable increment / decrement is a notable user annoyance, and was why we were asked to look into the situation. Though there may be an aspect of your point in that we didn't have to assure that the improved firmware was 100% noise immune, just that it was immune to the noise we sampled (which confused the old code) and did not fail often enough to notice. \$\endgroup\$
    – Chris Stratton
    Commented Nov 11, 2011 at 15:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.