USB colgado por transitorios
 

www.geocities.ws/danielperez    www.qsl.net/lw1ecp   Ing. Daniel Pérez    LW1ECP   

fb: Daniel Ricardo Perez Alonso    contacto: danyperez1{arrroba}yahoo.com.ar

Julio 2018

De vez en cuando aparecen consultas en foros sobre pérdida de comunicación USB sin motivo aparente o cuando chispea un contacto. En la siguiente imagen es lo que me pasó a mí: un Arduino conectado a una PC y sólo a la masa de una fuente. Omití dibujar todo componente que no tuviera que ver con el análisis del problema. El Arduino se alimenta por USB, la fuente no alimenta nada. Se envían datos únicamente hacia la PC.

Bien, el 95% de las veces que enchufo o desenchufo la fuente, se congela la comunicación. El chispazo genera un transitorio de alta frecuencia que viaja por las masas e induce estados lógicos erróneos en algún lado, posiblemente colgando el driver que hace que el USB le parezca un puerto serie virtual al soft de comunicaciones.
- El LED Tx del Nano sigue parpadeando.
- Pulsar su botón de Reset no tiene efecto.
- Si sólo salgo y vuelvo al .EXE (Termite) me da:
  'Run-time error '8015': Could not set comm state, there may be one or more invalid comm parameters.'
- Si en el IDE abro el Monitor Serie o reconfirmo el COM, me da:

  'Tarjeta en COM3 no disponible' o 'Error al configurar los parámetros del puerto serial: 9.600 N 8 1.'
- En el Administrador de Dispositivos en 'Puertos (COM y LPT)' sigue existiendo 'USB-SERIAL CH340 (COM3)'
Para restablecerla hay que desconectar y reconectar el USB, y ADEMÁS desactivar y reactivar el programa de comunicaciones.

Los problemas de interferencia pueden atacarse en cuatro lugares:

1) Donde se origina. En nuestro caso, evitar la chispa. Puede ponerse una red 'snubber' o apagachispas: R en serie con C, y esto en paralelo con el primario del transformador para absorber los picos inductivos. También es bueno encender y apagar con un interruptor adecuado, que conmuta mucho más rápido que una ficha introducida manualmente en un toma. Decidí no arrancar por ese lado, porque si logro inmunizar el sistema contra el chisporroteo generado intencionalmente con la ficha, también habrá mejorado frente a transitorios generados en otro lado que vengan por la red eléctrica.

3) Donde se recibe. Si fuésemos a diseñar los circuitos de comunicación, podríamos optar por integrados CMOS alimentados con 18V para meyor inmunidad al ruido, o usar redes RC para atenuar los transitorios (si es que fuesen más breves que los datos). Pero el USB no es así. Además, al igual que el estándar RS485 o Profibus, utiliza comunicación diferencial para reducir la captación de ruidos, por lo que extraña que ocurran los cuelgues, podría ser que el cable USB usado no tenga trenzados los conductores de señal.

4) Permitir que ocurra el problema pero evitar que pase a mayores. Por ejemplo, usar chequeo CRC y si el receptor detecta un error pedir retransmisión. O bien, si llega un único dato con un valor anormalmente fuera de lo esperado, ignorarlo. Pero en nuestro caso, no sólo se corrompen los datos, directamente se interrumpe la comunicación para siempre, lo cual podría indicar una debilidad en el software driver (CH340).

Dejé para lo último el 2) que es donde voy a atacar: el medio por donde se propaga la interferencia. Abriendo la unión de masas en 'X' desaparece el problema, lo cual indica que es una interferencia conducida, no radiada. Para mi uso necesito esa conexión ya que debo monitorear la carga de una pila alimentada por la fuente. Probé de conectar varios tipos de chokes (inductores) en serie para permitir el paso de la continua pero impedir que los impulsos de corta duración circulen por las masas. Probé con inductancias entre algunos uH hasta decenas de mH, incluso todas en serie, sin éxito. Con un R de 1k seguía colgándose. Recién tuve éxito con 10k, valor inadmisiblemente alto para poder medir tensión continua con confianza, en la eventualidad que circulase alguna corriente galvánica por masa.

Como el protoboard tiene una chapa metálica pegada en su base, por las dudas la conecté a la masa del Arduino.

Probé de evitar que la corriente de interferencia circule por el cable USB, conectando la fuente directamente a la carcasa de la PC, o bien a una chapa fina insertada a presión junto con el conector USB, (b). Desapareció el problema. Pero ahora habría una diferencia de potencial entre la masa de la fuente y la del Arduino, debido al consumo de éste circulando por la resistencia del conductor de masa USB, o sea una fuente de error en la medición.

No sólo eso, si acercaba algunos centímetros el cable de masa al USB, (c), reaparecía el problema.
 

Dado el éxito de (b) estuve tentado de poner el Arduino dentro de la PC, con su mini USB conectado directamente a chasis, pero eso obligaría al usuario a abrir la PC.

También se probó de enrollar el cable USB en un toroide (entraron 4 vueltas) para hacer un choke de modo común y obligar a la corriente de interferencia a circular por el cable agregado, (d), sin éxito.

Un amigo me sugirió probar con cable USB blindado. Lo había descartado desde un principio ya que se requeriría un componente 'especial'. El cable mini-USB que usa el Nano ya es una interfase obsoleta, y si bien encontré quien lo ofrece blindado en ML, conociendo lo pobre que es la malla en algunos cables blindados de audio (algunos pelitos ni siquiera trenzados), prejuiciosamente lo descarté.

Mejor, agregar blindaje uno mismo. Lo hice, y se acabó el problema, (e).

Las siguientes imágenes muestran los pasos. Se cortó una tira de aluminio con la cual recubrir el cable USB, de modo que también abarque el armazón metálico de los conectores. Nula flexibilidad mecánica, pero sirvió para encarar el enmallado casero.

Al pelar el cable verifiqué que los cables de señal no están trenzados. Además hay un film plástico metalizado recubriendo los conductores, más un cable pelado adentro y algunos pelitos afuera. Es posible que el cable pelado se encargara de conectar las armazones de ambos conductores, capaz que en el lado mini USB tenía conexión pero la destrocé al abrirlo. Nunca lo sabré, pero de otros 5 cables USB que tengo sólo 1 tenía continuidad entre las armazones.

La malla la obtuve de un coaxil. Probablemente fuese un RG58, de 50 ohm, porque los RG59 de 75 ohm usados en TV tienen malla de aluminio, casi imposible de soldar. Hubiese sido mejor obtener la malla de un coaxil más gordo como el RG8, de ese modo se podría parar la malla por el mini-USB sin cortar el cable.

Una vez retirada la cubierta uní un cable a continuación del otro con cinta de papel y fui trasplantando la malla.

La malla se soldó abundantemente a las armazones. Tras tomar la última foto, los extremos se protegieron con varias vueltas de cinta autosoldante.

El resultado fue tan bueno como con la chapa de aluminio. Ahora bien, es esto práctico para producción en serie? No! Sirvió para mostrar por dónde era la solución, pero para fines lucrativos será necesario investigar la disponibilidad de cable mallado. Y como probablemente el producto no contenga un Arduino sino el AtMega y el CH340 en una plaqueta específica, nos libramos de que el cable mallado sea mini-USB. Considerar cable de red blindado (STP) usando parte de los conductores.

Para entender el mecanismo de esta interferencia:

El impulso generado por la chispa tiene un camino completo a través del cable USB y la red eléctrica. Los capacitores Cy entre cada polo de la red y chasis son parte de las medidas anti interferencia de RF en las fuentes de PC. Del otro lado tenemos la capacitancia entre bobinados de la otra fuente. El impulso de corriente, al pasar por la R y L del cable de masa del cable USB, desarrolla una cierta caída de tensión momentánea. Si el Arduino estaba poniendo +0,3V en una línea de datos y +2,8V en la otra, en ese momento la placa USB de la PC va a 'ver' esas tensiones sumadas a la caída de tensión del ruido. El ruido queda sumado por igual en ambos bornes de datos en la placa USB y no debería haber problemas, es la ventaja de la comunicación diferencial, no?

No, mentira! Es más complicado, la corriente por masa también induce tensiones sobre las líneas de datos, que para ser iguales es necesario que estén trenzadas. O bien, blindar todo el manojo de datos para que el flujo magnético de ruido se acople por igual a todos los cables.

Realmente había apostado mis cartas a que esto se resolviera con un choke de modo común en la línea. La ineficacia de esos inductores en serie con la masa me hizo cambiar de opinión.

Alternativas a estudiar:

- Arduinos con el FTDI232 como interfase USB. Tal vez su driver sea más robusto. O ver si hay un driver CH340 mejorado.

- RS232. A favor: con niveles típicamente de -12/+12V sería mejor que los 0,3/2,8V del USB en modos low speed y full speed. Además no hay un driver que se cuelgue. Contras: no es diferencial, el USB sí (aunque de cuánto sirvió...?), y la peor de todas: las PC ya no traen puerto serie.

- RS232 en las líneas hacia la PC, pero con un conversor a USB enchufado directamente en un puerto USB.

- Fibra óptica.

- Radio (bluetooth, Wi-Fi, etc).

- CONVIVIR con el problema: que el sistema pueda recuperarse solo al estilo watchdog. P. ej. que tras cada transmisión el Arduino quede esperando un Ok del programa en PC, caso
contrario que haga algo como resetear la interfase USB, etc.

- Puesta a tierra: sugerido en un foro. No lo probé, es un método para cuando hay ciertos problemas con campos eléctricos, supongo que no influiría en esto que es un loop de corriente.

- Probar si anda Ok un cable comercial que tenga continuidad entre armazones de ambos conectores.
 

Pero por qué el USB es tan popular, si es tan frágil? Es que los problemas raros me pasan sólo a mí??? Veamos:

- Mouse, teclado: no están conectados a la red de por sí, por lo tanto no hay posibilidad de que se cierren transitorios por el cable USB.

- Impresora: sí se conecta a la red, pero qué importa lo que pase por el USB en el momento de enchufarla o desenchufarla. En cuanto a los transitorios desde otro punto de la red: llegan por igual a la PC y a la impresora mientras están ambas enchufadas, con lo que no es probable que afecten.