msgbartop
El problema de tener una mente abierta es que la gente insiste en entrar dentro y poner allí sus cosas
msgbarbottom

30 sep 20 Un gateway LoRaWAN de un canal. Trasteando con el protocolo

Esta entrada es la parte 7 de 7 de la serie Gateway LoRaWAN

Comentaba en un artículo anterior de la serie que había implementado un gateway LoRa*. Y no me faltaba razón. Estaba haciendo uso del protocolo LoRa de enlace basado en 868 MHz para enviar señales de entre un nodo emisor y un receptor, y de este último a un servidor MQTT. ¿Cuál es la diferencia? La más importante es que no estaba realizando ningún tipo de verificación de nodos, sin ni siquiera molestarme en verificar cuál es el emisor y cuál el receptor. Y ni hablemos de cifrado de comunicaciones ni nada que se le parezca. Pero para las pruebas preliminares que venía efectuando, en lo que el aspecto importante era verificar alcance entre nodos, sobraba y bastaba. Por cierto, para ver más detalles de las diferencias entre LoRa y LoRaWAN, tengo otro artículo dedicado a tal efecto.

Pero para este proyecto necesitaba dar un paso más allá, e implementar un verdadero gateway LoRaWAN. Y eso implicaba hacer uso de una red LoRaWAN, que proporcione su servidor de procesado de tráfico de red, y te permita explotar los datos enviados desde los dispositivos. Cuando te enfrentas a esto, tienes dos posibilidades: o te implementas la red, o te conectas a una ya existente. Sobre la primera opción ya hablaremos más adelante, en un artículo al respecto, pero para salir rápidamente del paso hice uso de la segunda. Existe una red pública a la que puedes conectar gateways y dispositivos LoRaWAN, que es la red The Things Network, o TTN. Cuando te registras como usuario, puedes añadir a la red tanto dispositivos como gateways. Si haces lo primero, dependes de que haya algún gateway cercano a ti para que tus dispositivos envíen datos a la red. Pero si no tienes ningún gateway a tu alcance, no te queda otra que implementar un gateway, y conectarlo a la red. Que es precisamente de lo que va esta serie.

Tengo que decir algo desde un principio: estoy haciendo trampas. Una de las especificaciones del protocolo LoRaWAN es que a la hora de establecer un enlace entre dispositivo y gateway se puede utilizar de manera aleatoria cualquier canal de la banda que estés utilizando. En el caso de Europa, la banda es la de 868 MHz, y existen 9 canales dedicados a tal efecto (aunque en realidad son 8+1). La razón para ello es evitar la congestión en cualquiera de los canales, siendo la red la encargada de analizar esta circunstancia, y la responsable de tomar las medidas necesarias (cambio de canal) para solucionarlo. Para ello, la idea es que cuando se configura un nuevo gateway, tu hardware tiene que estar preparado para operar en estos canales. El problema, en mi caso, es que el hardware del que dispongo sólo es capaz de funcionar en un solo canal. ¿Y cuál es este hardware? Nuestro viejo amigo el Heltec LoRa 32.

IMG_20200930_202951961~2.jpg

Tras trastear un poco por Internet, encontré un proyecto bastante interesante de Things4U que consiste exactamente en eso: implementar un gateway de un solo canal. Por supuesto, es un proyecto experimental que no debe usarse en un sistema en producción, pero para mis propósitos de investigación basta y sobra. La instalación es bastante sencilla: tan simple como descargar el código (viene con todas sus librerías), y en el caso de Arduino, hacer lo siguiente:

  • Crear un proyecto, y copiar al mismo el contenido del directorio ESP-sc-gway. Por otro lado, copiar el contenido del directorio lib en el directorio libraries de tu instalación de Arduino.
  • Por otro lado, editar el contenido de los ficheros configGway.h y configNode.h, que permiten establecer los parámetros de red WiFi a la que conectarse, modelo de dispositivo utilizado (Heltec, en mi caso), banda a utilizar (868), y algunos elementos adicionales como a qué nodo de la red TTN conectarse.
  • Compilar y listo. El dispositivo levanta una interfaz web que permite verificar el funcionamiento del mismo y cambiar algunos parámetros en tiempo de ejecución, y muestra información del comportamiento del dispositivo en la pantalla de cristal líquido.
Screenshot_20200927-103047.png

Captura de pantalla de la web de administración del gateway

Si todo ha ido bien, tu gateway se conectará a la red TTN (donde es preciso configurar tu gateway, aunque por lo que he visto no parece interactuar demasiado bien con la información de estado del mismo), y es cuestión de encender un dispositivo, empezar a emitir, y ver entrar los paquetes en tu aplicación:

Screenshot_20200927-103236.png

…sí claro. Ojalá. :mrgreen: Y es que hay un pequeño problema. Con esto hemos configurado nuestro gateway para que trabaje en un solo canal, pero por defecto nuestro dispositivo trabajará en cualquier canal de la banda, de manera aleatoria. Y esto implica que sólo vamos a recibir, estadísticamente hablando, 1 de cada 9 paquetes enviados. Una tasa bastante baja. ¿Cuál es la solución? Obviamente, forzar al dispositivo a emitir en una sola banda. Existe un tutorial de Sparkfun que lo explica bastante bien, pero para el caso de los dispositivos Heltec LoRa es necesario trastear un poco más, y especificar los valores del dispositivo:

const lmic_pinmap lmic_pins = {
.nss = 18,
.rxtx = LMIC_UNUSED_PIN,
.rst = 14,
.dio = {26, 35, 33},
};

…y con eso, ¡listos! Bueno, casi. Para los Heltec LoRa 32 vale, pero por desgracia no para los Cube Cell que estoy empleando, ya que las implementaciones de la librería LMIC que he encontrado no parecen funcionar bien con estos dispositivos. ¿La solución? Ser un poco más imaginativo. En mi caso, he modificado los parámetros de la librería LoRaWan_APP del fabricante, para hacer que todas las definiciones de la banda de 868 MHz trabajen exactamente en la frecuencia del canal 0, que es que se utiliza por parte del servidor. En concreto, se trata de localizar el fichero RegionEU868.h (en el directorio packages\CubeCell\hardware\CubeCell\1.x.0\cores\asr650x\loramac\mac\region), y modificar lo siguiente:

#define EU868_LC1 { 868100000, 0, { ( ( DR_5 < < 4 ) | DR_0 ) }, 1 }

/*!
* LoRaMac default channel 2
* Channel = { Frequency [Hz], RX1 Frequency [Hz], { ( ( DrMax << 4 ) | DrMin ) }, Band }
*/
#define EU868_LC2 { 868100000, 0, { ( ( DR_5 < < 4 ) | DR_0 ) }, 1 }

/*!
* LoRaMac default channel 3
* Channel = { Frequency [Hz], RX1 Frequency [Hz], { ( ( DrMax << 4 ) | DrMin ) }, Band }
*/
#define EU868_LC3 {868100000, 0, { ( ( DR_5 < < 4 ) | DR_0 ) }, 1 }

#define EU868_LC4 { 868100000,0, { ( ( DR_5 < < 4 ) | EU868_TX_MIN_DATARATE ) }, 0 }
#define EU868_LC5 { 868100000,0, { ( ( DR_5 < < 4 ) | EU868_TX_MIN_DATARATE ) }, 0 }
#define EU868_LC6 { 868100000,0, { ( ( DR_5 < < 4 ) | EU868_TX_MIN_DATARATE ) }, 0 }
#define EU868_LC7 { 868100000,0, { ( ( DR_5 < < 4 ) | EU868_TX_MIN_DATARATE ) }, 0 }
#define EU868_LC8 { 868100000,0, { ( ( DR_5 < < 4 ) | EU868_TX_MIN_DATARATE ) }, 0 }

Sí, es una ñapa. Pero una ñapa que funciona. :mrgreen: Una vez hecho esto y subido el código al Cube Cell, todo va como la seda. Y aprovechando que me encontraba en Córdoba, me decidí a hacer algunas pruebas adicionales de transmisión de datos: un verdadero (bueno, de aquella manera) gateway LoRaWAN conectado a la red TTN, y un dispositivo emitiendo de manera periódica una información sencilla (00 01 02 03). La idea era probar la transmisión en un entorno urbano, con orografía acusada, y sin visibilidad directa, y con el emisor haciendo uso de las antenas por defecto que proporciona el fabricante. Nada de antenas avanzadas. Y el resultado fue bastante mejor del esperado. EL sistema pudo cubrir sin interrupciones todo el parque de la Asomadilla con un único gateway, incluso en zonas donde la curvatura del terreno oculta de manera total el emisor del receptor.

20200926_202706.jpg

Emisor en el punto más alejado del parque

Como comentaba, el sistema fue capaz de proporcionar cobertura en todo el Parque de la Asomadilla de Córdoba.

20200926-asomadilla.JPG

Imagen de la zona cubierta

Es de esperar que en una zona con una ubicación óptima (zona alta del parque) la zona de cobertura fuera muy superior. Pero eso ya quedará para otro día.

VN:F [1.9.20_1166]
Rating: 0.0/10 (0 votes cast)
Series NavigationAlimentación eléctrica. Conversión DC-DC
Comparte este artículo:
  • Twitter
  • Facebook
  • email
  • StumbleUpon
  • Delicious
  • Google Reader
  • LinkedIn
  • BlinkList

Etiquetas: , , , , , , ,

Comentarios de los lectores

  1. |

    A Alex: Hola, vi que escribiste un comentario en este artículo. Por desgracia tuve un problema con el sitio, y tuve que restaurar una copia de seguridad, por lo que tu comentario se ha perdido. Si lees esto, por favor, publícalo de nuevo y estaré encantado de ayudarte en la medida de mis posibilidades.

    VN:F [1.9.20_1166]
    Rating: 0.0/5 (0 votes cast)
    Responder a este comentario
  2. |

    Hola Yuri, excelente tu publicación. Aquí va mi comentario, a ver si me puedes dar una luz en el camino.

    Fíjate que el Gateway ya se conecta a TTN. Pero el problema lo estoy teniendo con el CubeCell, cuando arranco el serial en arduino, el Cubecell se queda un rato en: Joining…join failed y por lo tanto lo único que me aparece en TTN en Data, si es un paquete del nodo, pero uno de “Activation”, que tiene un símbolo de un rayo, pero no datos.

    Ya utilice varias frecuencias, empecé con 915 y ahora lo realice como tu con 868.

    Una duda, agregaste o moviste algo en esta parte de configNode.h ??? Lo copio aquí abajo:

    // It is possible to use the gateway as a normal sensor node also. In this case,
    // substitute the node info below.
    #if _GATEWAYNODE==1
    // Valid coding for internal sensors are LCODE and RAW.
    // Make sure to only select one.
    # define _LCODE 1
    //# define _RAW 1
    # define _CHECK_MIC 1
    # define _SENSOR_INTERVAL 300

    // Sensor and app address information
    # define _DEVADDR { 0xAA, 0xAA, 0xAA, 0xAA }
    # define _APPSKEY { 0xBB, 0xBB, 0xBB, 0xBB, 0xBB, 0xBB, 0xBB, 0xBB, 0xBB, 0xBB, 0xBB, 0xBB, 0xBB, 0xBB, 0xBB, 0xBB }
    # define _NWKSKEY { 0xCC, 0xCC, 0xCC, 0xCC, 0xCC, 0xCC, 0xCC, 0xCC, 0xCC, 0xCC, 0xCC, 0xCC, 0xCC, 0xCC, 0xCC, 0xCC }

    // For ESP32 based T_BEAM/TTGO boards these two are normally included
    // If included make value 1, else if not, make them 0
    # define _GPS 0
    # define _BATTERY 1
    #endif //_GATEWAYNODE

    #if _TRUSTED_NODES >= 1
    struct nodex {
    uint32_t id; // This is the LoRa ID (coded in 4 bytes uint32_t
    char nm[32]; // Name of the node
    };

    // Add all your named and trusted nodes to this list
    nodex nodes[] = {
    { 0x260116BD , “lora-34 PIR node” }, // F=0
    { 0×26011152 , “lora-35 temp+humi node” }, // F=0
    { 0x2601148C , “lora-36 test node” }, // F=0
    };

    #endif //_TRUSTED_NODES

    Por ultimo, que ejemplo usaste en el cubecell??? Yo utilice el que viene en la librería de cubecell>LoRa>LoRaWAN>LoRaWANSensors>LoRaWAN_BH1750.

    Bueno, de antemano te agradezco el tiempo para leer mi comentario, cualquier luz en el camino te lo agradecería mucho.

    Saludos cordiales.

    Luis

    VA:F [1.9.20_1166]
    Rating: 0.0/5 (0 votes cast)
    Responder a este comentario
    • |

      Hola, Luis, gracias por escribir. También tengo observado el fenómeno que comentas del paquete de activation, pero no de datos. Ojo, no sólo con el gateway de un canal, sino usando gateways de la propia red. Tengo visto que pasa más cuando el nodo está configurado para tener autenticación OTAA que ABP. Por lo que he podido averiguar, muchas veces es tema de congestión de la propia red TTN (https://www.thethingsnetwork.org/forum/t/over-the-air-activation-otaa-with-lmic/1921/19). Así que paciencia, usar ABP, y mensajes sin confirmación. :D

      En cuanto a modificaciones en el fichero configNode.h, no he hecho ninguna, más allá de configurar los valores de mi entorno en la función wpas wpa[] (para indicar las WiFis a las que conectar) y las variables de identificación del gateway (Gateway Ident definitions). El resto es tal cual se indica en el tutorial de Sparkfun.

      Por último, en los ejemplos del nodo, he usado dos: uno específico para los nodos CubeCell (cubecell-LoRaWan-ttn), y otro para el Heltec (el que se indica en el tutorial de Sparkfun, https://cdn.sparkfun.com/assets/learn_tutorials/8/0/4/ESP-1CH-TTN-Device-ABP-v01.zip)

      Espero que consigas echarlo a andar todo. ¡Un saludo!

      VN:F [1.9.20_1166]
      Rating: 0.0/5 (0 votes cast)
      Responder a este comentario

Deje un comentario







× siete = 56