RS232 a RF

[emeceuy]

Hola foristas ! tengo una consulta... he buscado en el foro y por todos lados pero no logro encontrar lo que quiero...

Tengo una PC y un PIC comunicados via puerto serial por RS-232 (previo pasaje por MAX232 antes del PIC). Eso funciona ! pero ahora necesito mejorar la aplicación, sacar el cable y colocar un emisor/receotor de RF a lado de la PC y otro al lado del PIC, y de esa manera la transmision serial que antes era por el cable, ahora sea por el aire. No tengo restricciones de frecuencia, la velocidad de transmision no tiene porque ser muy alta. Lo que si es necesario que el alcance ande en el entorno de las centenas de metros (200, 300 o 500 mejor).

Estuve buscando por internet, hay mucha información, muchos circuitos de como armar los emisores y receptores, e inclusive PICs RF y otros chips que ya vienen preparados como emisores y receptores, pero lo que vi hasta ahora tienen un monton de patas... además de a las que se conectan capacitores, bobinas, cristales, la antena, etc, tienen varias para los datos, y eso me complica un poco, yo no necesito tantas patas de datos, sino TX y RX del puerto serial !

Alguien conoce algun integrado que sea simple y que transformadorrme sin mucha vuelta RS232 a RF y RF a RS232? existe algo así? porque los integrados que vi tienen tantas patas de datos (DIN, DOUT, CLK, SEL, DAT, etc)?

Agradezco su ayuda desde ya ! gracias por todo !

salu2, mArCe

 

[REKI]

ADuC

 

[telmocho]

Hola emeceuy,
yo estoy con un problema muy similar: conectar dos pic por rf (433 MHz) digital y me he encontrado con los encapsulados TQFP de transceivers como el trf6903 y at86rf211 (funcionan en FSK, genial) pero son muy complicados (condensadores, bobinas, cristales y demás componentes).
Uno de "mis pics" irá en un mando a distancia (a pilas, claso) y otro en un receptor alimentado con una fuente, sin problemas de consumo.
La comunicación mando->base será de los botones y base->mando de acks y poco más.
No necesito full duplex, sí half duplex.
Había pensado en los básicos emisores y receptores, pero busco un transceiver fsk o fm y no am que es más propenso a interferencias. ¿No existe ninguno que integre emisor y receptor? Si no existe, debe haber alguna razón de peso que se me escapa.
Un saludo, si encuentro o avanzo algo te comento.
Un saludo

 

[El nombre]

El menda,yo, Tengo un emisor y un receptor a 433 mhz y van bien.

hay hibridos de varias potencias por lo que el alcance es variable (encontre algunos en www.iberftura.com creo) le aplique directamente en UARD sin intermediario al emisor y del recetor al pic.

 

[emeceuy]

gracias por las respuestas ! es un tema complicado este, ciertamente...

dices que no agregaste max232 entre el emisor o receptor y el PIC? y cuales usaste exactamente? cuentanos mas !

 

[JV]

Había pensado en los básicos emisores y receptores, pero busco un transceiver fsk o fm y no am que es más propenso a interferencias. ¿No existe ninguno que integre emisor y receptor? Si no existe, debe haber alguna razón de peso que se me escapa.

En mi trabajo usamos estos modulos:

http://www.wenshing.com.tw/english/prouducts_información.asp?bookbm=370

tienen un precio de U$10, hemos logrado 50 metros en un ambiente con mucha ruido de RF.

Saludos..

 

[telmocho]

He de mirar si me vale esa frecuencia, a ver si esta semana me pongo ya con eso.
Sí El Nombre, danos algún dato más, pq parece que es lo que buscamos.
gracias.

 

[telmocho]

Bueno, al final opte por lo famosos XBEE que venden en farnell. Son realmente sencillos de usar, aunque salgan un poco más caros. No es necesaria la tarjeta del kit para configurarlos, pues se puede hacer por comandos. Consumen poco y valen como 21€ los normales (cada uno). Con ellos se pueden montar redes complejas pero para lo que yo busco en un principio, sustituir un cable, son muy buenos. Yo conecté los pines rx y tx de los pic directamente a la entrada y salida de los xbee y para transmitir con mikroc no hay más que poner el usar_init(9600), usart_write(datos)...

 

[Eduardo]

En mi trabajo usamos estos modulos:

http://www.wenshing.com.tw/english/prouducts_información.asp?bookbm=370

tienen un precio de U$10, hemos logrado 50 metros en un ambiente con mucha ruido de RF.

JV, donde los compraron?

 

[JV]

Hola _Eduardo_, los vende Cika. No estoy muy seguro del precio.

Saludos..

Edit: en la pagina de Cika figura U$15 mas IVA

 

[El nombre]

Le envie un transmisor que se integro a la web de pepechip.
Si no lo tiene subido lo envio al foro. (mi problema es el peso de las explicaciones)

De todas maneras con los mudulitos emeisores y transmisores de 433 solo tienes que limitarte a envarle las señales y recibirlas en el otro lado. Es muy simple y estable.

 

[ricardo marcelo]

Hola Eduardo:
soy nuevo en este foro, que hace mucho tiempo lo visito, hasta que hoy, me registré.
Fué justamente viendo uno de tus mensajes que encontré muy interesante, en donde citas a un módulo transeptor de rf que utilizan en tu trabajo >;;para comunicación serial que encuentro muy interesante, y lo necesito para un proyecto duplex entre pic's.
Sabrías decirme si en Argentina, se comercializan, o se importan?
Desde ya muchas gracias y saludos.

P: Soy de Argentina, Provincia de Mendoza.

 

[Eduardo]

? ? En el hilo soy el unico Eduardo, pero el que usaba esos modulos en el trabajo era JV.
Los vende Cika: www.cika.com

 

[Fogonazo]

Transmisor RF: TWS433 o TWS433-9A o TX433.
Receptor RF: RWS433


Aqui los tienen, averigua si te los mandan (U$ 5 c/u)

http://www.electronicaliniers.com.ar/principal.htm

 

[ado2008]

JV, tu dices que estan usando unos modulos de Wenshing conmejores prestaciones al ruido que los anteriores? Son los RWS-434N ASK de 433,92 Mhz? Estos son nuevos segun el link que colocaste.
Yo estoy usando los anteriores RWS-374-6 ASK tambien de 433,92 Mhz, y tengo un problema grande en una aplicacion; dicha aplicacion maneja un motor de arranque de mucha corriente (200A - 12Vdc) y mete tanto ruido que me corta la comunicacion. Saque la antena lo mas lejos posible pero aveces falla y mi cliente no esta satisfecho.
Alguien tiene experiencia con este tema?
Muchas gracias

 

[iagm]

Hace un tiempo hice algunas experiencias para comunicar 2 pics entre si por RF, lo cierto, es que si van a usar los TWS/RWS en alguna de las frecuencias que vienen, deben usar los modulos HT12 D/E que sirven para pasar los datos digitales a la forma que es capaz de manejar el RWS o TWS según si es receptor o transmisor.
En mi caso, el pic conectado directamente al modulo de RF no funcionó.

Aún así la comunicación entre PICs no siempre es exitosa y la velocidad termina siendo baja.
si alguien ha podido conectar directamente al pic con el modulo receptor y transmisor agradeceré una explicación de como lograrlo.

Muchas gracias

 

[swilwerth]

Sé que este tema es viejo, pero caí desde el buscador de internet acá y quizás les sirva este dato.
Especialmente por lo que comenta el usuaro lagm, sobre conectar los módulos de Wenshing directamente a un microcontrolador sin un integrado que haga de interfaz previa para enviar los datos serie como los que provee Holtek.
O intentar enviar en forma "cruda" la transmisión serie por estos módulos.

Hace como 10 años o más tuve que hacer un proyecto similiar half duplex que enviara y recibiera datos por el mismo canal.

Y lo logramos teniendo en cuenta que la codificación de los datos serie impacta en la modulación de RF y la reconstucción del clock en el receptor.
La salida serie de una UART como la RS232 es del tipo NRZ (Non return to zero).
Esa codificación serie es desfavorable para la transmisión tanto por cables largos como por RF, principalmente porque puede tener en el "chorro" de datos muchos ceros juntos o muchos unos juntos, o peor aún, un uno solo perdido en un chorro de ceros.
Lo cual en el dominio de los armónicos, es bastante desfavorable.
En lo particular, recomiendo adoptar otra forma de codificación de los datos serie, que sea en cuanto a espectro de frecuencias resultante y ancho de banda analógico requerido más acotado y no tan disperso.
Lo que probamos que andaba bien para pequeña escala, y con los conocimientos que teníamos por aquel entonces es mandar los datos serie codificados en manchester.
Solo baja la tasa de transferencia a la mitad, y asegura que el clock de datos siempre está presente en la transmisión.
Además de que su valor medio total es 0.

Pero otras técnicas más nuevas pueden ayudar, como 8b/10b y sus derivados.

Otro dato importante es la detección/corrección de errores.
Paridad como mínimo para descartar paquetes dudosos.
Algún checksum para algún dato que venga de un conversor A/D, etc ...
Se puede implementar un Hamming también, o un Reed-Solomon.

Todo dependiendo del alcance de la aplicación y la estabilidad requerida.

 

[iagm]

Estimado swilwerth, agradezco le hayas dedicado un tiempo a la respuesta de mi comentario.

Hice pocos intentos para hacer funcionar los modulos conectados directamente al pic, de todas formas he logrado un buen desempeño de comunicación con los HT12d y e, pero a baja velocidad.

Como hacés referencia, la descomposición armonica de la onda cuadrada contiene muchos armónicos, lo que implica que el ancho de banda que se necesita para transmitir una señal a una velocidad que se precie es importante.

En contraste, el modo ASK usado por estos módulos ofrece una solución a esto, pero a costa del sacrificio de la velocidad de transmisión.

como conclusión para mi, no fue posible la conexión directa pero siempre estoy atento a la solución de este problema con CIs intermediarios o sin ellos en post del aumento de velocidad de transmisión.

 

[swilwerth]

Como posible es posible, pero lleva más tiempo en desarrollo de software.

En el proyecto que comentaba alcanzamos los 2400 baudios con un pic 16F84 (que encima no tiene UART) y con un clock de 2,457 Mhz.
Y el alcance era mayor incluso y más tolerante a errores que el modelo de un amigo que uso un holtek como los que mencionás, además del PIC.
Transmitíamos todos en la misma frecuencia y nuestros datos llegaban, y los de ellos no, si encendíamos los equipos al mismo tiempo en la misma sala.
En cuanto a distancia, nos dió más de 40 metros con paredes intermedias.
No sé si los módulos darán una velocidad mayor de datos, probablemente sí.
Si lo tuviera que hacer hoy de nuevo, me buscaría un micro con UART, para no tener que hacer "la magia" de decodificar y mandar los datos en serie por software.
(Tiene sus ventajas, el "sampleo" del dato lo hacíamos desde el cambio de flanco, luego de un tiempo, y era más fiable que tomarlo directamente cuando aparece el flanco).
Todas estas cosas no las inventé yo, ehh, ya estaban estudiadas y documentadas, pero en esa época no lo sabíamos.
De hecho, hay técnicas de sampleo de datos digitales, que aconsejan samplear al menos dos a tres veces el dato para tomarlo como válido, desde la aparición del flanco.
Cosa que la entrada de la UART, al menos en las más sencillas, no lo hacen.
Y en cuanto a la codificación, si la velocidad es el factor clave a mejorar, no usaría manchester.
Intentaría hacer el ensayo con 8b/10b, una codificación que se está usando en todo lo relacionado a transmisión de datos serie alta velocidad, como el USB 3.0 y el HDMI, precisamente porque dicha codificación produce un espectro armónico de un ancho de banda menor, para la misma tasa de datos que si se transmitieran en NRZ.
Digamos, de modo simple, que dichas codificaciones vuelven los datos digitales más fáciles de transmitir por medios analógicos.
Una codificación parecida usan los CDs de audio, para asegurarse que el láser no pase por un pit demasiado largo como para desincronizar el reloj de datos con respecto a la velocidad de giro.

La idea más o menos es, agrupar de a cuatro paquetes de 8 bits previamente la transmisión.
Luego convertir los 8b a 10b usando la tabla de conversión de 8b/10b.
Vamos a tener unos 40b resultantes.
Esos 40b los partimos en paquetes de 8 (5 paquetes) para que entren en los registros de la UART y los mandamos todos uno atrás del otro.
Del otro lado recibimos y hacemos el proceso contrario.

Otra parte importante, es darle la menor prioridad a los datos que se transmiten primero, o tirar un paquete de "sincronismo" previo de 8 bits antes de mandar el resto.
Esto es porque del "silencio" a la transmisión, todo módulo económico tiene cierta "inercia", y los primeros datos que se envían tienen una amplitud menor, que cuando está en "régimen" de envío de datos. No sé si me explico.

Cuestión de tomarse el tiempo y probarlo, estoy seguro que funciona.

Te dejo algunos links interesantes sobre el tema:

http://www.rhyshaden.com/encoding.htm
http://www.maxim-ic.com/app-notes/index.mvp/id/3435

El manchester lo podés hacer duplicando el baudrate y codificando los datos en manchester

Es decir si tenés que transmitir 10000000 lo cortás en dos nibbles
1000 y 0000
Después lo convertís, (podés hacer una tabla), el secreto es por cada "1" es "10" y por cada "0" es "01".
1000 -> 10010101
0000 -> 01010101
Transmitís los dos nibbles en dos paquetes de 8, y del otro lado hacés la conversión inversa.

http://es.wikipedia.org/wiki/Codificación_Manchester

O la otra alternativa, si tu aplicación envía "palabras de comando" para hacer funciones remotas es elegir esas "palabras de comando" para que el valor medio resultante sea lo más cercano a 0 con una tasa de bits lo más cambiante posible.

En vez de enviar 10000000, es preferible enviar 10101010

Saludos!

 

[iagm]

Estimado swilwerth

La respuesta dada ha sido clarísima. Por el momento me dedico a otro proyecto que nada tiene que ver con transmitir datos. pero me has provocado interés en resolver el tema de forma definitiva.

En alquel momento, perseguía hacer un sistema de telemetría en 433Mhz, pocos datos a transmitir. Temperatura, velocidad de viento.

Usaba un 16F716 con la ventaja de sus entradas analógicas, pero desarrollé un protocolo de transmisión para poder usar los HT12D/E. el protocolo necesitó de un poco de refinamiento para poder aumentar la velocidad de Tx. nunca superé los 1200bps

El problema para mi se transformó en personal, ya que si quería aumentar la cantidad de datos a transmitir como estados digitales de las otras entradas o cosas similares y la baja velocidad me obligó a no ser mu ambicioso.

probaré lo que me comentás y si funciona te comentaré.