# [Aporte] Decodificador IR RC5 y SONY para control de 8 canales + 1 canal PWM



## D@rkbytes (Ene 29, 2014)

Este proyecto se trata de un decodificador de control remoto IR para los protocolos RC5 de Philips y el de SONY.
El sistema puede controlar 8 canales y también cuenta con un canal para generación de PWM a 1KHz.

Para utilizar un control remoto Philips, se usan los comandos numéricos del 1 al 8 para el control de los canales.
Para el control del ciclo activo del PWM se usa la tecla CH+ y la tecla CH-
Vol+ activa todos los canales y Vol- los desactiva.

Y para utilizar un control remoto Sony, se usan los comandos numéricos del 2 al 9 para el control de los canales.
Para el control del ciclo activo del PWM se usa la tecla Vol+ y la tecla Vol-
CH+ activa todos los canales y CH- los desactiva.

Para el control de los canales, al presionar por ejemplo la tecla 1, se activa el canal 1 y al presionar nuevamente la tecla el canal se desactiva, igualmente para los otros canales.

El sistema detecta todos los comandos válidos de los protocolos.
Cuando se detecta un comando fuera de los de control, se hace destellar un LED.

También incluí una salida serial RS-232 para obtener el valor de los comandos @ 9600bps.
Esta salida es únicamente para depuración del sistema y puede quedar sin conexión.
Por esta salida se envía unicamente el valor de los comandos fuera de los de control.

Notas:
Para la etapa de potencia se pueden usar transistores, SCR's, triacs, relevadores, etc.
En el esquema se muestran unicamente los LED's de monitoreo de los canales.

Para la etapa de potencia del control PWM se puede usar un transistor NPN o un Mosfet canal N.
Con esta etapa se puede controlar la velocidad de un motor DC, algún LED o lampara.
Se debe usar en configuración de Emisor/Fuente (Source) común.

Adjunto los archivos *.hex, el código fuente en Basic de Proton IDE y el diagrama esquemático.

Espero que este proyecto sea de su agrado y utilidad.

Saludos y suerte.


----------



## Fogonazo (Ene 31, 2014)

No había visto este aporte, *! Gracias ¡ D@rkbytes*


----------



## cristian76 (Ago 10, 2015)

Una consulta darkbytes mi unica duda seria el LIR1 , solo conseguiria un led infrarojo receptor ? gracias de igual modo , muy completo el aporte  .
https://www.forosdeelectronica.com/members/d-rkbytes/


----------



## TRILO-BYTE (Ago 11, 2015)

hijoles hiva hacer un aporte de eso pero para el control SONY en C

creo que me tarde mucho hare entonces el aporte de la LCD SPI


----------



## D@rkbytes (Ago 11, 2015)

cristian76 dijo:


> Una consulta D@rkbytes. Mi única duda sería el LIR1. ¿Sólo conseguiría un led infrarrojo receptor?


Te recomiendo usar un receptor infrarrojo del tipo TSOP17. Por ejemplo *TSOP1738*




​


----------



## TRILO-BYTE (Ago 11, 2015)

no recuerdo como se llaman pero en electronica a los receptores les llaman *REMCON* si me equivoco que alguien me corrija.

lo digo por que receptores infrarrojos hay muchos y de diferentes numeros de parte y fabricantes

son fototransistores con un amplificador y filtro pasabanda en un encapsulado raro de 3 a 4 patitas

por si nadamas quieren ponerle un fototransistor asi no funcionaria


----------



## Gerson strauss (Ago 13, 2015)

¡Genial! precisamente quería hacer algo asi para controlar un pequeño "robot". Gracias.


----------



## cristian76 (Ago 14, 2015)

El detalle que veo es que el tsop1738 consta de 3 patillas y en el diagrama que publicastes solo son 2 pareciendo un led infrarojo , un favor si pudieras aclararme esa duda que tengo , gracias .


----------



## D@rkbytes (Ago 14, 2015)

¿Miraste la hoja de datos?


D@rkbytes dijo:


> Te recomiendo usar un receptor infrarrojo del tipo TSOP17. Por ejemplo *TSOP1738*


Pin 1 = GND
Pin 2 = Vs (B+ 5V Typical)
Pin 3 = Out

El TSOP1738 es un foto módulo receptor PCM que internamente tiene el filtro pasa banda, el demodulador y el amplificador.
Conecta el pin 1 a negativo, el pin 2 lo conectas a + 5V y la salida es por el pin 3.




​


----------



## asherar (Oct 1, 2016)

Hola D@rkbytes. 

Disculpa que pregunte esto siendo que el programa data de varios años. 
A veces no me acuerdo de lo que yo mismo programé apenas unas semanas atrás.

En general no encuentro dificultad para comprender la parte Hardware, pero sí 
me gustaría saber el motivo de elegir la patilla RA4/TOKI/CMP2 para ingresar 
la señal del sensor. ¿ Es que usa la portadora como reloj ?

Además, hay algo que no encuentro en el código, y es la parte donde se decodifica 
el protocolo. Me refiero a la parte donde se reciben la señal IR "virgen" del sensor 
y se detecta el inicio de la trama, los diferentes bits, etc. 
No lo veo en el ".BAS". Si son detalles que coloca el compilador al generar el ".ASM" 
seguramente no estarán a la vista. 
Aclaro que no he usado nunca el Proton. 

Saludos


----------



## D@rkbytes (Oct 1, 2016)

Al usarse instrucciones nativas del compilador Proton, se puede usar cualquier pin.
Por ese motivo no está el código de decodificación dentro del programa principal.

Las instrucciones son las siguientes:
*RC5In*

```
[COLOR=#3365FF][B]Syntax[/B]
[I]Variable [/I][B]= RC5In[/B]
[B]Overview[/B] Receive Philips RC5 infrared data from a predetermined pin.
The pin is automatically made an input.
[B]Operators[/B]
[B][I]Variable [/I][/B]can be a bit, byte, word, dword, or float variable, that will be loaded by [B]RC5In[/B].
The return data from the [B]RC5In [/B]command consists of two bytes, the System byte containing the type of remote used. i.e. TV, Video etc,
and the Command byte containing the actual button value.
The order of the bytes is Command (low byte) then System (high byte).
If a byte variable is used to receive data from the infrared sensor then only the Command byte will be received.[/COLOR]
```
*SonyIn*

```
[COLOR=#3365FF][B]Syntax[/B]
[I]Variable [/I][B]= SonyIn[/B]
[B]Overview[/B] Receive Sony SIRC (Sony Infrared Remote Control) data from a predetermined pin.
The pin is automatically made an input.
[B]Operators[/B]
[B][I]Variable - [/I][/B]a bit, byte, word, dword, or float variable, that will be loaded by [B]SonyIn[/B].
The return data from the [B]SonyIn [/B]command consists of two bytes, the System byte containing the type of remote used. i.e. TV, Video etc,
and the Command byte containing the actual button value.
The order of the bytes is Command (low byte) then System (high byte).
If a byte variable is used to receive data from the infrared sensor then only the Command byte will be received.[/COLOR]
```
El pin seleccionado está declarado en esta parte:
*Symbol* IR_Pin = PORTA.4 ; Pin de recepción de datos (Foto diodo IR)
Y como mencioné, puede usarse cualquier pin.

El pin se establece en esta otra parte:
*Declare* RC5In_Pin = IR_Pin ; Si se desea decodificar el protocolo RC5
*Declare* SonyIn_Pin = IR_Pin ; Si se desea decodificar el protocolo SIRC

Las rutinas de decodificación, obvio sí están dentro del archivo ASM que genera el compilador.

Saludos.


----------



## asherar (Oct 2, 2016)

Gracias por la info. Está bueno que se pueda usar cualquier pin. 

¿ Lo has probado con todo andando: las CCP, las UART y/o interrupciones ?

Pregunto para saber si hay que tomar precauciones al incorporarlo a un 
programa que ya gestiona recursos del pic para otra cosa. 

Estoy probando decodificar comandos RC-5 desde un programa 
en mpasm, que ya gestiona TMR0 y otras interrupciones. 
Tomo la señal por la RB0/INT y detecto el flanco de subida con la interrupción. 
No me sirve contar pulsos de la carrier, de período ~ 28 us, porque la rutina 
de atención de interrupciones tarda mucho más que eso. 
Aunque la acortara y llegara cerca de 28 us, en la práctica me bloquearía el 
resto de las funciones del pic durante la decodificación. 
Tal vez tenga que hacer eso intencionalmente y usar el método que propones. 
Otra alternativa que pensé es filtrar la carrier con un pasabajos y detectar los 
flancos de la envolvente. 
Ahora estoy probando un sistema de flags, uno relativo al disparo del RB0/INT 
y otro absoluto (relativo al TMR0). 
Conociendo el tiempo entre desbordes del TMR0 y lo que tarda en atender un 
disparo intento contar tiempos "gruesos". 

No sé qué opinión les puede merecer este análisis.

PD: No uso osciloscopio.


----------



## TRILO-BYTE (Oct 2, 2016)

aaah para decodificar sin osciloscopio puedes evaluar con una señar de audio
por ejemplo conecta en el jack de microfono el receptor y con audacity puedes ver la forma de onda de la señal.

eso hise una vez.

por hay encontre un codigo interesante pero esta escrito en C no se si te sirva.


----------



## D@rkbytes (Oct 2, 2016)

asherar dijo:


> Gracias por la info. Está bueno que se pueda usar cualquier pin.
> 
> ¿Lo has probado con todo andando: las CCP, las UART y/o interrupciones?
> 
> ...


Sí, ya lo he probado físicamente y funciona muy bien.


asherar dijo:


> Estoy probando decodificar comandos RC-5 desde un programa
> en mpasm, que ya gestiona TMR0 y otras interrupciones.
> Tomo la señal por la RB0/INT y detecto el flanco de subida con la interrupción.
> No me sirve contar pulsos de la carrier, de período ~ 28 us, porque la rutina
> ...


Supongo que al decir "MPASM" te refieres a un programa en lenguaje ensamblador.
Tomando en cuenta que cada bit dura 1.778 mS. y que 64 bits serían 113.792 mS.
Entonces un desborde de 28 uS, se me hace muy corto.
Con un desborde cada +- 130 ms, se me hace suficiente para decodificar la palabra completa con los semiperiodos de 888.864 uS.
Como 130 milisegundos es muy alto para el Timer 0, optaría por usar el Timer 1 a 4 MHz.

Como quiera, es un hecho que tendrás detenido el microcontrolador durante el tiempo de decodificación.
O sea, unos 113.792 milisegundos +-. Y eso, si únicamente se enviara una palabra.


----------



## asherar (Oct 2, 2016)

TRILO-BYTE dijo:


> aaah para decodificar sin osciloscopio puedes evaluar con una señar de audio
> por ejemplo conecta en el jack de microfono el receptor y con audacity puedes ver la forma de onda de la señal.
> 
> eso hise una vez.
> ...



Gracias por el comentario, TRILO-BYTE.

No tengo osciloscopio en casa. Puedo usar el del empleo, cosa que prefiero no hacer. 
Hace unos días llevé al trabajo un control genérico ONE4ALL para testearlo, 
y como todavía no estaba programado todos los bits eran iguales. 
Además ví que los pulsos no tienen carrier. 

Tomando la señal sin filtrar, tal como la recibe el fototransistor, la única posibilidad que 
queda es que la conexión del propio sensor no tenga suficiente ancho de banda, cosa 
que puede ser. 
Tal vez sea que el remoto es muy simple y directamente no tiene carrier. 
En ese caso tendré que contar los pulsos de otra manera.





D@rkbytes dijo:


> Supongo que al decir "MPASM" te refieres a un programa en lenguaje ensamblador.


 - Exacto, el que viene con MPLAB, el entorno IDE de Microchip. 



D@rkbytes dijo:


> Tomando en cuenta que cada bit dura 1.778 mS. y que 64 bits serían 113.792 mS.
> Entonces un desborde de 28 uS, se me hace muy corto.
> Con un desborde cada +- 130 ms, se me hace suficiente para decodificar la palabra completa
> con los semiperiodos de 888.864 uS.
> Como 130 milisegundos es muy alto para el Timer 0, optaría por usar el Timer 1 a 4 MHz.


 - La rutina de atención de interrupciones para el pulso IR trato que sea lo más rápida posible 
y debe andar cerca de 100 us o menos. 
 - El desborde del TMR0 lo fijé en 200 us para que las interrupciones seguro se atiendan entre 
dos desbordes. 
 - Mi temporización más corta es de 1ms, o sea 5 desbordes de TMR0. 
 - En el pic 16F84 no tengo más que TMR0. Para usar TMR1 tendría que cambiar el pic y la placa. 



D@rkbytes dijo:


> Como quiera, es un hecho que tendrás detenido el microcontrolador durante el tiempo de
> decodificación.
> O sea, unos 113.792 milisegundos +-. Y eso, si únicamente se enviara una palabra.


 - Si. El sistema controla dos motores para mover un pequeño robot. 
Para mantener el sensor alineado con la señal entrante, es más conveniente que el aparato se 
detenga para recibir los datos sin errores. 
Para esta parte del sistema sería poco problema, pero no sé para otros procesos.


----------



## asherar (Oct 2, 2016)

Habida cuenta que el fototransistor que uso no tiene la respuesta en frecuencia suficiente para 
ver los pulsos de la portadora, me decanto por poner un pasabajos en el sensor y detectar los 
flancos de la envolvente. 

Si cambiara de sensor (por el TSOP17xx) para poder "ver" la portadora, la decodificación se me 
complicaría innecesariamente (o no, no sé). 

En el caso de cambiar el micro para usar el TMR1 debería además rehacer la placa. 

Por ahora intentaré con la opción más simple para el sistema que ya tengo: 
Optotransistor (lento pero fácil de conseguir y barato) + Capacitor (pasabajos simple). 

Está claro cuál es el criterio que predomina. 

Edit: Intenté descargar el PROTON IDE desde el sitio original 
https://www.mecanique.co.uk/shop/
y parece que ya no existe .. ???


----------



## D@rkbytes (Oct 2, 2016)

Yo nunca he visto la portadora, ya que lo que sale del sensor son los pulsos, que son los que importan.

Sobre Proton IDE, la descarga es aquí: *Proton Compiler Updates

*


----------



## asherar (Oct 2, 2016)

*Para los que intenten "ver" la portadora*

Los TSOP17xx detectan frecuencias desde 30 a 56 kHz, portadoras usadas en controles infrarrojos. 

Por otro lado, estuve revisando los datos de fototransistores "comunes" como el de la figura, 





y en la  *hoja de datos* se reportan tiempos de subida y bajada típicos de 10 us. 

En el protocolo RV-5 los pulsos individuales de la portadora (64 pulsos por cada bit de 1.78 ms)   
tienen ~ 28 us de período, pero para ahorrar batería, se les da un ciclo útil de 1/3 ó 1/4 en 
estado alto. 
Entonces, según el caso, la duración de los pulsos individuales a detectar quedaría: 

dT = (2*889 us)/(64 pulsos)/3 = 9.3 us como largo, ó 

dT = (2*889 us)/(64 pulsos)/4 = 6.9 us como corto,

con lo que los tiempos de subida/bajada de esos pulsos "deben ser" de ~1-2 us. 
No los he medido, pero es lo razonable para esas duraciones.

*Conclusión:* Aún teniendo un "buen" osciloscopio no se podría ver la portadora 
por culpa de la velocidad de respuesta en frecuencia del fototransistor. 

Me despido por ahora de este tema, dejándoles a modo de ilustración, una foto de mi "sistema" 
en etapa "prototipo". En la placa de abajo está el LM298 para controlar los motores. 
El fotosensor está arriba al medio y el preset de la derecha es para regularle la sensibilidad. 
Cuando lo tenga más o menos terminado lo subo en un post aparte ...


Saludos

PD: Se agradece el enlace al PROTON !!!

PD2: Los datos del protocolo los saqué de aquí: http://www.sbprojects.com/knowledge/ir/rc5.php.


----------



## TRILO-BYTE (Oct 2, 2016)

pues no es tan necesario saber la portadora digo un detector de IR sacado de cualquier aparato detecta la portadora y te deja los bits NEGADOS.

el START BIT y la trama entera salen negados.

lo que debes hacer es leer la trama entera, quitar el start bit, quitar de la trama la direccion y solo te quedas con los datos.

ejemplo en el del SONY SIRC

el startbit dura 2.4ms y a diferencia del RC-5 1 y 0 tienen periodos diferentes 1 dura 600us y 0 dura 1.2ms

en RC-5 duran lo mismo entonces lo que debes hacer es :

esperar al startbit 

cuando llegue startbit debes empezar a guardar los bits que llegan
los bits positivos en una variable y los bits negativos en otra variable.

al final la comparas la suma de los 2 debe dar 0xFFFF

entonces es un dato valido es mas simple que el del sony

en sony debes esperar startbit , si es valido debes leer un valor cercano a 550us y 650us para 1
para el 0 entre 1.1ms y 1.3ms 

aveces da errores pero funciona.


----------

