Estrategia de módulo inalámbrico de baja potencia


8

Estoy diseñando módulos de sensores de baja potencia que se distribuirán en un área razonablemente pequeña. Todos los módulos funcionan con baterías y deben funcionar durante un tiempo decente sin tener que recargar / reemplazar las baterías (cuanto más largas, mejor, piense al menos unas semanas, si no meses o años). La idea es que cada media hora u hora el módulo se activará desde el modo de baja potencia, tomará algunas muestras y transmitirá los datos a un registrador de datos central. El registrador de datos central probablemente será alimentado por la pared, por lo que el bajo consumo de energía no es tan necesario. No espero que ningún módulo esté a más de 100 metros del registrador central, probablemente mucho menos.

He identificado algunos posibles módulos de transceptor que potencialmente podrían funcionar:

  1. ALPHA-TRX433S, 433 MHz
  2. ALPHA-TRX915S, 915 MHz
  3. Microchip MRF89XAM8A, 868 MHz
  4. Microchip MRF89XAM9A, 915 MHz

Por lo que he leído, todos estos módulos operan en bandas no reguladas por la FCC y deben ser seguros de usar. Los módulos Alpha anuncian un rango de 300 m, pero no puedo entender cuál sería el rango máximo esperado de los módulos Microchip. ¿Cómo haría para calcular esto?

Además, dado que tengo mi elección de bandas, ¿cuál debo elegir y por qué (es decir, qué obtengo de 915 MHz a 433 MHz y qué pierdo)? En orden de qué parámetros consideraría más importante:

  1. De baja potencia
  2. Rango de transmisión (más es mejor, dentro de lo razonable)
  3. Inmunidad a otros factores ambientales (es decir, redes wifi / celulares, hornos microondas, paredes / obstáculos físicos, temperatura, etc.). El uso objetivo es en un entorno residencial y es probable que haya variaciones significativas de temperatura (digamos -20 ° C a 50 ° C).
  4. Velocidad de datos. Esto no es terriblemente importante ya que espero muy pocos datos por muestra (pocos bytes como máximo).

Otra pregunta que tengo es cómo manejar múltiples módulos que intentan transmitir datos al mismo tiempo. Tengo algunas ideas sobre cómo mitigar esto, pero no estoy seguro con qué solución proceder:

  1. Use un desplazamiento de tiempo aleatorio para cuando se transmiten los datos. La esperanza es que las colisiones simplemente se eviten. Este probablemente sería el más simple de implementar y potencialmente usará la menor potencia. Sin embargo, esto no garantiza que no habrá colisiones. Además, obtener una buena fuente de aleatoriedad o una semilla pseudoaleatoria única puede causar problemas, aunque no son irresolubles.

  2. Al despertar e intentar transmitir, verifique si hay alguna transmisión actualmente en progreso. Simplemente espere el final de la transmisión antes de enviar datos. El problema se convierte entonces en cómo manejo múltiples sensores en el estado de espera, ya que potencialmente ambos podrían decidir que la última transmisión ha finalizado y ambos comenzarán a transmitir al mismo tiempo.

  3. Alguna otra solución.


Tenga en cuenta que el rango de 300m es para la comunicación 'Clear Line of Sight', y generalmente eso puede caer a 50 o 100m (o incluso menos) en interiores, dependiendo del no. y tipo de paredes entre Tx / Rx. He usado un par de 433MHz ASK / OOK Tx / Rx en un proyecto, con un perfil de uso algo similar, apagado 4x1.5VDC AA (sin mercurio estándar), durante más de 6 meses.
icarus74

En cuanto al manejo de las transmisiones simultáneas múltiples, sus primeras soluciones están cerca de lo que uso. En mi caso, mi transmisor usa una entrada de sensor de temperatura no calibrada como semilla PRNG para convertir a un desplazamiento de hasta 3000ms, y luego también uso retransmisiones.
icarus74

Respuestas:


9

Tengo un código abierto y un sensor de hardware abierto que le daría un punto de partida funcional: está conectado a Internet y transmite su temperatura, humedad y voltaje de la batería cada dos minutos y durará de 3 a 5 años con baterías 2xAA. Se basa en el módulo M12 6LoWPAN .

Haré todo lo posible para captar todas sus preguntas:

Con respecto a la compensación de la banda:

433MHz, 915MHz, 2.4GHz

El alcance frente al tamaño de la antena es el claro compromiso aquí La pérdida de la trayectoria del espacio libre es una función de la longitud de onda, por lo que las frecuencias más bajas viajan mucho más lejos para la misma atenuación. PERO, para capitalizar esto, también necesitará una antena adecuada que también se adapte a la longitud de onda. La antena de 2.4Ghz en el M12 ocupa aproximadamente 2 cm2 de área de PCB.

Un segundo factor es la licencia. 2.4GHz puede tener estaciones sin licencia en todo el mundo. 915MHz solo no tiene licencia en los EE. UU. (Es una banda GSM en cualquier otro lugar). No estoy seguro de las restricciones en 433MHz.

La velocidad de datos también se ve afectada por la elección de frecuencia de acuerdo con el teorema de Shannon-Hartley ; puede agrupar más datos en una banda de frecuencia más alta. Sin embargo, esto no siempre se usa para una velocidad de datos más final. 802.15.4, por ejemplo, tiene 4 bits de redundancia por cada bit real visto en la capa de datos. Los 32 símbolos son pseudoortogonales, por lo que debe corromper varios bits de bajo nivel para causar un error. Esto permite que 802.15.4 funcione bajo el ruido de fondo (la investigación sugiere a -5dB SNR) y lo hace relativamente robusto a la interferencia.

Ahora al siguiente tema difícil,

operación de radio de baja potencia :

En comparación con las fuentes de baterías domésticas (p. Ej., Alcalinas AA), incluso los SoC de "baja potencia" como el mc13224v no son de muy baja potencia. Los transmisores son de alrededor de 30 mA a 2-3.5 V y los receptores son de 25 mA más o menos. Sin apagar la radio y poner la CPU en reposo, esta carga agotará 2 AA en unos pocos días. El alto consumo de energía del receptor a menudo es sorprendente para las personas y probablemente el mayor dolor en el desarrollo de sistemas de radio de baja potencia. La implicación es que, durante años, casi nunca se puede transmitir o escuchar.

El objetivo de obtener una operación "durante todo el año" de los alcalinos 2xAA es lograr que la corriente promedio del sistema sea <50uA. Si lo hace, lo enfrentará a años y contra los efectos secundarios de las baterías, como la autodescarga y la vida útil de 7 años para las baterías domésticas.

La mejor manera de obtener menos de <50uA promedio es si su transceptor no necesita recibir. Si esto es cierto, puede "piar" los datos lo más rápido posible y poner el sistema en un modo de bajo consumo (digamos, aproximadamente 10uA) durante la mayor parte del tiempo. El TH12 , por ejemplo, transmite durante aproximadamente 10 ms, pero hay otra sobrecarga en el sistema con respecto al tiempo de procesamiento y los tiempos de configuración para el sensor involucrado. Los detalles se pueden resolver con una sonda actual y una hoja de cálculo:

A partir de ese tipo de análisis, puede determinar cuál será la vida útil (suponiendo que tenga una curva de descarga precisa para su batería).

Si necesita recibir datos en el lado de baja potencia (por ejemplo, para hacer un enrutador inactivo en una red de malla), el estado actual de la técnica se centra en las técnicas de división de tiempo. Algunos sincronizan estrechamente la red, como las balizas 802.15.4, y otros usan un sistema "suelto" como ContikiMAC (que puede ser más fácil de implementar especialmente si su hardware no tiene una base de tiempo estable).

De todos modos, mi experiencia muestra que estos métodos tienen un promedio de alrededor de 400 uA, lo que lo coloca en el tiempo de ejecución de "meses a quizás un año" con 2xAA.

Colisiones :

Mi consejo: no te preocupes por ellos por ahora. En otras palabras, haz "aloha" (tu opción # 1) donde si tienes datos envíalo. Si colisiona, tal vez lo reenvíe. (Esto depende de tus objetivos). Si no necesita asegurarse de que se reciben todas las muestras, intente una vez y vaya a dormir de inmediato.

Encontrará que el problema del consumo de energía es tan difícil que la única solución será una red que no transmita mucho. Si solo lo intentas, probablemente pasará. Si no es así, siempre puedes volver a intentarlo más tarde.

Si usted no tiene que asegurarse de que cada datagrama consigue a través, entonces tendrá que hacer algún tipo de esquema de ACK. En el mundo 6LoWPAN, puede usar TCP, que volverá a intentarlo hasta que la batería se agote. También hay CoAP que usa UDP y tiene un mecanismo de reintento (pero no promete entrega). Pero cada elección aquí afectará el tiempo de ejecución. Si está operando durante años, el impacto será en meses.

Su opción # 2 está integrada en el hardware 802.15.4 como CCA. La idea es que el receptor se encienda para 8 símbolos y devuelva verdadero o falso. Luego puede tomar una decisión sobre qué hacer a continuación. Puedes jugar con estos esquemas todo el día / semana. Pero cada vez que haces algo como esto, te ahorras más semanas del tiempo de ejecución. Es por eso que sugiero comenzar de manera simple por ahora. Funcionará bastante bien si está intentando largos tiempos de ejecución.


¡Tu enlace no funciona!
Ryan Griggs

Me gustaría agregar a este Estimador Microchip XLP , que le mostrará el tiempo de ejecución esperado para varias configuraciones de baterías y estados / períodos de ejecución. Además, si todos los sensores son transceptores, podría implementar un esquema de 'round-robin' o 'token-ring' donde el maestro le pregunta repetidamente al dispositivo 0 a "¿Algo para mí?" El sensor espera su turno (digamos 10 ms), transmite y luego se apaga. Recomiendo usar algún tipo de suma de verificación CRC, para evitar aceptar datos confusos. norte
rdtsc

1

Puede que le interese JeeNodes, que es básicamente un Arduino Uno emparejado con un módulo de radio RFM-12B de HopeRF. Si escribe su código directamente en los "nodos" remotos, puede obtener meses fácilmente de un conjunto de baterías, dependiendo de sus sensores, etc.

Echa un vistazo a su sitio web, el consumo de energía es algo que está bien documentado. Una cosa ideal acerca de esto es que puede usar bibliotecas arduino estándar para sus sensores, o usar los sensores en la tienda de jeelabs y usar la biblioteca JeeLib que hace que todo sea muy fácil.

Hice un pequeño control remoto para una lámpara de un JeeNode v6, y apagué una batería Nokia vieja (aproximadamente 1 Ah, pero probablemente ahora menos), ha estado funcionando durante 3 meses y el voltaje de la batería todavía está por encima de 3.9v (es decir todavía bastante lleno). Simplemente se sienta allí en reposo de baja potencia, despertando cada pocos ms para verificar si se presionan los botones.

Compré los PCB en la tienda JeeLabs, pero obtuve todos los componentes de lugares como eBay, element14, etc., terminó siendo un poco más barato de esa manera.

Con un poco de atención al diseño de la antena, aparentemente puede obtener unos cientos de metros de ellos, línea de visión. Obtengo fácilmente cobertura en toda la casa con un simple cable vertical.


0

TASA DE DATOS "La tasa de datos también se efectúa mediante la elección de frecuencia de acuerdo con el teorema de Shannon-Hartley; puede agrupar más datos en una banda de frecuencia más alta". ¡¡¡Incorrecto!!!

La velocidad de datos tiene que ver con el ancho de banda, no con la frecuencia de la portadora. Puede tener una frecuencia de portadora baja, pero un ancho de banda alto y una velocidad de datos alta.

FRECUENCIA DEL PORTADOR La frecuencia del portador más baja es buena para el rango. Si la frecuencia se reduce a la mitad, el rango aumentaría cuatro veces. Pero el tamaño de la antena también aumentaría. Por lo general, las antenas son lamba / 2 o lambda / 4 (lambda es la longitud de onda en metros).

CONTENCIÓN DEL CANAL Esto parece bastante obvio a primera vista, pero puede ser complicado. Como otros han señalado, la estrategia más simple sería despertar y transmitir una vez y luego ir a dormir. Si el número de transmisores no es tan grande y la duración del sueño es mucho mayor que la duración de la transmisión, esto funcionaría. Pero debe estar listo para perder algunos datos en casos excepcionales.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.