Ideas de diseño

El diseño de un nuevo dispositivo se parece a la exploración de un nuevo mar, se parece en el sentido de que a pesar de que hay muchas manera de llegar a nuestro destino, habrá unas con el mar más quebrado, unas que requerirán de un barco más equipado, unas que requerirán de una tripulación más grande.

Siguiendo esta analogía, yo soy un barquero en una chalupa que le promete llegar al otro lado del Atlántico por solo 300 pesos. Quizá resulte difícil de creer pero quizá con eso me haya ganado su atención con este pequeño cuento. Además, no lo vea como comprar un viaje, yo aquí únicamente le estoy dando un panfleto de viajes "¡Llegue a América con 300mxn!".

En este capítulo se tratarán las múltiples ideas que se exploraron antes de comenzar con la exploración de la última iteración del proyecto. Por lo mismo, considero que no es demasiado importante profundizar en el funcionamiento propuesto al momento de proponer estas implementaciones, sin embargo, creo que merecen su mención.

A pesar de que muchos de estos fallos tienen una potencial solución relativamente sencilla, estas soluciones generalmente exceden el presupuesto límite, la facilidad de acceso para estudiantes o son un riesgo para el dispositivo a manos de un usuario inexperto. Esta lista está aquí más bien para dar idea del proceso de diseño que para descartar las ideas como inviables.

IDE Arduino

El IDE de Arduino es para muchos el primer contacto que tienen con el desarrollo de herramental lógico para tarjetas integradas. Ya sea por medio de las tarjetas de Arduino, las de la serie ESP o circuitos integrados de otros fabricantes, el IDE Arduino se ha convertido en una especie de herramienta estándar de la industria por su facilidad de uso. En este IDE podemos encontrar ciertas herramientas ya incluidas para realizar la lectura del monitor serial.

El IDE Arduino está programado en Java en buena medida por su compatibilidad entre diferentes plataformas y sistemas operativos. Al IDE también se le pueden agregar diferentes complementos para hacerlo "más completo" según el caso de uso que uno le esté dando. Consideré por un tiempo que quizá aprovechar gran difusión de el IDE Arduino sería benéfico al momento de realizar este proyecto, sin embargo, por las cuestiones aquí planteadas abandoné esa idea.

1. Limitantes de diseño
2. Dependencia de código exterior (Arduino) (La creación de este proyecto coincidió con el cambio del IDE Arduino a la versión 2.0)
3. Inestabilidad del IDE al momento de cambiar puertos (en especial en computadoras con sistema operativo (SO) Mac y Linux)

Programación en C++ con biblioteca olcPixelGameEngine.h

El segundo lenguaje de programación contemplado para la realización de este proyecto fue C++ haciendo uso de diferentes bibliotecas, en el caso de C++ (a diferencia de Java) no se incluye una manera directa de crear ventanas y graficar sobre de ellas por lo que es un poco más complicado realizar interfaces gráficas con aceleración por medio de la tarjeta gráfica (GPU).

Consideré que olcPixelGameEngine (documentación en inglés) era una opción viable para conseguir la graficación de las lecturas del osciloscopio por ser suficientemente amable al momento de graficar a altas velocidades y proporcionar un ciclo de graficación análogo al de la programación de un videojuego. Esto permitía que a pesar de que todo se graficara lento, uno podría mantener una imagen constante con problemas menores.

Hubo ciertas consideraciones que surgieron al momento de empezar a programar con C++, no existe una biblioteca única en C++ para el menejo de los puertos seriales por lo que la programación cambiaría bastante según qué biblioteca eligiera. En su momento había utilizado JSerialComm ya que era la más referenciada en el trabajo en Java, sin embargo, no había ningún análogo "estándar de industria" en C++.

Entre los problemas surgidos por el desconocimiento de C++ así como las ventajas que traía Java a la mesa surgieron las siguientes conclusiones:

Uso de ADC (Convertidor Analógico Digital) externo

Esta idea surgió y rápidamente desapareció ya que como se planteo en el capítulo de introducción. El uso de un dispositivo ADC externo podía haber resultado benéfico para conseguir mayores velocidades de muestreo, sin embargo, por restricciones de precio y de accesibilidad a los estudiantes esta propuesta fue rápidamente descartada.

Uso de tecnología Bluetooth

La tarjeta ESP-32 así como varias de las otras consideradas tienen capacidades de Bluetooth así como de Wi-Fi, sin embargo, dado que el máximo baudaje por medio de Bluetooth 4.0 es de 115200 baudios. Este protocolo serial, se traduce a 14'400 Bytes por segundo, cada una de las mediciones, por ser de 12 bits de resolución necesitaríamos 16 bits por lectura yendo desde la ESP-32 hacia la computadora. A pesar de que en papel esto debería de darnos aproximadamente un 1kHz en lecturas, la realidad es que este tiempo únicamente considera el tiempo que le toma al protocolo RXTX en la ESP-32. Dada la naturaleza de la tarjeta (cuyo lenguaje ensamblador no está bien documentado) estamos trabajando con el compilador de Arduino como una caja negra y por tanto no tenemos demasiado control con respecto a esto.

De todas formas, fijar la tasa de baudios a la mayor posible (en nuestro caso 1'000'000 de baudios) permitió aumentar sustancialmente la frecuencia de muestreo. Para mantener esta tasa de baudios fue necesario trabajar siempre con un cable USB-MicroUSB. Así también ahorrando la necesidad de usar alimentación con otros dispositivos.

Uso de baterías y alimentación externa

Simultáneamente a la exploración de la tecnología Bluetooth se consideró que el dispositivo osciloscopio podría ser un aparato con independencia energética de la computadora o teléfono móvil al que se encontrara conectado. Esto signficaría el uso de una batería para manterlo encendido y operando. Dado que el funcionamiento de las tarjetas ESP-32 es con voltajes de 3.3V necesitaríamos dos baterías de Ion Litio (Lion) para tenerlo funcionando de manera segura. Además, el tener baterías en serie nos facilitaría el uso de voltajes positivos y negativos con respecto a un punto de referencia (i.e. -2.2V a 2.2V con respecto al punto entre ambas baterías). La realidad es que el manejor de las baterías de litio resultó ser más conflictivo de lo que parecía inicialmente si uno decidía no usar dispositivos para su manejos.

Análisis muy posteriores (realizados por el laboratorio de Robótica en el edificio J) junto con información anecdótica por parte del profesor Yukihiro Minami dieron sustento y completitud a la hipótesis del fallo observado en su momento.

• Al armar el dispositivo para su uso con baterías, al momento de emparejar tierras entre las baterías de Ion-Litio y la computadora en la cual se realizaría la visualización de los datos de RXTX rápidamente se quemaba la tarjeta ESP-32 que se encontrara conectada.

Correo original

La información posterior reveló que en efecto era muy complicado obtener un comportamiento confiable de las baterías de Ion-Litio sin utilizar cuatro tipos de de circuito adicional:

1. Desconección automática a bajo voltaje
2. Circuito controlador de carga
3. Circuito controlador de descarga

Sin estos dispositivos o un (qph) (dispositivo que contiene a los tres) sería casi imposible utilizar baterías de Ion-Litio de forma segura. Es por eso que quedaron descartadas.

Uso de aplificadores operacionales

Durante la mayor parte del desarrollo de este circuito se contempló que sería imposible evitar el uso de amplificadores operacionales (a veces llamados "operacionales") para dar ganancia, reducción, filtrado y demás manipulaciones que se quisieran aplicar a las señales eléctricas leídas por el osciloscopio. A pesar de que la mayoría de los dispositivos del mundo real sí usan amplificadores operacionales para la manipulación de las señales que utilizan, en nuestro caso, una de las decisiones más difíciles de tomar fue el abandono total de los amplificadores para hacer la manipulación de la información de la señal completamente en herramental lógico (software).

Se llegó a esta decisión cuando se abandonó la idea de utilizar baterías externas. Esto nos llevó a únicamente poder trabajar con un intervalo de 5V para alimentar los amplificadores operacionales y con este voltaje poder invertir, amplificar, reducir o seguir voltajes. No pudimos lograr ninguno de estos comportamientos (además de la reducción) usando amplificadores de la serie TTL (los que se suelen usar en las otras prácticas de la Facultad) esto significaría tener que comprar dispositivos más raros de bajo voltaje haciendo el proyecto más difícil de conseguir y económicamente menos viable de lo que se deseaba.

Uso de condensadores para separar señales

Entre las propuestas que tiene un osciloscopio siempre se encuentra la separación de las señales de corriente alterna (CA) y corriente directa (CD). Esto puede resultar muy útil al momento de visualizar valores así como dar información que no es necesariamente fácil de leer únicamente a partir de gráficas pero sí resulta fácil de interpretar para una calculadora que conoce la información y la puede promediar o calcular.

Por medio de condensadores hubiera sido fácil separar la señal leída en dos diferentes señales, una señal pasa-bajas en la que únicamente se mediría el promedio de la señal introducida (esto nos daría inmediatamente el componente de CD) mientras que por medio de un condensador de "bypass" se podía haber desacoplado el componente de directa y únicamente medir la oscilación de voltaje después de ese condensador de desacomple. Esta idea se abandonó cuando se ponderaron las ventajas de usar condensadores contra el hecho de no usarlos.

Ventajas:

1. Facíl desacople de señales
2. Garantía de protección tras el condensador de desacople
3. Lectura inmediata del voltaje de CD
4. Lectura inmediata de voltaje de CA con respecto a la referencia

Desventajas:

1. Estados transitorios (inexactitudes)
2. Tiempo de transitorio (carga y descarga) a menos que se tuviera una señal estacionaria
3. Desfase de señales de alta frecuencia en el tiempo
4. Precio peligrosamente cercano al presupuesto máximo permisible

La realidad es que de haber querido armar un osciloscopio "mejor" hubiera sido posible dejarlos en el diseño final, sin embargo, se obviaron, dejándole el trabajo del análisis de las señales completamente al herramental lógico.

Uso de botones y controles externos

La propuesta inicial de osciloscopio contemplaba la posibilidad de modular resistores así como mandar comandos a la ESP-32 por medio de botones o interruptores. Con el abandono de los condensadores también se abandonó la idea de utilizar resistores modulares (potenciómetros) ya que tenerlos en el dispositivo hubiera significado un mayor nivel de desconocimiento con respecto a los resistores reales que de tener resistores fijos con un error de fábrica.

Posteriormente se volvería bastante claro que a pesar de tener un error de fábrica, dado que los fenómenos observados en los resistores son siempre lineales en nuestro rango de voltajes/corrientes esperado sería mayormente sencillo ajustar las lecturas con valores de voltaje de referencia y así tener valores más cercanos a la realidad pese a tener errores inherentes a la manufactura de nuestro dispositivo.