¿Consumo de energía real de xbee series 2 en modo de suspensión/apagado?

De acuerdo con el manual del usuario y varios otros documentos oficiales de Digi, xbee en el modo de apagado/reposo puede consumir tan solo 1uA. Pero de alguna manera, un consumo de energía tan bajo parece simplemente inalcanzable en mis manos.

La siguiente es mi configuración:

los pines DIN, DOUT, CTS, SLEEP_RQ, RESET, RSSI están conectados a MCU, VCC conectado a una fuente de 3,3 V en tándem con una resistencia de 10 ohmios (para medir el consumo de corriente), pin GND conectado a tierra. Todos los demás pines están configurados como salida como sugiere el manual.

El consumo real mide a 0,7 mA cuando se afirma el pin SLEEP_RQ. Ocasionalmente puede ser tan alto como varios mA.

Parece que no soy la única persona que puede vencer la corriente del sueño en el reino de uA. La siguiente es una publicación de blog: http://www.socgadget.com/2011/07/low-power-xbee-module/

Estoy diseñando una red de sensores alimentados por batería. cerca de 1 mA de consumo de energía en modo de suspensión es realmente una gran carga para la batería.

Me gustaría reunir alguna experiencia real de primera mano. Además, si alguien puede darme un número real de consumo de energía de onda Z en modo de suspensión, sería genial. Z-Wave también dice en su manual que puede ser menos de 1uA, pero me gustaría saber el número real antes de invertir varios miles en él.

Editar: apagar la línea UART TX en el lado de MCU parece no marcar la diferencia.

Gracias de antemano,

Los módulos deberían ofrecer un muy buen rendimiento a baja potencia cuando se utiliza el modo pin-sleep; me parece que no lo estás configurando para que se vaya a dormir. He observado en versiones anteriores del módulo que, a veces, si una unidad ha sido configurada para un modo de suspensión automático, no cumplirá con una solicitud de suspensión pin. Hacer un "restablecimiento de fábrica" ​​y luego solicitar el modo pin-sleep parece solucionarlo.
Esto podría ser un problema. Verificaré el módulo para ver si están en modo de suspensión de pin puro o en una combinación de suspensión de pin y cíclica. Pero hasta cierto punto, estoy bastante seguro de que el módulo se duerme. Debido a que el consumo de energía se mide de manera muy diferente al modo ascendente, una línea muy breve de 20 mA frente a una línea plana larga a un nivel de 0,7-0,8 mA.
Los 20mA representan el tiempo que la radio está encendida. Los 0,7 mA probablemente representan la corriente necesaria para que el módulo permanezca lo suficientemente despierto como para responder a los datos en serie. No creo que la versión que usé tuviera la opción de suspender el receptor de radio pero permitir las comunicaciones con la CPU host, pero algunas otras sí.
Eso en realidad puede explicar lo que está sucediendo. Un poco de corriente para mantener UART vivo en el lado xbee. Pero no tengo la intención de comunicarme con xbee después de afirmar el pin sleep_rq, porque al mismo tiempo, la MCU también se pone en suspensión. Intentaré hacer algo en el lado de MCU para que DIN y DOUT no se vean como la interfaz UART. Esperemos que esto haga una diferencia.
Es posible que el XBEE use la existencia de un nivel alto en su pin RX (su DOUT) como una señal de que el procesador debe mantenerse lo suficientemente activo para comunicarse, aunque los que he usado antes no lo hicieron. Esperaría que hubiera una opción para controlar dicho comportamiento (para usar con dispositivos que no pueden forzar su salida en serie a tierra).
Eso es exactamente lo que estoy pensando. Lo más probable es que el pin TX en el lado de la MCU (MSP430F6720) se deje alto cuando la MCU entre en suspensión. Debería poder apagar directamente el pin TX o indirectamente configurándolo primero como GPIO. Actualizaré más tarde.
Compruebe también el comportamiento de DSR/DTR. Eso también podría ser configurable.
También encontré algún problema al medir la corriente de apagado. Conecté un multímetro entre Arduino VCC y XBEE VCC, obtuve 13,41 mA durante el modo inactivo y -13,41 mA durante el modo de suspensión. No entendí eso. por favor, ayúdame
Gracias por la explicación, Metacollin. He estado viendo corrientes de "sueño" de 80 uA en un módulo XB3. Después de seguir las recomendaciones, la corriente de suspensión de 2 uA (Agilent 34401A, incluido el sensor) se activa desde el comando de suspensión de Micropython. Todas las salidas bajas, deshabilitadas, excepto las líneas I2C y TX/RX UART (DIO13 y DIO14). Líneas I2C extraídas por la placa del sensor T/RH (AHT10).

Respuestas (1)

Primero, para responder a tu pregunta:

La corriente de reposo real de los módulos Xbee Serie 2 depende del voltaje y la temperatura. En todo el rango de voltaje, es menos de 10 µA. Con el voltaje típico y 25 °C, es inferior a 1 µA. La variación de producto a producto hace que sea inútil especificar la corriente con mayor precisión, porque será diferente para cada módulo. Pero definitivamente estará por debajo de 1 µA.

En otras palabras, la corriente de sueño real es... bueno... lo que dicen que es la corriente de sueño real.

Lo que debe tener en cuenta es que esta no es la corriente de suspensión que obtendrá simplemente ingresando al modo de apagado. Esta es la corriente más baja posible.para entrar en el modo de apagado. Dicho de otra manera, eso no implica que el simple hecho de apagar el dispositivo produzca esta corriente. Significa que si un montón de otras cosas se organizan así, se cumplen un montón de condiciones y se resuelven todo tipo de pequeños inconvenientes, sin pasar por alto ni una sola cosa, puede obtener un consumo de corriente de <1 µA en el modo de apagado. El apagado no es un interruptor de encendido/apagado mágico (por mucho que nos gustaría que lo fuera), por lo general, simplemente apaga el núcleo de la CPU. Tiene que apagar manualmente otras cosas antes de eso, todas las cosas que no se ven afectadas por la condición SM = 1 y solo cuando todo eso se soluciona, entonces apaga el núcleo.

Con eso en mente, voy a repasar algunos escollos que cualquiera de ellos, o alguna combinación de ellos, produciría corrientes de sueño tan altas. De hecho, es especialmente importante evitar el pensamiento 'bala de plata' en estas situaciones. Ahí es donde asume que hay un único mecanismo detrás del problema y, por lo tanto, el problema tiene una única solución 'bala de plata'. En realidad, es probable que varias cosas diferentes funcionen en combinación.

  1. GPIOh no

    Los pines de E/S de los módulos Xbee Series 2 (y los primos más nuevos 2B y 2C) funcionan independientemente del núcleo de la CPU. Pin sleep, en pocas palabras, en realidad no afecta los pines IO. El núcleo de la CPU puede cambiarlos y configurarlos, pero eso es todo. Entonces, esos pines simplemente continuarán haciendo lo que sea que estuvieran haciendo (siendo entradas, o controlados como los configuró por última vez como salidas, etc.) independientemente de si está apagando el módulo o no. Pin sleep no se encargará de nada relacionado con GPIO por ti, tienes que hacerlo tú mismo.

    Mencionas configurar todos los pines no utilizados para la salida ... pero ¿con qué estado? Debe configurar los pines no utilizados para la salida, valor predeterminado bajo para lograr la corriente de suspensión más baja. Así que revisa eso dos veces.

    Además, apague las resistencias pull-up en todos esos pines GPIO no utilizados, aunque los esté configurando como salidas, no como entradas.

    Una vez que te hayas asegurado de que estás haciendo lo anterior, podemos movernos.

  2. La batería siempre pierde en una pelea de pines.

    Si no tenía sus salidas configuradas bajas (aunque no estén conectadas), eso podría haber contribuido a parte del consumo actual. Pero sospecho que también encontrará algo que no está del todo bien con la única otra cosa que podemos examinar: los pines conectados . En otras palabras, las líneas que van desde el Xbee hasta tu MCU.

    No desea duplicar las resistencias pull-up/pull-down. Para cada línea entre el Xbee y el MCU, asegúrese de haber desactivado las resistencias pull-up internas del MCU. Independientemente de su dirección (entrada/salida). Deje que los pull-ups de Xbee, y solo esos, hagan el trabajo.

    Además, asegúrese de que su MCU se comporte correctamente en términos de lo que realmente está haciendo con las líneas que ha conectado al Xbee. Apagar la línea UART TX no se está comportando correctamente. (Aunque, no empeoró las cosas, obviamente). No lo piense demasiado: es un puerto UART con control de flujo CTS. Así que haga lo que se supone que debe hacer y simplemente trátelo como cualquier otro puerto UART con control de flujo CTS: respete el CTS, eso es todo. No olvide los pull-ups internos de la MCU, esos deben estar apagados. Ahora, queremos asegurarnos de que los pines estén configurados en los niveles correctos. El pin TX de la MCU, cuando está inactivo, debe estar alto, y dado que un Xbee dormido afirma CTS alto (es decir, '¡no me hables!'), Eso significa que el pin TX de la MCU debe estar configurado en alto. Ponerlo en cualquier tipo de estado Z alto no es correcto, no

    La línea MCU RX será impulsada alta por el Xbee, así que asegúrese de que el pull-up de la MCU en esta entrada esté deshabilitado. No lo necesitamos, ya que está siendo conducido. Y habrá fugas, ya que nada tiene el mismo potencial, si existe ese camino adicional de extracción.

    Asegúrese de que su pin RSSI esté configurado en salida baja antes de dormir, y asegúrese de que su MCU tenga su pin en el otro extremo configurado para entrada baja/sin pull-up. Si hay un pull up activo, estará tirando hacia abajo y verá un consumo adicional de corriente de suspensión.

    Asegúrese de que los pines Xbee que son entradas no estén siendo reducidos por la MCU por algún motivo (y verifique el comportamiento ya que también está poniendo la MCU en suspensión. Asegúrese de que no esté bajando algo inesperadamente. La errata de silicio es una cosa real).

Y finalmente...

  1. Medición de mo, problemas de moA veces, es posible que solo estés midiendo mal. ¿Qué tan seguro está de la precisión del medidor que está usando? Está midiendo a través de la caída de voltaje a través de una resistencia de 10 Ω. Incluso en el modo de apagado, el Xbee se activará para restablecer algunos temporizadores y lo que no cada pocos segundos. Puede haber picos de corriente muy cortos, y una resistencia de 10 Ω podría estar bajando el voltaje lo suficiente como para activar un circuito de caída de tensión o hacer otras cosas raras. Sería una buena idea agregar un capacitor de tantalio realmente bueno y gordo, de al menos 100 µF, a través de las entradas de energía del módulo Xbee, pero después de la resistencia de detección de 10 Ω, para desacoplar más la energía de la resistencia de 10 Ω. Esto también servirá para filtrar los picos de corriente, que a menudo pueden causar lecturas erróneas en los multímetros, ya que esperan una CC constante. Una vez más, esto probablemente no sea

Todo lo anterior se aplica tanto a los Xbees de la serie 2B o 2C más recientes, así que no dejes que la edad de esta pregunta (¡casi 4 años ahora!) te engañe, mi respuesta aún se aplica incluso en 2018. Me temo que podría ser demasiado tarde para ser de mucha utilidad para el autor de la pregunta, pero espero que no.

Gracias por escribir una respuesta tan larga. Sería bueno si puede incluir algunos números reales de primera mano sobre el consumo de energía.