Estoy planeando usar el Sensor de Orientación Absoluta BNO055 para recolectar el acelerómetro, el magnetómetro y las mediciones giroscópicas para una aplicación. A partir de ahora quiero que los datos se envíen a una velocidad de 10 Hz a una entidad de recopilación de datos (Pi o BeagleBone con tecnología inalámbrica).
La configuración puede ser:
- 3 cosas de IoT
- 1 cosa central de la colección
- Topología en estrella con punto de recogida en el centro
Por lo que dice mi experiencia, 802.11 WLAN parece la única opción óptima en comparación con 802.15.4 ZigBee y / o Bluetooth LE (4.0) . La razón son los grandes conjuntos de datos que BNO055 generaría y enviaría a una velocidad muy rápida (~ 0.1 segundos ). Solo estoy haciendo un prototipo simple y, por lo tanto, prefiero usar UDP simple para enviar los datos.
Actualmente me estoy enfocando en el factor de alcance ya que la colocación estará dentro del casco de un barco y eso también implica que habrá una pérdida considerable de datos debido a las superficies metálicas. Pero me puedo tomar la libertad de ejecutar los nodos a plena potencia (conectados con fuentes de alimentación o baterías de alto nivel de iones de litio)
Preguntas:
¿Es WLAN la opción correcta de tecnología inalámbrica para la aplicación? Si no es así, ¿qué otra tecnología debería probar?
¿Cuáles pueden ser los obstáculos que pueden ocurrir para una aplicación de IoT de tan baja latencia (10 Hz) que puedo evitar o tener en cuenta?
Respuestas:
Latencia vs Tasa
Este es un error conceptual. La latencia y la tasa son en gran medida independientes. Podría tener un sistema que grabe miles de lecturas por segundo, las almacene en una tarjeta SD y, una vez al mes, alguien visite el sitio remoto, extraiga la tarjeta y se la envíe por correo; ese sistema tendría una tasa alta pero también extremadamente latencia . O podría tener un sistema que informara lecturas dentro de unos pocos microsegundos de cuando se toman, pero solo tomó una lectura por hora.
Entonces, lo primero que deberá hacer es aclarar su requerimiento: ¿necesita tomar una gran cantidad de datos, o necesita obtenerlos mientras todavía está muy actualizada, o ambos?
Una velocidad de actualización de 10 Hz es relativamente viable para la mayoría de los esquemas de transmisiones digitales, excepto para aquellos donde hay un límite regulatorio en el número de transmisiones por período de tiempo, o aquellos que tienen una velocidad de datos tan baja (ya sea porque son de banda estrecha para enlace eficiencia, o porque son crudos) que simplemente no pueden mover la cantidad de datos que desea enviar lo suficientemente rápido.
Latencia vs. Confiabilidad y Complejidad
Como el tiempo de propagación real en áreas pequeñas requiere un circuito exótico para medirlo, para los sistemas de radio locales, el tiempo necesario para mover un mensaje es básicamente el tiempo para codificarlo, a menos que los aspectos de diseño del sistema agreguen más. Un sistema que necesita "contemplar" mucho un mensaje podría agregar demora, aunque con un software decente que probablemente sea leve. Uno que requiere varios ciclos de "discusión" de ida y vuelta por mensaje necesariamente aumenta el tiempo en el número de ciclos y cualquier tiempo de respuesta del enlace o protocolo.
Pero la fuente más probable de demora es una capa de confiabilidad : si falta un mensaje o llega dañado, ¿qué debe hacer el sistema? Si lo intenta de nuevo, eso casi siempre significa agregar demora, mientras que si simplemente deja caer el mensaje y avanza, eso puede significar lagunas.
Para su tipo de aplicación, lo que puede funcionar bien es un esquema poco confiable , pero uno en el que cada paquete incluye no solo una medición actual, sino también repeticiones de algunas anteriores (o para una aplicación de conteo, un total acumulado). Y esas no necesariamente tienen que ser las mediciones recientes más inmediatas: dependiendo de los patrones de interferencia, el mejor esquema podría terminar siendo algo como actual, anterior, siguiente anterior, 5ta anterior, 13a anterior, o lo que sea, para que el los paquetes que pasan tienden a tener una alta probabilidad de incluir también los datos que no lo hicieron.
Sistemas practicos
Muchos sistemas estándar de 2.4 GHz probablemente funcionarían bien en su ejemplo, si hay líneas de visión razonables o rutas de fuga entre los componentes.
Las radios digitales de 2.4 GHz nRF24L01 manejarían fácilmente la velocidad de datos, y se utilizan fácilmente para crear sistemas de salto de canal de latencia bastante baja; por ejemplo, estos y sus competidores se utilizan para volar interactivamente muchos drones de bajo costo para el consumidor.
BTLE tiene modos con complejidad de estado que podrían ser problemáticos, sin embargo, el modo de publicidad es lo suficientemente simple y puede ejecutarse al tipo de tasas de repetición que está buscando. Los receptores personalizados construidos alrededor de placas integradas como su propuesta deberían poder mantenerse al día y brindarle los detalles completos de cada paquete. También existe cierta compatibilidad cruzada con los teléfonos inteligentes, sin embargo, en ese caso, el sistema operativo host puede proporcionarle solo una pequeña minoría del tráfico y puede no informarle de manera consistente cuando cambie el contenido del paquete.
Por supuesto, hay muchas otras opciones
fuente