Control remoto con transmisor ASK

[vlad67]

Compadres les cuento que necesito hacer un control remoto Tx y Rx, para esto ya compre un kit de tx y rx modulando en ASK.....lo utilizare en un microbot que estoy montando como proyecto de grado para mi tecnologia en telecomunicaciones.....
Yo tengo la idea de conectarle un conversor de decimal a binario y la señal ya en binario meterla en el Tx ,,,y al otro lado utilizar un conversor de binario a decimal y este conectaro al Pic 16f877
...Si me pueden facilitar algunos planos e ideas estare muy agradecido........

Un saludo desde Bucaramanga
Colombia..

[mario_pastor]

Vlad y Elizabeth

Trataré de ayudarlos en lo que pueda desde este sub-foro y estoy seguro que varios aportarán con sus ideas. Respecto a lo utilizar un conversor de DECIMAL a BINARIO para luego enviarlo al TX RF me parece que no va por muy buen camino, les recomiendo que usen el USART del PIC (en su caso el 16F877) y lo conecten al pin de DATOS del MODULO RF. También deberán de controlar la alimentación de éste modulo mediante un transistor con la finalidad de no estar transmitiendo todo el tiempo y ahorrar energía de las baterías de tu MICROBOT. Además al inicio de cada trama deberan enviar unos BYTES de SYNC (0xAA) para que no tengas problemas al recibir estos datos... Bueno estoy a la espera de sus resultados y/o consultas.

[Elizabeth2004]

Gracias Mario.. como te dije la idea de los conversores surgió en un principio cuando no sabíamos nada del tema...

Hoy en día, estamos generando los datos en formato rs-232 con un pic16f84a a una taza de tx de 2400baudios algo baja para evitar errores.. ya he solucionado algunos inconvenientes en el proyecto, simulando en proteus ya he realizado el código del tx en el f84a y del rx en el f877 y lo tengo hasta ahora sencillo (ke me muestre en el PORTB el byte ke estoy enviando).

Lo de los bytes de SYNC será necesario.?? esto no me hace muy complicado  el códio del receptor..??
Hay ke tener encuenta ke se va a manejar 4 servos,(2 para la cámara y 2 para el movimiento del microbot), seguir linea negra, detecar obstáculos, detectar movimiento con un módulo de ultrasonido. y a parte de eso.. debe tener 2 modos de funcionamiento... 1.. Autómata; donde va a actuar como seguidor de linea y solo se va a tener control del movimiento de la cámara.. 2. Manual; donde se va a tener control tanto de la cámara como del movimiento del microbot...

Bueno por ahora expongo a grandes rasgos el proyecto.. y les cuento ke estoy trabajando en estos momentos en el control remoto o mando a distancia..  lo pienso hacer de 2 maneras.. una generando la señal a enviar con el 16f84, donde también voy a utilizar una matriz de 4x4 para la entrada de los mandos al PIC y se va a poder visualizar en un LCD; el modo del microbot y otras cosillas....
La otra forma es enviar los datos desde el pc via COM1 con un programita en visual.

También les cuento ke ha sido un mes duro, me tocó aprender visual basic, hice el control en visual para enviar los datos por el puerto, luego me dediké al manejo del LCD y del teclado (suena fácil) pero casi me enlokezco porke estaba haciendo todo en el proteus y no me salía nada, y le daba vueltas al asunto y nada, hasta ke supe ke el proteus presenta ciertos problemitas a la hora de emular los LCDs con código en ASM, luego de solucionado el problema no me respondía a las ordenes ke le daba según la tecla pulsada, y en estos momentos 11:00pm hora local me he dado a la tarea de montar el hardware  para el LCD y una simulación de teclado (2 pulsadore) para probar el programa.. y sorpresa.. me ha funcionado de maravilla... ahora solo falta adecuarlo a mis necesidades y probarlo bien...

Bueno no los canso con mas.. espero sigan conmigo este proyecto.. estoy dispuesto como todos ustedes a compartir mi experiencia y todo lo ke logre con este proyecto... como es un proyecto de grado me toca hacer un librito lo mas explícito posible ya ke en mi U.. nada de microbots.. sería bueno tambien ponerlo a dispocición de todos..

Espero comentarios

Bye..

[mario_pastor]

Elizabeth, que buen proyecto tienes    hace mucho tiempo también queria hacer un mircrobot pero por falta de tiempo y trabajo nunca logré realizarlo     a lo mucho que llegue fue en realizar un brazo con 4 motores PAP controlados por RF para un curso en la universidad.

Respecto a lo de complicarte con los BYTES de SYNC no lo creo (en mi opinión), ya que es sólo agregarlos al inicio de la trama que envias, por ejemplo:  AA-AA-AA-dato1-dato2-dato3....datoN.  Ahora si deseas puedes agregar además de los BYTES de SYNC, BYTES de CABECERA por ejemplo: AA-AA-AA-S-T-A-R-T-dato1-dato2-dato3....datoN-E-N-D, de esta manera sabes donde inicia y termina la trama de DATOS, por si es que algunos BYTES se pierdan en la tx.

Todo esto que explico lo realicé en el proyecto que te menciono usando dos 16F84A (los primeros micros con los que me inicie) y los modulos de RF de RENTRON y te dire que trabajo sin problemas a una distancia de 50mt. Como comentario use el control de un PLAYSTATION dañado adaptado para el PIC, modulo RF, ANTENA y otros... creo que el acabado del control quedo mucho mejor que el BRAZO      bueno ya me comentaras los avances en tu proyecto.

[dogflu66]

Hola me alegro que tu proyecto este saliendo bien, yo no utilizo el proteus, pero por lo que vi en los foros, tiene sus propias manias...
 
Y entrando un poco con tu proyecto, hace unos años me encargaron un control via radio para llenado de depositos para riego, y el mejor resultado para la comunicación de las placas remotas fue, algo muy sencillo, una trama de datos con inicio de un byte como nombre de la red, seguido de byte que indica a que punto remoto me dirijo + byte que indica el nombre del que manda la orden + nº de orden de la trama + comando + datos + datos + checksun

Y el punto de recepción mandaba una trama de respuesta mas corta de OK, indicando nombre de red + punto remoto + mas nombre propio + nº de la orden recibida +  byte de ok y checksun

Lo que quiero indicarte con este ejemplo es que con un sistema sencillo podrias integrar una red de robot interactuando unos con otros y con el pc...

[Elizabeth2004]

Hola denuevo, gracias por interesarse en mi proyecto y aportar ideas para su realización..

Disculpen la ignorancia , pero estaba pensando enviar un solo byte por mando, por ejemplo si kiero ke el microbor se mueva hacia adelante envío el byte b"01001100" mientras esté presionado el pulsador, con una separación entre byte de 50ms.... será ke con esto no basta???...

Porke he pensado y cómo no tengo mucha experiencia con esto se me hace un poco enrredado a la hora de la recepción...

Ke opinan.??

Akí les dejo la imagen del mando ke diseñé en visual... en teoría debe hacer lo mismo ke el micro.. según el botón presionado envía un caractér por el puerto serial, en el caso del ejemplo de arriba sería la letra "L"..  es algo sencillo pero aceptable para ser mi primer programa en visual


Gracias..

Bye

[dogflu66]

La forma que estas desarrollando tu aplicación es perfecta para uso en laboratorio, pero si sales fuera, es posible que tengas otros equipos funcionando en la misma frecuencia o canales que generan armónicos que te pueden interferir o incluso otro tipo de maquinas que no trabajan con rf pero que generan interferencias de rf u otras que nos interferirán totalmente los datos o enmascaran los datos durante un determinado tiempo, con lo que se suelen colocar temporizadores a la desconexión cuando la perdida de las señales de control son muy prolongadas, o se generan protocolos mas o menos complicados para detectar las tramas de datos correctas... de todas formas el mandar una orden de forma repetitiva puede ser un solución, pero si otro mando a distancia usa el mismo sistema que el tuyo y coincide en tu mismo canal es posible que envié los datos cuanto tu TX esta en reposo o incluso al mismo tiempo pero su señal prevalezca por que es mas potente... e interprete tu equipo ordenes indebidas... y fin...

[Elizabeth2004]

Bueno, ya como ke entendí... listo voy a empezar a implementar en la rutina del envio de bytes lo ke me dicen... un o 2 bytes de sincronización, byte de datos, etc..

Ahora una de las tantas preguntas ke me surgen ... con que separación envío los bytes, con ke separación envio la "trama"...

En realidad lo ke mas preocupa es la parte del rx... cosas como, si utilizo la usart para cuando llegue un byte genere una interrupción.. o si no es así cada cuanto debo estar pendiente de los datos ke llegan... cosas así...

Disculpen si me estoy enrredando o complicando las cosas pero como no tengo mucha experiencia en esto pues hay veces ke lo veo como difícil

Pero gracias a ustedes ke me ayudan con las dudas... cada día lo veo mas factible de lograr..

Thanksss

Bye

[dogflu66]

Pues si utilizas ensamblador para programar el pic, y este tiene usart lo mas lógico y razonable es que utilices las posibilidades del micro, usart + interrupciones, y en principio si utilizas el micro por encima de los 10Mhz de reloj, las trama de datos puedes enviarla todos continuos, y en todo caso puedes dejar los 50ms que dejas actualmente entre trama y trama... tendrás que crear seguramente un bufer de entrada que retenga la trama de datos, es decir al mismo tiempo que el bufer se esta llenado tendrás que ir sacando los datos mas antiguos, también para el caso de que el programa sea muy sencillo y se ejecute muy rápido es posible que puedas prescindir del bufer, otros lenguajes de alto nivel normalmente ya tienen este bufer integrado y no tienes que crearlo... e incluso tienen variables del sistema que te indican el estado del bufer serie... de todas formas para trabajar la usart + interrupciones yo no utilizo menos de 20Mhz, de esta forma me evito que se bloquee, ya que si no extraes los datos suficiente mente rápido se bloquea em Rx y entonces tienes que llevar el control de errores de la usart para detectar este fallo y obrar en consecuencia...

[Elizabeth2004]

Bueno amigos, continuando con esto les cuento que estoy modificando el código del envio de los datos, en estos momentos lo tengo AA-AA-datos, entre trama y trama tengo un retardo de 50ms... tengo una inkietud...

Cómo será mejor.?? enviar un solo dato por mando o enviar el dato pero continuamente... me explico;
Cuando presiono cualkier botón por ejemplo el de "cámara arriba" envio un dato y ya.. o envio el dato indefinidamente hasta ke deje de presionar el botón.??

Ustedes que han tenido experiencia... cual será la mejor opción...

He estado pensando en la parte de la recepción... lo tengo configurado ke cuando reciba info por la usart genere una interrupción... entonces en la interrupción identifico ke dato es y pongo en alto un bit de un registro XXX (como un bandera) ke me indica ke he presionado un botón específico... y ya... entonces a la hora del programa general  debo estar pendiende es de esas banderas... me parece como mas fácil así no se ke pensarán..

Gracias

Bye

[mario_pastor]

Lo de los flags (banderas) me parece genial, yo trabajo de esa manera y ten por seguro que tu programa no se complica a la hora de realizar todo dentro de la rutina de interrupción. Respecto a la forma de enviar el DATO, te sugiero que hagas lo siguiente: cuando presiones un boton envias un DATO indicando que, por ejemplo, la cámara se mueva a la derecha sin parar; y cuando la sueltas envia un segundo DATO para que se detenga. De esta forma evitas que tu programa (en el receptor) se quede enganchado en la rutina de interrupción por estar constantemente recibiendo datos del TX. Esto puede ser muy útil cuando primero realizas un movimiento, por ejemplo, a la derecha y simultáneamente quieres hacer un movimiento hacia arriba, sin dejar de presionar el primer boton. Espero haber sido claro en la explicación   ya nos seguiras comentando tus logros

[dogflu66]

La mejor rutina es la mas simple, ya habrá tiempo de complicar el sistema...

[Elizabeth2004]

Bueno amigos, gracias por esos "tips".. he decidido tomar una cosa de cada respuesta.. por tal motivo les cuento como voy...

He desarrollado un código ke según la tecla pulsada (teclado matricial 4x4) me envíe una pekeña "trama" jejeje.. un byte de inicio AA y el de datos XX, .. también me tiene ke mostrar en un LCD la acción correspondiente a la tecla pulsada..

Me surge una duda...

1. Será mejor enviar bytes bien diferentes?? me explico estoy enviando caracteres ascii  A, B, C, D...etc... entonces son muy parecidos entre si a la hora del dato a enviar A="01000001" B="01000010"..etc.. osea solo varía un bit .. estó será problema a la hora de facilitar a errores en la tx...??
O mejor envío caracteres donde cambien varios bits???

Los tendré informados de todos los avances..
Por ahora me voy a dedicar a la parte del tx.

Espero sugerencias, opiniones... etc

gracias..

[dogflu66]

Existe un sistema para detectar errores cuya simplicidad merece una medalla para el que se le ocurrió, y es el enviar un byte de terminación que contiene la suma de los byte anteriores, y cuando recibes estos bytes, internamente los sumas y si esta suma es igual al ultimo byte recibido (checksun) la trama es correcta y en caso negativo se descarta... esto te permite recibir datos prácticamente iguales sin problemas...

[Elizabeth2004]

Escrito originalmente por dogflu66Existe un sistema para detectar errores cuya simplicidad merece una medalla para el que se le ocurrió, y es el enviar un byte de terminación que contiene la suma de los byte anteriores, y cuando recibes estos bytes, internamente los sumas y si esta suma es igual al ultimo byte recibido (checksun) la trama es correcta y en caso negativo se descarta... esto te permite recibir datos prácticamente iguales sin problemas...

Gracias por la info, siempre había escuchado del checksum pero no le había puesto cuidado..

Pero bueno hagamos el ejemplo.. envio AAh - 40h entonces check sum debe ser "EA"  si he enendido bien..

éntonces la trama sería "AAh-40h-EAh"
si envío como dato el caracter "B" 41h kedaría  "AAh-41h-EBh

Mi inkietud keda resulta
Al enviar el dato "40h" sin checksum si cambia  un bit ya se convierte en otro dato.. pero con el checksum deberán cambiar 2 bits específicos para ke se convierta en otro dato válido.. es muy difícil ke esto suceda.. y no creo ke sea tan demalas...

Gracias por el Checksum dogflu66

Bye