Stromsparmaßnahmen für die MicroPython-Firmware im Batteriebetrieb

clemens · June 19, 2019, 5:38pm

Ok, further research! Habe den WiPi am Multimeter, der im deep sleep 10 mA verbraucht und nacheinander die einzelnen Sensoren abgeklemmt.

kritischer Stromverbrauch einzelner Sensoren im deep sleep

Keine DS18B20 reduzieren den Verbauch nicht sonderlich, auch der BME280 ist erst mal unkritisch. Der faule Apfel oder gärige Honig ist die Wägezelle / der HX711. Wenn man E+ abklemmt geht der Verbauch von 10 mA auf ca. 3,5 mA zurück.

Ab Zeile 101 gibt es in der /hiveeyes/sensor_hx711.py eine power_off mit

github.com

hiveeyes/hiveeyes-micropython-firmware/blob/df2e78a82578cf2426a4f3920a325fe83f74201c/hiveeyes/sensor_hx711.py#L101-L103


def power_off(self):
    log.info('Turning off HX711')
    self.loadcell.power_down()

und auch das logging sagt

32.4655 [hiveeyes.sensor_hx711    ] INFO   : Turning off HX711

scheint aber irgendwie nicht zu greifen!

Unsere Standard-Arduino-Bibliothek kann den HX711 bzw. über den HX711 den Verbraucher Wägezelle gut abschalten, an der Hardware sollte es also nicht scheitern. Müsste 'ne Software-Geschichte sein.

Andreas · June 19, 2019, 7:19pm

Hi Clemens,

Schade. Also Haube auf…

Die C++-Implementierung sieht folgendermaßen aus:

github.com

bogde/HX711/blob/0.7.2/src/HX711.cpp#L266-L273


      
          void HX711::power_down() {
          	digitalWrite(PD_SCK, LOW);
          	digitalWrite(PD_SCK, HIGH);
          }
          
          void HX711::power_up() {
          	digitalWrite(PD_SCK, LOW);
          }

Die MicroPython-Implementierung sieht ganz gleich aus:

github.com

hiveeyes/terkin-datalogger/blob/0.4.0/lib/hx711.py#L120-L125


      
          def power_down(self):
              self.pSCK.value(False)
              self.pSCK.value(True)
          
          def power_up(self):
              self.pSCK.value(False)

Für Vorschläge und Nachforschungen wäre ich sehr dankbar. Gerade habe ich noch Turn off interrupts when powering down the HX711 · hiveeyes/terkin-datalogger@1d88b63 · GitHub hinzugefügt, aber dann bin ich mit meinem Latein am Ende. Wäre vorstellbar, dass der ESP32 auch hier zu schnell unterwegs ist und man daher zwischen dem Zuppeln am SCK kurz mal warten sollte?

Merci,
Andreas.

P.S.: Falls das “zwischendrin warten” irgendwie Sinn machen sollte – so ginge es:

import time
time.sleep_ms(50)

Andreas · June 19, 2019, 8:28pm

Hi there,

Just learned from [SOLVED/WORKEDAROUND] Having problems with HX711 load cell sensor - MicroPython Forum (Archive) that

def powerDown(self):
    """
    Power the HX711 down as per datasheet.
    Setting high longer than 60 microseconds.
    """
    self.pdsckPin.low()
    self.pdsckPin.high()
    time.sleep_us(80)

Which is also confirmed through the datasheet and Electrical Engineering Stack Exchange:

A GPIO-based implementation for the RaspberryPi is also doing it likewise:

github.com

dcrystalj/hx711py3/blob/master/hx711.py#L99-L115


      
          # HX711 datasheet states that setting the PDA_CLOCK pin on high
          # for a more than 60 microseconds would power off the chip.
          # I used 100 microseconds, just in case.
          # I've found it is good practice to reset the hx711 if it wasn't used
          # for more than a few seconds.
          def powerDown(self):
              GPIO.output(self.PD_SCK, False)
              GPIO.output(self.PD_SCK, True)
              time.sleep(0.0001)
          
          def powerUp(self):
              GPIO.output(self.PD_SCK, False)
              time.sleep(0.0001)
          
          def reset(self):
              self.powerDown()
              self.powerUp()

That research was easy.

Cheers,
Andreas.

MKO · June 19, 2019, 8:51pm

Bin zu dem gleichen Ergebnis wie @Clemens gekommen, was ich mich jetzt noch frage ist, was macht der Pycom im Deep Sleep modus draus. Habe mich noch nicht viel damit beschäftigt, aber fällt der SCK dann nicht wieder auf False und der HX711 fährt dann wieder hoch?

Andreas · June 19, 2019, 9:11pm

Exakt jenes frage ich mich auch. Ich hoffe wir wissen grob was wir tun und es klappt aufgrund von PULL-UP/PULL-DOWN Charakteristika ebenfalls genau so wie anderswo auch. Wenn jemand unsere Zweifel fundiert vom Tisch wischen kann: Her damit!

MKO · June 19, 2019, 9:17pm

Das schnellste was mir jetzt auf die schnelle einfallen würde, wär ein externer Pullup.

Den könnte man auch zum testen mal auf die schnelle unten auf die Platine klöppeln.

Andreas · June 19, 2019, 9:27pm

Per Sleep for 80 microseconds after pulling HX711 clock pin to high · hiveeyes/terkin-datalogger@fedbe6f · GitHub jetzt mal so implementiert wie auch anderswo gesehen – mit der Bitte um Review und Tests.

Andreas · June 19, 2019, 9:33pm

Andere sagen das auch:

Set the PD_SCK pin to the output mode before readings, and to the HIGH-Z/INPUT mode before esp8266/hx711 powerdown, use pullup resistor.

– esp8266 - HX711 Power Down Handling - Electrical Engineering Stack Exchange

Und/oder:

Haben wir das schon vorgesehen und hier berücksichtigt? Steht bestimmt schon irgendwo im Forum… ;].

Andreas · June 19, 2019, 10:00pm

Die Dokumentation sagt zu den möglichen Pin-Modi:

Quelle: Pin

Kann uns hier vielleicht irgendein eingebautes Peripheriemerkmal weiterhelfen oder gibt es bereits entsprechende Beschaltungen auf Euren Boards, @clemens und @didilamken?

MKO · June 19, 2019, 10:15pm

Nein und Nein.
Die internen Pullup und Pulldown sind ebenso Im Deep Sleep abgeschaltet und auch die bisherigen Schaltungen weisen keine Pullup auf.

habe gerade mal getestet ein FiPy auf Clemens Weißem Board ist bei mir mit heftigen 77mA im Deep Sleep.
Ohne aufgestecktem HX711 bei 67mA.
Mit externem 10K pullup.bei 67,5mA

Habe ihn auf die schnelle einfach direkt oben auf dem HX711 zwischen VCC und SCK gehängt.

Andreas · June 19, 2019, 10:27pm

@clemens?

Andreas · June 19, 2019, 10:35pm

Externer pullup im Spiel?

Damit meinst Du vermutlich den externen pullup?

Ich bin mir nun unsicher, ob und wie ich das bei der Programmierung berücksichtigen sollte. Aktueller Stand:

github.com

hiveeyes/terkin-datalogger/blob/0.4.0/lib/hx711.py#L15-L16


      
          self.pSCK = Pin(pd_sck, mode=Pin.OUT)
          self.pOUT = Pin(dout, mode=Pin.IN, pull=Pin.PULL_DOWN)

Data pin (DOUT) als pullup konfigurieren?

Im Beitrag bei [SOLVED/WORKEDAROUND] Having problems with HX711 load cell sensor - MicroPython Forum (Archive) wird darüber gesprochen, den dataPin - also der auch als pOUT bzw. dout bezeichnete - als PULL_UP zu konfigurieren à la

self.dataPin = Pin(dout, Pin.IN, Pin.PULL_UP)

Hier geht es aber um etwas anderes. Beim Schreibenden hat das Auslesen vorher überhaupt nicht funktioniert. Ich für meinen Teil wundere mich nur über die Anomalie bei der Konfiguration des entsprechenden Pins - dort als PULL_UP, bei uns als PULL_DOWN.

Fazit

Also: Muss ich für die korrekte Ansteuerung des Pullups zur besseren Abschaltung des HX711 im deep sleep nun irgendetwas softwareseitig berücksichtigen und falls ja, könntet Ihr mir das grob beschreiben?

MKO · June 19, 2019, 10:42pm

Nein, wen ein externer Pulup dran ist brauchst Du ihn Intern( Softwareseitig) nicht auch noch dazu schalten oder berücksichtigen.

Ich habe den Pullup jetzt auch nochmal drastisch auf 1 MOhm erhöht, da bei mir der HX711 nicht immer sauber aufgewacht ist. Er war für die Taktrate wahrscheinlich zu niedrig.
1M weil ich den hier eh gerade auf dem Schreibtisch hatte.

weef · June 19, 2019, 10:45pm

Die maximal mögliche Impulslänge der PD_SCK -Pulse beim HX711 ist 50 µs. Wenn dieses pad länger als -mit Zugabe- 80 µs HIGH ist, geht der HX711 schlafen und schaltet die Erregerspannung der Wägezelle aus - dem Verbraucher, den wir hier jagen.

Dies muß in der Software manifestiert werden (this is the “how could this ever have worked” -part), - unabhängig davon, daß die hier gerade besprochenen Maßnahmen für den deep sleep -Fall des Prozessors sein sollen, und da wird auch ein gewöhnlicher GPIO anders bedient als sonst.

Heißt also: Dein Streben, die Treiber auch für nur 80 µs mal endlich interruptfest™ zu bekommen, wäre auch hier schön und ist zu begrüßen! ;)
Aber für externe pull-ups solltest Du nichts anfassen müssen.

Andreas · June 19, 2019, 10:52pm

Wir sollten noch einmal auf die Funkinterfaces schauen – die brauchen im Verhältnis definitiv am meisten Strom. Danke, @weef.

LTE-Modem ordentlich deaktiviert?

Im Pycom-Forum fanden wir ja irgendein Gefasel, dass man das LTE-Modem nur ordentlich deaktivieren kann, wenn 'ne SIM drin ist. WTF!

Hier: Stromsparmaßnahmen für die MicroPython-Firmware im Batteriebetrieb - #8 by clemens

Remove RTS/CTS jumpers on Expansion Board

Unter Umständen sollten wir aber einfach nur jenen Rat befolgen, den ich bisher überlesen hatte:

State of the onion

Aktueller Stand beim LTE-Modem pragmatisch:

github.com

hiveeyes/terkin-datalogger/blob/0.4.0/terkin/radio.py#L49-L55


      
          # We don't use LTE yet.
          try:
              log.info('Turning off LTE modem on boot')
              import pycom
              pycom.lte_modem_en_on_boot(False)
          except:
              log.exception('Shutting down LTE modem failed')

… wenn es denn so funktioniert?

Other thoughts?

Ich nehme hier gerne Vorschläge entgegen, in welche Richtungen wir noch schauen könnten.

MKO · June 19, 2019, 10:56pm

Evtl Softwareseitig noch einen internen Pull Down was erklären würde warum ich den Widerstand erhöhen musste.
Ich habe mich bisher noch nicht mit Ausgängen und Pull up und pull down beschäftigen müssen aber es scheint, das er den Pin bei False nicht auf GND gezogen wird, sondern offen/undefiniert ist.

Andreas · June 19, 2019, 11:09pm

Ok, danke. Jene Bemerkung hatte mich stutzig gemacht, die von einem invertierten Verhalten bei open drain spricht:

MKO · June 19, 2019, 11:15pm

Ja mit der FET-Schaltung wird das Signal Extern umgedreht False wird zu True und umgekehrt.
Daher müßte man Softwareseitig auch wieder alles umdrehen, damit es wieder hinter der FET-Schaltung wieder wie gewünscht ist.

MKO · June 19, 2019, 11:20pm

Habe in deinem verlinkten Beiträgen gelesen, das das Modem anscheinend 30-60 Sec braucht um sich schlafen zu legen. Habe daher mal auf 120 Sec gestellt um das zu testen. Leider Fehlanzeige der Wert bleibt wie angenagelt bei 67mA stehen.

Meinem Modem habe ich bisher aber noch kein Firmwareupdate gegönnt meine das mal irgendwo gelesen zu haben, das extra Flashen kann/muss, Richtig?

clemens · June 20, 2019, 7:39am

Meine Messungen oben waren schon ohne expansion board, aber sollten wir im Hinterkopf behalten, wenn wir des Zusatzboard (z.B. für SD) nutzen.