# Cheapest way to do an IR re-transmitter (IR protocol agnostic, dumb device is good enough)

Looking out for ways to retransmit IR, bi-directionally, like this:

[IR TX-A]----->[IR RTR-1]------>[IR RTR-2]------>[IR RX-B]
[IR RX-A]<-----[        ]<------[        ]<------[IR TX-B]


My interest, is in the "IR RTR" device which can retransmit received IR data bidirectionally, s.a. to increase effective distance. While if it is specific to the IR protocol, it is fine, but if it cheaper / easier to behave in a protocol agnostic way, i.e. received signal is just amplified as-is and fed "dumbly" on the transmitter LED, without needing any transmitter, this is quite acceptable, unless of-course it might introduce significant noise, s.t. it becomes difficult / expensive to deal with on the other end.

If there are ready schematics for this, would be glad to be pointed to it.

BTW, I have nothing against a uC based approach, but I'm probably keeping that option as a backup, since my requirements in order of priority are:

1. Low cost - My target is a sub \$5 BOM -- all components, PCB, battery holder etc. included, but except the enclosure.
2. Low power consumption - This is probably going to be the hardest part, given how power-hungry IR LEDs are. Maybe I am dreaming, but it'd be great to see this circuit run-off disposable batteries (like the A23 or PP9), for last for at least 6 months without a change.
3. Small size - I'd like to keep it no bigger than a box of Altoids.

Edit: I do not need this to function as a universal remote control range extender, i.e. I am also quite happy if this little device of mine can act as a bidirectional signal repeater for a specific carrier frequency, modulation-type which might well be proprietary and chosen so as to avoid interference and effects of ambient noise.

• Throughput of 80-100bps is good enough, excluding the error-check/correction overhead
• Communication is bursty but cannot be predicted. However communication during a burst is a repeated transmission of same information several times, s.t. if receiver can sleep/wakeup fast enough, it shouldn't miss information. Information is a 10 byte packet, that is sent upto 10 times, with/without acknowledgement.
• The RX/TX IR-pair in each end-node, and the repeater need to be placed close together to make a compact pair, but I am hoping of avoiding interference between the pair by having some optical barrier between them, similar to double-barrel gun.
• Typical distance between end-node and repeater, I hope to achieve, is 10-12feet.
• Your specs are missing a few important issues: 1. which speed do you need (for instance IR-remote like, or more like IRDA); 2. for battery lifetime: what is the active (IR tretransmitting) percentage of time? 3. what is the distance from the retransmit LED to the receiving gadget? 4. (least important) what is the electronic distance? – Wouter van Ooijen Dec 26 '11 at 13:02
• As Wouter says, it will be critcal to know the protocol or data rate you're working with to be able to give a solid answer. Also consider directionality. Does your system have any receivers that will have both the repeater (what you called a retransmitter) and the original transmitter in line of sight? if so, you have to worry about the interference between the two sources as seen at the receiver. – The Photon Dec 26 '11 at 19:01
• Updated my question with the information. – icarus74 Dec 27 '11 at 9:05

One would think the purest way is to use a photodiode to drive a transistor, which in turn drives an infrared LED. Let's call it the three parts solution (actually you also need a small series transistor for the LED). This can be done, but it has the disadvantage that everything the photodiode detects gets amplified, including noise it picks up. You don't want that.

OTOH, IR receiver modules are usually tuned to a specific protocol and frequency, but if the used frequencies are close a single receiver may be used. The module includes a filter around the center frequency, which eliminates noise, together with an AGC (Automatic Gain Control) stage, which also helps eliminating unwanted (low level) signals, like the radiation from HF fluorescent lamps. But if no real signal is present the AGC will amplify the incoming noise to a normal signal level. And this noise will be retransmitted. When a real signal is received the AGC's amplification will be adjusted, and the noise will be suppressed, so a real signal will come through properly, despite high noise levels when not transmitting.
So while there will also be a lot of noise picked up and retransmitted by an IR receiver module, just like the three parts solution. The disadvantage of the latter is that it won't suppress the noise if a proper signal is detected. Its advantage is that it's protocol-independent.

As for power, this is a tall order. The three component solution will transmit noise all of the time, and will drain the battery fast. The receiver module contains more electronics, and will draw around 0.5 to 1 mA. Which is also too much to let the battery last six months.

edit
If the power is really premium you may have to stick to a specific protocol and decode the received commands before retransmitting. The $\mu$C will consume some power too, but will cause the LED to remain off for most of the time, like up to 99.99%, since it won't transmit noise, just valid commands. It's possible to program the $\mu$C to decode multiple protocols, but like I said earlier, they'll have to have close characteristics, like pulse-pause ratio and carrier frequency.

• Thanks. I have edited my question slightly. Would be nice to see if you think that it might have an impact on reliability / complexity of the circuit. – icarus74 Dec 26 '11 at 10:17

You say a dumb device is "good enough", but I would suggest that it will probably be easier to make a "smart" device that works well than a "dumb" device that works equally well. For a "dumb" device to work well, it's important that it faithfully capture all of the transitions on the incoming signal so that it can forward them precisely. For example, suppose that the protocol requires that there be no more than 20us deviation between the time an edge occurs and the time it's supposed to occur. If you use a "dumb" repeater, then the combined uncertainty of your device and the device it's sending to would have to be 20us or less. By contrast, if you use a "smart" repeater, then both links could tolerate 20us of uncertainty each.