1
\$\begingroup\$

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.

Edit (#2): Adding some more information about the comm. needs:

  • 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.
\$\endgroup\$
3
  • 1
    \$\begingroup\$ 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? \$\endgroup\$ Commented Dec 26, 2011 at 13:02
  • \$\begingroup\$ 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. \$\endgroup\$ Commented Dec 26, 2011 at 19:01
  • \$\begingroup\$ Updated my question with the information. \$\endgroup\$ Commented Dec 27, 2011 at 9:05

2 Answers 2

Reset to default
5
\$\begingroup\$

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.

\$\endgroup\$
1
  • \$\begingroup\$ 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. \$\endgroup\$ Commented Dec 26, 2011 at 10:17
3
\$\begingroup\$

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.

Addendum

Reading some more about your specs, you don't seem to specify what sort of transmission delays are acceptable. It may be helpful to have a system whereby there is a designated 100ms spot during every five-second interval where a packet transmission must begin; units would exchange messages often enough to keep their clocks synchronized within 20ms. Depending upon what sort of compensated accuracy you can get with units' clocks, you may be able to do a very effective job of minimizing 'listening' time. Whether this is a good approach would depend upon how much delay you can tolerate in forwarding packets, and also how often you expect units to actually be transmitting data. A synchronized-listening approach would add 'idle' traffic, but would could reduce the number of times that packets have to be retransmitted.

\$\endgroup\$
5
  • \$\begingroup\$ Thanks @supercat. The consensus does seem to be in this direction. In this particular case, I am at liberty to define the communication protocol, if it makes help make the communication infrastructure "cheaper" and help them run off batteries. \$\endgroup\$ Commented Dec 27, 2011 at 9:09
  • \$\begingroup\$ @icarus74: Feel free to post any information you have that you think would help me provide any information or ideas you need. I've done four general kinds of repeaters: (1) protocol-agnostic; (2) low-level signaling aware, with minimal buffering and no ack/retry logic; (3) high-level protocol aware, with full buffering but no ack/retry logic; (4) high-level protocol aware, with full buffering and ack/retry logic (meaning the repeater acknowledges the packet before trying to send it on). \$\endgroup\$ Commented Dec 27, 2011 at 18:17
  • \$\begingroup\$ @icarus74: A repeater that knows the low-level signaling but not the high-level protocol details may be able to do a good job of transmitting the signal through multiple generations without too much delay. In an IR system, for example, such a system might know that all pulses trains are supposed to be 100us or 200us long, and retransmit 75us-125us trains as 100us trains, 175us to 225us trains as 200us, and drop all others; depending upon precise implementation the delay would probably be about 200us. \$\endgroup\$ Commented Dec 27, 2011 at 18:20
  • \$\begingroup\$ @icarus74: A buffering system would read a whole packet of data and, if it's valid, send it along. This system would reduce the number of spurious signals that would get passed along (a stray 80us pulse received by the first type of repeater would be retransmitted as a perfect 100us pulse, which would get sent along to everyone as a perfect 100us pulse) but would have the disadvantage of adding considerable delay. If the original sender will expect an acknowledgment of its transmission, such delays might cause the originator to time out before the packet and reply could... \$\endgroup\$ Commented Dec 27, 2011 at 18:22
  • 1
    \$\begingroup\$ ...make the round trip. Having the original receiver acknowledge the packet before passing it along avoids the time-out problem, but creates the possibility of a packet getting lost. Some systems use a double-ack scheme, with a low-level ack that indicates the next link received the packet, and a high-level ack that indicates the final recipient got the packet. Under such a scheme, the sender may retransmit the packet very quickly if it fails to receive the low-level ack, but still be able to wait a second or two for a high-level ack. \$\endgroup\$ Commented Dec 27, 2011 at 18:24

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.