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,
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.
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.
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...
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.
Super gato
Zhiyong-li
Super gato
Zhiyong-li
Super gato
Zhiyong-li
Super gato
usuario93881
CARGAR