or de linarestauja.ujaen.es/bitstream/10953.1/8385/1/tfg_pablo...1 escuela politécnica superior de...
TRANSCRIPT
Escuela
Polit
écnic
a S
uperior
de L
inare
s
UNIVERSIDAD DE JAÉN Escuela Politécnica Superior de Linares
Trabajo Fin de Grado
______
MONITORIZACIÓN DE
PARÁMETROS
MEDIOAMBIENTALESMEDIANTE SENSORES Y LA
RED SIGFOX
Alumno: Pablo Castillo Segura
Tutor: José Ángel Fernández Prieto Depto.: Ingeniería de Telecomunicación
Junio, 2018
1
Escuela Politécnica Superior de Linares
Trabajo Fin de Grado
Curso 2017-2018
MONITORIZACIÓN DE
PARÁMETROS
MEDIOAMBIENTALES MEDIANTE
SENSORES Y LA RED SIGFOX
Alumno: Pablo Castillo Segura Tutor: José Ángel Fernández Prieto
Depto.: Ingeniería de Telecomunicación
Firma del autor Firma del tutor
Junio, 2018
2
CONTENIDO 1 Resumen ...................................................................................................................... 6
2 Introducción .................................................................................................................. 7
3 Objetivos ..................................................................................................................... 11
4 Metodología ................................................................................................................ 12
4.1 Introducción a Sigfox ....................................................................................................... 12
4.2 Puesta en funcionamiento de Sigfox ............................................................................... 17
4.3 Envío de información a la nube de Sigfox ....................................................................... 24
4.3.1 Introducción ............................................................................................................ 24
4.3.2 Módulo Sigfox ......................................................................................................... 24
4.3.3 Observar mensajes recibidos por Sigfox. ................................................................ 26
4.3.4 Sensores utilizados para recoger valores reales. ..................................................... 28
4.3.5 Arduino UNO ........................................................................................................... 29
4.3.6 Arduino DUE ............................................................................................................ 35
4.3.7 Waspmote ............................................................................................................... 38
4.3.8 Raspberry ................................................................................................................ 44
4.4 Configurar nodos como Gateway .................................................................................... 50
4.4.1 Introducción ............................................................................................................ 50
4.4.2 Waspmote ............................................................................................................... 51
4.4.3 Arduino DUE ............................................................................................................ 58
4.4.4 Arduino UNO WiFi ................................................................................................... 60
4.4.5 Raspberry ................................................................................................................ 67
4.5 Servidor propietario ........................................................................................................ 70
5 Conclusiones .............................................................................................................. 80
6 Referencias bibliográficas ........................................................................................... 81
3
Figura 2.1. Diagrama de comunicación utilizando Sigfox. ............................................................... 10
Figura 4.1. Ciclo de vida de un mensaje de Sigfox. ......................................................................... 13
Figura 4.2. Envío de mensajes en la red de Sigfox. ......................................................................... 13
Figura 4.3. Cobertura de proveedores Sigfox. ................................................................................. 15
Figura 4.4. SDR Dongle. ................................................................................................................... 15
Figura 4.5. Modulación DBPSK. ....................................................................................................... 16
Figura 4.6. Modulación GFSK. ......................................................................................................... 16
Figura 4.7. Efectos de UNB en el espectro de frecuencias. ............................................................. 17
Figura 4.8. “Device List” en Backend de Sigfox. .............................................................................. 18
Figura 4.9. Información del módulo escogido en el Backend de Sigfox. ......................................... 19
Figura 4.10. “Callbacks” en el Backend de Sigfox. ........................................................................... 19
Figura 4.11. “Callback edition” en el Backend de Sigfox. ................................................................ 19
Figura 4.12. Módulo y antena Sigfox. .............................................................................................. 25
Figura 4.13. “Device List” en Backend de Sigfox. ............................................................................ 26
Figura 4.14. Información técnica del módulo en Backend de Sigfox. .............................................. 27
Figura 4.15. Mensaje enviado por Arduino UNO. ........................................................................... 27
Figura 4.16. LM35. .......................................................................................................................... 28
Figura 4.17. LDR .............................................................................................................................. 28
Figura 4.18. Divisor de tensión.. ...................................................................................................... 29
Figura 4.19. Arduino UNO WiFi.. ..................................................................................................... 30
Figura 4.20. Communication Shield. ............................................................................................... 30
Figura 4.21. Hardware para Arduino con módulo Sigfox. ............................................................... 31
Figura 4.22. Callback para el envío de parámetros de Arduino UNO. ............................................. 32
Figura 4.23. Mensaje enviado por Arduino UNO. ........................................................................... 32
Figura 4.24. Conexionado de sensores en Arduino. ........................................................................ 33
Figura 4.25. Datos recogidos por Arduino y enviados a Sigfox. ...................................................... 34
Figura 4.26. Mensaje con parámetros medioambientales enviado por Arduino. ........................... 34
Figura 4.27. Arduino DUE ................................................................................................................ 35
Figura 4.28. Mensaje enviado por Arduino con sonómetro. ........................................................... 36
Figura 4.29. Medida de corriente que demanda Arduino UNO. ..................................................... 37
Figura 4.30. Medida de corriente en Arduino DUE. ........................................................................ 37
Figura 4.31. Waspmote.. ................................................................................................................. 39
Figura 4.32. Sockets de Waspmote. ................................................................................................ 39
Figura 4.33. Hardware para Waspmote con módulo Sigfox ............................................................ 40
Figura 4.34. Mensaje enviado por Waspmote a Sigfox. .................................................................. 41
Figura 4.35. Pines de entrada y salida de Waspmote.. ................................................................... 42
Figura 4.36. Conexionado de sensores en Waspmote. ................................................................... 42
Figura 4.37. Datos recogidos por Waspmote y enviados a Sigfox. .................................................. 43
Figura 4.38. Datos de sensores de Waspmote recogidos por Sigfox. .............................................. 43
Figura 4.39. Raspberry Pi 3.. ........................................................................................................... 44
Figura 4.40. Puente de conexión entre Raspberry Pi y Arduino. ..................................................... 45
Figura 4.41. Hardware para Raspberry Pi 3 con módulo Sigfox. ..................................................... 45
Figura 4.42. Mensaje enviado por Raspberry Pi 3. .......................................................................... 48
Figura 4.43. Conexionado de sensores en Raspberry. .................................................................... 49
Figura 4.44. Datos de sensores de Raspberry recogidos por Sigfox. ............................................... 50
Figura 4.45. Envío a Sigfox utilizando un Gateway. ......................................................................... 50
Figura 4.46. Sockets de Waspmote. ................................................................................................ 51
Figura 4.47. Módulo WiFi-pro compatible con Waspmote. ............................................................ 51
4
Figura 4.48. Módulos conectados a los sockets de Waspmote. ...................................................... 52
Figura 4.49. Comunicación utilizando Waspmote Gateway. ........................................................... 52
Figura 4.50. Filtrado por MAC activo en el punto de acceso de la red. ........................................... 53
Figura 4.51. Bucle producido en Waspmote al no conectar al AP de la red. ................................... 53
Figura 4.52. Filtrado por MAC en router de la red desactivado. ..................................................... 54
Figura 4.53. Configuración de módulo WiFi-pro de Waspmote realizada con éxito. ...................... 54
Figura 4.54. Conexión WiFi entre servidor TCP en Waspmote y Cliente TCP en PC. ....................... 55
Figura 4.55. Recepción de datos del cliente TCP y envío a Sigfox. ................................................. 56
Figura 4.56. Envío a Sigfox de Waspmote Gateway. ....................................................................... 57
Figura 4.57. Conexión WiFi entre cliente TCP en Waspmote y servidor TCP en PC. ....................... 58
Figura 4.58. Shield Multiprotocolo.................................................................................................. 58
Figura 4.59. Shield Ethernet. .......................................................................................................... 59
Figura 4.60. Uso del ISCP en Shields de Arduino. ............................................................................ 59
Figura 4.61. Conexión a la red del Arduino UNO WiFi. ................................................................... 61
Figura 4.62. Página de configuración del servidor web integrado del Arduino UNO WiFi. ............. 61
Figura 4.63. Comunicación utilizando Gateway Arduino UNO WiFi. ............................................... 61
Figura 4.64. Configuración de IP estática en Arduino UNO WiFi. .................................................... 62
Figura 4.65. Envío de datos mediante cliente HTTP. ....................................................................... 62
Figura 4.66. Problemas de estabilidad en Arduino Uno WiFi. ......................................................... 63
Figura 4.67. Problemas de estabilidad en Arduino Uno WiFi tras eficiencia del código. ................ 63
Figura 4.68. Problemas de estabilidad en Arduino Uno WiFi tras eliminar funciones innecesarias
de librería Sigfox. ........................................................................................................ 63
Figura 4.69. Fallo en comportamiento del servidor (solo envía un parámetro al cliente). ............. 63
Figura 4.70. Uso de RAM dentro de límites para el correcto funcionamiento. ............................... 64
Figura 4.71. Envío de cliente web tras optimización ....................................................................... 64
Figura 4.72. Mensaje recibido en Backend de Sigfox. ..................................................................... 65
Figura 4.73. Envío de datos mediante cliente web Arduino Uno WiFi y recepción mediante
servidor web en ordenador. ....................................................................................... 66
Figura 4.74. Comunicación con Sigfox usando Gateway Arduino UNO WiFi y cliente Waspmote. . 67
Figura 4.75. Comunicación utilizando Raspberry Gateway. ............................................................ 68
Figura 4.76. Conexión WiFi entre cliente TCP en PC y servidor Rasperry........................................ 69
Figura 4.77. Envío a Sigfox de Raspberry Gateway. ........................................................................ 69
Figura 4.75. Tabla “sensores”. ........................................................................................................ 71
Figura 4.76. Tabla “sondas”. ........................................................................................................... 71
Figura 4.77. Tabla “variables”. ........................................................................................................ 71
Figura 4.78. Tabla "medidas" filtrada por día. ................................................................................ 72
Figura 4.79. Tabla “sensores” con nuevo sensor. ........................................................................... 72
Figura 4.80. Tabla “sondas” con nuevas variables activas para sensor 54. ..................................... 72
Figura 4.81. Tabla “medidas” incluye medidas provenientes de SIgfox. ......................................... 72
Figura 4.82. Tabla “sensores” con atributo idSigfox. ...................................................................... 73
Figura 4.83. Tabla “Medidas” incluye medidas recibidas dado identificador de Sigfox. ................. 73
Figura 4.84. Formulario para añadir nuevo sensor. ........................................................................ 74
Figura 4.85. Añadir otro sensor en la página del formulario para crear un sensor. ........................ 75
Figura 4.86. Tabla con información de los sensores. ...................................................................... 75
Figura 4.87. Filtrar sensor por nombre. .......................................................................................... 76
Figura 4.88. Editar sensor. .............................................................................................................. 76
Figura 4.89. Añadir Sonda. .............................................................................................................. 77
Figura 4.90. Tabla con Sondas. ........................................................................................................ 78
5
Figura 4.91. Filtrar sonda. ............................................................................................................... 78
Figura 4.92. Tabla para mostrar aplicaciones en sondas. ............................................................... 79
Figura 4.93. Filtrar aplicaciones. ..................................................................................................... 79
6
1 RESUMEN
El presente proyecto tiene como objetivo la monitorización de parámetros
medioambientales mediante sensores y la red Sigfox, una solución de red de área amplia
de baja potencia (LPWAN), que une redes locales de sensores de distintas ubicaciones
con una velocidad de transmisión baja, para ahorrar energía.
Para este cometido, se utilizarán distintos dispositivos, como Arduino, Waspmote y
Raspberry, que recogerán información a través de múltiples sensores, por ejemplo de
temperatura o fotorresistencias, entre otros. Estos parámetros, permiten el control de
variables medioambientales.
Los valores tomados, se codificarán en sistema numérico hexadecimal, para su
envío e interpretación por parte de la red de Sigfox. Para ello, los dispositivos deberán
contar con funciones específicas en su programación que permitan la conversión de los
valores reales tomados a valores numéricos hexadecimales.
Una vez codificada la información, mediante una cadena de caracteres, se enviará
a la red de Sigfox. Dicho envío se realizará a través de un módulo proporcionado por
Sigfox con una antena que, transmite la información a varias estaciones base que se
encuentren en su cobertura, y estas a la nube de Sigfox.
Se configurará la nube, para decodificar la cadena de caracteres, y así poder
recuperar los valores reales que tomaron los sensores inicialmente. Para ello, se indicarán
qué caracteres de la cadena pertenecen a los distintos parámetros recogidos (temperatura,
humedad, intensidad lumínica, etc) y el tipo de valor que poseen (entero, punto flotante,
booleano, etc).
Una vez decodificada dicha información, se configurará el reenvío de esta, a
través de una petición HTTP, a un servidor propietario. En la citada petición se indicará
también el identificador del módulo de Sigfox, que permitirá su reconocimiento en dicho
servidor.
Este servidor propietario, que consiste en un servidor web desarrollado por el grupo
de investigación de Ingeniería de Sistemas Telemáticos (TIC-220), se modificará para
realizar la recepción de los distintos parámetros enviados en la petición proveniente de
Sigfox y los almacenará en una base de datos, indicando los valores tomados por los
sensores de cada módulo. El servidor también se modificará para poder manejar, en las
vistas mostradas, el identificador de los distintos módulos de Sigfox.
Finalmente, se implementarán dispositivos que actuarán como puente (Gateway)
entre las tecnologías WiFi y Sigfox. Así, varios dispositivos que no posean el módulo
Sigfox, podrán realizar el envío de información a dicha red, mediante la transmisión a través
de WiFi al Gateway más cercano, que se encargará de su remisión.
7
2 INTRODUCCIÓN
Como se ha explicado anteriormente, el objetivo principal de este proyecto es la
monitorización de parámetros medioambientales mediante sensores y la red Sigfox.
En la actualidad, se demandan, cada vez más, servicios que permitan la
recolección, análisis y distribución de información relacionada con variables
medioambientales. Esta información tiene diversos fines, como la preservación digital de
datos, el modelado de patrones climatológicos o su representación gráfica.
Para la recogida de este y otros tipos de información, surge el concepto de Internet
of Things (IoT), que permite la interconexión de cualquier producto con Internet. De esta
manera, distintos dispositivos interactúan con elementos de la vida real, se comunican
entre sí y transmiten información a Internet, con el objetivo de permitir su uso en
aplicaciones y una mayor facilidad en la vida de las personas.
Uno de los campos más interesantes del IoT son las redes de sensores
inalámbricos (WSN). A diferencia de otras redes, las WSN poseen la característica de
recolectar datos detectados (presión, temperatura, humedad, detección de movimiento,
intensidad lumínica, pulsaciones por minuto, cantidad de glucosa en sangre, etc) y
reenviarlo a un Gateway. Posteriormente, se puede recopilar toda la información para su
utilización en distintos campos de aplicaciones, como son:
- Educación: Puede ayudar a monitorizar la actividad diaria en clases mediante
obtención de datos sobre el estilo de vida saludable de los alumnos.
- Industria: Para controlar el proceso de producción y realizar un seguimiento de
la cadena de suministro.
- Agricultura inteligente: Monitorizar la producción del cultivo y su gestión de
calidad.
- Medicina inteligente: Para la recolección y análisis de parámetros de fisiología
y medicina en humanos o servicio médico a distancia.
- Ciudades inteligentes: Combina tecnologías de la información para promover un
crecimiento económico y sostenible con la finalidad de lograr una mejora en la
calidad de vida de los ciudadanos.
Para la obtención de toda esta información y su posterior uso en las aplicaciones
anteriormente indicadas, así como otra gran cantidad de ellas, son necesarios dispositivos
con ciertas características que los hacen aptos para las WSN. Entre ellas se encuentran:
- Coste económico: Dispositivos baratos.
- Hardware libre y modificable: Posibilidad de modificar el hardware para
conseguir un menor consumo, o la capacidad de utilizar múltiples tecnologías
de comunicación entre sensores, como WiFi, Bluetooth, etc.
8
- Uso de software y librerías de uso público: La utilización de este tipo de
dispositivos debe de tener las mínimas barreras posibles. Así, se fomentará la
emergencia de las redes WSN para múltiples tipos de aplicaciones.
- Flexibilidad en la programación: Los dispositivos deben de permitir su
programación para distintos tipos de aplicaciones.
- Apoyo de la comunidad: Empresas y distintos usuarios realizan aportaciones y
ejemplos de uso para facilitar su evolución.
Algunos de los dispositivos que cumplen estas características son:
- Arduino: Es una plataforma de hardware libre programable y software flexible
y fácil de usar, de código abierto. Tiene un gran apoyo por parte de la comunidad
y permite el uso de una gran cantidad de librerías compatibles.
- Waspmote: Es una plataforma modular de código abierto, enfocada en construir
redes de sensores inalámbricas de muy bajo consumo. Posee una gran
variedad de placas para medir parámetros necesarios en las ciudades
inteligentes, así como módulos que permiten la comunicación inalámbrica a bajo
consumo.
- Raspberry: Es una placa que posee la potencia de un ordenador en un tamaño
compacto. Debido a su bajo coste, potencia, y diversidad y sencillez de
aplicaciones, se ha popularizado entre la comunidad que aporta valor a este
proyecto.
Para el intercambio de información entre las redes de sensores, existen numerosas
tecnologías con las que se pueden transmitir información a la base de datos que la
almacena. Entre ellas, se encuentran:
- WiFi: Su estándar es el 802.11. Permite transmitir información entre dispositivos
por medio del uso de radiofrecuencias, evitando el cableado. Para su
funcionamiento, es necesario un punto de acceso, que posibilite el reenvío de
mensajes que se transmiten en la red. Está extendida a entornos domésticos y
comerciales, permitiendo el intercambio de grandes cantidades de datos con
gran rapidez.
- Bluetooth: Similar a WiFi, pero diseñado para dispositivos de bajo consumo, que
requieren corto alcance de emisión. A diferencia de WiFi, el envío de
información se lleva a cabo punto a punto, sin necesidad de un punto de acceso
en la red.
- ZigBee: Tecnología inalámbrica centrada en aplicaciones industriales. Está
basada en el protocolo 802.15.4, una tecnología de red inalámbrica que trabaja
a 2.4 Ghz, al igual que WiFi. Dicha tecnología se usa en aplicaciones que
9
requieren comunicaciones con baja tasa de envío de datos en un área de corto
alcance (inferior a 100 metros).
- 6LowPAN (IPv6 Low-power wireless Personal Area Network): Se ha diseñado
sobre redes 802.15.4, y es una tecnología inalámbrica basada en IP. En lugar
de tratarse de una tecnología de protocolos de aplicaciones IoT, como ZigBee
o Bluetooth, esta tecnología es un protocolo de red que permite mecanismos de
encapsulado y compresión de cabeceras. Su frecuencia se puede adaptar a
múltiples capas como Bluetooth o ZigBee.
- Red de telefonía móvil: Permite el envío de grandes cantidades de datos, a
largas distancias. Entre las tecnologías que utiliza se encuentran GSM, 3G y
4G. Para el envío de información es necesario un consumo demasiado alto para
muchos de los dispositivos contemplados.
- Ethernet: A pesar de no formar parte en las WSN, ya que no se trata de una
tecnología inalámbrica, sino cableada, permite el envío de una gran cantidad de
información entre sensores a gran velocidad. Por lo que se tendrá en cuenta
para el diseño de un Gateway para Sigfox.
A las tecnologías citadas anteriormente, se suma la de Sigfox, una alternativa de
amplio alcance, cuyas distancias a recorrer se encuentran entre WiFi y la comunicación
móvil. A pesar de no lograr las distancias de la red de telefonía móvil, tiene un gran
rendimiento. Está enfocada a aplicaciones entre máquinas remotas (M2M), con un
consumo mínimo, y se usa en dispositivos que funcionan con una batería, por lo que se
persigue un ahorro de energía, y que solo requieren velocidades menores de transferencia
de datos.
La red Sigfox, proporciona cobertura en numerosas zonas a nivel global, lo que
permite que distintos tipos de sensores, independientemente de su localización, puedan
enviar datos a la red, simplemente poseyendo el módulo Sigfox. Una vez almacenada la
información, permite su redirección a un servidor propietario, a través de la red Internet, lo
que unifica la metodología en cuanto a los dispositivos de IoT.
Para este proyecto, se realizará el envío a Sigfox desde varios dispositivos. Además
se configurarán algunos como Gateway para permitir el reenvío de información, a través
de WiFi, en el caso de que otros dispositivos no posean el módulo característico para hacer
uso del servicio en la nube.
10
Figura 2.1. Diagrama de comunicación utilizando Sigfox.
Como se puede apreciar en la Figura 2.1, Waspmote, Raspberry y Arduino se
encargarán de recoger parámetros medioambientales por medio de sensores, los
codificarán en sistema hexadecimal y realizarán el envío a la nube de Sigfox, por medio
del módulo que hace uso de este servicio. Además, el Waspmote WiFi-Pro recogerá
información desde los sensores y, a través de WiFi, enviará los valores reales en un
mensaje TCP al Gateway Waspmote o al Gateway Raspberry, que los codificará y
enviará a Sigfox. El Arduino UNO WiFi, se encargará también de recoger información de
los sensores, y, a diferencia de Waspmote WiFi-Pro, este codificará los parámetros y
realizará el envío al Gateway Arduino por medio de WiFi, que se limitará a reenviar la
información codificada a Sigfox.
Finalmente, la nube de Sigfox se configurará para decodificar toda esa información,
proveniente de los distintos tipos de sensores, y poseerá el mismo formato para unificar las
comunicaciones, de esta manera se realizará el reenvío a un servidor propietario, que, en
el caso de este proyecto, se trata de un servidor web.
11
3 OBJETIVOS
En este apartado, se presentarán los objetivos de este proyecto para conseguir la
monitorización de parámetros medioambientales mediante sensores y la red Sigfox.
Además de las metas iniciales, se incluyen otras que se han ido incorporando, para añadir
más funcionalidades a los dispositivos:
- Familiarizarse con la tecnología Sigfox: Se debe hacer uso de la documentación
proporcionada por el operador de Sigfox que explica la tecnología y cómo usarla.
- Familiarizarse con sensores Arduino, Waspmote y Raspberry: Debe buscarse
información de los distintos dispositivos para comprender su funcionamiento.
- Programar sensores para la monitorización de variables medioambientales,
haciendo uso de la red de Sigfox: Utilizar información que aporta el proveedor de
servicios para programar los distintos dispositivos con el fin de enviar datos a la
nube de Sigfox.
- Programar sensores para actuar como Gateway que recogen información de varios
dispositivos, y reenviarla a Sigfox: Valorar alternativas para el envío de información
desde varios sensores al Gateway, que será el que actúe de puente con Sigfox.
- Configuración de la nube de Sigfox para remisión de información: Se debe hacer
uso de la documentación del operador para configurar el Backend y así decodificar
la información y reenviarla a un servidor propietario.
- Programar servidor propietario que procese la información recibida por el Backend
de Sigfox: Modificar la programación del servidor para aceptar peticiones
provenientes de Sigfox y el correcto almacenamiento de los parámetros en la base
de datos.
- Pruebas para validar la programación y comprobar que la monitorización se realiza
de forma satisfactoria: Asegurarse de que todos los dispositivos realizan el correcto
envío de parámetros medioambientales y el éxito en el almacenamiento de medidas
en el servidor.
12
4 METODOLOGÍA
4.1 Introducción a Sigfox
4.1.1 ¿Qué es Sigfox?
Sigfox se encarga de proveer un servicio de IoT, a través de una red LPWAN de
radio, para dispositivos que necesitan enviar información utilizando muy poco consumo, y
en casos en los que no es necesaria una alta velocidad de transferencia de datos. Esta red
se despliega a nivel global mediante estaciones base y permite reenviar, todos los
mensajes que le llegan, hacia servidores propietarios. También puede hacer uso, en
algunos casos, de puentes o conectores con otras plataformas en la nube.
En resumen, Sigfox posee una red dedicada que proporciona una conexión de baja
energía, confiable y económica para conectar dispositivos y sensores, que realizan el
transporte de información a través de su red de radio para, posteriormente, reenviarla a un
servidor propietario [1].
4.1.2 Características del protocolo de Sigfox
Las características del protocolo de Sigfox son las siguientes:
o Autonomía: El consumo de energía es muy bajo, permitiendo un tiempo de
vida de la batería de años, ya que simplifica las comunicaciones.
o Simplicidad: No hay señalización, configuración o petición de conexión por
parte de los dispositivos de la red.
o Eficiencia de coste: Sigfox optimiza el hardware que se usa en los
dispositivos de su red, así como el precio de la suscripción, para permitir lo
máximo posible su efectividad de coste.
o Mensajes pequeños: Solo envía pequeñas notificaciones para transmitir
información.
o Complementario a otras soluciones: Posee una fácil configuración y bajo
coste que permite que pueda ser usado junto con otro tipo de redes
(Bluetooth, WIFI, GPRS).
Mediante la tecnología Sigfox existen dos maneras de transportar datos de forma
optimizada:
o Bidireccional: Los mensajes pueden ser enviados desde los sensores hacia
la nube de Sigfox y esperan una respuesta desde esta.
o Dúplex: Los mensajes se envían y reciben al mismo tiempo por un
dispositivo conectado en la red.
La red de Sigfox funciona como un canal de transporte transparente, ya que permite
la conexión de objetos de forma segura mediante mecanismos de redundancia (diversas
13
estaciones base recolectando paquetes) y la supervisión del canal de comunicación (con
paquetes de control). Además, utiliza protocolos de comunicación encriptados.
4.1.3 Ciclo de vida de un mensaje Sigfox
Un mensaje Sigfox enviado desde cualquier sensor conectado a la red sigue las
siguientes etapas:
1. Uno de los dispositivos conectados a la red despierta y emite información a
través de un mensaje.
2. Las estaciones base de Sigfox que se ubiquen en el área reciben el mensaje.
Las citadas estaciones están compuestas de una antena para captar señal, un
amplificador de bajo ruido para filtrar dicha señal y un punto de acceso para
enviar la información a la plataforma Cloud.
3. Las estaciones envían el mensaje a la plataforma Cloud. El primer mensaje que
llega a la nube implica el descarte de los posteriores que han sido enviados por
otras estaciones que se encontraban en el radio del sensor.
4. La plataforma Cloud envía el mensaje al Backend que desee el cliente. Se
puede programar un servidor propio o, mediante un puente, transmitir
información a otras plataformas para IoT como “Amazon Web Services IoT”,
“Amazon Kinesis” o “Servicios de Microsoft Azure para IoT”.
Figura 4.1. Ciclo de vida de un mensaje de Sigfox.
4.1.4 Mensajes de Sigfox
Para el correcto funcionamiento de las comunicaciones en la red de Sigfox, esta
requiere de varias características y restricciones. La siguiente figura muestra el recorrido
de un mensaje en la red de Sigfox de subida y de bajada.
Figura 4.2. Envío de mensajes en la red de Sigfox.
14
Características de los mensajes de subida:
- Los sensores envían mensajes de un máximo de 12 bytes. El límite de mensajes
de subida es de 140 al día.
- Las estaciones base de Sigfox que se encuentren en su alcance lo reciben, y lo
envían a la nube. Esta, se encargará de eliminar mensajes duplicados si fuera
necesario.
- Si existiera un Backend configurado, la nube de Sigfox reenvía la información a
este.
Características de los mensajes de bajada:
- Se pueden configurar eventos que permiten a los sensores enviar una petición a
los servidores de Sigfox, y esperar su respuesta.
- Los mensajes de respuesta, de un máximo de 8 bytes, se reenvían al dispositivo
específico que envió la petición. Se usa para que Sigfox conozca las necesidades
de la red de sensores (cobertura, restricciones de contrato, etc).
Por lo tanto, la nube:
- Proporciona una interfaz entre el proveedor de Sigfox y los clientes, permitiendo el
reenvío de datos a otros servidores o plataformas.
- Atiende los mensajes que llegan de los dispositivos, para almacenar su información
y reenviarla.
- Obtiene las necesidades de la red de sensores, como su cobertura, y permite
gestionar partes de un dispositivo o el contrato de uso de usuario (“Business
Support System”).
- Atiende a los operadores de la red de Sigfox funcionando como un controlador de
gestión de red, una herramienta de gestión de contrato, una herramienta de plan de
radio, etc (“Operation Support System”).
4.1.5 Operadores de Sigfox (SNO)
Sigfox posee operadores que despliegan sus servicios de forma global. Los SNO
varían en función del país, y garantizan el acceso a:
- La red pública de Sigfox.
- Sigfox cloud para manejar y observar los dispositivos de la red.
- La plataforma de soporte Sigfox (siempre disponible), que permite la solución de
problemas para implantar la tecnología Sigfox en cualquier proyecto.
En la siguiente imagen se puede observar la cobertura mundial de la red Sigfox. En
azul, los países donde ya está implantado Sigfox. En morado, los países donde se han
desplegado estaciones base para el funcionamiento del sistema, pero todavía no existe
cobertura con un operador [2].
15
Figura 4.3. Cobertura de proveedores Sigfox. Fuente: https://www.sigfox.com/en/coverage.
Sigfox proporciona una red pública, por lo que los dispositivos confían en la
infraestructura desplegada por el operador local para comunicar. En España, por ejemplo,
el operador que proporciona la cobertura es Sigfox Spain, o en Alemania, el SON es IoT
Denmark A/S.
En función de la zona de cobertura, Sigfox ha desarrollado otros servicios que se
adapta a las necesidades el cliente:
- Connectivity as a Service: Si el cliente se ubica en un área en el que no existe
cobertura todavía, pero sí se ha desplegado la tecnología Sigfox, se pueden alquilar
estaciones base de Sigfox para crear un punto de acceso propio, y extender la red
de manera flexible, simple y con bajo coste.
- SRD Dongle: Si el cliente se ubica en una zona donde no está presente Sigfox,
este dispositivo permite simular la nube para probar el funcionamiento de
dispositivos en la red.
Figura 4.4. SDR Dongle. Fuente: https://build.sigfox.com/sdr-dongle.
16
4.1.6 Tecnología de Radio
La red que proporciona Sigfox para dispositivos IoT es celular, lo que quiere decir
que existen distintas estaciones base recubriendo áreas en cada país alrededor del mundo.
Es similar a las redes GSM-GPRS-3G-4G, pero posee mayor eficiencia de energía.
Esta eficiencia se consigue mediante UNB (Ultra Narrow Band), o utilización de una
banda estrecha en el espectro de frecuencias. Dicha tecnología se usa para conectar los
dispositivos a su red global, lo cual proporciona una red escalable y de alta capacidad, con
poco consumo de energía.
4.1.6.1 UNB
UNB es una tecnología para transmitir sobre un canal estrecho en el espectro de
frecuencias, con el objetivo de conseguir el intercambio de mensajes a través de mayores
distancias.
La modulación que utiliza es DBPSK para subida y GFSK para bajada de mensajes:
- DBPSK: Consiste en un cambio de fase para transmitir un símbolo u otro. Un
símbolo ‘1’ implica el cambio de fase en la señal transmitida, y un ‘0’, hace que
permanezca en la fase en la que se encontraba.
Figura 4.5. Modulación DBPSK.
- GFSK: Los símbolos se representan mediante una desviación, positiva o negativa,
de la frecuencia de la onda portadora.
Figura 4.6. Modulación GFSK.
17
La clave para conseguir distancias más largas es su baja velocidad de datos.
Cuanto más baja sea la velocidad de los datos, más estrecha será la banda, por lo que
mejorará la relación señal-ruido. Esto permite que estén más alejados transmisor y
receptor.
Figura 4.7. Efectos de UNB en el espectro de frecuencias.
La modulación UNB posee dificultades en la recepción que Sigfox resuelve
utilizando técnicas de radio modernas.
4.1.6.2 Banda de frecuencias
La red opera en la banda ISM (Industrial, Scientific and Medical), una banda
reservada internacionalmente para uso no comercial de radiofrecuencia. Es una banda libre
de licencias y coexiste con otras tecnologías sin riesgo de colisiones o capacidad de canal.
Sigfox utiliza la banda de 868 MHz en Europa (definido por ETSI y CEPT) y 900
MHz para USA y Canada. Esta empresa colabora con ETSI para la estandarización de
redes de bajo rendimiento. [3]
4.2 Puesta en funcionamiento de Sigfox
4.2.1 Servicio de Sigfox
Para permitir la recepción y gestión en Sigfox de los datos enviados por un
dispositivo, es necesario asociarlo a una suscripción del servicio de Sigfox. [4]
Procedimiento:
1. Comprar un kit de desarrollo (arduino, Rasberry Pi, etc) que incluye una
suscripción al servicio. Se puede acceder a los módulos de compatibilidad a
través de la plataforma que proporciona el operador.
2. Crear cuenta y activar servicio en la página correspondiente, indicando el país
y el kit de desarrollo. También es necesario el identificador de dispositivo y el
número PAC (Porting Authorisation Code).
3. Activar la cuenta desde el correo para acceder al dispositivo desde el Backend.
18
Una vez dado de alta el módulo en la plataforma de Sigfox, se podrá enviar
información a la red, configurar eventos, reenviar la información y observar los mensajes
que se han transmitido.
4.2.2 Callbacks
4.2.2.1 Introducción
Gracias a los Callbacks, se puede recuperar, en un servidor propietario, la
información que llega a la nube de Sigfox. Estos, permiten realizar una petición, por medio
de diversos medios, sobre un servidor Backend cuando ocurre algún evento (también
existe compatibilidad con otras plataformas como AWS IoT y Microsoft Azure, que,
posteriormente, pueden enviar información al Backend deseado).
Un ejemplo de evento puede ser recibir información de un dispositivo. El Backend
de Sigfox monta una petición hacia el servidor propietario mediante el método deseado.
4.2.2.2 Custom Callback
Una vez se registre un dispositivo en la nube de Sigfox, se puede visualizar en la
pestaña “Device”. Entre otros indicadores, posibilita la comprobación del nombre del
dispositivo, su identificador de Sigfox, el indicador de fuerza de la señal (RSSI) recibida por
las estaciones que se encuentran en el rango del módulo y la relación señal-ruido (SNR)
que perciben las estaciones base.
Figura 4.8. “Device List” en Backend de Sigfox.
Si se elige uno de los módulos registrados, se puede visualizar una página de información
sobre el dispositivo escogido.
19
Figura 4.9. Información del módulo escogido en el Backend de Sigfox.
Desde esta página, existe una opción que permite editar los Callbacks, o eventos.
Figura 4.10. “Callbacks” en el Backend de Sigfox.
Uno de esos Callbacks permite redirigir la información al servidor propietario
implementado cuando se recibe un mensaje del dispositivo en la nube de Sigfox.
Figura 4.11. “Callback edition” en el Backend de Sigfox.
20
Opciones para editar en los Callbacks:
- Tipo: Muestra el tipo de mensaje a enviar. Pueden ser:
o Data: Indica que el mensaje que se recibe por el dispositivo será transportar
datos.
o Service: El mensaje transmitido por el dispositivo es de control. Indicando
su estado (activo o no).
o Error: El mensaje que envía el dispositivo puede tratarse de un error.
En cuanto a la comunicación, la dirección de los mensajes puede ser:
o Uplink: Mensaje de subida del dispositivo.
o Bidireccional: Tras recibir el mensaje del dispositivo, Sigfox puede enviar
otro a él.
- Canal: Dicha opción permite elegir si se desea enviar al servidor propietario desde
el Backend de Sigfox mediante HTTP, con una URL, o mediante un e-mail.
- Mandar duplicado: Da la opción de configurar si se desea enviar por duplicado al
Backend propietario.
- Configuración de la carga útil: Permite a Sigfox decodificar la carga útil del
mensaje que transmite un sensor. El dispositivo envía los valores reales codificados
en una cadena de caracteres hexadecimales, y esta opción se configurará para
distinguir qué partes de dicha cadena pertenecen a los distintos parámetros, para
así poderlas decodificar y reenviar.
- URL: Proporciona un medio para establecer la URL que enviará la petición al
servidor web propietario, en caso de escoger el canal HTTP.
- Método HTTP: En caso de escoger el canal HTTP, se pueden configurar los
métodos GET, POST y PUT (para estos dos últimos se activan varias opciones que
completan el envío, como tipo de contenido o cuerpo de la petición enviada).
En este proyecto, se utilizará:
- Tipo: Data-Uplink, ya que se enviarán mensajes desde los sensores con
información, y esta será de subida.
- Canal: URL, ya que se producirá el reenvío de datos al servidor web mediante
HTTP, con el localizador de recurso universal.
- Método: GET, petición HTTP que permite el envío de información en la cabecera
del mensaje, y no en el cuerpo.
- Configuración de carga útil: Permite decodificar la información que llega.
- URL: Parámetros que se envían mediante HTTP.
La configuración de carga útil y la URL, a la que remitir los datos, se explicarán en
el apartado 4.2.3.
21
4.2.3 Funciones para codificar y configurar Callbacks para decodificar
4.2.3.1 Decodificar datos recibidos
Como ya se ha explicado, los sensores tomarán valores reales. Dichos valores se
deberán codificar en sistema hexadecimal para su envío. Debido a esta codificación, el
Callback que se activa al recibir un mensaje, debe decodificar los datos para poder
reenviarlos al servidor propietario.
Hay que realizar la configuración de la carga útil indicando el nombre del parámetro,
dos puntos dobles, tipo de dato (entero sin signo, de punto flotante, carácter, etc), y los bits
del mensaje recibido que le corresponden.
[NOMBRE DEL PARÁMETRO] :: [TIPO DE DATO] : [NÚMERO DE BITS]
En la URL se hace referencia a los nombres de los parámetros indicados en la
configuración de la carga útil, entre llaves, y tras “customData#”.
[URL] ? [VARIABLE1] = {customData# [NOMBRE DEL PARÁMETRO] }
Por ejemplo: http://servidor/rdin.php?i={device}&r={data}&t={customData#temper
atura}&p={customData#presion}&rmax={customData#rmax}&rmin={customData#rmin}
Se expondrán distintos ejemplos de envío de cadenas de caracteres con el sensor
y su decodificación en la plataforma de Sigfox para poder enviar la información al Backend
propietario.
Número que se envía desde el sensor: 30
Decimal: 30
Binario: 0001 1110
Hexadecimal: 1 E
El sensor envía “1E”, que se codifica como 2 caracteres hexadecimales (8 bits).
En la configuración de la carga útil hay que indicar el nombre del parámetro, el tipo
de número y los bits que corresponden a esa variable de todos los que se han recibido del
sensor.
Configuración de carga útil: temp::int:8
Se monta la URL con ese parámetro:
http://servidor/index.php?isig={device}&d={data}&t={customData#temp}
ediante esta petición, se ha de indicar el recurso al que se realizará el envío de
datos (“index.php”) del servidor “servidor”, con los parámetros “isig”, “d” y “t”, cuyos valores
son el identificador de la antena de Sigfox, la cadena de caracteres enviada por el sensor
y la parte de la cadena que almacena la temperatura, respectivamente.
- Números que se envían desde el sensor: 30 y 46
Decimal: 30 46
Binario: 0001 1110 0010 0110
22
Hexadecimal: 1 E 2 E
El sensor envía “1E2E”, cuyos primeros 8 bits corresponden a un parámetro, y los
8 siguientes a otro.
De los 16 bits que se reciben, hay que especificar que los 8 primeros corresponden
a un parámetro entero, que se indicará como temperatura y los 8 siguientes a otro
parámetro, también entero, que corresponderá a frecuencia:
Configuración de carga útil: temp::int:8 fre::int:8
Se monta la URL con ambas variables:
http://servidor/index.php?isig={device}&d={data}&t={customData#temp}&f={custom
Data#fre}
Se realizará el reenvío, mediante una petición, al servidor indicado anteriormente
con los parámetros recogidos en el Callback (“temp” y “fre”).
- Números que se envían desde el sensor: 3025, 4025, 30
Decimal: 3025 60235 30
Binario: 0000 1011 1101 0001 1110 1011 0100 1011 0001 1110
Hexadecimal: 0 B D 1 E B 4 B 1 E
El sensor envía “0BD1EB4B1E”, de los cuales los 16 primeros bits corresponden a
un parámetro (temperatura), los 16 siguientes, a otro (frecuencia), y los 8 siguientes, a otro
(presión).
De los 40 bits que se reciben, hay que especificar que los 16 bits primeros y los 16
bits siguientes corresponden a parámetros enteros, y los 8 bits finales a otra variable
entera:
Configuración de carga útil: temp::int:16 fre::int:16 pre::int:8
Se configura la URL con esos parámetros:
http://servidor/index.php?isig={device}&d={data}&t={customData#temp}&f={custom
Data#fre}&p={customData#pre}
Hay que indicar los bits de almacenamiento en función del valor entero.
𝑉𝑎𝑙𝑜𝑟 𝑚á𝑥𝑖𝑚𝑜 𝑑𝑒𝑙 𝑝𝑎𝑟á𝑚𝑒𝑡𝑟𝑜 = 2𝑛ú𝑚𝑒𝑟𝑜 𝑑𝑒 𝑏𝑖𝑡𝑠
o Entero < 2 (valores de parámetros 0, 1): 1 bit
o Entero < 4 (valores de parámetros 0, 1, 2, 3): 2 bits
Parámetros con tan pocos valores no interesan para caracterizar las variables
medioambientales. En el caso de este proyecto, los más utilizados serán:
o Entero < 256 (valores de parámetros entre 0 y 255): 8 bits
o Entero < 65536 (valores de parámetros entre 0 y 65535): 16 bits
Se hará uso, en el código de todos los dispositivos utilizados, de una función creada
para devolver una cadena de caracteres hexadecimales si acepta como entrada un valor
entero.
23
4.2.3.2 Enviar parámetros con punto flotante
Los anteriores apartados explican el uso del módulo de Sigfox y su Backend para
parámetros enteros tomados. Verdaderamente, muchos de los valores recogidos por los
sensores serán números reales, es decir, números con punto flotante, además de números
enteros.
Se ha creado una función para transformar números con punto flotante a una
cadena hexadecimal. Para ello, se utilizará la norma IEEE 754, estándar para la
representación de coma flotante en hexadecimal. La citada norma utiliza 8 caracteres
hexadecimales, pudiendo representar cualquier número real.
Para esta conversión, se diseñará una función para convertir el número de coma
flotante a entero de 32 bits, y, posteriormente, otra para pasar del entero de 32 bits a
cadena hexadecimal, que representa el número con punto flotante mediante la norma IEEE
754.
Así, cada vez que se quiera convertir un valor con punto flotante a hexadecimal se
utilizarán las funciones:
uint32_t bin32 = ConvertFloatToB32(float);
String hex1 = Uint32ToString(bin32);
Y si se desea convertir un valor entero a hexadecimal:
unsigned int entero = 255;
String hex2 = UintToString(entero);
Finalmente, se concatenarán todas las cadenas hexadecimales en el código de los
dispositivos para el envío. En el Backend de Sigfox se decodificarán, para su correcta
interpretación, en función del tipo de valor y el número de bits que ocupa en la cadena,
como se ha explicado anteriormente en los Callbacks.
String message = hex1+hex2;
La ventaja del uso de la norma IEEE 754 es que se pueden representar todos los
valores reales, con una determinada precisión, pero existe el inconveniente del uso de 8
caracteres hexadecimales, por lo que, en un mensaje Sigfox, cuyo tamaño máximo es 12
bytes (24 caracteres hexadecimales), solo se podrían enviar 3 variables representadas
mediante la norma IEEE 754.
4.2.3.3 Ahorrar bits en el mensaje
Para el envío de números con punto flotante, existe la limitación de un máximo de
3 en un mensaje Sigfox.
Se pueden realizar cálculos a las variables tomadas para que se encuentren, por
ejemplo, entre los valores 0 y 255 o entre 0 y 65535, y así ahorrar caracteres, aunque
requiere que el servidor propietario realice los cálculos inversos.
24
En el supuesto de que la presión detectada estuviera comprendida entre 90.2 y
110.5 mbar, se puede multiplicar por 10 y restar 900 al valor tomado para permitir su
codificación con solo 2 caracteres hexadecimales, en lugar de 8. Los pasos necesarios
serían:
1. Sensor mide el valor real.
2. Cálculos en el sensor:
Función: Valor * 10 – 900
o Mínimo: 90.2 * 10 – 900 = 2
o Máximo: 110.5 * 10 – 900 = 205
Los valores se encontrarán entre 2 y 205, valores menores a 256 (8 bits), lo que
permite su representación con dos caracteres hexadecimales.
3. Se envían a Sigfox dos caracteres hexadecimales, y este lo reenvía al Backend
propietario.
4. Cálculos en el servidor:
Función inversa: (Valor + 900) / 10
o Mínimo: (2 + 900) / 10 = 90.2
o Máximo: (205 + 900) / 10 = 110.5
En el servidor se puede recuperar el valor del sensor tomado inicialmente.
De esta manera, se ahorrarían bits para enviar y así incluir más parámetros en el
mensaje, a costa de realizar cálculos en el sensor y sus correspondientes transformaciones
inversas en el servidor.
4.3 Envío de información a la nube de Sigfox
4.3.1 Introducción
Una de las características de los mensajes de Sigfox, es que están preparados para
contener la mínima información y así optimizar los sensores que transmiten solo con una
pequeña cantidad de energía.
Excluyendo las cabeceras, se pueden introducir hasta 12 bytes (96 bits o 24
caracteres hexadecimales) en la carga útil de los mensajes.
Un dispositivo realiza una difusión de los mensajes a las estaciones base durante
aproximadamente 6 segundos con un ratio de 100 bit/s (en la zona de Sigfox europea).
Existen comandos, para la programación del módulo, a bajo nivel con los que enviar
los datos, pero en los dispositivos utilizados, se realizará a través de librerías que ayudan
a su funcionamiento. [3]
4.3.2 Módulo Sigfox
Este módulo, proporcionado por el operador, posibilita el envío de información a la
red de Sigfox. El identificador que posee el módulo, permite indicar a la nube el dispositivo
25
que envía la información y se incluirá en los mensajes transmitidos a esta, sin afectar al
límite de carga útil de los mensajes de 12 bytes.
Figura 4.12. Módulo y antena Sigfox. Fuente: https://www.cooking-hacks.com/documentation/tutorials/sigfox-connectivity-arduino-raspberry-pi-868mhz-
europe-900mhz-us/.
Las principales características son:
o Frecuencia: ISM 868 MHz.
o Potencia de transmisión: 16 dBm.
o Consumo:
Transmisión: 51 mA a 16 dBm.
Recepción: 16 mA.
o Sensibilidad de recepción: -126 dBm.
o Limitación ETSI: 140 mensajes de 12 bytes, por módulo por día.
o Certificado Sigfox: Clase 0u (certificado de solución radio Sigfox [Sigfox
Verified] y certificado de producto terminado [Sigfox Ready]).
El módulo se alimenta a 3.3V. El consumo para distintos estados es:
o Apagado 0 mA.
o Transmitiendo datos 52 mA.
o Recibiendo datos 13 mA.
El tiempo de consumo hasta que el proceso de envío se completa es de unos
segundos. Durante el transcurso de ese tiempo, se producirá el consumo de corriente
especificada anteriormente.
26
Modo de transmisión Tiempo transcurrido
Envío desde estado de encendido. [ ̴ 6 segundos] 6 segundos para enviar
paquete.
Envío desde estado de apagado.
[ ̴ 12 segundos] 6 segundos para
encender y 6 segundos para enviar a la
red.
Envío con ACK desde estado de
encendido.
[ ̴ 39 segundos] 6 segundos para enviar a
la red, 14 segundos para entrar en estado
de espera de datos y 19 segundos
recibiendo el paquete.
Envío con ACK desde estado de
apagado.
[ ̴ 45 segundos] 6 segundos para
encender, 6 segundos para enviar a la
red, 14 segundos para entrar en estado
de espera de datos y 19 segundos
recibiendo el paquete.
Tabla 4.1. Tiempo transcurrido en función del modo de transmisión del módulo Sigfox.
4.3.3 Observar mensajes recibidos por Sigfox.
Una vez se ha realizado el envío de algún mensaje mediante el módulo, se
procederá a visualizarlo en el Backend y así comprobar si realmente se ha reenviado la
información al servidor propietario.
Existe una opción en el Backend de Sigfox, que muestra información técnica del
dispositivo que realiza el envío de mensajes. Para ello, se debe acceder a la página desde
su identificador.
Figura 4.13. “Device List” en Backend de Sigfox.
Se mostrará una página con información técnica sobre el dispositivo.
27
Figura 4.14. Información técnica del módulo en Backend de Sigfox.
En el apartado “Messages” de esta página, se visualizan todos los mensajes
transmitidos por el dispositivo a Sigfox. Se realizará esta comprobación para todos los
mensajes transmitidos desde los distintos dispositivos utilizados en el proyecto.
Si se enviara la cadena “000102030405060708090A0B”, el mensaje recibido sería
el siguiente.
Figura 4.15. Mensaje enviado por Arduino UNO.
URL
28
Se puede comprobar que ha llegado con éxito el mensaje “00010203040506
0708090a0B”, enviado por el módulo con identificador “1AD932”. Pero no ha se ha podido
reenviar al Backend propietario ya que, en el CallBack, no había montada una URL válida
para reenviar la información (el host utilizado en la URL no existe), por lo que ha ocurrido
un error en el reenvío (se representa con un símbolo en rojo).
4.3.4 Sensores utilizados para recoger valores reales.
Para recoger valores en los distintos dispositivos y codificarlos, o realizar
operaciones con ellos, se utilizarán dos tipos de sensores para medir variables
medioambientales.
- Se utilizará un sensor de temperatura, LM35. Dicho sensor tiene una precisión
calibrada de 1 ºC, y su rango de medición abarca desde los -55 ºC hasta los 150ºC.
La salida del sensor es lineal, y por cada grado centígrado que detecta, su salida
asciende 10 mV.
Figura 4.16. LM35. Fuente: http://henrysbench.capnfatz.com/henrys-bench/arduino-temperature-measurements/lm35-arduino-temperature-sensor-user-manual/.
Para alimentar dicho sensor es necesario un voltaje de 5 V en su primera patilla y
la conexión a tierra en la tercera patilla. Por su segunda patilla, se obtendrá un voltaje en
función de la temperatura que detecte.
- Además, para captar otra variable medioambiental, se medirá la intensidad lumínica
mediante una fotorresistencia (LDR).
Figura 4.17. LDR. Fuente: https://www.daraz.pk/teknuclei-ldr-light-dependent-resistor-light-sensor-6769259.html.
29
Dicho sensor funcionará mediante un divisor de tensión, ya que, para distintas
intensidades lumínicas, poseerá diferentes valores de resistencia, que permitirán un mayor
o menor voltaje a la salida del divisor.
Figura 4.18. Divisor de tensión. Fuente: http://www.educachip.com/utilizar-ldr-arduino/.
4.3.5 Arduino UNO
4.3.5.1 Características
Esta placa permite una gran flexibilidad y facilidad de configuración en cuanto a su
hardware y programación. Para este proyecto, se ha utilizado un Arduino UNO WIFI, que
posee características parecidas al Arduino UNO, además de poseer un módulo WiFi
integrado [8].
Por lo tanto, todos los apartados realizados en este proyecto con el Arduino UNO
WiFi, excepto la comunicación WiFi, se puede realizar con el Arduino UNO.
Características:
- Microcontrolador:
o Microcontrolador: ATmega328
o Arquitectura AVR
o Voltaje al que opera: 5 V
o Memoria Flash: 32 KB
o SRAM: 2 KB
o EEPROM: 1KB
o Frecuencia de reloj: 16 MHz
o Entradas/salidas digitales: 14
o Entradas analógicas: 6
o Corriente continua por entrada/salida: 40 mA
- General:
o Voltaje de entrada: 5-12 V
o Consumo de corriente: 130 mA
30
Además, posee el módulo integrado ESP8266 que permite la comunicación WiFi,
haciéndolo compatible con las tecnologías 802.11 b/g/n.
Figura 4.19. Arduino UNO WiFi. Fuente: https://docs-emea.rs-online.com/webdocs/14da/0900766b814da22e.pdf.
4.3.5.2 Hardware compatible con Sigfox
Para realizar el envío de datos desde el Arduino UNO, se necesitará el
“Communication Shield”. Esta placa, permite la comunicación entre dispositivos mediante
XBee, Bluetooth, RFID o Sigfox.
Como se ha mencionado, dicha placa es compatible con Arduino UNO, Arduino
UNO WiFi y Arduino DUE, que se utilizará más adelante. Así, el Arduino podrá comunicarse
con el módulo de Sigfox.
Figura 4.20. Communication Shield. Fuente: https://www.cooking-hacks.com/documentation/tutorials/sigfox-connectivity-arduino-raspberry-pi-868mhz-
europe-900mhz-us/.
De este modo, y tras montar todo el hardware, se consigue la compatibilidad.
31
Figura 4.21. Hardware para Arduino con módulo Sigfox. Fuente: https://www.cooking-hacks.com/documentation/tutorials/sigfox-connectivity-arduino-raspberry-pi-868mhz-
europe-900mhz-us/.
4.3.5.3 Programación
La programación del Arduino se realizará a través de “Arduino IDE” (Integrated
Developed Services), un entorno de programación, de código abierto, que permite
fácilmente la escritura de código y su carga en el Arduino.
El módulo de Sigfox posee una librería C++, que permite gestionarlo de una manera
sencilla a través de un conjunto de funciones. Es un sistema de código libre, al que se
podrá acceder a través de Internet [5].
Para utilizar las funciones a alto nivel, se debe descargar la librería, se debe
descomprimir e incluirla en el directorio de librerías de “Arduino IDE” (“My Documents\
Arduino\libraries”), además de incluirla en los códigos con “#include <arduinoSigfox.h>”.
En el código, se debe utilizar una de las funciones para activar el módulo Sigfox al
iniciar el Arduino, y. posteriormente, se podrá enviar una cadena de caracteres, con un
máximo de 24 bytes.
32
Se procede a transmitir desde el sensor los siguientes parámetros enteros.
Decimal entero Hexadecimal Parámetro
3025 0BD1 Temperatura
4025 0FB9 Presión
30 1E Ruido máximo
40 2E Ruido mínimo
Tabla 4.2. Parámetros enviados con Arduino UNO.
Se configura el Callback para que pueda reenviar los parámetros enteros. Primeros
16 bits para temperatura, segundos 16 para presión, siguientes 8 para frecuencia máxima,
y últimos 8 para frecuencia mínima.
Figura 4.22. Callback para el envío de parámetros de Arduino UNO.
El mensaje que llega a la nube se decodifica y se realiza la redirección al servidor
web con los datos recogidos.
Una vez se ha ejecutado el código de envío de la cadena, se comprueba si ha
llegado el mensaje, en el apartado 4.3.5.4.
4.3.5.4 Mensajes recibidos por Sigfox
Se comprueba si realmente se ha recibido y redirigido el mensaje por el Backend
de Sigfox.
Figura 4.23. Mensaje enviado por Arduino UNO.
URL
33
Se puede comprobar en la figura que se realiza un reenvío al servidor con la
temperatura, presión, ruido máximo y ruido mínimo, enviados en el sistema hexadecimal
por el Arduino.
4.3.5.5 Envío de parámetros recogidos por sensores
Mediante los pines analógicos del Arduino, se recogen valores entrantes de voltaje
entre 0 y 5 V, que se transforman en valores enteros de entre 0 y 1023 unidades.
Se realizará una trasformación de esos valores enteros, de entre 0 y 1023, para
obtener el valor real de los parámetros medioambientales, que posteriormente serán
enviados a SIgfox.
El conexionado de sensores se realizará de la siguiente manera:
Figura 4.24. Conexionado de sensores en Arduino.
Se probará un código en el que cada 3 segundos se leerá información mediante los
sensores, y se almacenará. A las 3 iteraciones (9 segundos) realizará la media de los
valores tomados, la codificará, y enviará a Sigfox.
34
Figura 4.25. Datos recogidos por Arduino y enviados a Sigfox.
Se configurará el Backend para que se reenvíe la temperatura como parámetro “p”,
y la intensidad lumínica como parámetro “t”, acompañados de dos enteros constantes de
prueba, que serán “rmax” y “rmin”.
Figura 4.26. Mensaje con parámetros medioambientales enviado por Arduino.
URL
35
4.3.6 Arduino DUE
4.3.6.1 Características
Este microcontrolador es similar al Arduino UNO, pero posee una mayor potencia,
lo que lo hace perfecto para su uso en las WSN.
Características:
- Microcontrolador: AT91SAM3X8E
- Voltaje al que funciona: 3.3 V
- Voltaje de entrada recomendado: 7-12 V
- Pines digitales de entrada/salida: 54
- Pines de entrada analógicos: 12
- Pines de salida analógicos: 2
- Corriente continua de salida en las líneas de entrada/salida: 130 mA
- Memoria Flash: 512 KB
- SRAM: 96 KB
- Frecuencia de reloj: 84 MHz
Figura 4.27. Arduino DUE. Fuente: https://store.arduino.cc/arduino-due.
4.3.6.2 Hardware compatible con Sigfox
Para la preparación del hardware, el conexionado del Shield de comunicación y el
del módulo de Sigfox es igual al del Arduino UNO, así como el acoplamiento de sensores
ya que posee los mismo pines que este.
4.3.6.3 Programación
La librería Sigfox y el propio Arduino UNO utilizan las librerías “arduino-api”. El
Arduino DUE, al tener distinta arquitectura que el Arduino UNO, no puede ejecutar
correctamente las librerías.
Para utilizar el mismo código que el Arduino UNO, algunas de las librerías de
“arduino-api”, se deben comentar para el Arduino DUE.
36
- En arduinoClasses.h se debe comentar la línea “#include <avr/sleep.h>”, que
permite al Arduino UNO dormir mientras no trabaja, para ahorrar energía. Debido a
su arquitectura, al Arduino DUE no se le permite ese ahorro.
- En arduinoUtils.h se debe comentar la línea “#include <avr/eeprom.h>”, que hace
referencia al tipo de memoria flash del Arduino UNO. Como ya se ha comentado, el
Arduino DUE tiene distinta arquitectura, por lo que esta memoria no existe.
En cuanto al código del programa, se compila perfectamente y permite enviar
información a Sigfox de la misma manera.
4.3.6.4 Sonómetro integrado
En el grupo de investigación de Ingeniería de Sistemas Telemáticos (TIC-220), se
ha desarrollado un código para Arduino DUE en el que se toman valores de un sonómetro,
que permite calcular el nivel de señal de una zona.
En este proyecto, se ha integrado el código de dicho Arduino, junto con el código
que posibilita el envío de datos codificados en hexadecimal a Sigfox.
Simplemente se ha introducido el decimal con punto flotante resultado de realizar
la media de la intensidad de ruido, en las funciones que lo codifican en hexadecimal,
obteniendo así su valor representado mediante la norma IEEE 754.
Tras unas medidas recogidas por el sonómetro, se calcula la media del nivel de
señal de ruido, obteniendo 47.6 db. Se codifica el valor mediante la norma IEEE 754, y se
envía a Sigfox junto con otros datos enteros, que no son necesarios para este ejemplo.
En el Callback, se le indica que los primeros 32 bits pertenecen a la media de ruido,
y que corresponden con el parámetro “p”.
Se puede observar el correcto envío de datos a Sigfox, y al servidor del Backend.
Figura 4.28. Mensaje enviado por Arduino con sonómetro.
URL
37
4.3.6.5 Consumo de Arduino UNO y Arduino DUE
Para obtener el consumo del Arduino UNO, se debe medir la intensidad de corriente
eléctrica que pasa por el cable USB con el que se programa, que es USB tipo A, conectado
al PC mediante USB tipo B, que lo alimenta a 5V.
En el estándar de “Universal Serial Bus”, se puede observar que el cable rojo
pertenece a la alimentación de 5 V, el negro a tierra, y los otros dos permiten la transmisión
de datos.
Se cortará el cable para conectar solo alimentación y tierra, haciendo que pase la
corriente por un amperímetro.
Figura 4.29. Medida de corriente que demanda Arduino UNO.
El Arduino UNO consume 160 – 170 mA cuando no transmite, y 230 – 240 mA
durante 5 segundos al transmitir con la antena de Sigfox.
El Arduino DUE se alimenta mediante un USB tipo mini, conectado a un USB tipo
B, que lo alimenta.
Figura 4.30. Medida de corriente en Arduino DUE.
El Arduino DUE consume 150 mA cuando no transmite, y 210 – 220 mA al transmitir.
4.3.6.6 Mejorar eficiencia de Arduinos
Como ya se ha explicado anteriormente, no es posible dormir el Arduino DUE para
ahorrar energía, por lo que no se puede obtener un consumo más eficiente. De esta
manera, solo se perseguirá el ahorro de energía en el Arduino UNO.
Para ello, se utilizará una de las librerías que permite dormir a esta última placa,
“Low-Power” [7], para poder comprobar si resulta más eficiente dormirlo cuando no
transmite a Sigfox. Mediante la librería, se le permite dormir, utilizando una función, con un
tiempo máximo de 8 segundos.
38
Si al Arduino UNO se le añade un retardo de 3 segundos en su código antes de
enviar a Sigfox y un tiempo de sueño de 8 segundos, la respuesta del consumo será,
atendiendo a la corriente demandada por el módulo y a la tabla 4.1, que figuran en el punto
4.3.2:
o 11 segundos a 160 mA (normal).
o 5 segundos a 220 mA (transmitiendo).
o 8 segundos a 140 mA (sueño).
Existen 24 segundos entre mensajes.
Consumo = 140∗8 + 220∗5+160∗11
24 𝑠= 165.83
𝑚𝐴
𝑠
Si en su código no se activará el sueño del Arduino:
o 9 segundos a 160 mA (normal).
o 5 segundos a 220 mA (transmitiendo).
Existen 14 segundos entre mensajes.
Consumo = 220∗5+160∗9
14 𝑠= 181.42
𝑚𝐴
𝑠
Como no hay prácticamente ahorro de energía, debido a que se trata de un módulo
de Arduino con mayores capacidades de computación que los módulos que ahorran
bastante energía durmiendo, como es el caso de Arduino Mega, no se seguirá intentando
disminuir su consumo. Con esta última placa el ahorro es más significativo, si bien no posee
las características de computación que se buscan para el procesado de los datos
recolectados.
4.3.7 Waspmote
4.3.7.1 Características
Waspmote es una placa programable diseñada para WSN de baja potencia. Su uso,
junto con Sigfox, permite una gran durabilidad de los sensores para la recogida de
parámetros medioambientales.
Características:
- Microcontrolador:
o Microcontrolador: ATmega1281
o Memoria Flash: 128 KB
o SRAM: 8KB
o EEPROM: 4 KB
o Frecuencia de reloj: 32 KHz
o Entradas/salidas digitales: 8
o Entradas analógicas: 7
- General:
39
o Voltaje al que opera:
Con batería: 3.3 – 4.2 V
En carga mediante USB: 5 V
o Consumo de corriente:
Encendido: 17 mA
Durmiendo: 30 μA
Figura 4.31. Waspmote. Fuente: http://www.libelium.com/downloads/documentation/waspmote_datasheet.pdf.
Waspmote posee varios sockets que permiten su compatibilidad con numerosos
módulos de comunicación, como WiFi, Bluetooth o Sigfox.
4.3.7.2 Hardware compatible con Sigfox
Para el envío de datos a Sigfox desde el Waspmote, simplemente es necesario
conectar el módulo del proveedor al socket 0, o al socket 1, mediante una placa de
expansión.
Figura 4.32. Sockets de Waspmote.
40
De esta forma, el dispositivo final para enviar a Sigfox, queda de la siguiente
manera:
Figura 4.33. Hardware para Waspmote con módulo Sigfox. Fuente: https://www.cooking-hacks.com/documentation/tutorials/sigfox-connectivity-arduino-raspberry-pi-868mhz-
europe-900mhz-us/.
4.3.7.3 Programación
La librería Sigfox para Waspmote se denomina WaspSigfox, por lo que se debe
añadir al principio del código con “#include <WaspSigfox.h>”. Permite el uso de las mismas
funciones que “ArduinoSigfox” [9].
Para el envío de datos desde Waspmote, hay que realizar unos cambios en el
código con respecto al Arduino, ya que Waspmote trabaja en el lenguaje de programación
C y no existe el tipo “String”, sino “char[]”. Por tanto, se debe modificar todo el código (desde
las funciones para enviar información a Sigfox, hasta las funciones que transforman los
valores decimales en sistema hexadecimales) para que permita su ejecución.
41
Una vez actualizado el código, se enviará:
Decimal Hexadecimal Parámetro
28.51 41e4147b Temperatura
5852.34 45b6e2b8 Presión
65 41 Ruido máximo
42356 a574 Ruido mínimo
Tabla 4.3. Parámetros enviados por Waspmote.
Al concatenar todas las cadenas hexadecimales, en total, se envían 22 caracteres:
“a5744141e4147b45b6e2b8”.
4.3.7.4 Mensajes recibidos por Sigfox
En el Callback, se tiene configurado lo siguiente:
temperatura::float:32 presion::float:32 rmax::uint:8 rmin::uint:16
En la URL para la redirección se ha definido lo siguiente:
http://servidor/rdin.php?t={customData#temperatura}&p={customData#pres
ion}&rmax={customData#rmax}&rmin={customData#rmin}
El mensaje que se reenvía es:
Figura 4.34. Mensaje enviado por Waspmote a Sigfox.
Se puede observar que decodifica bien los parámetros de temperatura (28.51),
presión (5852.34), ruido máximo (65) y ruido mínimo (42356).
4.3.7.5 Librería WString
Incluimos la librería “WString” de Arduino, para ejecutar el código utilizando cadenas
String, permitiendo trabajar más fácilmente con cadenas de caracteres. Para ello,
simplemente se debe incluir la librería en el directorio de librerías, e invocarla en el código
del Waspmote. Así el código de programación de esta placa podrá ser el mismo que el que
posee el Arduino.
URL
42
4.3.7.6 Envío de parámetros recogidos por sensores
El proceso de conexionado es similar al Arduino, pero teniendo en cuenta las
siguientes entradas del Waspmote:
Figura 4.35. Pines de entrada y salida de Waspmote. Fuente: http://www.libelium.com/uploads/2013/02/waspmote-utilities-programming_guide.pdf.
De esta manera, el conexionado final quedará de este modo:
Figura 4.36. Conexionado de sensores en Waspmote.
43
Se realizarán las mediciones cada 3 segundos, se almacenarán, y, a las 5
iteraciones, se realizará la media, codificará y enviará a Sigfox.
Figura 4.37. Datos recogidos por Waspmote y enviados a Sigfox.
Se enviarán codificadas la temperatura como parámetro “p”, y la intensidad lumínica
como parámetro “t”, acompañados de dos enteros constantes, que serán “rmax” y “rmin”.
Figura 4.38. Datos de sensores de Waspmote recogidos por Sigfox.
URL
44
4.3.8 Raspberry
4.3.8.1 Características
Raspberry es una placa que posee la potencia de un ordenador en un tamaño
comprimido. Dicho dispositivo permite la recolección y procesado de datos con una
potencia mayor que la que posee, por ejemplo, Arduino UNO.
Características:
- Procesador:
o Broadcom BCM2387
o Frecuencia de reloj: 1.2 GHz
o 4 Núcleos ARM Cortex-A53
o Soporte para 802.11 b/g/n Wireless LAN y Bluetooth 4.1
- Memoria: 1 GB LPDDR2
- Sistema operativo: Versión de Linux corriendo en una tareta micro SD
- Salido de vídeo y audio HDMI.
- Salida de audio Jack de 3.5 mm.
- Conector de display DSI.
- Entradas USB 2.0.
- Alimentación: Micro USB a 5V y 2,5 A.
- 10/100 BaseT Ethernet socket
- Conector GPIO: 27 pines de entrada y salida con líneas de alimentación a 3,3V, 5
V y tierra.
Figura 4.39. Raspberry Pi 3. Fuente: http://docs-europe.electrocomponents.com/webdocs/14ba/0900766b814ba5fd.pdf.
45
4.3.8.2 Hardware compatible con Sigfox
Para el envío de datos a Sigfox a través de la Raspberry Pi 3, es necesario el uso
de un puente de conexión entre esta y Arduino, ya que no existe otra manera de conectar
el módulo Sigfox.
Figura 4.40. Puente de conexión entre Raspberry Pi y Arduino. Fuente: https://www.cooking-hacks.com/documentation/tutorials/sigfox-connectivity-arduino-
raspberry-pi-868mhz-europe-900mhz-us/.
A través de esta placa de compatibilidad, se puede conectar el módulo de Sigfox y
realizar un programa con el que se podrá enviar información a través de él.
Figura 4.41. Hardware para Raspberry Pi 3 con módulo Sigfox. Fuente: https://www.cooking-hacks.com/documentation/tutorials/sigfox-connectivity-arduino-
raspberry-pi-868mhz-europe-900mhz-us/.
46
La idea de esta placa es la de permitir usar cualquier Shield compatible con Arduino
en la Raspberry Pi, así como usar sensores analógicos o digitales, con las mismas salidas
de pines que posee el Arduino, pero con la potencia y capacidades de la Raspberry.
4.3.8.3 Programación
Para permitir esta compatibilidad, Libelium ha desarrollado la librería “arduPi”, que
permite a la Raspberry usar el mismo código que Arduino. En esta librería, se implementan
funciones de conversión para que se pueda controlar las interfaces de entrada/salida como
en Arduino (i2C, SPI, UART, analog, digital, etc).
Antes de su programación se deberán activar las interfaces que usará el código del
Arduino. Para ello, se deben seguir los siguientes pasos [6]:
1. Abrir un terminal.
2. Ejecutar:
>>nano /boot/config.txt
3. Añadir unas líneas al archivo:
dtoverlay=pi3-miniuart-bt
enable_uart=1
dtparam=spi=on
dtparam=i2c_arm=on
4. Guardar archivo
5. Ejecutar:
>>nano /boot/cmdline.txt
6. Eliminar los parámetros que referencian al puerto serial de UART (ttyAMA0)
7. Guardar archivo
8. Actualizar el sistema operativo
9. Reiniciar Raspberry Pi 3
Ahora se deberá usar la librería “arduPi”. Para ello, se ejecutarán los siguientes
comandos en la Raspberry [3]:
1. Es importante situarse en el mismo directorio para descargar todas las librerías.
>> cd /home/pi
2. Se descarga e instala la librería arduPi para Raspberry Pi 2, que es también
compatible con Raspberry Pi 3.
>> wget http://www.cooking-hacks.com/media/cooking/images/documentat
ion/rasp berry_arduino_shield/raspberrypi2.zip && unzip raspberrypi2.zip &&
cd cooking/arduPi && chmod +x install_arduPi && ./install_arduPi && rm
install_arduPi && cd ../..
47
3. Se descarga e instala también la librería para Sigfox.
>> wget http://www.cooking-hacks.com/media/cooking/images/documenta
tion/tutorial_kit_sigfox/arduPi_api_Sigfox_v1_2.zip && unzip -u
arduPi_api_Sigfox _v1_2.zip && cd cooking/examples/Sigfox && chmod +x
cook.sh && cd ../../..
Si se han ejecutado correctamente los comandos, el directorio raíz “/home/pi/
cooking”, debe contener las siguientes carpetas:
- “arduPi”: Contiene las librerías necesarias para ejecutar el código de Arduino en
Raspberry.
- “arduPi-api”: En esta carpeta residen las librerías que necesita Arduino para su
funcionamiento (“arduPiClasses”, “arduPiMultiprotocol”, “arduPiUART” y
“arduPiUtils”).
- “libraries/arduPiSigfox”: Contiene la librería de Sigfox para Arduino
(“arduPiSigfox”), con la que se podrá activar el módulo Sigfox y enviar a la nube.
- “examples/Sigfox”: Contiene ejemplos de códigos básicos para enviar datos a
Sigfox. Desde aquí se deben compilar los códigos de los programas que se desean
ejecutar en la Raspberry, ya que contiene el archivo “cook.sh”, que permite
compilarlos junto con las librerías.
Hay que asegurarse de que dentro de la carpeta “cooking”, se encuentran las
carpetas “arduPi” y “Sigfox”. Si el comando para instalar la librería Sigfox no se ejecuta en
la ruta “/home/pi”, y se realizara en “/home/pi/cooking”, por ejemplo, se crearía otra carpeta
“cooking” raíz, que contendría la librería Sigfox y sus ejemplos, lo que impediría ejecutar
correctamente el código.
El proceso para compilar un ejemplo.cpp
>>./cook.sh ejemplo.cpp
El script “cook.sh” compila todas las librerías existentes en los directorios, y el
código, devolviendo el ejecutable “_exe”.
Para ejecutar el ejemplo
>>./ejemplo.cpp_exe
Se utilizará el mismo código que para enviar datos que con Waspmote, con arrays
de caracteres (CHAR[]), pero con algunos cambios para adaptarse a la Raspberry Pi 3, ya
que se producían fallos de compilación y el error “Segmentation Fault”, con el uso indebido
de punteros.
Así, los cambios que se han realizado en el código son los siguientes:
- Definir “strrev”: Esta función permite invertir una cadena de caracteres. Es
necesaria para el correcto funcionamiento de la función programada que convierte
48
un número entero en sistema hexadecimal. No está definida en la librería de ArduPi,
como en Waspmote, por lo que se tendrá que diseñar de manera correcta.
- Errores de compilación: La solución es declarar funciones en el código antes de su
uso. En Waspmote no existía este problema.
- “Segmentation Fault”: El error reside en que no es posible pasar un puntero de tipo
CHAR a una función, por lo que, a veces, intenta acceder a una posición de la
memoria a la que no se tiene acceso. La solución es redefinir arrays de caracteres
con los que se trabajaba, ya que se usaban indebidamente los punteros. Permitía
su ejecución en Waspmote, pero no así con la Raspberry.
En el código se enviarán los siguientes valores:
Decimal Hexadecimal Parámetro
28.51 41e4147b Presión
42356 a574 Ruido máximo
126 7e Ruido mínimo
46 2e Temperatura
Tabla 4.4. Parámetros enviados por Raspberry Pi 3.
Una vez concatenadas las cadenas, en total, se envían 16 caracteres
hexadecimales: “41e4147ba5747e2e”.
4.3.8.4 Mensajes recibidos por Sigfox
En el Backend de Sigfox, se indicará el siguiente Callback:
presion::float:32 rmax::uint:16 rmin::uint:8 temperatura::uint:8
Obteniendo el siguiente mensaje:
Figura 4.42. Mensaje enviado por Raspberry Pi 3.
Se puede observar como el primer parámetro enviado corresponde con un número
flotante, que es 28.51, el segundo, con el ruido máximo que es un entero de 16 bits, cuyo
URL
49
valor es 42356, el siguiente con otro entero, ruido mínimo, pero de 8 bits, con un valor de
126, y el siguiente con otro entero de 8 bits, temperatura, cuyo valor es 46.
4.3.8.5 Intento de uso de librería WString
En este apartado, se ha intentado ejecutar la librería String de Arduino en la
Raspberry Pi, sin éxito.
Se han introducido los códigos de la librería de Arduino (“WString.cpp” y
“WString.h”) en el directorio de librerías de Raspberry Pi “/home/pi/cooking/libraries/
arduPiSigfox”. Dicho directorio contiene las librerías definidas en “cook.sh” para su
compilación.
Primeramente, se ha intentado cambiar el archivo “cook.sh” para que ejecute la
librería “WString.cpp”, pero siempre se producen fallos, ya que es necesario compilar las
librerías en código objeto.
Para ello se ha ejecutado el compilador de C++ que traduce el código fuente
(archivos .cpp) a código objeto (archivos .o), mediante el siguiente comando:
>> g++ -c WString.cpp
Si se consiguiera la librería en código objeto (WString.o) se podría incluir en
“cook.sh” para compilar el programa. Pero se producen errores en múltiples funciones al
ejecutar el compilador. Por lo que es necesaria la adaptación de esta librería para “arduPi”.
Al no compilar bien, quedará enviando datos con arrays de caracteres (char[]), lo
cual no supone ningún problema para la recepción correcta de Sigfox.
4.3.8.6 Envío de parámetros recogidos por sensores
Puesto que se posee la placa de compatibilidad de Raspberry con Arduino, el
conexionado de sensores es igual a este último.
Figura 4.43. Conexionado de sensores en Raspberry.
50
Se recogerán datos de temperatura y de luz cada cierto tiempo. En este ejemplo,
se ha medido una temperatura de 30.3 grados Celsius y una intensidad lumínica de 84 lux.
En el Backend de Sigfox se obtiene el siguiente mensaje:
Figura 4.44. Datos de sensores de Raspberry recogidos por Sigfox.
4.4 Configurar nodos como Gateway
4.4.1 Introducción
Previendo el envío de información desde dispositivos que no posean el módulo de
Sigfox, se ha decidido utilizar varios de ellos para recibir datos desde estos nodos, y así
funcionar como Gateway, reenviando la información a Sigfox.
Para ello, el Gateway recibirá parámetros de los nodos a través de distintas
tecnologías (cuya viabilidad se evaluará), se realizará la media al cabo de unos mensajes
recibidos, se codificarán los valores, y se enviarán a Sigfox.
Figura 4.45. Envío a Sigfox utilizando un Gateway.
URL
51
4.4.2 Waspmote
4.4.2.1 Hardware
Para utilizar Waspmote como Gateway, se configurará uno de sus dos sockets
disponibles, para recibir desde dispositivos a través de Wifi, y el otro para enviar a Sigfox
[10].
Figura 4.46. Sockets de Waspmote.
Al evaluar alternativas, se ha pensado en utilizar distintas tecnologías como
Bluetooth o ZigBee, pero debido a su corto alcance, se hará uso de WiFi.
Para ello, el módulo WiFi-pro permite la comunicación entre dispositivos Waspmote
utilizando esta tecnología. Los protocolos que soporta son UDP, TCP, y HTTP entre otros,
lo que lo hace la opción ideal para el intercambio de información en una red WSN.
Figura 4.47. Módulo WiFi-pro compatible con Waspmote. Fuente: http://www.libelium.com/downloads/documentation/wifi_networking_guide.pdf.
En el Socket 1, se conectará el módulo WiFi-Pro, a través de una placa de
expansión, y al socket 0, se conectará el módulo de Sigfox, directamente sin necesidad de
esta.
52
De tal forma que el dispositivo que actúa como Gateway queda de la siguiente
manera:
Figura 4.48. Módulos conectados a los sockets de Waspmote.
4.4.2.2 Programación
Mediante la librería “WiFiPro” de Waspmote, se activará un punto de acceso WiFi
en el que existirá un servidor TCP esperando conexiones. Se recibirán datos de un cliente
TCP, que se conecta también a través del mismo módulo utilizado.
Figura 4.49. Comunicación utilizando Waspmote Gateway.
53
El problema al incluir las librerías “WiFiPro” y “WaspSigfox”, es que se produce un
error de compilación ya que ambas definen los mismos parámetros para declarar frases de
aceptación y error de mensajes (“AT_OK“ y “AT_ERROR”). Se redefinirán los parámetros
en la librería de Sigfox a “AT_OK3” y “AT_ERROR3”, lo cual solucionará el problema.
Para que cualquiera de ambos dispositivos, tanto el servidor WiFi TCP como el
cliente WiFi TCP, será necesario compilar el código para conectar a una red WiFi, y así se
configurará el módulo WiFi-pro que se unirá al punto de acceso de la red cada vez que se
encienda el dispositivo. Deben compartir la red el servidor y el cliente TCP para comunicar
ambos.
Tras ejecutar el código para unirse a la red WiFi, se puede compilar el código para
crear un servidor TCP. Si el punto de acceso de la red a la que está conectado no le da
acceso (porque tenga filtrado por MAC, por ejemplo), el Waspmote entrará en bucle hasta
que le permita la conexión.
Figura 4.50. Filtrado por MAC activo en el punto de acceso de la red.
Todo ello es debido a que el punto de acceso solo permite la conexión a la red de
aquellos equipos que controla, y el Waspmote no se incluye en la lista, por lo que no se le
permitirá el acceso. De este modo, el dispositivo entrará en bucle encendiendo el módulo
WiFi y autenticándose en la red constantemente hasta conseguir el permiso.
Figura 4.51. Bucle producido en Waspmote al no conectar al AP de la red.
54
Se puede observar cómo, a pesar de autenticarse correctamente en la red, al
intentar unirse al AP, le impide la conexión, y vuelve a repetir el proceso una y otra vez.
Ahora, se desactivará el filtrado por MAC para permitir la conexión del dispositivo.
Figura 4.52. Filtrado por MAC en router de la red desactivado.
Figura 4.53. Configuración de módulo WiFi-pro de Waspmote realizada con éxito.
Una vez unido al punto de acceso de la red, se ejecuta el código del servidor TCP.
El Gateway va guardando datos que le llegan, y cuando recibe varias peticiones, realiza
sus medias y las codifica en hexadecimal. Cada vez que se quiere enviar datos a la nube
mediante el módulo Sigfox, primero se activará, enviará la información y posteriormente se
apagará para evitar el consumo innecesario de energía.
55
Ahora se procederá a comunicar el Gateway de Waspmote con un cliente TCP.
Para ello, se usará un programa que permite la conexión de un cliente a un servidor TCP.
Con el servidor TCP WiFi del Waspmote escuchando, se enviará una petición con el cliente
TCP del ordenador a la IP que posee el Waspmote, y el puerto configurado. Es necesario
que el cliente (PC) y el servidor (Waspmote) se encuentren en la misma red.
Figura 4.54. Conexión WiFi entre servidor TCP en Waspmote y Cliente TCP en PC.
Se enviará desde el cliente, un mensaje TCP de la siguiente manera:
[FLOAT] & [ENTERO<255] & [ENTERO<255] & [ENTERO<65535]
Así, un ejemplo de mensaje enviado puede ser:
Mensaje TCP: 155.56&78&255&26545
Debido a que el servidor TCP del Waspmote ya conoce el tipo y orden de los datos
(por ejemplo, primero temperatura, que es decimal con punto flotante, luego presión, que
es entero de 8 bits, etc), simplemente separará la cadena por el carácter “&”, e irá
almacenándolos en un array hasta que el número de iteraciones llegue al límite. En el
ejemplo expuesto, al recibir dos mensajes, realizará la media de los datos, codificará todos
los parámetros en sistema hexadecimal, y los enviará a Sigfox.
Para dicho envío, se activa el Socket 0, se envían los datos, y se apaga, evitando
tener un consumo constante debido al módulo Sigfox.
Cliente TCP ordenador
Servidor TCP Waspmote
56
En el ejemplo propuesto, se han enviado dos cadenas con el formato especificado
anteriormente, y tras la recepción de los dos mensajes, el servidor realiza las medias y las
envía a Sigfox.
Figura 4.55. Recepción de datos del cliente TCP y envío a Sigfox.
De esta manera, a partir de los parámetros recibidos, se obtiene la siguiente
información.
Mensaje 1 Mensaje 2 Media Hexadecimal
155.56 125.33 140.445 430c71ec
78 25 51 33
255 0 127 7f
26545 25258 25901 652d
Tabla 4.5. Parámetros enviados a Sigfox por Waspmote como Gateway.
Cliente TCP ordenador
Mensaje 1
Conexión de cliente TCP
Mensaje 2
Mensaje 1
Mensaje 2
Envío a Sigfox
57
Una vez concatenadas las cadenas de caracteres, el mensaje que se envía a Sigfox
es “430c71ec337f652d”.
Figura 4.56. Envío a Sigfox de Waspmote Gateway.
4.4.2.3 Waspmote como cliente TCP
Una vez configurado el servidor TCP WiFi, es necesario crear el cliente Waspmote.
Para ello, se implementará de la misma manera, activando el socket donde se encuentre
el módulo WiFi-Pro para la comunicación a través de WiFi.
Esta vez, solo se usará el socket 0 para el módulo WiFi-Pro, aunque se puede
cambiar en el código al socket 1, en el caso de que se quiera utilizar con la placa de
expansión.
En el código, se indicará la dirección del servidor TCP y su puerto. En este caso, el
PC con la aplicación socket hará de servidor, por lo que se comprueba su IP en la red, y
se incluye en el código.
Para permitir que el Waspmote se conecte al servidor TCP del PC, se deberá
desactivar el firewall de Windows del ordenador de tal forma que posibilite las conexiones
entrantes.
URL
58
Se prueba el código para comprobar que se conecta bien y envía correctamente el
mensaje en el formato especificado en el punto anterior.
Figura 4.57. Conexión WiFi entre cliente TCP en Waspmote y servidor TCP en PC.
4.4.3 Arduino DUE
4.4.3.1 Intento de Gateway con WiFi-Pro
Se ha intentado utilizar el módulo WiFi-Pro de Waspmote para el Arduino Due. De
esta manera, se obtendrían por WiFi los datos de un dispositivo sin módulo de Sigfox, y el
Arduino DUE los enviaría a la nube. Pero tal supuesto no es viable, ya que la librería
“WiFiPro” es incompatible con Arduino. Solo es compatible con Waspmote.
4.4.3.2 Intento de Gateway con Shield Multiprotocolo
A su vez, se ha pensado en utilizar, como con Waspmote, dos socket, uno para un
módulo WiFi que fuera compatible con el Arduino, y otro para el módulo de Sigfox.
El Shield Multiprotocolo, compatible con Arduino, permite el uso de dos sockets, por
lo que se podría obtener información de un nodo, a través de un módulo WiFi conectado a
uno de ellos, y enviarlo a la nube, a través del módulo Sigfox conectado al otro socket [11].
Figura 4.58. Shield Multiprotocolo. Fuente: https://www.cooking-hacks.com/documentation/tutorials/multiprotocol-shield-connect-two-xbee-connector-
arduino-raspberry-pi-galileo/.
Servidor TCP ordenador
Cliente TCP Waspmote
Mensaje recibido por cliente
59
Debido a la inexistencia de una librería Sigfox compatible con este Shield, se
descarta su uso. La librería Sigfox que proporciona Libelium solo es compatible con el
Shield de comunicación, como se ha visto anteriormente.
4.4.3.3 Intento de Gateway con Ethernet
La otra manera de conseguir que el Arduino Due actúe como Gateway es mediante
Ethernet. De este modo, podría recibir información de algún dispositivo a través de
Ethernet, y el Arduino lo podría reenviar a Sigfox.
Figura 4.59. Shield Ethernet. Fuente: https://electronilab.co/tienda/ethernet-shield-con-wiznet-w5100-internet-para-arduino/.
Esta opción se descarta, ya que es necesario el uso del ISCP (mediante el que se
pueden comunicar el Arduino y el Shield) para la placa Ethernet y la de comunicación que
utiliza Sigfox, siendo imposible apilarlos.
Figura 4.60. Uso del ISCP en Shields de Arduino.
60
Como se puede observar en la figura, el uso del ISCP del Arduino solo se permite
para un Shield, y es el medio por el que el Arduino y este, se comunican. Si se intentara
apilar otro Shield, no existe medio de conexión con el ISCP.
4.4.4 Arduino UNO WiFi
4.4.4.1 Intento de servidor TCP
En este epígrafe, el objetivo era conseguir la transmisión de información vía WiFi
mediante mensajes TCP, para permitir su uso junto con el Cliente TCP Waspmote. Para
ello, se han buscado varias librerías WiFi que permitieran el envío de datos mediante TCP,
pero ninguna es compatible con Arduino UNO WiFi.
Debido a que dicho Arduino tiene integrado el módulo WiFi, puede recibir datos
mediante esta tecnología sin necesidad de un módulo, siendo solo necesario conectar el
Shield de Sigfox para el reenvío de datos en caso de que se quiera remitir la información
que le llega a través de WiFi.
En la búsqueda de librerías compatibles con Arduino UNO WiFi, solo la librería
“Arduino_Uno_WiFi_Dev_Ed_Library” [12] lo es, la cual solo permite el envío de datos a
través de HTTP.
HTTP funciona sobre TCP, pero los mensajes son peticiones que se realizan al
servidor, mediante una URL, por lo que dichos mensajes no son configurables como lo
eran con Waspmote. Esta librería está configurada de tal manera que lo único que se puede
modificar del mensaje a enviar es el método HTTP, la URL del servidor web, y la dirección
de este.
Se ha intentado modificar la librería para conseguir el envío de un mensaje TCP,
sin montar una petición HTTP, pero no ha sido posible.
4.4.4.2 Envío de datos a Sigfox mediante servidor web
4.4.4.2.1 Configuración de la red
Como en Waspmote, para el uso de un cliente web y un servidor web a través de
WiFi, ambos deben ubicarse en la misma red. Así, el punto de acceso de esta, podrá
reenviar todos los paquetes que le llegan a sus correspondientes equipos en la red.
La librería tampoco permite la conexión mediante funciones a un punto de acceso
o la asignación de una IP al dispositivo para el envío o recepción de datos, por lo que se
deberá conectar el Arduino a través de su configuración.
61
En dicho Arduino, se debe indicar la red a la que se conecta a través de su servidor
web integrado. Para ello, es necesario que el equipo desde el que se vaya a configurar, se
conecte a su red:
Figura 4.61. Conexión a la red del Arduino UNO WiFi.
Posteriormente, se accede mediante un navegador a http://192.168.240.1, donde
se ubica su servidor web de configuración, para modificar esta [13].
Figura 4.62. Página de configuración del servidor web integrado del Arduino UNO WiFi.
El objetivo es que un cliente se conecte al servidor web del Arduino UNO WiFi que
recoge datos para reenviarlos a Sigfox.
Figura 4.63. Comunicación utilizando Gateway Arduino UNO WiFi.
62
Para lograr la conexión, los clientes Arduino UNO WiFi, deberán conectarse a la
misma red del Gateway. Perfectamente pueden acceder a la red del Arduino UNO WiFi
que funcionará como Gateway y así ubicarse en la misma red. En el Gateway no es
necesaria la configuración para que se conecte a ningún punto de acceso, ya que, se
encontrará en la misma red que sus clientes, si estos se conectan a él.
Aunque en su página de configuración se pueda cambiar la dirección IP a estática,
el Arduino no permite el envío de datos punto a punto; es necesaria la conexión a una red
para que el punto de acceso de esta realice el envío de mensajes.
Figura 4.64. Configuración de IP estática en Arduino UNO WiFi.
4.4.4.2.2 Servidor web y envío a Sigfox
Una vez se ha implementado el código en el Gateway, se podrán recibir peticiones
desde cualquier cliente HTTP que se encuentre en su red. Para ello, desde un navegador,
se puede escribir la URL para enviar datos, con el formato:
http:// [dirección del servidor web] / arduino / digital / [dato 1] & [dato 2] & [dato 3] &
[dato 4]
Por ejemplo: http://192.168.240.1/arduino/digital/45.5&432432&234&23
Figura 4.65. Envío de datos mediante cliente HTTP.
Y el Gateway podrá recibir correctamente la información a través de una petición
HTTP con el método GET, donde se incluirán los parámetros cuyo orden y tipo conocerá.
Por el ejemplo, el Gateway se ha programado para reconocer el dato 1, como temperatura
y float, el dato 2, como entero de 8 bits, etc.
63
Pero si se incluye la parte de envío de datos a Sigfox, aparece el siguiente
problema:
Figura 4.66. Problemas de estabilidad en Arduino Uno WiFi.
La memoria RAM que utiliza el Arduino para el código programado, es de un 83%
de 2048 Bytes. Se recomienda el uso de una memoria dinámica de entre el 70 y 75% para
la ejecución correcta del código sin que se produzcan errores. Con más de un 75% de
ocupación de la RAM, se puede incluir el código en el Arduino, pero se producirán errores
inesperados, pudiendo no ejecutar algunas líneas y provocando un funcionamiento
inestable.
Para ello, se ha reestructurado el código, haciéndolo más eficiente. Y se ha
conseguido:
Figura 4.67. Problemas de estabilidad en Arduino Uno WiFi tras eficiencia del código.
La memoria RAM pasa a un 80%, pero si se realizan pruebas, se siguen
produciendo errores.
Se ha seguido optimizando el código, eliminando las funciones que no se utilizan
de la librería Sigfox, y dejando las imprescindibles para activar el módulo, enviar datos, y
apagarlo. Con esto, se consigue el siguiente rendimiento:
Figura 4.68. Problemas de estabilidad en Arduino Uno WiFi tras eliminar funciones innecesarias de librería Sigfox.
El consumo de RAM todavía es alto, por lo que continua sin ejecutarse bien,
produciéndose errores. En este caso, el servidor debe recoger los parámetros transmitidos
por el navegador en la URL, y enviarlos de vuelta para que aparezcan en el cliente, pero
no muestra todos los datos recibidos:
Figura 4.69. Fallo en comportamiento del servidor (solo envía un parámetro al cliente).
64
Puesto que es recomendable bajar del 75% de ocupación de RAM, se evitará el
procesado de los datos enviados por los nodos al Gateway, limitándose a reenviar a Sigfox
la cadena que le llegue. De esta manera, se persigue un reparto de carga, dejando el
procesado y codificación de datos al cliente, y solo el envío al servidor.
Para ello, los clientes tienen que haber hecho ya las medias de los datos y la
codificación a hexadecimal. En la URL se enviará lo siguiente:
http:// [dirección del servidor web] / arduino / digital / [hex 8 caracteres] [hex
2 caracteres] [hex 2 caracteres] [hex 4 caracteres]
Por ejemplo: http://192.168.240.1/arduino/digital/ab04f11176faa010
El servidor se limitará a recoger la cadena que le llega y reenviarla a Sigfox,
eliminando toda ejecución de separación de datos en la cadena, almacenamiento de los
parámetros, cálculo de medias cuando se reciben varios mensajes y codificación de los
resultados en sistema hexadecimal.
Así se consigue que el Arduino se encuentre en un 75% de su uso de RAM, y
permitirá remitir la información a Sigfox correctamente. A pesar de lo cual sigue dando
aviso de error, si bien su funcionamiento es más estable.
Figura 4.70. Uso de RAM dentro de límites para el correcto funcionamiento.
Se realiza una prueba para el envío:
Figura 4.71. Envío de cliente web tras optimización
Hexadecimal Decimal
ab04f111 -4.723037E-13
76 118
fa 250
a010 40976
Tabla 4.6. Parámetros enviados a Sigfox por Arduino UNO WiFi como Gateway.
65
En el Backend de Sigfox se obtienen los datos correctamente:
Figura 4.72. Mensaje recibido en Backend de Sigfox.
4.4.4.3 Cliente HTTP Arduino UNO WiFi
El cliente se encarga de realizar las medias de los datos recogidos y enviarlos, ya
codificados, al Gateway, para reducir su carga de trabajo.
Para comprobar que los datos se transmiten correctamente, se ha creado un
servidor web sencillo con el framework Spring y se pondrá en funcionamiento el servidor
escuchando en el puerto 8081.
Puesto que la librería de WiFi de este Arduino tiene configurado el puerto por
defecto para HTTP (80), se realizará una modificación en el script “rest.cpp”, del cual hace
uso la librería. En dicho archivo, se cambiará el puerto al 8081, para que envíe la petición
HTTP, por defecto, a él.
El Arduino se programará para tomar datos y almacenarlos cada 10 segundos. A
las 3 iteraciones (30 segundos), se calcularán las medias de las variables, se codificarán
en sistema hexadecimal y se enviarán al servidor, concatenadas, para que este solo se
limite a reenviarlas.
URL
66
Para la prueba del envío de datos con el cliente web Arduino Uno WiFi y el
ordenador con el servidor web, se han situado ambos equipos en la misma red, con el
firewall del ordenador desactivado para permitir conexiones entrantes.
Figura 4.73. Envío de datos mediante cliente web Arduino Uno WiFi y recepción mediante servidor web en ordenador.
Los datos que son recibidos por el servidor web y que se reenviarían a Sigfox son:
Decimal Hexadecimal
28.51 41e4147b
255 ff
51 33
65535 ffff
Tabla 4.7. Parámetros enviados por cliente web Arduino a Gateway.
En el Backend de Sigfox se indicaría el tipo y número de bits que pertenecen a cada
uno de los valores, como se ha visto en los Callbacks anteriormente.
Medias de datos recogidos
URL enviada a servidor web Recepción de URL en servidor
67
4.4.4.4 Cliente HTTP Waspmote
Debido a la posibilidad de conectar el Waspmote a cualquier red y el uso de librerías
para enviar datos, como cliente web, mediante HTTP, se implementará el dispositivo para
permitir su funcionamiento junto con el Gateway Arduino UNO WiFi.
Figura 4.74. Comunicación con Sigfox usando Gateway Arduino UNO WiFi y cliente Waspmote.
Para su funcionamiento, se realizará lo siguiente:
- Configurar módulo WiFi-Pro de Waspmote para que se conecte al punto de acceso
de la red del Gateway Arduino UNO WiFi.
- Se utilizará la función de las librerías que permite enviar una petición HTTP,
mediante el método GET, enviando la cadena de caracteres que se quiere enviar a
Sigfox.
4.4.5 Raspberry
4.4.5.1 Hardware
Para utilizar Raspberry como Gateway, se configurará su módulo WiFi integrado
para aceptar mensajes TCP desde dispositivos a través de Wifi, y el módulo de Sigfox para
enviar a la nube. De esta manera, el dispositivo final quedará como en la figura 4.41.
4.4.5.2 Programación
Haciendo uso de un código en C para ejecutar un servidor TCP que acepta
mensajes a través de WiFi, e integrándolo con el código que envía datos a Sigfox, se
programará la Raspberry como un Gateway, que recogerá datos a través de WiFi, y así
permitir su remisión a Sigfox.
68
Figura 4.75. Comunicación utilizando Raspberry Gateway.
El Gateway se encargará, como en el caso de Waspmote, de recibir un mensaje
TCP en el mismo formato que se enviaba con el Gateway Waspmote, realizará las medias
de los valores a las varias iteraciones, las codificará, para enviar a Sigfox.
Se procederá a comunicar el un cliente TCP con el Gateway para probar el envío a
Sigfox. Para ello, se usará el programa que permite la conexión de un cliente a un servidor
TCP. Con el servidor TCP WiFi de la Raspberry escuchando, se enviará una petición con
el cliente TCP del ordenador a la IP que posee la Raspberry, y el puerto configurado. Es
necesario que el cliente (PC) y el servidor (Raspberry) se encuentren en la misma red.
Se enviará desde el cliente, un mensaje TCP de la siguiente manera:
[FLOAT] & [ENTERO<65535] & [ENTERO<255] & [ENTERO<255]
Así, un ejemplo de mensaje enviado puede ser:
Mensaje TCP: 158.15&15151&23&48
Debido a que el servidor TCP de la Raspberry ya conoce el tipo y orden de los
datos, simplemente separará la cadena por el carácter “&”, e irá almacenándolos en un
array hasta que el número de iteraciones llegue al límite. En el ejemplo expuesto, se
realizará la media al cabo de dos mensajes, los codificará y enviará a Sigfox. El módulo
Sigfox se activará solo para su envío.
69
Figura 4.76. Conexión WiFi entre cliente TCP en PC y servidor Rasperry.
De esta manera, a partir de los parámetros recibidos, se obtiene la siguiente
información.
Mensaje 1 Mensaje 2 Media Hexadecimal
146.89 158.15 152.52 4318851f
25562 15151 20356 4f84
99 23 61 3d
23 48 35 23
Tabla 4.8. Parámetros enviados a Sigfox por Raspberry como Gateway.
Una vez concatenadas las cadenas de caracteres, el mensaje que se envía a Sigfox
es “4318851f4f843d23”.
Figura 4.77. Envío a Sigfox de Raspberry Gateway.
Cliente TCP ordenador
Servidor TCP Raspberry
URL
Mensaje 1 TCP
Mensaje 2 TCP
70
4.5 Servidor propietario
4.5.1 Introducción
El servidor que se usará para recoger los datos que provienen de Sigfox será un
servidor web. El Backend de Sigfox, cada vez que reciba información, enviará las variables
de los sensores y el identificador del módulo que los ha transmitido, en una petición HTTP
al servidor web configurado.
La función a realizar es modificar el servidor web, que ha programado el grupo de
investigación de Ingeniería de Sistemas Telemáticos (TIC-220), para que acepte las
peticiones provenientes de Sigfox y poder almacenar las medidas que ha recolectado un
dispositivo, así como modificar algunas vistas para la visualización del identificador Sigfox
en los sensores que lo posean.
La siguiente URL es la que transmite Sigfox al Backend propietario deseado:
http://servidor/rdin.php?isig={valor}¶metro1={valor}&...¶metroN={valor}
Como el servidor solo acepta peticiones mediante un identificador propio, que sitúa
a los sensores geográficamente (por ejemplo, “Calle_a”), hay que modificar tanto el script
que recibe la petición HTTP de Sigfox, como la base de datos para que acepte las nuevas
medidas.
4.5.2 Insertar medidas de Sigfox
En este apartado, se explicará la lógica de la base de datos que ha implementado
el grupo de investigación TIC-220. Una vez comprendida, se procederá a su modificación
para que acepte medidas provenientes de Sigfox.
En el servidor web existe una tabla que permite almacenar información de los
sensores y si se encuentran activos, denominada “Sensores”, así como una tabla que
identifica las variables a recoger (temperatura, ruido máximo, presión, etc), cuyo nombre
es “Variables”. La tabla “Sondas”, almacena los identificadores de sensores e
identificadores de variables, indicando para cada dispositivo, las variables que están
activas para aceptar datos. Si se envía una medida de un sensor cuya variable no está
activa, no será aceptada.
Por ejemplo, para el sensor “Calle_aaa”, el identificador es 53:
71
Figura 4.78. Tabla “sensores”.
Para el sensor 53, que es “Calle_aaa”, están activas las variables 6 y 7:
Figura 4.79. Tabla “sondas”.
Las variables 6 y 7 corresponden a ruido máximo y ruido mínimo:
Figura 4.80. Tabla “variables”.
Se probará a introducir una medida mediante un navegador. Para el sensor
“Calle_aaa”, se enviarán valores, que simulan medidas para ruido máximo y ruido mínimo.
Para lo cual, se debe enviar, mediante un navegador, los acrónimos de variables y el
identificador de sensor, resultando la siguiente URL:
servidor/rdin.php?i=Calle_aaa&rmax=30.3&rmin=10.5
Se comprueba que las medidas se han introducido correctamente el día que se
recibieron por parte del servidor:
>> SELECT * FROM medidas WHERE fecha LIKE ‘2018-02-26 %’;
72
Figura 4.81. Tabla "medidas" filtrada por día.
Ahora se realizará el envío de una medida con Arduino, y se comprobará si el
servidor propietario acepta medidas provenientes de Sigfox.
En la base de datos se incluirá un sensor cuyo nombre sea el identificador de Sigfox.
Simplemente se realiza esta prueba para comprobar que realmente se pueden aceptar
peticiones de la nube.
Figura 4.82. Tabla “sensores” con nuevo sensor.
Para el dispositivo con identificador 1AD932 (identificador de sensor 54), se incluirá
en la tabla “sondas” las variables Rmax, y Rmin (6 y 7).
Figura 4.83. Tabla “sondas” con nuevas variables activas para sensor 54.
Con los cambios realizados, se configurará el Backend para enviar la siguiente
información:
servidor/rdin.php?i=1AD932&rmax=25.1&rmin=9.4
Se comprueba que la base de datos almacena para el identificador de Sigfox, las
medidas enviadas por el Arduino.
Figura 4.84. Tabla “medidas” incluye medidas provenientes de SIgfox.
73
4.5.3 Modificación del servidor para aceptar medidas con identificador de Sigfox
Para los sensores, se debe almacenar también, en el caso de que lo posean, un
identificador de Sigfox. Para ello, se modificará la tabla “Sensores”, incluyendo una
columna más.
>> ALTER TABLE sensores ADD idsigfox CHAR(10) NULL AFTER identificador;
Figura 4.85. Tabla “sensores” con atributo idSigfox.
El servidor está preparado para aceptar peticiones que contengan el identificador
de sensor. En el archivo “rdin.php” al cual se envían los datos, se debe realizar una consulta
a la base de datos para obtener el identificador del sensor, en función del identificador
“idSigfox” que proviene de la nube.
Se configurará el sensor “Calle_aaa” para que contenga el identificador de Sigfox:
>> UPDATE sensores SET idsigfox = ’1AD932’ WHERE identificador = ‘Calle_aaa’;
La petición que se deberá configurar en el Backend de Sigfox será:
servidor/rdin.php?isig=’1AD932’&rmin=22.2&rmax=44.1
Con el parámetro “isig” de la petición, en el archivo “rdin.php” se realiza la consulta
para comprobar el identificador que le corresponde, que será “Calle_aaa”, para el que
realizará el almacenamiento de las medidas.
Se comprueba que recoge bien dichas medidas en la base de datos para el
identificador “Calle_aaa”.
Figura 4.86. Tabla “Medidas” incluye medidas recibidas dado identificador de Sigfox.
4.5.4 Modificar las vistas
4.5.4.1 Sensores
4.5.4.1.1 Crear nuevo sensor con identificador de Sigfox
Esta página permite aceptar nuevos sensores en la base de datos. Si no se activan
aquí o en la página de modificación de sensores, no se aceptarán las medidas.
74
En el formulario para añadir Sensores, se añadirá otro campo más que será el
identificador de Sigfox. No se incluirá la obligatoriedad de añadirlo para los sensores, ya
que algunos pueden no tenerlo.
Además, se modificará la consulta que se realiza a la base de datos, para que recoja
el nuevo campo del formulario, y lo pueda almacenar.
Figura 4.87. Formulario para añadir nuevo sensor.
75
4.5.4.1.2 Añadir otro sensor introducir
En el formulario para añadir sensores, hay una opción para incluir más de uno. Se
modificarán los códigos pertinentes, para añadir el campo de identificador Sigfox al
formulario.
Figura 4.88. Añadir otro sensor en la página del formulario para crear un sensor.
4.5.4.1.3 Mostrar sensores con idsigfox
En la tabla de sensores, se modificará la consulta que se realiza a la base de datos,
para que incluya la nueva columna. Esto se realiza por medio de una función que recoge
la información de la base de datos mediante un JSON, con el que se podrá mostrar la tabla.
Figura 4.89. Tabla con información de los sensores.
76
4.5.4.1.4 Filtrar sensores
En la página de sensores, existe un campo mediante el cual se pueden realizar
consultas. Para llevarlas a cabo se modifican los archivos pertinentes. Puesto que la base
de datos almacena una columna nueva, el JSON que se recibe, cambia, por lo que hay
que tenerlo en cuenta. Si no se realizaran estos cambios, no filtrará por el atributo
correspondiente.
Figura 4.90. Filtrar sensor por nombre.
4.5.4.1.5 Editar sensores
En la tabla que muestra los sensores, existe un botón para editar cualquiera de
ellos, con el que se pueden actualizar los campos de los dispositivos, incluyendo la
posibilidad de cambiar su estado a “activado” o “desactivado”, para que se acepten o no
medidas de él.
Se debe modificar la consulta a la base de datos para recibir correctamente el JSON
que se mostrará en el formulario. En los sensores que no poseen identificador de Sigfox,
se realizará la consulta con el atributo a NULL, en caso de que el campo se encuentre
vacío, para evitar errores al modificar los parámetros.
Figura 4.91. Editar sensor.
77
4.5.4.2 Sondas
4.5.4.2.1 Crear nueva sonda
Las sondas permiten asociar un sensor a una variable medioambiental. Si no se
activan en esta tabla, las medidas que se envíen por el Backend de Sigfox, no serán
aceptadas.
En el formulario para añadir Sondas, deben modificarse algunos archivos para
mostrar los sensores y variables. Si no se realizan los cambios, no se recogerán bien los
datos que aparecen en el formulario.
Entre los cambios, se encuentran:
o Incluir identificador de Sigfox en los objetos de la clase “Sensor” que se
utilizan en el código PHP.
o Modificar consultas a la base de datos.
Figura 4.92. Añadir Sonda.
Modificando estos archivos, también se consigue añadir correctamente múltiples
sondas a la vez.
4.5.4.2.2 Mostrar identificador de SIgfox en tabla de sondas
Esta página muestra para cada sensor, las variables de medidas que puede
recoger.
78
Se debe modificar la consulta que se realiza a la base de datos y el JSON que se
devuelve, para poder mostrar la columna de identificador de Sigfox, en la tabla.
Figura 4.93. Tabla con Sondas.
Modificando estos archivos, también se pueden editar correctamente cada una de
las sondas.
4.5.4.2.3 Filtrar sonda
Este apartado permite filtrar sondas de la tabla, mediante nombre, acrónimo de
variable, o ambas.
Deberá modificarse la consulta que se realiza a la base de datos para que acepte
el identificador SIgfox, así como el JSON que devuelve.
Figura 4.94. Filtrar sonda.
4.5.4.3 Registro de Aplicaciones
4.5.4.3.1 Mostrar identificador de Sigfox en Registro de Aplicaciones
Esta página permite asociar cada sonda con su aplicación (contaminación acústica
o calidad del aire).
79
Se deben modificar de nuevo las consultas, y el JSON que devuelven, para poder
mostrar el identificador de Sigfox.
Figura 4.95. Tabla para mostrar aplicaciones en sondas.
Modificando esto, también permite editar correctamente cada aplicación.
4.5.4.3.2 Filtrar por nombre
Este apartado proporciona la posibilidad de filtrar una aplicación por su nombre, por
nombre de sensor, por acrónimo de variable, o todas ellas.
Se deben modificar las consultas y el JSON que se devuelve.
Figura 4.96. Filtrar aplicaciones.
80
5 CONCLUSIONES
En este apartado se repasarán los objetivos planteados inicialmente, indicando los
beneficios del uso de Sigfox como tecnología para el envío de parámetros en IoT.
Una vez leída toda la documentación que proporciona el operador para el uso del
servicio de Sigfox, se puede comprender el funcionamiento de esta tecnología y sus
beneficios. Entre ellos, se encuentran la posibilidad de desplegar sensores por todo el
mundo para la recolección de datos, ya que Sigfox posee estaciones base de distintos
operadores en gran parte de los países, unificando todos ellos en una nube, la cual, permite
el control de los datos de manera sencilla.
Entre toda la documentación, se encuentran pruebas y casos de implementación
para enviar datos a Sigfox, tanto para Arduino, como Waspmote o Raspberry. Su código
libre, permite la creación de numerosas aplicaciones, que pueden beneficiarse de la red de
Sigfox. Un ejemplo de estas aplicaciones, puede ser la recogida de variables ambientales
alrededor de todo el mundo para su posterior análisis y estudio.
Una de las características que posee Sigfox, es la necesidad de pagar por el servicio
de la nube que proporciona, si bien resulta económico, para los beneficios que ofrece,
aunque puede suponer una gran inversión en caso de utilizar varios sensores. Para
solventar este problema, se ha desarrollado un Gateway, que permite a los dispositivos el
envío de datos a Sigfox sin tener que utilizar un módulo del operador en cada uno de ellos.
Así, sensores que se encuentren en una misma zona, pueden enviar sus variables a la
nube.
Este envío, a pesar de realizarse a través de distintos dispositivos, permite una
homogeneidad en la tecnología y en el tratamiento de los datos, que facilita su
implementación. Desde el Backend de Sigfox se puede configurar, de manera sencilla, la
decodificación proveniente de los distintos sensores y su reenvío a un servidor propietario.
En este proyecto se ha modificado un servidor web con una base de datos que
acepta los parámetros que se envían desde Sigfox. Esto ha sido posible gracias a la
facilidad en el envío de información desde la nube, en una petición web, que permite su
recolección mediante cualquier servidor web sencillo.
Por lo tanto, Sigfox permite que los sensores, independientemente de su
programación o de su ubicación, envíen a un servidor propio, toda la información que
recogen, sin ninguna dificultad en cuanto a la creación de redes o la necesidad de
implementar múltiples servidores en las zonas donde se encuentren, permitiendo un control
sencillo de los datos muy útil en las redes IoT.
81
6 REFERENCIAS BIBLIOGRÁFICAS
[1] Sigfox. Sigfox Build. Disponible el 14/06/2018 en:
https://build.sigfox.com/steps/sigfox
[2] Sigfox. Coverage. Disponible el 14/06/2018 en:
https://www.sigfox.com/en/coverage
[3] Cooking Hacks. Sigfox Ready Technology for Arduino, Waspmote and Raspberry Pi.
Disponible el 14/06/2018 en:
https://www.cooking-hacks.com/documentation/tutorials/sigfox-connectivity-arduino-
raspberry-pi-868mhz-europe-900mhz-us/
[4] Sigfox. Getting Started. Disponible el 14/06/2018 en:
http://makers.sigfox.com/getting-started/
[5] Cooking Hacks. Librería Sigfox Arduino v1.2. Disponible el 14/06/2018 en:
http://www.cooking-
hacks.com/media/cooking/images/documentation/tutorial_kit_sigfox/sigfox_library_arduino
_v1_2.zip
[6] Cooking Hacks. Raspberry Pi to Arduino shield connection bridge. Disponible el
14/06/2018 en:
https://www.cooking-hacks.com/documentation/tutorials/raspberry-pi-to-arduino-shields-
connection-bridge#step3
[7] Github. Librería LowPower. Disponible el 14/06/2018 en:
https://github.com/rocketscream/Low-Power
[8] Arduino. Arduino Uno Documentation. Disponible el 14/06/2018 en:
https://store.arduino.cc/arduino-uno-rev3
[9] Waspmote. Guía de programación de Waspmote. Disponible el 14/06/2018 en:
http://www.libelium.com/uploads/2013/02/waspmote-utilities-programming_guide.pdf
[10] Libelium. Guía de Módulo WiFi-PRO. Disponible el 14/06/2018 en:
http://www.libelium.com/downloads/documentation/wifi_networking_guide.pdf
[11] Cooking Hacks. Multiprotocol Radio Shield Tutorial for Arduino. Disponible el
14/06/2018 en:
https://www.cooking-hacks.com/documentation/tutorials/multiprotocol-shield-connect-two-
xbee-connector-arduino-raspberry-pi-galileo/
[12] Arduino. Librería Arduino Uno WiFi Developer Edition. Disponible el 14/06/2018 en:
https://www.arduinolibraries.info/libraries/arduino-uno-wi-fi-dev-ed-library
[13] Arduino. Getting started with Arduino Uno WiFi. Disponible el 14/06/2018 en:
https://www.arduino.cc/en/Guide/ArduinoUnoWiFi#toc12