La forma más económica de hacer un retransmisor IR (el dispositivo tonto es lo suficientemente bueno)

Buscando formas de retransmitir IR, bidireccionalmente, así:

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

Mi interés está en el dispositivo "IR RTR" que puede retransmitir los datos IR recibidos bidireccionalmente, para aumentar la distancia efectiva. Mientras que si es específico para el protocolo IR, está bien, pero si es más barato / más fácil comportarse de una manera agnóstica del protocolo, es decir, la señal recibida se amplifica tal cual y se alimenta "tontamente" en el LED del transmisor, sin necesidad de transmisor, esto es bastante aceptable, a menos que, por supuesto, pueda introducir un ruido significativo, por lo que se vuelve difícil / costoso de manejar en el otro extremo.

Si hay esquemas listos para esto, estaría encantado de ser señalado.

Por cierto, no tengo nada en contra de un enfoque basado en uC, pero probablemente mantenga esa opción como respaldo, ya que mis requisitos en orden de prioridad son:

  1. Bajo costo: mi objetivo es una lista de materiales de menos de $ 5: todos los componentes, PCB, soporte de batería, etc. incluidos, excepto el gabinete.
  2. Bajo consumo de energía: esta será probablemente la parte más difícil, dado el gran consumo de energía de los LED IR. Tal vez estoy soñando, pero sería genial ver que este circuito se agote con baterías desechables (como la A23 o la PP9), durante al menos 6 meses sin cambios.
  3. Tamaño pequeño: me gustaría mantenerlo no más grande que una caja de Altoids.

Editar: no necesito que esto funcione como un extensor de rango de control remoto universal, es decir, también estoy muy contento si este pequeño dispositivo mío puede actuar como un repetidor de señal bidireccional para una frecuencia portadora específica, tipo de modulación que bien podría ser patentado y elegido de forma que se eviten las interferencias y los efectos del ruido ambiental.

Editar (n. ° 2): agregar más información sobre la comunicación. necesidades:

  • El rendimiento de 80-100bps es lo suficientemente bueno, excluyendo la sobrecarga de verificación/corrección de errores
  • La comunicación es a ráfagas pero no se puede predecir. Sin embargo, la comunicación durante una ráfaga es una transmisión repetida de la misma información varias veces, por lo que si el receptor puede dormir/activarse lo suficientemente rápido, no debería perder información. La información es un paquete de 10 bytes, que se envía hasta 10 veces, con/sin acuse de recibo.
  • El par IR RX/TX en cada nodo final y el repetidor deben colocarse juntos para formar un par compacto, pero espero evitar la interferencia entre el par al tener una barrera óptica entre ellos, similar a la doble. pistola de cañón.
  • La distancia típica entre el nodo final y el repetidor, que espero lograr, es de 10 a 12 pies.
A sus especificaciones les faltan algunas cuestiones importantes: 1. qué velocidad necesita (por ejemplo, como IR-remoto, o más como IRDA); 2. para la vida útil de la batería: ¿cuál es el porcentaje de tiempo activo (tretransmisión IR)? 3. ¿Cuál es la distancia desde el LED de retransmisión hasta el dispositivo receptor? 4. (menos importante) ¿cuál es la distancia electrónica?
Como dice Wouter, será fundamental conocer el protocolo o la tasa de datos con la que está trabajando para poder dar una respuesta sólida. Considere también la direccionalidad. ¿Tiene su sistema algún receptor que tenga tanto el repetidor (lo que llamó un retransmisor) como el transmisor original en la línea de visión? si es así, debe preocuparse por la interferencia entre las dos fuentes como se ve en el receptor.
Actualicé mi pregunta con la información.

Respuestas (2)

Uno pensaría que la forma más pura es usar un fotodiodo para controlar un transistor, que a su vez controla un LED infrarrojo. Llamémoslo la solución de las tres partes (en realidad, también necesita un transistor de serie pequeña para el LED). Esto se puede hacer, pero tiene la desventaja de que todo lo que detecta el fotodiodo se amplifica, incluido el ruido que capta. No quieres eso.

OTOH, los módulos receptores IR generalmente se sintonizan a un protocolo y frecuencia específicos , pero si las frecuencias utilizadas son cercanas, se puede usar un solo receptor. El módulo incluye un filtro alrededor de la frecuencia central, que elimina el ruido, junto con una etapa AGC (Automatic Gain Control), que también ayuda a eliminar señales no deseadas (de bajo nivel), como la radiación de las lámparas fluorescentes HF. Pero si no hay una señal real presente, el AGC amplificará el ruido entrantea un nivel de señal normal. Y este ruido será retransmitido. Cuando se recibe una señal real, la amplificación del AGC se ajustará y el ruido se suprimirá, por lo que la señal real llegará correctamente, a pesar de los altos niveles de ruido cuando no se transmite.
Entonces, aunque también habrá una gran cantidad de ruido recogido y retransmitido por un módulo receptor IR, al igual que la solución de tres partes. La desventaja de este último es que no suprimirá el ruido si se detecta una señal adecuada. Su ventaja es que es independiente del protocolo.

En cuanto al poder , esta es una tarea difícil. La solución de tres componentes transmitirá ruido todo el tiempo y agotará la batería rápidamente. El módulo receptor contiene más componentes electrónicos y consumirá alrededor de 0,5 a 1 mA. Lo que también es demasiado para dejar que la batería dure seis meses.

editar
Si la potencia es realmente premium, es posible que deba ceñirse a un protocolo específico y decodificar los comandos recibidos antes de retransmitirlos. El m C también consumirá algo de energía, pero hará que el LED permanezca apagado la mayor parte del tiempo, como hasta un 99,99 %, ya que no transmitirá ruido, solo comandos válidos. Es posible programar el m C para decodificar múltiples protocolos, pero como dije antes, deberán tener características cercanas, como la relación pulso-pausa y la frecuencia de la portadora.

Gracias. He editado mi pregunta ligeramente. Sería bueno ver si cree que podría tener un impacto en la confiabilidad/complejidad del circuito.

Usted dice que un dispositivo tonto es "suficientemente bueno", pero sugeriría que probablemente sea más fácil hacer un dispositivo "inteligente" que funcione bien que un dispositivo "tonto" que funcione igualmente bien. Para que un dispositivo "tonto" funcione bien, es importante que capture fielmente todas las transiciones en la señal entrante para que pueda reenviarlas con precisión. Por ejemplo, suponga que el protocolo requiere que no haya más de 20 us de desviación entre el momento en que ocurre un borde y el momento en que se supone que debe ocurrir. Si usa un repetidor "tonto", entonces la incertidumbre combinada de su dispositivo y el dispositivo al que está enviando tendría que ser de 20us o menos. Por el contrario, si utiliza un repetidor "inteligente", ambos enlaces podrían tolerar 20 us de incertidumbre cada uno.

Apéndice

Al leer un poco más sobre sus especificaciones, no parece especificar qué tipo de retrasos en la transmisión son aceptables. Puede ser útil tener un sistema en el que haya un punto designado de 100 ms durante cada intervalo de cinco segundos donde debe comenzar la transmisión de un paquete; las unidades intercambiarían mensajes con la frecuencia suficiente para mantener sus relojes sincronizados dentro de los 20 ms. Dependiendo del tipo de precisión compensada que pueda obtener con los relojes de las unidades, es posible que pueda hacer un trabajo muy efectivo para minimizar el tiempo de "escucha". Si este es un buen enfoque dependerá de la cantidad de demora que pueda tolerar en el reenvío de paquetes, y también de la frecuencia con la que espera que las unidades transmitan datos. Un enfoque de escucha sincronizada agregaría tráfico 'inactivo', pero podría reducir la cantidad de veces que los paquetes deben retransmitirse.

Gracias @supercat. El consenso parece estar en esta dirección. En este caso particular, tengo la libertad de definir el protocolo de comunicación, si ayuda a que la infraestructura de comunicación sea "más barata" y ayuda a que se agoten las baterías.
@icarus74: Siéntase libre de publicar cualquier información que tenga y que crea que me ayudaría a brindarle cualquier información o idea que necesite. He hecho cuatro tipos generales de repetidores: (1) protocolo-agnóstico; (2) consciente de la señalización de bajo nivel, con almacenamiento en búfer mínimo y sin lógica de reconocimiento/reintento; (3) reconocimiento de protocolo de alto nivel, con almacenamiento en búfer completo pero sin lógica de reconocimiento/reintento; (4) reconocimiento de protocolo de alto nivel, con almacenamiento en búfer completo y lógica de reconocimiento/reintento (lo que significa que el repetidor reconoce el paquete antes de intentar enviarlo).
@icarus74: un repetidor que conoce la señalización de bajo nivel pero no los detalles del protocolo de alto nivel puede hacer un buen trabajo al transmitir la señal a través de varias generaciones sin demasiado retraso. En un sistema IR, por ejemplo, dicho sistema podría saber que se supone que todos los trenes de pulsos tienen una longitud de 100us o 200us, y retransmitir trenes de 75us-125us como trenes de 100us, trenes de 175us a 225us como trenes de 200us, y descartar todos los demás; dependiendo de la implementación precisa, el retraso probablemente sería de unos 200 us.
@icarus74: un sistema de almacenamiento en búfer leería un paquete completo de datos y, si es válido, lo enviaría. Este sistema reduciría la cantidad de señales espurias que se transmitirían (un pulso perdido de 80us recibido por el primer tipo de repetidor se retransmitiría como un pulso perfecto de 100us, que se enviaría a todos como un pulso perfecto de 100us) pero tienen la desventaja de añadir un retraso considerable. Si el remitente original esperará un reconocimiento de su transmisión, dichos retrasos pueden hacer que el emisor se agote antes de que el paquete y la respuesta puedan...
... hacer el viaje de ida y vuelta. Hacer que el receptor original reconozca el paquete antes de pasarlo evita el problema del tiempo de espera, pero crea la posibilidad de que se pierda un paquete. Algunos sistemas utilizan un esquema de doble reconocimiento, con un reconocimiento de bajo nivel que indica que el siguiente enlace recibió el paquete y un reconocimiento de alto nivel que indica que el destinatario final recibió el paquete. Bajo tal esquema, el remitente puede retransmitir el paquete muy rápidamente si no recibe el acuse de recibo de bajo nivel, pero aun así puede esperar uno o dos segundos por un acuse de recibo de alto nivel.