Tatsächlicher Stromverbrauch der xbee-Serie 2 im Ruhe-/Ausschaltmodus?

Laut Benutzerhandbuch und mehreren anderen offiziellen Dokumenten von Digi kann xbee im Abschalt-/Schlafmodus nur 1 uA verbrauchen. Aber irgendwie scheint mir ein so geringer Stromverbrauch einfach unerreichbar.

Folgendes ist mein Setup:

Die Pins DIN, DOUT, CTS, SLEEP_RQ, RESET, RSSI sind mit der MCU verbunden, VCC ist mit einer 3,3-V-Quelle verbunden, zusammen mit einem 10-Ohm-Widerstand (zur Messung des Stromverbrauchs), der GND-Pin ist mit Masse verbunden. Alle anderen Pins sind wie im Handbuch vorgeschlagen als Ausgang konfiguriert.

Der tatsächliche Verbrauch liegt bei 0,7 mA, wenn der SLEEP_RQ-Pin aktiviert ist. Gelegentlich kann er mehrere mA betragen.

Ich scheine nicht die einzige Person zu sein, die den Schlafstrom in den Bereich von uA schlagen kann. Das Folgende ist ein Blogbeitrag: http://www.socgadget.com/2011/07/low-power-xbee-module/

Ich entwerfe ein batteriebetriebenes Sensornetzwerk. Nahezu 1 mA Stromverbrauch im Schlafmodus ist wirklich eine große Belastung für die Batterie.

Ich möchte konkrete Erfahrungen aus erster Hand sammeln. Es wäre auch großartig, wenn mir jemand eine tatsächliche Zahl des Z-Wave-Energieverbrauchs im Schlafmodus nennen könnte. Z-Wave sagt in seinem Handbuch auch, dass es weniger als 1 uA sein kann, aber ich würde gerne die tatsächliche Zahl wissen, bevor ich mehrere Tausend darin investiere.

Bearbeiten: Das Ausschalten der UART-TX-Leitung auf der MCU-Seite scheint keinen Unterschied zu machen.

Vielen Dank im Voraus,

Die Module sollten im Pin-Sleep-Modus eine sehr gute Low-Power-Performance bieten; es klingt für mich, als ob Sie es nicht so konfigurieren, dass es tatsächlich schlafen geht. Ich habe bei früheren Versionen des Moduls beobachtet, dass manchmal, wenn ein Gerät für einen automatischen Schlafmodus konfiguriert wurde, eine Anforderung für Pin-Sleep nicht berücksichtigt wird. Das Durchführen eines "Factory Reset" und das anschließende Anfordern des Pin-Sleep-Modus scheint das zu beheben.
Dies könnte ein Problem sein. Ich überprüfe das Modul, um festzustellen, ob es sich im reinen Pin-Schlaf oder in einer Kombination aus Pin- und zyklischem Schlaf befindet. Aber bis zu einem gewissen Grad bin ich mir ziemlich sicher, dass das Modul in den Ruhezustand geht. Da der Stromverbrauch im Up-Modus ganz anders misst, eine sehr kurze 20-mA- vs. lange flache Linie bei 0,7-0,8-mA-Pegel.
Die 20 mA stellen die Zeit dar, in der das Radio eingeschaltet ist. Die 0,7 mA stellen wahrscheinlich den Strom dar, der erforderlich ist, damit das Modul gut genug wach bleibt, um auf serielle Daten zu reagieren. Ich glaube nicht, dass die von mir verwendete Version eine Option hatte, den Funkempfänger in den Ruhezustand zu versetzen, aber die Kommunikation mit der Host-CPU zu ermöglichen, aber einige andere könnten dies tun.
Das könnte tatsächlich erklären, was passiert. Etwas Strom, um UART auf der xbee-Seite am Leben zu erhalten. Aber ich beabsichtige nicht, mit xbee zu kommunizieren, nachdem ich die sleep_rq-Pin bestätigt habe, da gleichzeitig die MCU auch in den Ruhezustand versetzt wird. Ich werde versuchen, auf der MCU-Seite etwas zu tun, damit DIN & DOUT nicht wie eine UART-Schnittstelle aussehen. Hoffentlich wird dies einen Unterschied machen.
Es ist möglich, dass das XBEE das Vorhandensein eines hohen Pegels an seinem RX-Pin (Ihrem DOUT) als Signal verwendet, dass der Prozessor am Leben bleiben sollte, um zu kommunizieren, obwohl die, die ich zuvor verwendet habe, dies nicht getan haben. Ich würde erwarten, dass es eine Option gibt, um ein solches Verhalten zu steuern (zur Verwendung mit Geräten, die ihren seriellen Ausgang nicht auf Masse zwingen können).
Genau daran denke ich. Höchstwahrscheinlich bleibt der TX-Pin auf der MCU-Seite (MSP430F6720) auf High, wenn die MCU in den Ruhezustand wechselt. Ich sollte in der Lage sein, den TX-Pin entweder direkt oder indirekt abzuschalten, indem ich ihn zuerst als GPIO konfiguriere. Ich werde später aktualisieren.
Prüfen Sie auch das DSR/DTR-Verhalten. Das könnte auch konfigurierbar sein.
Ich habe auch ein Problem beim Messen des Abschaltstroms festgestellt. Ich habe ein Multimeter zwischen Arduino VCC und XBEE VCC angeschlossen, ich habe 13,41 mA im Leerlaufmodus und -13,41 mA im Schlafmodus erhalten. Ich habe das nicht verstanden. Bitte hilf mir
Danke für die Erklärung, Metacollin. Ich habe in einem XB3-Modul "Schlaf" -Ströme von 80 uA gesehen. Nach Befolgung der Empfehlungen Schlafstrom 2 uA (Agilent 34401A, einschließlich Sensor), ausgelöst durch Micropython-Schlafbefehl. Alle Ausgänge niedrig, Pullups außer I2C-Leitungen und TX/RX-UART (DIO13 & DIO14) deaktiviert. I2C-Leitungen, die von der T / RH-Sensorplatine (AHT10) hochgezogen werden.

Antworten (1)

Zunächst zur Beantwortung Ihrer Frage:

Der tatsächliche Schlafstrom der Module der Xbee-Serie 2 hängt von Spannung und Temperatur ab. Über den gesamten Spannungsbereich beträgt sie weniger als 10µA. Bei der typischen Spannung und 25 °C beträgt sie weniger als 1 µA. Abweichungen von Produkt zu Produkt machen es nutzlos, den Strom genauer anzugeben, da er für jedes Modul anders sein wird. Aber es wird definitiv unter 1µA sein.

Mit anderen Worten, der tatsächliche Schlafstrom ist ... na ja ... was sie sagen, der tatsächliche Schlafstrom ist.

Beachten Sie, dass dies nicht der Schlafstrom ist, den Sie erhalten, wenn Sie einfach in den Abschaltmodus wechseln. Dies ist der niedrigste Strom, der möglich istum in den Power-Down-Modus zu gelangen. Anders ausgedrückt bedeutet dies nicht, dass das einfache Ausschalten des Geräts diesen Strom liefert. Das bedeutet, wenn ein Haufen anderer Dinge einfach so arrangiert, ein Haufen Bedingungen erfüllt und alle möglichen anderen kleinen Fallstricke erledigt werden, ohne eine einzige Sache zu übersehen, können Sie im Abschaltmodus <1µA Stromaufnahme erhalten. Das Ausschalten ist kein magischer Ein-/Ausschalter (so sehr wir es uns wünschen), es schaltet normalerweise nur den CPU-Kern ab. Sie müssen vorher andere Dinge manuell abschalten, all die Dinge, die nicht von der Bedingung SM = 1 betroffen sind, und erst wenn all dies erledigt ist, schalten Sie den Kern aus.

In diesem Sinne werde ich einige Fallstricke durchgehen, die eine oder eine Kombination davon zu so hohen Schlafströmen führen würde. Tatsächlich ist es besonders wichtig, in diesen Situationen „Wunderwaffe“-Denken zu vermeiden. An dieser Stelle gehen Sie davon aus, dass hinter dem Problem ein einziger Mechanismus steckt und das Problem somit eine einzige „Wunderwaffe“-Lösung hat. In Wirklichkeit arbeiten wahrscheinlich mehrere verschiedene Dinge zusammen.

  1. GPIOh-Nr

    Die E/A-Pins der Module der Xbee-Serie 2 (und der neueren Cousins ​​2B und 2C) arbeiten unabhängig vom CPU-Kern. Pin-Sleep, einfach ausgedrückt, wirkt sich nicht wirklich auf die IO-Pins aus. Der CPU-Kern kann sie ändern und konfigurieren, aber das ist alles. Diese Pins tun also einfach weiterhin das, was sie getan haben (Eingänge sein oder angesteuert werden, wie Sie sie zuletzt als Ausgänge festgelegt haben usw.), unabhängig davon, ob Sie das Modul ausgeschaltet haben oder nicht. Pin Sleep kümmert sich nicht um GPIO-bezogene Dinge für Sie, das müssen Sie selbst tun.

    Sie erwähnen, dass alle nicht verwendeten Pins auf Ausgabe gesetzt werden ... aber mit welchem ​​​​Zustand? Sie müssen unbenutzte Pins auf Ausgang setzen, standardmäßig niedrig , um den niedrigsten Ruhestrom zu erreichen. Also überprüfe das nochmal.

    Schalten Sie auch die Pull-up-Widerstände an all diesen nicht verwendeten GPIO-Pins aus, obwohl Sie sie als Ausgänge und nicht als Eingänge festlegen.

    Sobald Sie sich besonders vergewissert haben, dass Sie die oben genannten Schritte ausführen, können wir umziehen.

  2. Bei einem Pinfight verliert immer der Akku.

    Wenn Sie Ihre Ausgänge nicht niedrig eingestellt hatten (obwohl sie nicht verbunden sind), könnte dies zu einem Teil der aktuellen Auslosung beigetragen haben. Aber ich vermute, Sie werden auch bei dem einzigen anderen, was wir untersuchen können, etwas nicht ganz richtig finden: die verbundenen Pins. Mit anderen Worten, die Leitungen, die vom Xbee zu Ihrer MCU verlaufen.

    Sie möchten die Pull-Up / Pull-Down-Widerstände nicht verdoppeln. Stellen Sie für jede Leitung zwischen dem Xbee und der MCU sicher, dass Sie die internen Pull-up-Widerstände der MCU deaktiviert haben. Unabhängig von ihrer Richtung (Eingang/Ausgang). Lassen Sie die Klimmzüge des Xbee, und nur diese, die Arbeit erledigen.

    Stellen Sie außerdem sicher, dass sich Ihre MCU in Bezug auf das, was sie tatsächlich mit den Leitungen tut, die sie mit dem Xbee verbunden hat, korrekt verhält. Das Ausschalten der UART-TX-Leitung verhält sich nicht korrekt. (Obwohl es die Dinge offensichtlich nicht schlimmer gemacht hat). Denken Sie nicht darüber nach: Es ist ein UART-Port mit CTS-Flusskontrolle. Tun Sie also, was Sie tun sollen, und behandeln Sie ihn einfach wie jeden anderen UART-Port mit CTS-Flusskontrolle: Respektieren Sie den CTS, das ist alles. Vergessen Sie nicht die internen Klimmzüge der MCU, diese sollten ausgeschaltet sein. Jetzt wollen wir sicherstellen, dass die Stifte auf die richtigen Ebenen eingestellt sind. Der TX-Pin der MCU sollte, wenn er inaktiv ist, hoch sein, und da ein schlafender Xbee CTS hoch behauptet (was bedeutet: „Sprich nicht mit mir!“), bedeutet dies, dass der TX-Pin der MCU auf hoch gesetzt werden sollte. Es ist nicht richtig, es in irgendeinen hohen Z-Zustand zu versetzen, nicht

    Die MCU-RX-Leitung wird vom Xbee hoch getrieben, also stellen Sie sicher, dass der Pull-up der MCU an diesem Eingang deaktiviert ist. Wir brauchen es nicht, da es gefahren wird. Und es wird Lecks geben, da nichts jemals ganz das gleiche Potenzial hat, wenn es diesen zusätzlichen Pull-up-Pfad gibt.

    Stellen Sie sicher, dass Ihr RSSI-Pin vor dem Ruhezustand auf Low-Ausgang eingestellt ist, und stellen Sie sicher, dass der Pin Ihrer MCU am anderen Ende auf Low/no Pull-up eingestellt ist. Wenn ein Klimmzug aktiv ist, ziehen Sie nach unten und sehen eine zusätzliche Stromaufnahme im Schlaf.

    Stellen Sie sicher, dass alle Xbee-Pins, die Eingänge sind, aus irgendeinem Grund nicht von der MCU auf Low getrieben werden (und überprüfen Sie das Verhalten, da Sie die MCU ebenfalls in den Ruhezustand versetzen. Stellen Sie sicher, dass sie nicht unerwartet etwas Low zieht. Silizium-Errata ist eine echte Sache).

Und schlussendlich...

  1. Mo messen, mo ProblemeManchmal misst du vielleicht einfach falsch. Wie zuversichtlich sind Sie in die Genauigkeit des von Ihnen verwendeten Messgeräts? Sie messen über den Spannungsabfall an einem 10Ω-Widerstand. Selbst im Power-Down-Modus wacht der Xbee auf, um ein paar Timer zurückzusetzen und was nicht alle paar Sekunden. Es kann sehr kurze Stromspitzen geben, und ein 10-Ω-Widerstand lässt die Spannung möglicherweise so weit sinken, dass eine Brownout-Schaltung ausgelöst wird oder andere seltsame Dinge geschehen. Es wäre eine gute Idee, einen wirklich schönen und fetten Tantalkondensator, mindestens 100 µF, über die Leistungseingänge des Xbee-Moduls hinzuzufügen, aber nach dem 10-Ω-Messwiderstand, um die Leistung stärker vom 10-Ω-Widerstand zu entkoppeln. Dies dient auch dazu, Stromspitzen herauszufiltern, die häufig zu fehlerhaften Messwerten auf Multimetern führen können, da sie einen konstanten Gleichstrom erwarten. Auch dies ist wahrscheinlich '

All dies gilt genauso für die neueren Xbees der 2B- oder 2C-Serie, also lassen Sie sich nicht vom Alter dieser Frage (fast 4 Jahre alt!) Täuschen, meine Antwort gilt auch im Jahr 2018. Ich fürchte es könnte zu spät sein, um dem Fragesteller viel Nutzen zu bringen, aber ich hoffe nicht.

Danke, dass du so eine lange Antwort geschrieben hast. Es wäre schön, wenn Sie einige tatsächliche Zahlen aus erster Hand zum Stromverbrauch hinzufügen könnten.