Tal como os decía en los primeros artículos este era un proyecto de dos semanas, pero ya llevo seis. Durante esta serie de artículos os he ido resumiendo las dificultades y las soluciones que he encontrado (las que tienen que ver con el proyecto, claro!!), la parte de Lora no ha estado exenta, es más ha concentrado una buena parte de las dificultades.
Como en el resto de artículos haré una lista de dificultades encontradas y soluciones después de la investigación en cada caso. Hay muchas horas de trabajo para entrar en el detalle de dada una, pero espero que sirva como orientación a las personas que tengan problemas parecidos.
En general poner a funcionar un RFM95W comunicando con la red de The things Network siguiendo los numerosos ejemplos de código que hay en la web es relativamente sencillo. Un poco más complicado con ESP8266 que con Arduino y bastante más complicado cuando vas un poco escaso de GPIOS, aunque ese es un problema que ya tratamos en el artículo Sexto paso: pines, pines y más pines.
El problema viene cuando intentas hacerlo en bajo consumo. Con la librería LMIC si comunicas en el modo OTAA lo primero que intenta es hacer un join a la red. Después pones el micro en deep-sleep y cuando vuelves a enviar tiene que hacer otro join. En una red que tiene muy imitado el duty cycle por la normativa ETSI y en un dispositivo en el que el consumo es importante eso no es una opción. Ese ha sido uno de los problemas más importantes ¿la solución? las claves de red y de aplicación se pueden derivar de la respuesta del join, una vez derivadas solo hay que almacenarlas en la memoria RTC Ram y reutilizarlas para cada envio sin la necesidad de hacer el Join.
El siguiente problema es que el protocolo tiene unos contadores de paquetes ascendentes y descendentes para evitar ataques de suplantación. La red descarta automáticamente los paquetes con el contador en valores más bajos que el último enviado, al volver del modo sleep el contador de paquetes está a cero. ¿la solución? almacenar antes del deep sleep el valor del contador y recargarlo en el momento en el que el dispositivo vuelva a despertar.
Aunque posiblemente ninguno de estos dos problemas existan si no se apaga la radio (no lo se porque mi enfoque ha sido diferente) , al ponerla en sleep lo que si que se pierde es la referencia de tiempos de LMIC, al perder la referencia de tiempos el dispositivo podría incumplir las especificaciones de duty cycle de ETSI para ese rango de frecuencias. Para evitar que esto pueda suceder antes de dormir el nodo hay que mirar cual es el proximo airtime disponible, descontar el tiempo que ha estado encendido y el tiempo que lo vamos a tener en sleep y recuperarlo de nuevo al inicio para evitar que se puedan enviar paquetes en el tiempo de prohibición.
Para finalizar (y esto es solo un resumen de algunas de las dificultades más importantes) los paquetes de downlink (de la red al dispositivo) se envían al dispositivo en unas ventanas que se abren después de los paquetes de uplink, las imprecisiones en el reloj del dispositivo provocan que algunos paquetes se pierdan. En la librería se puede configurar un parámetro para definir el porcentaje de error del reloj, esto ampliará las ventanas, pero también ampliará el tiempo y por lo tanto el consumo. La solución en este caso ha sido ampliar las ventanas solo cuando se esperen paquetes de downlink.
Seguimos….