En este artículo, veremos como controlar temperaturas a distancia mediante un enlace Bluetooth y como recibir los eventos de activación de dos pulsadores remotos sobre nuestro móvil con Android. La versatilidad que nos brindan los sensores integrados, como el LM92, sumado a la practicidad de trabajar en cualquier entorno con un dispositivo móvil Android, nos llevan a idear elementos que antes dependían de transportar un ordenador portátil a donde sea necesario controlar y/o registrar eventos o condiciones de trabajo de alguna máquina, de un ambiente o de cualquier entorno “que debía ser controlado”. Hoy, gracias a Android, a App Inventor y a un elemental hardware construido alrededor de un 18F25K20 podremos controlar todo esto y mucho más desde la comodidad de nuestro dispositivo móvil.
En artículos anteriores pudimos ver todo lo necesario para alcanzar un enlace entre nuestro dispositivo móvil, dotado de Android, y un circuito sencillo basado en un PIC, el poderoso 18F25K20 que, gracias a la utilización del software libre Amicus nos permitía recibir instrucciones y datos enviados desde nuestro dispositivo móvil. La aplicación, por sencilla que fuera, nos permitió alcanzar un “Hola Mundo” encendiendo un LED a distancia. Por supuesto que ese puntapié inicial nos creó el entusiasmo para intentar la comunicación inversa, es decir, transmitir hacia el dispositivo con Android, datos generados en nuestro circuito de ensayo. Además de dos pulsadores, hemos incluido en este trabajo un sensor de temperatura para recibir a distancia un dato adicional que agrega más complejidad al trabajo, pero que sirve para imaginar el control total que podemos ejercer sobre un equipo remoto. Esto es, nos muestra el potencial de comodidad que podemos alcanzar, dejando de lado los ordenadores portátiles que antes eran los reyes de los trabajos de campo. Hoy, Android llega para ocupar ese lugar y que todo sea más sencillo, rápido y práctico que antes. Las aplicaciones ahora pueden desarrollarse en ámbitos insólitos. Observa:
Lo que vemos en imagen es la aplicación que venimos desarrollando desde hace algunos artículos atrás, con el beneficio de recibir información en el dispositivo móvil, proveniente de nuestro circuito con microcontrolador. Recuerda que tú puedes utilizar cualquier microcontrolador y cualquier lenguaje de programación, nosotros por comodidad utilizamos el PIC 18F25K20, pero estos ejemplos pueden trasladarse a cualquier microcontrolador. En este desarrollo concreto, tomamos lectura de dos pulsadores y la cadena de datos que nos envía el termómetro integrado LM92 para presentarlas en la pantalla de nuestro dispositivo móvil. Hasta ahora, nuestro trabajo se construía en el App Inventor con los eventos de pulsar un botón y ello se continuaba con acciones que se presentaban en la pantalla del móvil y con datos enviados vía Bluetooth a nuestro desarrollo remoto. Estos eventos ocurrían a cada momento en que “nosotros decidíamos ejecutar la acción” y el PIC los esperaba con la instrucción HSERIN para recibir los datos, interpretarlos y ejecutar el trabajo en función de la estructura de los datos enviados. Ahora, es nuestro móvil Android el que debe estar a la escucha y atento, de manera permanente, esperando las instrucciones o datos que el PIC pueda enviarle en cualquier momento con el comando HSEROUT. Es muy importante comprender esto: la aplicación de campo puede enviar datos en cualquier momento y Android deberá estar atento siempre.
Por supuesto, siempre existe una tasa de error, en la recepción de datos, que puede ser resuelta de muchas formas, de acuerdo a la habilidad del programador y a la complejidad necesaria para el trabajo. No será igual la prevención de errores para una sala de cuidados intensivos en un hospital que para un sencillo juego de luces de entretenimiento. En nuestro ejemplo, intentamos reducir al mínimo los errores aunque se trate de una aplicación trivial, pero de todos modos, nuestro propósito (ahora) no es explicar ahora cómo evitar o minimizar errores sino cómo enviar datos útiles y que se puedan utilizar para aplicaciones con un alto potencial de desarrollo posterior. El video anterior muestra un simple protoboard dentro de una heladera (nevera/refrigerador/cámara de frío) pero con algo más de esfuerzo y atención en el trabajo del software, puede transformarse en el control de una cámara frigorífica industrial que puede ser monitoreada con un simple teléfono móvil que disponga de Android. Las alarmas del LM92 más todos los eventos y parámetros que puede controlar el PIC, estarían en la palma de tu mano o lo que es mejor, de tu futuro cliente. Como mencionamos antes, para ello hay que trabajar sobre las rutinas de corrección de errores para evitar falsas alarmas o funcionamientos erráticos. El circuito utilizado es el mismo que el anterior con el agregado de los pulsadores y el LM92.
Para estar siempre alerta y “a la escucha” de cualquier arribo de datos, App Inventor, como todo sistema de programación orientada a objetos, posee lo que se conoce como “Timer”. A este importante elemento de programación podemos utilizarlo para muchas cosas dentro de un programa. Con él podemos construir desde una alarma, pasando por un temporizador o un cronómetro hasta para lo que nosotros lo necesitamos: para ejecutar eventos cada un determinado período de tiempo. Es decir, nuestro “Timer” (o temporizador, o reloj, o clock) se encargará de decirle a Android que “escuche” si llega algún dato. Mientras no está escuchando, Android hará otras tareas, pero cada determinados lapsos de tiempo (establecidos por nosotros) se pondrá atento a recibir datos. Estos datos quizás nunca lleguen, o tal vez lo hagan en el momento menos oportuno, pero tarde o temprano llegarán y Android deberá recibirlos, procesarlos y ejecutarlos. Demás está decir que, todo esto será preparado mediante la aplicación App Inventor para finalmente ser cargada y utilizada en el dispositivo móvil. Uno de los criterios más importantes que debemos considerar entonces es que el “Timer” se activa cada determinado lapso de tiempo, el que puede no coincidir con la llegada de los datos. Es decir, puede presentarse la situación en que el los datos comienzan a llegar y a la mitad de ellos, el Timer se activa. Resultado: cadena de datos rota y resultados incorrectos para procesar.
El peor escenario es cuando el programador desconoce el tipo de información que debe recibir la aplicación. En cambio, si sabemos que siempre leeremos una cadena de datos que empieza con un asterisco, será sencillo rechazar cualquier cosa que no comience con un asterisco. Como dijimos antes, este no es un artículo donde explicaremos los métodos de corrección de errores, pero no debemos dejar de explicarte que te encontrarás con ellos al trabajar en App Inventor (o en cualquier tipo de software) y deberás trabajar para resolverlos. Retomando el trabajo de nuestro Timer, podemos mostrarte que utilizaremos dos. Uno será para marcar el ritmo de la “escucha” de los datos provenientes de la aplicación remota y el otro lo utilizamos para permitir que los datos recibidos se puedan mostrar un lapso de tiempo útil en pantalla. En el editor de bloques, el Timer más “rápido” servirá para tomar lectura de los datos (cada 10 milisegundos se activa) y el otro servirá para dejar la indicación en pantalla durante un tiempo prudencial.
Los temporizadores (Clock1.Timer y Clock2.Timer) se pueden apreciar en la parte inferior de la imagen. Clock1.Timer, cada 10 milisegundos (tú puedes ensayar otros lapsos de tiempo), en nuestro caso realiza la siguiente secuencia. Primero controla si el dispositivo Android está conectado con el dispositivo remoto. Si esto es así, observa si hay Bytes para recibir (en una cantidad mayor a cero). Nuevamente, si esto se cumple coloca sobre la etiqueta 10 (Label10) un texto. Este texto será la conjunción (join) de todos los Bytes recibidos en la cadena transmitida y acumulados en Label10.Text. Eliminará el color de fondo de la etiqueta y ofrecerá las letras de color amarillo. Por este motivo, cada vez que veías la temperatura entregada por el LM92, ésta aparecía de color amarillo. De este modo entonces, cada 10 milisegundos estamos atentos a lo que el módulo Bluetooth recibe. Pero al texto recibido hay que borrarlo porque de lo contrario se acumularía en pantalla y se perdería la lectura de datos en el fondo de la misma. Por este motivo, hay que colocar un segundo temporizador para borrar los textos mostrados después de un tiempo prudente. Para borrar un texto el procedimiento es muy simple, se escribe en su lugar un texto vacío. Obsérvalo en Clock2.Timer. Una vez que el intervalo se realiza, se aplica un texto vacío donde antes se mostraba la información.
Uno de los problemas habituales es “sincronizar” los temporizadores, cosa que nosotros no hemos hecho ya que, te repetimos, nuestra intención (ahora) no es corregir errores, sino recibir y mostrar datos. Ya tendremos oportunidad de aprender a corregir los defectos que provocan las activaciones fuera de tiempo de los temporizadores y que se manifiestan con una corta exposición del texto siendo en ocasiones, muy fugaz y breve mientras que en otras es prolongada y eficiente. Otro detalle que habrás notado en los videos es que, en ocasiones, el texto es truncado al inicio de los datos. Más allá de esto, ya estamos en condiciones de comenzar a trabajar con datos en ambos sentidos sobre Android. Ahora depende de ti y tu creatividad. En el Foro de Electrónica de NeoTeo estaremos siempre atentos a tus aportes, ejemplos, experiencias y enseñanzas que puedas ofrecernos. ¿Te imaginas todo lo que puedes lograr enviando y recibiendo datos de manera inalámbrica vía Bluetooth? Pues si te lo imaginas, compártelo con todo el mundo aquí, en NeoTeo.
La aplicación de campo puede enviar datos en cualquier momento y Android deberá estar atento siempre.
