Haz una pregunta
  Foros de Electrónica » Temas de Interés » Aportes y documentación
Foros Registrarse ¿Olvidaste tu contraseña?

Temas similares

29/01/2014 #1
Moderador

Avatar de D@rkbytes

[Aporte] Decodificador IR RC5 y SONY para control de 8 canales + 1 canal PWM
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.
31/01/2014 #2
Moderador general

Avatar de Fogonazo

No había visto este aporte, ! Gracias ¡ D@rkbytes
10/08/2015 #3

Avatar de cristian76

Una consulta darkbytes mi unica duda seria el LIR1 , solo conseguiria un led infrarojo receptor ? gracias de igual modo , muy completo el aporte .
11/08/2015 #4

Avatar de TRILO-BYTE

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
11/08/2015 #5
Moderador

Avatar de D@rkbytes

cristian76 dijo: Ver Mensaje
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

11/08/2015 #6

Avatar de TRILO-BYTE

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
13/08/2015 #7


¡Genial! precisamente quería hacer algo asi para controlar un pequeño "robot". Gracias.
14/08/2015 #8

Avatar de cristian76

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 .
14/08/2015 #9
Moderador

Avatar de D@rkbytes

¿Miraste la hoja de datos?
D@rkbytes dijo: Ver Mensaje
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.


01/10/2016 #10

Avatar de asherar

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
01/10/2016 #11
Moderador

Avatar de D@rkbytes

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
Código:
Syntax
Variable = RC5In
Overview Receive Philips RC5 infrared data from a predetermined pin.
The pin is automatically made an input.
Operators
Variable can be a bit, byte, word, dword, or float variable, that will be loaded by RC5In.
The return data from the RC5In 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.
SonyIn
Código:
Syntax
Variable = SonyIn
Overview Receive Sony SIRC (Sony Infrared Remote Control) data from a predetermined pin.
The pin is automatically made an input.
Operators
Variable - a bit, byte, word, dword, or float variable, that will be loaded by SonyIn.
The return data from the SonyIn 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.
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.
02/10/2016 #12

Avatar de asherar

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.
02/10/2016 #13

Avatar de TRILO-BYTE

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.
02/10/2016 #14
Moderador

Avatar de D@rkbytes

asherar dijo: Ver Mensaje
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.
Sí, ya lo he probado físicamente y funciona muy bien.
asherar dijo: Ver Mensaje
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.
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.
02/10/2016 #15

Avatar de asherar

TRILO-BYTE dijo: Ver Mensaje
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.
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.

---------- Actualizado después de 19 minutos ----------

D@rkbytes dijo: Ver Mensaje
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: Ver Mensaje
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: Ver Mensaje
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.
02/10/2016 #16

Avatar de asherar

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 .. ???
02/10/2016 #17
Moderador

Avatar de D@rkbytes

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

02/10/2016 #18

Avatar de asherar

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.
Imágenes Adjuntas
Tipo de Archivo: jpg foto.jpg (43,8 KB (Kilobytes), 44 visitas)
02/10/2016 #19

Avatar de TRILO-BYTE

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.
Respuesta
¿Tienes una mejor respuesta a este tema? ¿Quieres hacerle una pregunta a nuestra comunidad y sus expertos? Registrate

Buscar más temas sobre:
Lupa Aportes y documentación

Artículos técnicos, notas de aplicación, diagramas circuitales, y demás documentos de interés enviados por nuestra comunidad.

Cerrar
Foros de Electrónica » Temas de Interés » Aportes y documentación

Powered by vBulletin® Version 3.8.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Search Engine Optimization by vBSEO ©2011, Crawlability, Inc.