PAK_CaoBT_v1

 

(Controladores CAO comunicados con

terminales Android por Bluetooth)

 

 

 

 

 

http://www.ciberdroide.com/cao/

 

 

 

 

 

 

 

 

 

 

 

 

Autor: Antonio Castro Snurmacher.

Copyright © octubre 2016.

 

Copyright y descarga de responsabilidades

Este libro ha sido publicado en modalidad de autopublicación. Tanto este libro como el software del paquete PAK_CaoBT_v1, (Que se corresponde con el primer volumen de la serie CaoBT) se distribuyen bajo la licencia Creative Commons Attribution-NonCommercial-ShareAlike.

 

 

Cuenta del autor en Twitter: @acastro333

Página del proyecto CAO: http://ciberdroide.com/cao

Formulario de contacto:  http://www.ciberdroide.com/wordpress/quien-soy-yo/formulario-de-contacto/

Canal YouTube: https://www.youtube.com/user/acastro008

  

 

 

En el momento de la publicación de este libro ya se ha publicado la primera parte del vídeo que ilustra este trabajo. Véase:  Proyecto CaoBT parte 1

Índice de contenido

Copyright y descarga de responsabilidades

Dedicatoria y agradecimientos

Prólogo

Consideraciones generales sobre CaoBT

CaoBT una bifurcación de CAO1

Comunicaciones serie en Arduino

Protocolo USART

Comunicación Serial en Arduino

Opciones de comunicación serie en Arduino.

Comparativa Arduino Pro Mini vs Arduino Pro Micro

Más diferencias entre Arduinos con Atmega328 y los que usan Atmega32U4

Forma de iniciar la conexión Serial en un Arduino Pro Micro o Arduino Leonardo

Posibilidad de uso de un módulo ESP8266

Módulo de enlace Bluetooth HC-05

Especificaciones técnicas

Modos de funcionamiento

Conexiones eléctricas para el HC-05.

Configuración del módulo HC-05 mediante comandos AT

Comandos básicos AT para configurar el HC-05

Métodos alternativos de configurar el módulo HC-05

Vincular en Android una conexión Bluetooth

Aplicación para Android

Video-tutoriales de referencia

Entorno de programación Android

App Inventor

Livecode

Processing

Lista de otros entornos de programación

Protocolos de comunicación entre aplicaciones

Protocolo Firmata

Algunas razones para no usar Firmata con CaoBT

Protocolo y tecnología Amarino

Nuestro Protocolo Cao_Serial_V2.0

Descripción del protocolo

Comandos de ordenes que pueden ser enviados por el Interfaz

Comandos de respuesta que pueden ser enviados por Arduino

Redundancia del protocolo

Gramática del protocolo

Los comandos y sus posibles respuestas

Posible mejora del protocolo

Carga de los programas de CaoBT

Carga de programas en Arduino por USB

Carga de programas en Arduino Pro Mini

Carga de programas App Inventor en Android

Gestión de ficheros en las APPs CaoBT para Android

Descripción de PAK_CaoBT_v1

Aplicaciones contenidas en PAK_CaoBT_v1

Cao_RefrigV1

TestHW01_CaoBTRM

TestHW02_CaoBTRM

TestHW03_TxRxLn

TestHW04_CaoBTRM

CaoBTrefrigMini

Aplicación principal CaoBTrefrigMini

Hardware de CaoBTrefrigMini

Microcontrolador Arduino Pro Mini

Lista de materiales para CaoBTrefrigMini

Esquema de CaoBTrefrigMini

Diseño de PCB para CaoBTrefrigMini

Sonda DS18B20

Metodología de montaje paso a paso y configuración de CaoBTrefrigMini

Paso 1) Configuración del HC-05

Paso 2) Primera prueba del hardware Arduino

Paso 3) Segunda prueba de hardware Arduino.

Paso 4) Tercera prueba de hardware Arduino.

Paso 5) Cuarta prueba de hardware

Paso 6) Montaje definitivo del circuito

Paso 7) Cargar el software de la aplicación

Software de CaoBTrefrigMini para Android

Primera pantalla Screen1

Segunda pantalla CaoBTrefrigMiniV03d

Tercera pantalla ViewTrazas

Recomendaciones finales para este programa.

Software de CaoBTrefrigMini para Arduino

Generalidades

Módulos de PAK_CaoBT_v1

Guía de usuario para CaoBTrefrigMini

Unas palabras para finalizar

 

 

Dedicatoria y agradecimientos

Quiero dedicar, tanto la elaboración de este libro, como el desarrollo del  software, a toda la comunidad acuariofilia de habla hispana con la que he compartido tantos buenos momentos.

Un agradecimiento especial para Rubén Claramonte que aportó un par de diseños de PCBs para este proyecto, lo cual va a facilitar mucho el montaje del circuito a los aficionados que quieran llevarlo a cabo.

Prólogo

 

El proyecto CAO ya fue objeto de la publicación de un primer volumen titulado “CAO1: Controlador de Acuarios por Ordenador basado en Arduino”.

En este caso se inicia una colección llamada CaoBT que reutiliza una parte de los conocimientos del desarrollo anterior  CAO1, pero que cambia el enfoque de los diseños tal y como explicaremos seguidamente.

No resulta imprescindible la lectura del volumen de “CAO1”, pero si ya lo ha leído, disfrutará de una cierta ventaja al leer este segundo volumen, pese a no ser exactamente una continuación del primero. A diferencia de la aplicación monolítica anterior CAO1, en los proyectos de  CaoBT, abordamos una nueva línea de proyectos más pequeños y especializados que responden a una nueva filosofía de diseño. Esta ofrece como interfaz de usuario la posibilidad de usar un terminal Android comunicado por Bluetooth.

Así pues, en lugar de un mega controlador de acuarios, tipo CAO1, en CaoBT iremos desarrollando con el tiempo un conjunto de controladores independientes, más pequeños, y que se podrán ser monitorizados y configurados mediante comunicación inalámbrica Bluetooth. Esto último se realizará  desde un terminal Android tipo tablet o smartphone.

Este nuevo enfoque no pretende sustituir a CAO1, sino ofrecer una alternativa al control de acuarios. CaoBT representa a una bifurcación del proyecto CAO1 que probablemente seguirá su propio desarrollo incorporando nuevas funcionalidades.

Al ser este volumen el primero de una serie que denominamos CaoBT, se dedica bastante contenido a explicar una serie de conocimientos que son de carácter general para toda esta serie CaoBT.

 

Consideraciones generales sobre CaoBT

Empezaré intentando explicar los motivos que me llevaron a desarrollar esta nueva línea de proyectos para el control de acuarios basado en Arduino.

CaoBT una bifurcación de CAO1

 

Una de las cosas que pude observar en CAO1, es que pese a ser una aplicación flexible y altamente configurable, muchos usuarios necesitaban hacer un tipo de controles muy concretos y más sencillos para sus acuarios.

Por ello, además de continuar ampliando funcionalidades de CAO1,  decidí bifurcar el proyecto para que fuera aún mas flexible dividiéndolo en módulos hardware independientes.

Con este nuevo enfoque lo que se pretende es que un mayor número de módulos hardware más sencillos se puedan implementar por separado. Todo ello permitirá soluciones aún más flexibles, escalables, más baratas y mucho más fáciles de mantener. Además, el tamaño del software de CAO1 ya resulta un poco intimidante para los que entienden que no necesitan algo tan completo.

También vi otro problema en el diseño de CAO1. Para arreglar una parte del controlador había que parar todo ese equipo y eso no resultaba práctico ya que se trata de un equipo que ha de proporcionar un soporte vital permanente a nuestros peces. Por ello, muchas veces resulta más útil poder mantener por separado distintos controladores, que tener uno que lo controle todo.

Igualmente comprendí que el diseño software del interfaz de usuario, basado en un LCD de 20x4 y una botonera de 5 pulsadores usaba un sistema de menús que no escalaba bien. Resultaba costoso de programar y consumía mucha memoria SRAM, que es un recurso escaso en Arduino. El resultado tampoco era demasiado bueno, porque las capacidades gráficas del interfaz eran inexistentes, la introducción de datos numéricos era poco ágil y la introducción de datos alfanuméricos era simplemente imposible. Este primer interfaz de display de 20x4 más 5 botones, resultó ideal para implementar un par de cosillas, pero a medida que CAO1 creció y se convirtió en un gran controlador,  su interfaz se convirtió en un lastre cada vez más pesado para la aplicación.

Además, se da la circunstancia de que la ubicación física de ese interfaz con LCD más botonera tenía que estar en un lugar accesible para el usuario y no muy lejos del controlador Arduino ni del acuario y todo ello unido por un considerable número de cables. En resumen, pensé que CAO1 no escalaba bien.

Es evidente que todo diseño hardware se puede mejorar con más trabajo y más dinero, pero siempre pensé que el precio de los componentes era un factor muy importante a tener en cuenta en estos proyectos y ese fue uno de los motivos por los cuales me decanté inicialmente por el mencionado interfaz  basado en LCD y botonera. Pensé que era un hardware barato, sencillo y se le podía sacar bastante partido con un buen software, pero todo cambió cuando descubrí el HC-05. Este es un modulito que está muy bien de precio, me permitía una comunicación inalámbrica sencilla vía Bluetooth con cualquier terminal Android y por ello me abría la puerta a nuevas posibilidades para un interfaz de usuario mucho mejor y que más tarde comentaré. Existen otro tipo de modulitos igualmente baratos que permiten igualmente dotar a Arduino de la capacidad de comunicar de forma inalámbrica con un terminal tipo smartphone o una tablet. Hablo del ESP8266 que me permitía una comunicación vía WiFi. Por razones que luego también explicaré, preferí el HC-05.

Llegados a este punto, con el nuevo enfoque tenemos involucrados tres sistemas hardware cada uno con su propio procesador independiente de los demás y que son: Un terminal Android, Un módulo HC-05, y un micro controlador Arduino.

El HC-05 será el sistema central que ha de puente para permitir la comunicación serie inalámbrica entre ambos extremos (Android/HC-05/Arduino) y usa la tecnología Bluetooth ya incluida en la mayoría de los terminales Android.

Este cambio de enfoque respecto al LCD más botonera supone inicialmente un esfuerzo extra para usar este tipo de tecnología, ya que obligará al desarrollador a familiarizarse con algunas nuevas cuestiones técnicas derivadas del uso de estos modulitos HC-05, pero para el usuario final, casi todo son ventajas. El pequeño esfuerzo inicial que esto suponga para los programadores que quieran basarse en estos desarrollos, estoy convencido de que a medio y largo plazo merecerá mucho la pena, ya que una vez dominados estos nuevos temas, los podremos aplicar a diferentes necesidades no limitadas a la acuariofilia.

Los proyectos que se van a realizar con esta filosofía  recibirán el nombre genérico de proyectos CaoBT. Serán en principio proyectos minimalistas. Es decir, que han pocas cosas en el acuario, pero las harán de forma independiente y lo mejor posible. En este primer proyecto vuelvo a abordar el problema de la refrigeración de acuarios y usaré  componentes muy baratos y he denominado a este controlador CaoBTrefrigMini  (lo de Mini es porque usará el Arduino Pro Mini).

Existen bastantes consideraciones previas y ya hablaré más detalladamente de CaoBTrefrigMini un poco después, pero adelanto que al usar Arduino Pro Mini, que es un minicontrolador con una potencia muy similar al Arduino Uno, eso tendrá implicaciones importantes. Por ejemplo, a diferencia del enfoque anterior de CAO1, ya no vamos a optar por un potente Arduino 2560 con 256 KB de memoria flash para código, 8 KB de SRAM para datos del programa.  En lugar de ello, optamos por un Arduino Pro Mini 328 que solo tiene 32 KB de memoria flash para el programa y 2 KB de memoria SRAM para datos. Lo realmente interesante es que en el mercado chino hay algunos modelos que se pueden conseguir por solo dos dólares y este dato nos parece muy interesante. Hace que merezca la pena trabajar un poco más para conseguir un resultado similar al de un hardware más caro porque así un mayor número de usuarios podrá adoptarlo para cubrir sus necesidades.

En un futuro se podrían implementar con la misma filosofía de diseño CaoBT otros controladores especializados. Por ejemplo:  dimmers de iluminación,  controladores de nivel de agua, programadores de salidas,  controladores de CO2, etc. Así pues podremos ir añadiendo diferentes módulos controladores acorde a nuestras nuevas necesidades y dependiendo de las mismas, quizás usemos controladores Arduino más o menos potentes. Todos ellos trabajaran con total autonomía y podrían ser manejados desde nuestro smartPhone o nuestra tablet Android. Las ventajas pueden ser varias:

Desde este nuevo tipo de interfaz para el proyecto CAO podremos monitorizar el funcionamiento de estos controladores o cambiar su configuración en caliente (sin detener su funcionamiento).

Con este nuevo enfoque (CaoBT), incluso para un controlador concreto, podemos desarrollar diferentes Apps, que ofrezcan diferentes posibilidades de interacción con un determinado controlador.

Pongamos un ejemplo: a alguien podría interesarle una monitorización diferente de los sensores del acuario para representar los valores de algunos sensores mediante gráficas en nuestra tablet. Nosotros no lo hemos hecho, pero  no es muy difícil. Con App Inventor 2 podemos generar una URL con los datos adecuados para obtener esa gráfica invocando el servicio Google chart. Se trata de una API de Google que nos permite escribir una línea de dirección web, con cierto formato, y nos retorna gráficas estadísticas que pueden ser trazos, puntos, barras, tipo tartas, etc. Este simple ejemplo no podemos soñar hacerlo con un simple LCD porque nuestro interfaz Android es mucho más que eso.

En otras palabras, podemos diseñar diferentes aplicaciones para trabajar de diferentes formas con un mismo controlador o con varios de ellos y lo podemos hacer usando tecnologías de programación muy variadas. El diálogo entre el terminal Android y la aplicaciones CAO harán uso de un protocolo de comunicaciones desarrollado para el tipo de aplicaciones CAO, y eso simplificará bastante la programación de las App Android y hará que el funcionamiento de todo el sistema sea más adecuado y seguro para trabajar con  controladores automatizados de vivarios en general. (huertos, acuarios, insectarios, paludarios, aviarios,...)

Comunicaciones serie en Arduino

Protocolo USART

El acrónimo USART Universal Synchronous/Asynchronous Receiver Transmitter, (que significa Receptor y Transmisor Sincrónico/Asincrónico Universal). Los términos síncrono y asíncrono se refieren a cómo se transmite la señal de reloj, para establecer el sincronismo.

 

Comunicación síncrona:  

Cuando se transmite de manera síncrona lo primero que se envía es un octeto de sincronismo <syn> que generalmente será reenviado, cada uno o dos segundos, para garantizar el sincronismo de los relojes en el lado emisor y receptor. Estos caracteres de sincronismo deben diferenciarse de los caracteres de datos de usuario. Por ejemplo, el código ASCII utiliza el octeto 00010110 como carácter <syn>. Permite una comunicación de datos generalmente más rápida que el método asíncrono.

Comunicación asíncrona:

Cuando se opera en este modo no existe una línea de reloj y el carácter puede ser enviado en cualquier momento. Para ello,  ambos dispositivos acordarán transmitir datos a la misma velocidad. Cuando no hay transmisión la señal entre ambos puntos se mantiene en alto, en el momento que se envía un carácter, este se  acompaña de un bit de inicio y uno o más de paro. Este protocolo es la base del estándar RS-232.

Protocolo RS-232:

Es una variante del protocolo USART. Generalmente usa voltajes entre ±12V y ±9V. Los valores negativos significan el cero lógico y los positivos el uno. Por lo general, las velocidades de transmisión varían desde 300 Kbps hasta los 9600Kbps.

Protocolo USB:

Es una variante del protocolo USART. USB es el acrónimo de Universal Serial Bus. Se usa ampliamente para la conexión de periféricos de todo tipo a los computadores, tales como, impresoras, teclados, teléfonos, etc. Este estándar desplazó del mercado a su antecesor, el RS-232, ya que entre otras cosas puede dar soporte a la comunicación serial. En realidad, se ha convertido en el estándar de conexión entre el PC y otros periféricos gracias a su gran versatilidad y eficiencia, desplazando así a la mayoría de los conectores anteriores: puerto serie, puerto paralelo, puerto de juegos, Apple Desktop Bus o PS/2. Las nuevas versiones de USB mejoran el rendimiento y amplían aún más su versatilidad aumentando la velocidad de transferencia. Con ello están sustituyendo algunas conexiones reservadas al uso de discos duros tales como IDE, Serial ATA, o SCSI.

USB se usa como conector multiusos y de hecho incluso se está utilizando como estándar de conexión para proporcionar alimentación a 5v a una gran variedad de dispositivos. Las señales del USB se transmiten usando un cable de par trenzado con impedancia de 90 ohmios ± 15%. En el USB 3.0 se añade un segundo par de hilos y usa comunicación full dúplex.

Actualmente podemos usar las siguientes velocidades:

Baja velocidad (USB 1.0): Tasa de transferencia de hasta 1,5 Mbit/s.

Alta velocidad (USB 2.0): Tasa de transferencia de hasta 480 Mbit/s.

Superalta velocidad (USB 3.0): Tiene una tasa de transferencia de hasta 4,8 Gbit/s.

Comunicación Serial en Arduino

La comunicación serie en Arduino es asíncrona y FullDuplex, que por otra parte, es lo más habitual entre ordenadores y dispositivos.

Existen varias posibilidades para usar comunicación Serial en Arduino. No todas las placas ofrecen las mismas posibilidades. En Arduino Uno existe un solo canal Serial implementado por hardware (que en adelante llamaremos Hardware Serial), mientras que en Arduino Mega y Arduino Due existen cuatro.

Se pueden implementar comunicaciones Serial usando pines de entrada salida digital normales. Para ello se usan diferentes librerías, cada una de ellas con diferentes tipos de ventajas o limitaciones. Las principales limitaciones al usar métodos alternativos al Hardware Serial que usa pines concretos, es que la recepción serie implica hacer uso de un servicio de interrupción.

Opciones de comunicación serie en Arduino.

Seguidamente se comentan las opciones de comunicación serie por orden de preferencia, aunque eso no significa que para un caso concreto  no existan motivos para optar por alguna opción menos eficiente si ello comporta otras ventajas.

 

Hardware Serial:

Ofrece sin duda el mejor rendimiento. Siempre que sea posible, ha de utilizarse esta opción, pero nosotros no lo vamos a hacer debido a las limitaciones de Arduino Pro Mini.

Arduino Mega tal como ya hemos indicado tiene 3 puertos Hardware Serial adicionales (Serial1, Serial2, Serial3). Arduino Uno no tiene ningún puerto adicional aparte del consabido puerto Serial (a secas) que se usa principalmente para cargar programas y para depurarlos.

AltSoftSerial:

Puede transmitir y recibir simultáneamente. Ofrece una interferencia mínima con el uso simultáneo de Hardware Serial y otras bibliotecas. Consume un temporizador de 16 bits (y no funcionará con ninguna biblioteca que necesite ese temporizador). Por esa razón, provoca la desactivación del PWM en algunos pines. Puede ser sensible a entrar en conflicto por el uso de otras bibliotecas. Salvo incompatibilidad con otros servicios, por las razones expuestas, sería una buena opción para usar varias conexiones serie en un Arduino Uno o similar, pero tampoco lo hemos considerado adecuado  para nuestro caso concreto.

NewSoftSerial:

(Se redenominó SoftwareSerial en Arduino 1.0 y más adelante) - Puede tener varias instancias, pero sólo una de ella puede estar activa a la vez. No permite transmitir y recibir simultáneamente. Puede interferir con otras bibliotecas o con HardwareSerial, si se utiliza a velocidades de transmisión más lentas.

SoftwareSerial:

(SoftwareSerial en Arduino 0023 y anteriores) - Muy mal desempeño, pero puede bastar. De hecho, será nuestra opción para comunicación serie en Arduinos como el Uno o el Pro Mini que no disponen más que de un puerto Hardware Serial y a nosotros nos conviene reservarlo para poder depurar código con toda comodidad. Los inconvenientes de SoftwareSerial pueden ser perfectamente manejados cuando no se necesita un desempeño a velocidades altas estableciendo un protocolo que contemple las limitaciones de este sistema. Por ejemplo, La comunicación con SoftwareSerial puede tener dificultades al leer los primeros caracteres hasta que logra sincronizar la recepción. SoftwareSerial tampoco permite trabajar a velocidades ni muy lentas ni muy rápidas. Nosotros nos vamos a limitar a usar siempre 9600 baudios, porque no necesitamos más (vamos sobrados a esa velocidad) y teniento en cuenta estas limitaciones tenemos la posibilidad de usar sin problemas un Arduino barato. A nosotros SoftwareSerial nos basta y nos sobra para usarlo en un proyecto como CaoBTrefrigMini y en cualquier otro parecido. En el hipotético caso de que se necesitara más velocidad la compatibilidad de nuestro software con el Hardware Serial a velocidades superiores está garantizada.

La alternativa a SoftwareSerial en Arduino Pro Mini sería usar AltSoftSerial, pero ello consumiría un temporizador de 16 bits y este es un recurso importante para estos Arduinos pequeños que no están sobrados de recursos.

Comparativa Arduino Pro Mini vs Arduino Pro Micro

En nuestro primer proyecto CaoBT vamos a usar un Arduino Pro Mini porque nos basta para lo que necesitamos, pero hay que advertir que es un procesador con una fuerte limitación de SRAM.  Por ello, no podemos descartar que en futuras ocasiones necesitemos algo un pelín más potente. El Arduino Pro Micro en tal caso podría ser una opción a considerar. También existen clónicos baratos aunque siempre un poco mas caros que el Arduino Pro Mini.

Tabla comparativa Arduino Pro Mini Vs. Arduino Pro Micro

Name

Processor

Operating

Input

Voltage

CPU

Speed

Analog

In/Out

Digital

IO/

PWM

EEPROM

[KB]

SRAM

[KB]

Flash

[KB]

USB

UART

Pro

Mini

Atmega 328P

3.3v
5v

8 MHz
16 MHz

6/0

14/6

1

2

32

-

1

Pro

Micro

Atmega 32U4

3.3v

5v

8 MHz
16 MHz

4/0

14/5

1

2.5

32

Micro

1

 

Por desgracia la distribución de pines es parecida pero no idéntica y la compatibilidad no es completa, pero los 2 KB de SRAM en el Pro Mini han resultado justitos para el primer proyecto CaoBT y dependiendo del caso podría interesar los 2,5 KB de SRAM de Arduino Pro Micro. Otra diferencia importante es que Arduino Pro Micro sí que trae un conector USB.

Más diferencias entre Arduinos con Atmega328 y los que usan Atmega32U4

 

Hay que tener en cuenta que en Arduino Leonardo, la clase Serial se refiere a la comunicación USB (CDC); para serie TTL en los pines 0 y 1, hay que utilizar la clase Serial1. Tanto Serial como Serial1 en Atmega32u4 son puertos emulados por software. Esto tiene inconvenientes pero también alguna ventaja a la hora de ciertas interacciones con el PC.

En Arduino UNO además de procesador Atmega328 existe un procesador hardware que se usa tanto para el USB como para los pines 0 y 1 y que físicamente están ligados al mismo puerto serie que el USB.

Arduino Pro Mini solo tiene el procesador Atmega 328p (la p es porque consume menos que el Atmega328 a secas) pero no tiene un procesador hardware para el puerto Serial. Esto se soluciona conectándole el adaptador USB-FTDI.

Forma de iniciar la conexión Serial en un Arduino Pro Micro o Arduino Leonardo

 

En Leonardo no se reinicia el programa al abrir la conexión Serial, por ello cuando en el programa no introducimos una espera para detectar la apertura del puerto Serial, algunas trazas iniciales se perderán. Concretamente se irán perdiendo todas las salidas por puerto Serial hasta que decidamos abrir el monitor serial en el IDE. En ese momento aparecerán las trazas que se estén ejecutando con el programa ya empezado, porque a diferencia de Arduino UNO, el programa continua ejecutándose normalmente cuando arranca conectado a un puerto aunque este no está abierto y no se produce un reinicio del programa cuando se abre o se reabre el puerto Serial como ocurre en Arduino UNO.

Este comportamiento no es necesariamente algo malo, pero es un detalle que hay que conocer, y si se está acostumbrado a otros Arduinos puede desconcertar bastante.

Si Arduino Micro (o Leonardo) se pone la espera de la conexión Serial (por ejemplo se usando un simple while(!Serial); ) el programa quedará a la espera de que se abra la conexión y en el momento que esta se abra, proseguirá la ejecución con toda normalidad.

En Arduino Pro Micro (o Leonardo) nunca ocurre el reinicio automático con la apertura del puerto Serial, por eso, en muchos programas, se suelen poner las instrucciones de espera en setup() a fin de evitar que durante el transcurso de tiempo que va desde que empieza a ejecutarse hasta que activamos el monitor en el IDE, se pierdan algunos datos. Esperar permanentemente ya hemos dicho que tampoco sería una buena idea porque si lo ejecutamos sin conexión al monitor Serial se quedará bloqueado.  Hacer en Arduino Pro Micro (o Leonardo) una espera indefinida, puede dar problemas. Pero no hacer ninguna espera también.  Lo más acertado para un uso ocasional para trazas, sería hacer una espera con TIMEOUT (con tiempo limite).

Código:

#define TIMEOUT_SERIAL  5000  // Esperamos como máximo 5 segundos a la conexion Serial

// ***********************************************************************

void setup(){

    Serial.begin(9600); // Intentamos inicializar a 9600 baudios

    int t1=millis(); // Tomamos referencia del tiempo en t1

    // Mientras no transcurran TIMEOUT_SERIAL milisegundos

    while (millis()-t1<TIMEOUT_SERIAL){

        if (Serial) // Si se ha logrado conexión...

            break;  // forzamos la salida del bucle

    }

    // Se permite continuar con conexión o sin ella.

Preguntar por la disponibilidad del puerto Serial en cualquier otro Arduino, siempre devolverá el valor true (cierto). Esto despista un poco, porque lo hace incluso cuando el puerto no está disponible. Lo que ocurre, es que la disponibilidad de la conexión Serial en Arduino UNO, no es tan crítica para el programa. Realmente en Arduino UNO no importa mucho, porque cuando por fin se abra la conexión Serial, el programa se reiniciará normalizando su funcionamiento y en caso contrario tampoco se bloqueará y funcionará con la conexión cerrada.

 

Posibilidad de uso de un módulo ESP8266

 

Al igual que en el caso del módulo Bluetooth HC-05, la relación calidad precio de este módulo WiFi es buenísima y durante un tiempo pensé que ofrecería mayores posibilidades de uso que el módulo HC-05 que estaba reservado a un uso local para una distancia máxima de unos 10 metros. Este módulo permitiría un acceso a nuestra red controladora de acuarios desde cualquier punto del planeta, lógicamente parecía ideal.

Por desgracia ofrece algunos inconvenientes. ESP8266 no permite implementar un auténtico servidor WEB. A la hora de recibir mensajes, toma todo el empaquetado TCPIP pero nos envía por el puerto serie los datos limpios. Eso nos ahorra tener que hacer esa limpieza olvidándonos de la gestión del TCPIP y de otros detalles tan importantes como complicados, pero el precio de todo ello es que finalmente no tendremos nunca la funcionalidad de un auténtico servidor WEB. En realidad, no tenemos ni siquiera la funcionalidad de una verdadera conexión WiFi ya que no tenemos acceso al stack o al socket IP.

Lo que he visto usar en muchos ejemplos de uso de este módulo podríamos llamarlo pseudoservidor-Web-ESP8266 que solo nos permitirá intercambiar peticiones sencillas y hay bastantes funcionalidades que no podemos implementar. Por ejemplo es imposible implementar un servidor seguro (https). Tampoco permite el uso de POST method, ni otra serie de recursos útiles para tener una conexión segura a prueba de ataques, todo ello porque no no es un auténtico servidor web.

En estas condiciones, poner un formulario de entrada para autentificar al usuario tiene el peligro de que su comunicación, al viajar sin cifrado, pueda ser fácilmente interceptada por un snifer.

La ventaja es que ESP8266 es muy barato. Para hacer algo tan seguro como deseemos, deberíamos montar un auténtico servidor Web. Como opción relativamente barata podríamos hacerlo en una Raspberry Pi, aunque su precio es muy superior a un simple ESP8266 y no se trata de sistemas comparables.

Para que entienda la diferencia le proponemos que haga un pequeño experimento. Instale un servidor apache en su ordenador y cree una página php en el directorio reservado al uso del servidor, que contenga tan solo:

<?php  phpinfo();  ?>

Se trata de un programita que ofrece toda la información del servidor.

Desde el navegador acceda a esa página usando:

 http://127.0.0.1/<ruta>/<página.php>

Podrá ver la cantidad de datos que maneja internamente apache. ESP8266 no tiene nada de eso. No olvide borrar esa página para evitar que alguien que se  pueda conectar a ella, obtenga información que le permita planificar algunas estrategias de ataque a su servidor Apache.

La mala noticia es que ni siquiera con un auténtico servidor nos libramos de ciertos inconvenientes para usarlo con nuestro nuevo enfoque para CaoBT.

El primer problema es que Internet es un medio hostil y nuestros controladores dan soporte vital a seres vivos. Un fallo de seguridad podría tener consecuencias nefastas.

Si obviamos ese gran inconveniente veremos que no es el único. Un servidor robusto conectado a Internet podría dar un buen servicio a un controlador monolítico tipo CAO1, para ello podríamos recurrir a montar un servidor en un Raspberry Pi y recurrir a un servicio No-IP para lograr la accesibilidad de nuestro servidor pese a carecer de un servicio de acceso más caro con IP estática. Los servicios de acceso a Internet domésticos usan IP dinámica. Es decir, cada vez que se reinicia el router nos proporciona una dirección IP de salida a Internet diferente e imprevisible. Un servicio No-Ip serviría para salvara ese problema, y si nuestro controlador es monolótico como CAO1, el asunto estaría solucionado.

El problema con CaoBT es que tendríamos varios controladores pequeños y baratos y cada uno de ellos necesitarían salir a Internet a través de una única dirección IP. Quizás se pueda conseguir evitar esta limitación, pero desde luego no parece un tema trivial.

Tal como yo lo veo, para conectar un Arduino con Internet o se usa un ESP8266 con las grandes limitaciones de seguridad y de otro tipo, o se usa un Raspberry Pi con un servidor Apache y lo suyo sería conectar por cable serie, Raspbery Pi con Arduino. Es decir, entre el router y Arduino se puede intercalar un ESP8266 o un Raspberry Pi, pero no tendría sentido usar ambos.

En otras palabras, un servicio No-Ip solo serviría para salvar el problema causado por la IP-Dinámica, y si nuestro controlador es monolótico como CAO1 bastaría. Si por el contrario en lugar de un controlador monolítico para todo el acuario tuviéramos un sistema distribuido formado por pequeños controladores, se necesitaría una IP de salida para cada dispositivo o implementar una pequeña red con un nodo central que ofrezca la salida a Internet a todos ellos. Por ejemplo se podría usar varias conexiones serie con entrada por USB conectados a una Raspberry Pi que hiciera de nodo central de comunicaciones, y este haria de centralita para serivir las peticiones de todos los nodos a Internet. Me temo que esta solución nivel de comunicaciones resultaría demasiado compleja y no la hemos considerado factible para nuestros proyectos.

Por todas estas razones, hemos terminado usando un Terminal Android con Bluetooth. De esa forma podremos conectarnos en un futuro a tantos controladores CaoBT cercanos como deseemos por medio de Bluetooth y podróamos usar un sistema completo que permita monitorizar y cambiar la configuración de un controlador porque tendríamos un acceso seguro.

Usar el módulo  ESP8266 para algo así sería peligroso. Lo que sí podría ser interesante es usar este modulito ESP8266 para ofrecer un servicio de monitorización web de nuestro acuario, aunque tampoco podríamos darle un uso estrictamente privado. Tendríamos que ser cautos con la información que ofrezcamos con un servicio Web de este tipo, además solo sería factible usarlo para un solo controlador de acuario que estaría dedicado a la tarea de recoger una variedad de datos para hacerlos accesibles por Internet.

Módulo de enlace Bluetooth HC-05

 

Después del Arduino Pro Mini, este será el segundo componente clave del controlador  CaoBTrefrigMini ya que nos proporciona la posibilidad de conectar nuestro controlador con un dispositivo Bluetooth que en nuestro caso hará las veces de interfaz de usuario. Tal como ya hemos comentado la relación calidad precio de este pequeño módulo es muy buena.

Especificaciones técnicas

El alcance máximo de este módulo es de unos 10 metros y su velocidad de transmisión puede ir de 1200bps a 1.3Mbps. Nosotros lo usaremos a 9600 baudios.  Recomendamos una lectura de las especificaciones técnicas en el datasheet siguiente: BTM-5 Bluetooth Wireless TTL Master/Slave Transceiver Module Rev 2.0  2011:

(https://docs.google.com/file/d/0B93S-Z6qmW9EM0tkb2R4eTEwZnM/edit)

Existen otros  datasheet que aportan informaciones complementarias relativas a diferentes aspectos del HC-05:

  1. 1.ftp://imall.iteadstudio.com/Modules/IM120723009/DS_IM120723009.pdf 

  2. 2.http://www.electronica60norte.com/mwfls/pdf/newBluetooth.pdf 

  3. 3.http://www.tec.reutlingen-university.de/uploads/media/DatenblattHC-05_BT-Modul.pdf 

Modos de funcionamiento

Lo primero que hay que aclarar es que en el protocolo Bluetooth no se pueden establecer conexiones maestro-maestro, ni esclavo-esclavo. Solo maestro-esclavo.

El módulo de Bluetooth HC-05 además de recibir conexiones desde un PC o tablet, que siempre funcionan en modo maestro, también podría establecer conexiones con otros dispositivos Bluetooth colocando uno de ellos en modo maestro (ROLE=1), y formar así una conexión punto a punto para transmitir datos entre dos microcontroladores o dispositivos. Esta interesante característica del HC-05 nosotros no la vamos a considerar para el proyecto actual. Por lo tanto, necesitaremos configurar nuestro HC-05 como esclavo (ROLE=0) que es el modo por defecto en el que viene el módulo de fábrica. En realidad, existe un tercer modo (ROLE=2) que tampoco vamos a usar.

Por defecto el HC-05 entrará en modo esclavo, y mientras no consiga conexión, realizará un parpadeo rápido. Cuando logre conectar el HC-05  hará periódicamente dos parpadeo rápidos intercalando entre ellos una pausa más prolongada. Si arrancamos con el pin KEY a valor alto, entrará en modo de comandos AT y parpadeará lentamente (2 segundos encendido 2 segundos apagado).

Conexiones eléctricas para el HC-05.

Hay que advertir que existe una variedad importante de módulos HC-05 que ofrecen distintos pines de conexión y que pueden venir preparados para trabajar a diferentes voltajes.

Algunas veces se venden en Internet el HC-06 y HC-05 como si fueran un mismo módulo. Esto se debe a que esencialmente el hardware es el mismo y la única diferencia entre ambos es el firmware que viene cargado de fábrica.

Los diferentes modelos tienen los pines TX, RX, VCC y GND, pero existen generalmente pines extra que pueden ser KEY, STATE, etc. Algunos modelos funcionan a 5v, otros a 3.3v.

Cuando usemos un Arduino Pro Mini lo alimentaremos a través del adaptador USB_FTDI o mediante un regulador de voltaje, por ejemplo un  integrado regulador de voltaje del tipo LM7805. Este tendrá la capacidad para alimentar tanto al Arduino Pro Mini a 5v como a un HC-05 de un modelo preparado para esa alimentación a 5v y ese debe ser el tipo de HC-05  que deberá conseguir para este proyecto.

La entrada de los pines de E/S digital de un Arduino con un Vcc de 5v aceptarán un valor entre 3 y 5v como si fuera un estado alto. Por esa razón, siempre resultará válido conectar directamente el TX del HC-05 con el RX del Arduino. Por el contrario, la entrada RX del HC-05 no siempre viene preparada para aceptar un voltaje superior a 3.3v por lo cual convendría aplicar un divisor de tensión preparado con resistencias. De lo contrario, podemos llegar a pensar que funciona, pero podría terminar fallando tras un tiempo de uso en esas condiciones. Se recomienda usar un divisor de tensión en los casos en el fabricante indique que la entrada RX del módulo de HC-05 no esta adaptada para usar 5V:

En teoría podemos usar diversos tipos de divisores de tensión usando Resistencias  con valores estándar. Nosotros no lo hemos implementado en nuestra placa pero para poder habilitar o deshabilitar en una placa a voluntad el divisor de tensión y no tener que soldar y desoldar en caso de cambiar de módulo HC-05, se puede preparar un divisor asociado a un jumper, tal y como se refleja en la imagen siguiente.

 

Si llamamos R1 al la resistencia de menor valor, (la que está recibiendo los 5v de la salida de Arduino)  y R2 a la de mayor valor (la que esta en contacto con GND), podemos usar la siguiente fórmula.

 

Vdiv=5*R2/(R1+R2)

Para que funcione R1 debe ser aproximadamente la mitad que R2.

Ejemplo: R1=2K2 y R2 4K7. Debería funcionar, pero podrían vendernos una combinación de resistencias que no funcione por la desviación debida a la tolerancia de las mismas, por ejemplo:

 

R2=5.07K  y R1=2.17K

5*5.07/(5.07+2.17) = 3.50138  (voltaje excesivo, no funcionará)

 

Valores típicos de tolerancia en resistencias son 5%, 10% y 20%, pero también hay resistencias con tolerancias más bajas de 0.1%, 0.25%, 0.5%, 1%, 2%, 3% y 4%.

IMPORTANTE: Nosotros deberíamos medir el voltaje y asegurarnos que nuestro divisor de tensión para 5v entregue un voltaje que en teoría tendría que estar comprendido entre 2.4v y 3.4v, pero que en la práctica podría ser un rango algo diferente (más estrecho) dependiendo del módulo. Yo he encontrado algunos HC-05 que con 3.15v no funcionaban y también los he encontrado que por encima de 3.4v no funcionaban.  El rango suele ser más amplio, pero no ve voy a aventurar a dar un rango concreto porque hay diferencias entre los diferentes modelos y si no usamos el divisor adecuado el tipo de problema que ocasiona no suele ser fácil de diagnósticar, es mejor no arriesgarse y medir. Cuando se indique que necesita un voltaje de 3.3v, procure que el voltaje sea muy próximo a ese valor,  de lo contrario puede no funcionar. Si los datos enviados desde Arduino no llegan a Android de manera limpia y clara asegúrese nuevamente de que su HC-05 de 3.3v recibe los 3.3v en su pin RX. Use para ello un polímetro. Considere este punto como uno de los puntos críticos para el funcionamiento de un HC-05 a 3.3v. Mida  el voltaje entregado por el divisor de tensión cuando la salida de Arduino esté a HIGH. Puede usar para ello el programa TestHW01_CaoBTRM que le facilitará un nivel alto en todos los pines digitales de salida alternando de forma intermitente con breves periodos a nivel LOW.

A la hora de comprar resistencias, debe saber que no debe confiar en la suerte ni en la ley de probabilidades. Las resistencias en muchos comercios, no vienen con una distribución gausiana en torno a su valor ideal, como sería lógico esperar por puro azar, y suelen venderlas con desviaciones extremas dentro del nivel de tolerancia especificado. Las que más se ajustan al valor ideal son mejores y seguramente las ofrezcan a un precio superior teniendo en cuenta su mejor calidad. Cuando se compran varias resistencias de un mismo valor, también suele ocurrir que todas comparten idéntica desviación del valor especificado.

Comento a continuación las características de unos pocos módulos HC-05 que pueden encontrarse en el mercado.

 

CZ-HC-05 Gomcu:

Está bastante bien adaptado para el uso con Arduinos de 5v. Puede verlo en la imagen siguiente:

 

Concretamente este módulo,  acepta 5v en la entrada de Vcc. por incluir un regulador de voltaje para ello y a diferencia de otros también módulo trae adaptada RX, TX para poder usar 5V. Sí se usa con el divisor de tensión en RX, cosa necesaria en otros módulos, no funcionará. En este caso necesita los 5v en RX. Quizás sí necesites un divisor de voltaje para poner el pin KEY a nivel alto (HIGH), pero esta entrada estará muy poco tiempo a nivel alto. Por ejemplo, presionando durante un segundo mientras arranca. Yo lo he usado durante periodos cortos de tiempo a 5v para configurar el dispositivo y me funcionó perfectamente.

Sus pines son:

 

JY-MCU:

Ojo este es un módulo que funciona  a 3.3v para la entrada RX.

 
 

HC-05 ZS-040:

Este es un modulito no trae pin key, en lugar de ello trae un botón  para configurarlo. Admite alimentación desde 3.6 a 6V, pero necesita la entrada RX a 3.3v.

 
 

Sus pines son:

Configuración del módulo HC-05 mediante comandos AT

Después de conectar los pines correctamente, necesitamos abrir una conexión serie entre el Arduino y el módulo HC-05 con las características siguientes:  Velocidad: 38400 baudios, caracteres:8 bits, stop bit:1, bits de paridad: 1, sin control de flujo.

En el momento de dar tensión al módulo HC-05, el pin KEY debe estar conectado a Vcc (al tratarse de cortos periodos de tiempo, parece que admite bien los 5V). Con ello forzaremos que entre en el modo de comandos AT durante su encendido. Compruebe que el módulo HC-05 parpadea lentamente (Significa que ya está en modo AT) y libere entonces el pin KEY (resulta práctico hacer un pequeño circuito con un pulsador). Después de esto hay que abrir el puerto con HC-05 e introducir los comandos AT.

Si su HC-05 no incluye un pin KEY, mire si tiene un pequeño pulsador. Deberá mantenerlo presionado antes de dar tensión al módulo y cuando parpadee, soltar el botón.

NullProg.ino:

Se trata de un programa sin código que hay que cargar en el Arduino. Debe configurar en el IDE el monitor serial. Las conexiones y la forma de lograr que el HC-05 entre en modo AT al recibir tensión, es idéntica al caso anterior ya que estaremos usando una variante mediante la cual usaremos un Arduino con un programa cuyo código no hace nada. El Arduino usado de esta forma no hará uso de los pines de entrada salida RX,  TX. Estamos engañando a IDE para que crea que le estamos haciendo funcionar con un Arduino, pero en realidad estará interactuando directamente con el HC-05.

Hay muchas otras formas de conectar con HC-05 en modo AT, pero yo recomiendo usar este método. Es el más sencillo y quizás el más seguro porque algunos emuladores de terminales teóricamente configurados correctamente, no serán capaces de dialogar con el HC-05. Todo sea que en algún momento decidan cambiar algo en el IDE de las nuevas versiones y como el modo AT de HC-05 es tan quisquilloso, deje de funcionar. Las conexiones para NullProg.ino son:

Cargue el programa en su Arduino:

// NullProg.ino

// Atencion!  Conectar TX con TX y RX con RX

// Configurar monitor serial [Ambos NL y CR]

// y [38400 baudios] para trabajar con HC-05 en modo AT

void setup(){}

void loop(){}

 

En lo relativo a las conexiones eléctricas, vamos a ilustrar los dos caso más frecuentes para conectar HC-05. En el primer caso necesitaremos un divisor de tensión o podríamos terminar quemando la entrada del HC-05 que viene preparada para 3.3v. En el segundo caso usamos un HC-05 totalmente preparado para 5V y si lo conectamos con el divisor de tensión no funcionará, porque no le llegará el voltaje necesario.

Hemos incluido la conexión del pulsador para forzar el arranque en modo AT. Los cables amarillos conectan el RX del HC-05 con el RX de Arduino y el azul el TX del HC-05 con el TX del Arduino. Esto no es lo habitual. En cualquier otro caso habríamos usado conexiones cruzadas RX-TX pero insistimos, con NullProg.ino estas conexiones no van cruzadas.

El Arduino Mini, lógicamente necesita un adaptador USB_FTDI para conectarse al ordenador. En el IDE de Arduino deberá abrir el monitor serial una vez que HC-05 entre en modo de comandos AT y deberá configurarlo a  38400 baudios, y con envío de  CRLF (puede venir expresado como “\r\n”, (NL + CR), “0x0d 0x0a”).  El HC-05 es bastante exigente con el envío de estos dos caracteres. Algunos programas no envían estos caracteres en la forma que HC-05 espera recibirlos y en ese caso no aceptará los comandos o podría salir del modo AT.

La imagen siguiente muestra como conectar un HC-05  modelo ZS-040 que viene preparado para ser alimentado con un voltaje entre 3.6v y 6v, pero que no tiene adaptada la entrada RX (cables amarillos) y por ello se conecta a través de un divisor de tensión formado por dos resistencias.

 

En este modelo hay que usar el pulsador incluido en el propio módulo que en la imagen está señalado con la flecha blanca (parte superior de la imagen). Es muy pequeño y en la foto se aprecia mal por estar cubierto por el plástico.

La resistencia que va al polo negativo es de 4k7 Ohmios y la que va al cable amarillo que viene del pin RX de Arduino es de 2k2 Ohmios.

En la imagen siguiente vemos un montaje muy similar para el modelo  CZ-HC-05,  que no necesita el divisor de tensión a la entrada de RX del HC-05.

Hemos indicado, con cierto nivel de transparencia, la parte del montaje que cambia entre un montaje y otro, pero lo importante es conectar el cable RX directamente.