Notas del proveedor de IoT. LoRaWAN y RS-485

Hola queridos amantes de Internet de las cosas. Continúo mi serie de artículos.


Parte unoParte dosParte tresParte cuatroParte cinco

Entonces, aprendimos cómo trabajar con la salida de pulso de los contadores y el cifrado masterizado. ¿Cuál es el siguiente paso? La respuesta es obvia. RS-485.

Un poco de teoría RS-485 (Estándar recomendado) es una interfaz asincrónica de capa física. Obtuvo una inmensa popularidad en Internet industrial, que abarca desde servicios públicos y termina en varias fábricas y empresas.


En principio, casi cualquier medidor que quiera darnos no uno, sino varios parámetros, muy probablemente, estará equipado con RS-485. Con menos frecuencia, RS-232 o M-Bus, pero por ahora dejémoslos a un lado y analicemos el ejemplo más revelador. Más precisamente, problemas para trabajar con él.



Problema de velocidad


RS-485 es un estándar cableado. LoRa: inalámbrico. Es lógico que debe haber un cierto dispositivo capaz de hacer amigos con ellos.

De acuerdo Casi todos los fabricantes del terminal en la línea tienen un módulo de radio con soporte RS-485. Funciona según el principio de un canal transparente. Todos los paquetes que pasan por el cable se empaquetan como una carga útil de paquetes LoRaWAN y se envían a la transmisión. O son recibidos y convertidos en impulsos eléctricos.


Y aquí está el primer problema. RS-485 es una interfaz de muy alta velocidad. Los paquetes en él van a velocidades de varios kilobits / seg o incluso varias decenas. Por ejemplo, una de las velocidades típicas de Modbus es 9.6 kbit / s.


LoRa, incluso con el mejor SF = 7 (125 kHz, 4/5) exprimirá 5,5 kbit / s. Con mayor SF habrá aún menos.

Esto significa que el estudio de los valores de algunos medidores eléctricos no tomará segundos, y ni siquiera decenas de segundos. El puntaje durará minutos. Y esto es con un tiempo de espera ajustado adecuadamente. Si deja la configuración predeterminada, lo más probable es que su encuesta termine en un error de tiempo de espera. No menciono las restricciones sobre la longitud de los paquetes de LoRaWAN. Solo hay problemas.



Problema de sondeo


Con salidas de pulso, todo es simple. Contamos los pulsos, los multiplicamos por el precio de división y obtenemos la lectura del medidor. Cualquier interfaz simple puede manejar esto. Y dicha interfaz, además de la simplicidad, será más universal.


Con RS-485, todo es mucho peor. Sorprendentemente, muchos no entienden una cosa importante.
¡RS-485 NO ES UN PROTOCOLO DE INTERCAMBIO! No especifica el formato de los paquetes que van dentro de él. De hecho, es solo un medio de transmisión. Solo se especifican las características eléctricas y temporales de la interfaz. Eso es todo! Todo en la parte superior ya debe desmontarse por separado.


¡Y hay algo que desmontar! Además de nuestro entorno, cada fabricante puede terminar lo que quiere. Bueno, o lo que resultó ser conveniente para él personalmente. Por ejemplo, el medidor de calor VKT-7 se comunicará con nosotros a través de ModBus. Y Energomera - a través de GOST R IEC 61107-2001.


Todos estos protocolos se superponen en el medio de transmisión desde arriba y tienen un nivel más alto. Cada protocolo tiene su propia composición del marco, requiere que sus propios equipos realicen ciertas acciones, proporciona un almacenamiento diferente (y, por lo tanto, sondeo) de valores. Por lo tanto, cada dispositivo necesita su propio script de sondeo. Además, incluso dentro del marco de un protocolo (el mismo ModBus), este script diferirá de un dispositivo a otro.


Los protocolos en sí mismos no son secretos y, en su mayor parte, están abiertos. Además, el sitio web de cada fabricante a menudo contiene una utilidad gratuita con la que puede interrogar a los dispositivos. Pero estas utilidades no son universales y están afiladas para un fabricante. Y recordamos que casi siempre tenemos un zoológico de dispositivos. Y poner varios programas en el cliente al mismo tiempo ... bueno, esto no es demasiado conveniente.


Hay dos salidas. O escribe algo tuyo. O tome un programa en el que ya se hayan compilado los scripts de sondeo para los dispositivos más populares. Hay muchas soluciones preparadas en el mercado, por ejemplo, "contabilidad LERS" o "YaEnergetik". Pero se les paga y cuestan mucho dinero. Así como el desarrollo de su software.

Además, si hablamos de Internet industrial (es decir, vamos más allá del marco de la vivienda y los servicios comunales), las soluciones universales ya no le ayudarán. Como ser


De ninguna manera


Si todavía planea sondear a través de LoRa a través de un canal transparente, aún se encontrará con límites de velocidad y tiempos de espera. Puede que no sea inmediato y no con el primer dispositivo, pero sucederá.


Problema estándar


Además de todos los problemas, tenemos uno más. Porque RS-485 implica que podemos contactar el dispositivo en cualquier momento, el módulo de radio LoRa con su soporte debe ser de clase C. Es decir, siempre escuche la transmisión y esté listo para responder.

Permítame recordarle que la clase C no implica energía de la batería, pero el problema no es tan grave. Típicamente, el RS-485 es donde se puede obtener energía externa.


Peor es otro.

Por ley, podemos operar en dos rangos de frecuencia. ¿Recuerdas el límite de 864-865 MHz? ¿No más del 0.1% del tiempo en el aire? Esto significa que cada dispositivo tomado por separado puede estar en el aire, por ejemplo, no más de 3.6 segundos por hora. Pero durante este tiempo, en SF = 12 ni siquiera enviaremos tres paquetes.

Puede intentar exprimir al máximo los canales 868.7-869.2. Sin embargo, otra restricción de los estándares regionales de especificación LoRaWAN entra en vigencia aquí: no más del 1 por ciento del tiempo de aire para cada dispositivo terminal (ciclo de trabajo). OK, ya más fácil, 36 segundos. Solo que el sentido todavía no es realmente.



En algún momento, podemos decir: ¡oh, ellos, estas tonterías! ¡Me sentaré en el aire todo el tiempo que sea necesario! Pero luego aparece:


Problema de capacidad de éter


LoRa no es en vano intercambiando paquetes cortos y raros. De hecho, todo el estándar se basa en esto. Es necesario que cada dispositivo tome el menor tiempo posible en el aire. Luego, reduciremos el riesgo de colisiones y podremos lograr esa densidad fantástica de varios miles de radimódulos por BS. ¿Qué sucederá si un módulo de radio garabatea en paquetes como una ametralladora? Su frecuencia está ocupada en el momento de la transmisión. Y en el momento de la respuesta, todas las frecuencias están ocupadas, ya que la estación base no escucha nada cuando se transmite.


Por supuesto, nadie canceló los retrasos para aumentar la capacidad. Es decir Si hay dos BS en el área de cobertura de un módulo de radio, uno seguirá respondiendo y el segundo puede escuchar algún otro paquete. Sin embargo, el éter no es de goma. Si cada módulo de radio tomará un minuto para intercambiar paquetes, entonces en una hora no podemos colgar más de 60 dispositivos terminales por BS, esto está sujeto a la ausencia de colisiones. Muy poco, especialmente si recuerdas que el radio de acción de cada BS en la ciudad es de aproximadamente 2 km, o tal vez más.


Entonces no?


Resulta que nuestra red LoRaWAN está limitada solo a dispositivos con salida de pulso y sistemas de vigilancia, ¿dónde se registra el hecho de un viaje?


No

Solo tratamos de usar el concepto de Internet de las personas donde esto no se puede hacer. De acuerdo, es un hábito para nosotros usar excesivamente un canal de Internet estable. Por ejemplo, abra un video, tomando acciones en el búfer y no mire. Es decir el tráfico pasará, pero de hecho no se utilizará.

Sin embargo, todo es diferente aquí. Tenemos poca velocidad, tampoco hay tiempo en el aire. Debe usarse con moderación. ¿Qué se te ocurre?


La respuesta está en la superficie. No conduzca un montón de tráfico de sobrecarga de protocolo a través de RS-485 a través de LoRa.

La secuencia de comandos de sondeo se puede descargar en el propio módulo de radio. Interrogará el medidor en el lugar con cierta frecuencia y nos enviará solo valores secos, previamente acordados.


Este método tiene dos desventajas:


  • Tal módulo de radio requiere ciertos recursos informáticos. Este no es un gran problema en el nivel actual de desarrollo tecnológico.
  • Tal módulo de radio consume más energía. Pero en el caso de un canal transparente, nos vemos obligados a usar la clase C, que tampoco funciona con baterías. Eso es lo que es.

Pero obtenemos toda la información que necesitamos en 2-3 paquetes. Y luego todo encajará en uno, si necesita literalmente varios parámetros. De hecho, a menudo sucede que no necesitamos pasar TODO, un conjunto de valores bastante limitado.

El módulo de radio puede transmitir datos, por ejemplo, una vez por hora. Y en el lado del servidor, los pondremos en almacenamiento. Si necesita acceder al archivo, el servidor ni siquiera tiene que sondear el dispositivo.


Por supuesto, debe tener algún tipo de módulo de radio universal en el que se carguen varios scripts. Y una interfaz capaz de percibir dicha información. Esta no es una manera fácil, pero solo cumple con todos los requisitos y limitaciones.

En este momento, más y más fabricantes están tomando esta decisión. Vega está preparando dispositivos similares; icbcom, ORION M2M y otros ya lo tienen.

Porque Si usamos una interfaz autoescrita, entonces tenemos desarrollos similares. En algún momento, quedó claro que si no profundizábamos, simplemente no podríamos trabajar.


Además de los trucos para ahorrar tráfico, aún necesitamos una buena red en la que los dispositivos funcionen a una velocidad mínima y máxima de SF. Lo enfatizo, no es una red en la que todos los dispositivos con SF = 7. Aún no lograrás esto.


Tal red que busca SF = 7. Esto significa planificación competente y ADR.


En la salida, obtenemos velocidades suficientes para que viajen los paquetes, todavía una gran cantidad de módulos de radio por BS y la capacidad de trabajar con interfaces de un nivel superior a la salida de pulso. Lo cual fue requerido.


PD Colegas, estoy agradecido a todos por los comentarios. Dime, ¿todavía estás interesado en aprender sobre LoRaWAN o el Internet de las cosas? Las respuestas pueden escribirme en PM o en los comentarios. Para las solicitudes más interesantes o masivas, se publicarán artículos.

Source: https://habr.com/ru/post/es414159/


All Articles