Haz una pregunta
  Foros de Electrónica » Diseño digital » Microcontroladores y sistemas embebidos
Foros Registrarse ¿Olvidaste tu contraseña?

Temas similares

11/03/2014 #21

Avatar de papirrin

Bueno yo ofrezco subir fotos, si el creador del post vuelve a aparecer, desconecto la alarma de mi auto que tiene un PIC (no recuerdo la nomenclatura pero es PIC) y un ULN2803 para los cables de los sensores, y no lleva nada de cables apantallados, UPT y ni nada trensado y son mas de 1 metro, quien sepa conectar una alarma sabra que no lleva nada de eso y los cables van a unos cuantos centimetros de la bobina del motor tras la pared de fuego.

yo no tengo ninguna duda de que lo que propongo puede ser una solucion real y que este sin fundamento.

si no las subo den por echo que lo que propongo no sirve.
11/03/2014 #22

Avatar de Dr. Zoidberg

analogico dijo: Ver Mensaje
el cable utp solo funciona en un orden

Funciona en eses orden si lo que intentás hacer es conectar una red Ethernet, pero no son mas que 4 pares de cables y podés conectarlos como quieras... aunque no necesariamente en este caso .

Por supuesto que es mejor transmitir en serie con un driver de bus CAN, pero eso requiere modificar el circuito y poner inteligencia en ambos extremos, lo que es mas caro y complicado que "cuidar un poco el cableado". Por fovor.. balanceen la ecuación costo-beneficio!!!!

---------- Actualizado después de 2 minutos ----------

papirrin dijo: Ver Mensaje
Bueno yo ofrezco subir fotos, si el creador del post vuelve a aparecer, desconecto la alarma de mi auto que tiene un PIC (no recuerdo la nomenclatura pero es PIC) y un ULN2803 para los cables de los sensores, y no lleva nada de cables apantallados, UPT y ni nada trensado y son mas de 1 metro, quien sepa conectar una alarma sabra que no lleva nada de eso y los cables van a unos cuantos centimetros de la bobina del motor tras la pared de fuego.
No conozco alarmas de auto que envíen 7 pulsos TTL en paralelo con rise time de menos de 100 ns
11/03/2014 #23


Dr. Zoidberg dijo: Ver Mensaje

Funciona en eses orden si lo que intentás hacer es conectar una red Ethernet, pero no son mas que 4 pares de cables y podés conectarlos como quieras... aunque no necesariamente en este caso .
si te fijas bien el orden se parece algo a un post anterior


Dr. Zoidberg dijo: Ver Mensaje

GND / D7 / GND / D6 / GND / D5 / GND / D4 / GND / ENA / GND / RS / GND / RW / GND

.
y si en una red ehernet podes conectarlos como quieras
la diferencia es que en el orden correcto el cable funciona a los 100 metros y un poco
mas
11/03/2014 #24

Avatar de papirrin

No conozco alarmas de auto que envíen 7 pulsos TTL en paralelo con rise time de menos de 100 ns
mmm puede que tengas razon por ese lado... aun asi me reservo la duda.

de cualquier manera subo la foto de otra alarma que tengo, claramente se ve que va del micro al uln2003
Imágenes Adjuntas
Tipo de Archivo: jpg IMG_20140311_211317.jpg (118,1 KB (Kilobytes), 27 visitas)
Tipo de Archivo: jpg IMG_20140311_211342.jpg (93,3 KB (Kilobytes), 18 visitas)
Tipo de Archivo: jpg IMG_20140311_211355.jpg (101,8 KB (Kilobytes), 17 visitas)
11/03/2014 #25

Avatar de TRILO-BYTE

el par trenzado del UTP esta trenzado por alguna razon

en este mundo nada esta hecho al azar bueno solo el sazon de la comida

el UTP esta trenzado por las leyes del electromagnetismo el flujo electromagnetico se monta en ambos cables y como esta trenzado se anula

en este caso deben ser datos diferenciales

¿poner voltaje diferencial a 4 bits y sus lineas de control?
eso seria buscarle 3 pies al gato
como dicen es mejor poner todo detras de la LCD

hay que pensar barato

¿UTP , soldaduras de cacahuate y papel aluminio?
me hubieran reprobado si entregaba algo asi en la escuela de ingenieria
11/03/2014 #26


Pues el mayor problema que tiene el usar un cable sin blindar en un ambiente tan ruidoso son los voltajes que se inducen en estos. Lo que yo aria, es colocar un microcontrolador de los pequeños detrás del display LCD, y conectar este con el PIC principal de la aplicación. También lo que aria es usar un protocolo que incluya comprobación de errores en la transmisión, yo cree hace poco un protocolo de comunicaciones que incluye comprobación de errores de forma nativa, solo se carga el dato a transmitir, se llama a la rutina y listo, el PIC transmitirá el dato hasta que el dispositivo responda que recibió correctamente la transmisión. Aunque el protocolo que cree tiene muchos baches en el programa y quizás en el protocolo en sí, es útil para comunicaciones que requieren corrección de errores de manera automatica.

El programa está configurado a una velocidad de 1 bit por cada 100us... Una velocidad muy lenta... espero que no entre en resonancia junto con el motor, eso sería muy malo...
El código está en Basic del PIC Simulator IDE, pero pueden portarlo hacia otro lenguaje fácilmente. Lee los archivos de definiciones para saber cómo funciona y saber como usarlo…
Archivos Adjuntos
Tipo de Archivo: rar Proyecto BSAMP.rar (389,2 KB (Kilobytes), 7 visitas)
12/03/2014 #27


disculpen pero me a sido imposible pasarme por aquí antes .
haber contestando a todo así por encima:(espero no dejarme nada )
-el display LCD lo he montado en el cuadro de instrumentos del vehículo concretamente entre el cuenta revoluciones y velocidad. Y aunque la pcb solo mide 12x8 cm(decir que el vehículo es del año 2008 XD) y de hay que todo este tan justo xD.
-ahora mismo no dispongo de fotos ya que lo tengo montado pero espero disponer de algo de tiempo el fin de semana y cuando lo vuelva a desmontar tomare fotos de ubicaciones y demás.
-a pesar de lo que dicen el cable utp es el que me da el mejor resultado ya que es capaz de mostrar todos los "caracteres" (aunque con acople) pero otras configuraciones ni eso... es mas algunas ni siquiera muestras nada en el lcd..(y hablo de cables apantallados.)
-Dr. Zoidberg la solución que usted propone me a funcionado a la perfección en la mesa de "pruebas" en una distancia máxima de 40cm pasados esos 40 cm vuelve el problema

bien:
pues después de a ver probado con varios tipos de cables apantallados sin apantallar,paralelos utp etc y varias configuraciones me declino por unas de las siguiente soluciones.
1ºprovar por ultima vez con un cable del tipo SSTP (ya que el utp es el que mejor resultado me da)
mientras consigo un ULN 2803 para probar la idea de papirin si aun así no funciona ya que parece podría ser la solución mas “facil” de adoptar.

2ºsi aun así pese a esas 2 soluciones no se soluciona pues tendré que ingeniármelas para “ubicar” el display en otro sitio donde este a la vista fácilmente y si pueda reducir la distancia del cable a unos 5 u 10 cm.

Perdonen por el tocho y espero no dejarme a nadie atrás:S

muchas gracias a todos.

Un saludo.
12/03/2014 #28

Avatar de cosmefulanito04

Dr. Zoidberg dijo: Ver Mensaje
Por supuesto que es mejor transmitir en serie con un driver de bus CAN, pero eso requiere modificar el circuito y poner inteligencia en ambos extremos, lo que es mas caro y complicado que "cuidar un poco el cableado". Por favor.. balanceen la ecuación costo-beneficio!!!!
Ya, pero 1 mt de 6 líneas paralelas, es para problemas.

Además un uC tranca, no es tan caro y mejorás los errores que podés tener como dijo gonzalocg.

Esta bien, es solo un LCD, pero si perdés un caracter queda fea la presentación. Habría que ver que pasa si repite los caracteres varias veces (cuestión de que uno entre ).
12/03/2014 #29

Avatar de Dr. Zoidberg

moisesviso dijo: Ver Mensaje
-Dr. Zoidberg la solución que usted propone me a funcionado a la perfección en la mesa de "pruebas" en una distancia máxima de 40cm pasados esos 40 cm vuelve el problema
No has usado un osciloscopio para ver la forma de la señal en los cables??? Por que no se sabe cual es el problema real... si es que las ondas se "aplastan" y no consiguen el nivel adecuado o que las señales se retrasan y desincronizan entre sí o que hay un crosstalk violento.
Esa configuración de cables no es mas que un conjunto de capacitores colgados a las salidas del PIC, así que una posible solución parcial a ambas problematicas anteriores sería usar resistencias de pull-up en las líneas que vienen del PIC en el PCB del LCD (en esa Y NO en el pcb del PIC). El pull-up podría ayudar a fijar los niveles de tensión a valores mas saludables en el LCD y ayudaría a cargar las capacidades del cable, mejorando tal vez la performance para la distancia requerida.
El ULN2803 haría algo parecido pero tenés inversión de niveles lógicos en las líneas y el LCD no va a entender un pomo de lo que le mandés a menos que cambies la biblioteca de gestión del LCD o metás otro ULN junto al LCD... con lo cual necesitarías 2 chips extra... . Tal vez sea preferible usar un buffer no-inversor CMOS como el CD4050 que puede manejar mucha corriente de salida, pero no soy muy amigo de agregar hardware a menos que sea necesario.

---------- Actualizado después de 10 minutos ----------

cosmefulanito04 dijo: Ver Mensaje
Ya, pero 1 mt de 6 líneas paralelas, es para problemas.
Seee... no me cabe dudas que es para problemas, pero las impresoras de PC mandaban info por 25 cables paralelos a mas de 1 metro y andaban bien así que no es imposible ni mucho menos.

cosmefulanito04 dijo: Ver Mensaje
Además un uC tranca, no es tan caro y mejorás los errores que podés tener como dijo gonzalocg.
Naaa!!!! Otro chip para manejar la comunicación y corregir errores en un LCD???? No solo el problema es el precio, sino el PCB, el diseño del software y el mantenimiento de dos partes "inteligentes" que no sabés cual es la que puede fallar. Eso exige diseñar un sistema adicional con un micro solo para ensayar ambos extremos desacoplados entre sí y encontrar fallas. La verdad... no me parece una solución viable....

cosmefulanito04 dijo: Ver Mensaje
Esta bien, es solo un LCD, pero si perdés un caracter queda fea la presentación. Habría que ver que pasa si repite los caracteres varias veces (cuestión de que uno entre ).
Con los LCD siempre hay líos cuando los cables son muy largos, pero dudo que sea algo taaan grave que no pueda solucionarse bajando la velocidad de las señales y mejorando el enlace...
12/03/2014 #30


moisesviso dijo: Ver Mensaje
pues después de a ver probado con varios tipos de cables apantallados sin apantallar,paralelos utp etc y varias configuraciones me declino por unas de las siguiente soluciones.
probaste cable vga ese tiene blindaje individual
y se puede obtener gratis de un crt
12/03/2014 #31


seguramente el programa del pic escribe en la pantalla una y otra vez para provocar la ilusion de que los datos cambian, pero intenta lo siguiente: como las interferencia son las que te crean problemas, disminuye la velocidad de los comandos y datos a unos 100 por segundo a lo mucho, y envez de escribir toda la pantalla a cada rato, solo reescribe los datos que cambian, asi disminuyen la cantidad de comandos al minimo y con ello la tasa de errores. cada cierto tiempo reescribe toda la pantalla para asegurarse que no se modifican por el ruido en el ambiente.

esta es una solucion un poco complicada de implementar pero te permitira solo hacer cambios en software del pic. y otra cosa, como el ruido que entra en las lineas y aumenta o disminuye los voltajes, lo que podrias hacer es colocar condensadores en la entrada y salida de los cables para enviar a tierra el ruido introducido pero con el aumento de la capacitancia de las lineas sera necesario inyectarle mas corriente pero dado que las salidas de los pic pueden manejar 25mA no tendras problemas, y como la velocidad sera menor, los datos estaran seguros en las lineas antes de que actives el comando habilitando el display...

en fin, no se que mas podrias hacer...
12/03/2014 #32

Avatar de Dr. Zoidberg

gonzalocg dijo: Ver Mensaje
seguramente el programa del pic escrive en la pantalla una y otra vez para probocar la ilucion de que los datos cambian

Los LCD no trabajan de esa forma!!!! El display LCD tiene un microcontrolador on-board con la memoria necesaria para capturar los datos que le envía el PIC y gestionarlos en el display.
El PIC solo escribe cuando quiere cambiar la información que envió antes, así que NO HAY un flujo contínuo de datos en el PIC y el LCD excepto cuando se envía un comando y/o un string para mostrarlo. La escritura en un LCD es costosa en tiempo de procesamiento (los tiempos son generados con busy-loops), así que no dá para estar mandando verdura al display permanentemente.
12/03/2014 #33

Avatar de papirrin

El ULN2803 haría algo parecido pero tenés inversión de niveles lógicos en las líneas y el LCD no va a entender un pomo de lo que le mandés a menos que cambies la biblioteca de gestión del LCD o metás otro ULN junto al LCD... con lo cual necesitarías 2 chips extra... .
Dr. Zoidberg Que le hice yo para merecer su desprecio

ya puse el esquema completo unos mensajes antes y lo que se necesita para mi propuesta, en donde estoy me costaria hacer la prueba esto:
1 7414 y 1 uln2803 costo total 9+23=32 pesos mx + cero tiempo de codigo

para la opcion del RS485 me costaria esto:
pic16f628a+max485+max485=79+(34+34+100envio)=247mx + tiempo de codigo
el max485 por lo menos donde vivo no se consige facil por eso incluyo el envio

y es cierto si se quiere ahorrar 9 pesotes del 7414 y trabaja con C, nada mas se cambia la libreria

P.D. para hacer la prueba del ULN tengo todo, pero desafortunadamente el tiempo y las ganas por ahora no, despues con tiempo y si nuestro compañero no hace la prueba yo la hago y les comento si funciona o no.
13/03/2014 #34


En una máquina en que se daño el circuito de control, esta tenia el display (VFD: vacuum fluorescent display) a cierta distancia, al modulo vfd (similar al lcd+hd44780) llegaba un circuito como este:


Los cables no estaban apantallados, ni llevaban cables de tierra, ni tenia cable trenzado, y el sistema funcionaba bien.
Cuando se daño el VFD me toco reemplazarlo por un LCD, para evitar problemas de ruido le hice una placa adicional al lcd, similar a la que tenia el VFD incluso usando los mismos ferrites y capacitores, sin embargo no se soluciono nada y a cada rato aparecían caracteres raros, la pantalla se ponía en blanco o simplemente dejaba de responder, incluso baje la velocidad de transmisión y ni así logre desaparecer el problema.
Al final lo que hice fue hacer una rutina para refrescar el LCD periódicamente, pero dentro de esta rutina de refresco enviaba el reset para el LCD, fue una solución un poco para salir del paso, pero quizá le sirva de algo al que pregunto.
Saludos al foro.
16/03/2014 #35

Avatar de Cyborg16

Y si trabajas con un lazo de corriente, tipo 4-20 mA? Vas a tener que agregar algo de hardware principalmente del lado del PIC (algunos transistores), pero del otro lado podes poner una resistencia en serie con el hilo y a masa calculada de tal manera que a máxima corriente te caigan 5 V y tomar las señales para el display de ahí. No sería 4-20 mA sino 0-20 mA igual jaja, pero es mas o menos la idea.

Saludos.
23/03/2014 #36

Avatar de papirrin

Hoy tuve el animo para experimentar en lo del LCD y mi esquema, y les tengo noticias buenas y malas:

las malas es que no funciono con solo 1 metro, funciono con cuatro metros y creo que aguanta mas pero no tenia mas cable.

las buenas es que no es ni cable apantallado, ni aislado, quizas solo trenzado pero casi seguro que eso no importa


aqui video de prueba:


solo faltaria hacer la prueba dentro de un vehiculo pero casi seguro funciona pues la cabina hace las veces de jaula de faraday
23/03/2014 #37

Avatar de cosmefulanito04

Buen dato, un pull-up más fuerte puede salvarte .
24/03/2014 #38

Avatar de Scooter

Lo malo es que luego llega el mundo real a fastidiarlo todo.
Si en tu casa va con 4m en la realidad seguramente no; chispas de las bujías, corrientes alternas del alternador etc.
Lo malo de las cápsulas de faraday es que si están dentro las emisiones...
De cualquier modo es cuestión. De probar.
25/03/2014 #39

Avatar de papirrin

Si en tu casa va con 4m en la realidad seguramente no; chispas de las bujías, corrientes alternas del alternador etc.
Hombre de poca Fe (broma)

funciona perfecto!


se ve que cambia el dato pero estoy apretando el boton del control remoto, que asi esta programado el pic.
el video es de mala calidad esta echo con telefono. tiene alguna duda o quieren un video de HD me dice pero no creo que desconfien de mi.
25/03/2014 #40


un control remoto
¿Tienes una mejor respuesta a este tema? ¿Quieres hacerle una pregunta a nuestra comunidad y sus expertos? Registrate

Foros de Electrónica » Diseño digital » Microcontroladores y sistemas embebidos

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