Antes de empezar a programar he pensado que es conveniente definir completamente la comunicación inalámbrica ya que es el punto central del proyecto y al ser nexo entre maestro y esclavo condiciona totalmente el funcionamiento de estos. Es por esto que esta entrada define en esencia el funcionamiento tanto del sensor como del transceptor y en algunos casos detalles del software de representación de datos.
Comunicación inalámbrica
Para reducir el consumo la comunicación debe evitar largos periodos de "polling" en el canal. Es por esto que se ha decidido que la comunicación se realizará acorde al funcionamiento del sensor.
El funcionamiento básico consiste en que el sensor realiza una medida cada periodo configurable (este periodo es muy prolongado respecto a la velocidad de funcionamiento de los microcontroladores por lo que la mayor parte de ese tiempo el microcontrolador se encuentra en modo de bajo consumo) ,envía el dato medido y entra en modo de bajo consumo esperando a realizar otra medida. Lógicamente este funcionamiento descrito muestra un tipo de comunicación unidireccional, el sensor no puede recibir datos. Por supuesto se necesita una comunicación bidireccional por lo que se debe añadir al funcionamiento del sensor la acción de ver si le han enviado algo, recibirlo y procesarlo.
No es eficiente dedicar el tiempo entre medidas al "muestreo" (polling) del canal debido al elevado consumo que introduciría. Es por esto que se ha decidido que el polling del canal se realizará durante un instante de tiempo cuya duración sea la necesaria para que el tiempo de procesado y respuesta del maestro permita la recepción del paquete. Para advertir al maestro de cuándo podrá realizar el envío de los datos, el polling se realizará tras enviar las medidas el sensor, es decir, el sensor enviará las medidas y dejara un tiempo ajustado para recibir datos.
De este modo, la dinámica de la comunicación consistirá en el envío de las medidas al maestro por parte del sensor; el sensor se mantendrá un tiempo a la escucha, tiempo que el maestro aprovechará para enviar los comandos oportunos al sensor. Una vez el sensor recibe los datos, inmediatamente deja de estar a la escucha, procesa los datos y entra en modo de bajo consumo esperando la medida siguiente. Esto se aprecia en la tabla siguiente.
| Estado | t medida HR | t medida Tª | envio datos | t en el aire | t espera | recepción | espera medida | ||||
| Micro | duerme | lee | duerme | lee | envía | duerme | pon RX | duerme | |||
| Transceptor | duerme | carga datos | transmite | duerme | recibe | apagado | |||||
| Sensor | mide | mide | duerme | ||||||||
Esta tabla muestra gráficamente la función de cada dispositivo del sensor en cada estado resaltando las funciones a razón del consumo que suponen. El consumo se muestra en forma de gradiente, siendo el azul el de menor consumo y el rojo más oscuro el de mayor.
Tal y como se aprecia, para reducir el consumo estático del nodo, se ha decidido desconectar el transceptor durante el tiempo entre medidas ya que su consumo estático, en modo reposo 12µA, es elevado en proporción al resto.
Iniciar la conexión inalámbrica:
Se debe permitir la conexión en caliente por lo que el proceso de conexión de un nuevo sensor a la red se muestra a continuación.
El maestro está escuchando (polling) contínuamente por el canal en el que esté trabajando. El sensor se sitúa junto al maestro y se enciende. Una vez encendido, el sensor envía el paquete de "conexión inicial" el cual contiene su dirección y la configuración de su sensor y de su transceptor.
Cuando el maestro recibe dicho paquete, actúa asignando a la dirección recibida, la del sensor, un número de identificación (ID) de menor tamaño que la dirección y posteriormente se la envía al sensor. A partir de ahora la comunicación del sensor con el maestro contendrá la ID que le indicará al maestro quién le está enviando el paquete. En el caso en el que el sensor no reciba respuesta del maestro, cambiará de canal y lo volverá a intentar. Si esto tampoco funcionase, se podría intentar hacer un cambio de potencia y volver a realizar el barrido de canales. Si todo esto falla, el sensor entrará en reposo y lo indicará con su indicador luminoso LED.
Una vez el maestro ha recibido el dato MY_NAME_IS del sensor y le ha respondido, manda la configuración, la dirección y la ID asignada al sensor al PC para ser procesada y mostrada por el software de representación.
Cuando el software de representación recibe los datos del sensor enviados por el maestro, este crea una nueva clase que contiene los paneles que se mostrarán para cada sensor pasándole los datos recibidos al constructor. Esto produce una ventana la cual contiene una gráfica donde se muestran los datos de HR y Tª y una serie de etiquetas y botones que permiten mostrar los datos del sensor y configurar el sensor.
Configurar el sensor:
Una vez establecida la conexión, para configurar el sensor el usuario interactúa mediante el software de representación. El software envía un comando que contiene la ID del sensor a modificar al maestro, el cual almacena en el "buffer FIFO" de la ID el comando a enviar para que el sensor actúe como se ha pedido. El "buffer" consiste en un array donde se van almacenando los comandos que se le quieren enviar a una ID (sensor) determinada; esto es así debido a la naturaleza de la comunicación.
Cuando un dato del sensor es recibido por el maestro, el maestro mira si el buffer correspondiente está vacío, en caso contrario, manda todos los comandos posibles (cada paquete puede contener hasta dos comandos) contenidos en el buffer.
Cuando el sensor recibe el dato, actúa en consecuencia y envía un paquete de respuesta el cual es interpretado por el maestro como cambio realizado correctamente y es comunicado al software de representación.
Una vez el sensor ha contestado, continúa con el funcionamiento normal. Esto supone una modificación del tiempo entre lecturas.
