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.
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:
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.
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?
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.
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.
Wir sollten noch einmal auf die Funkinterfaces schauen – die brauchen im Verhältnis definitiv am meisten Strom. Danke, @weef.
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
Unter Umständen sollten wir aber einfach nur jenen Rat befolgen, den ich bisher überlesen hatte:
Aktueller Stand beim LTE-Modem pragmatisch:
… wenn es denn so funktioniert?
Ich nehme hier gerne Vorschläge entgegen, in welche Richtungen wir noch schauen könnten.
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.
Ok, danke. Jene Bemerkung hatte mich stutzig gemacht, die von einem invertierten Verhalten bei open drain spricht:
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.
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?
Meine Messungen oben waren schon ohne expansion board, aber sollten wir im Hinterkopf behalten, wenn wir des Zusatzboard (z.B. für SD) nutzen.
Danke fürs Testen! D.h. Warten nutzt nichts, dann könnte es nach der aktuellen Lage noch das geschilderte Verhalten sein, dass man nur ausschalten kann, wenn eine SIM-Karte eingelegt ist! :-/
Ja, kann es heute Abend nochmal testen. Hab noch ein paar alte und neue Sims liegen. Hoffe Mal das klappt auch mit irgendeiner abgetragen deaktivierten Sim.
Das LTE Modul neu zu flashen ist auch ein Fall für sich. Hab mir das gestern Mal kurz angeschaut. Würde ich versuchen zu vermeiden, vor allem da ich noch nicht weiß ob er überhaupt was bringen könnte. Nicht umsonst ist diese Firmware bei Pycom in einem Passwort geschützt Bereich zu finden.
Die aktuelle Ausbeute sind ~17,75 Stunden Akkulaufzeit.
Folgende Details sind dabei fürs Kontrollzentrum interessant:
Danke für Eure Mithilfe!
Die SIM muß nur überhaupt lesbar sein und braucht kein Guthaben. Danke, @weef.
Von letzterem würde ich mich nicht per se abschrecken lassen. Das ist vermutlich nur irgendwelchen Vertriebs-Policies geschuldet, die Pycom ihrerseits wahrscheinlich mit ihren Zulieferern eingehen musste – in diesem Fall dem Hersteller des Sequans Modems bzw. des Baseband-Chips, der darin verbaut ist.
Diese Domäne konnte bisher leider noch nicht von Open Source Implementierungen erschlossen werden, da das Know-How von den entsprechenden Herstellern intensiv gehütet wird. Entsprechend sensibel und diffizil gestaltet sich oft der Umgang mit jeglichen Firmwarebestandteilen in diesem Bereich.
Habe jetzt aber mal was richtig Gutes zu verkünden. Ich habe den Test mal mit dem WiPy wiederholt.
und was soll ich sagen 0.00A im Deep Sleep mit allen Sensoren und WLAN nur die MQTT und HTML Übertragung war aus genau so wie gestern mit dem FiPy.
Unter 0.00A konnte ich allerdings nicht Messen, da ich mein Messgerät in der Firma liegen lassen habe und mein Digitalnetzteil es nicht genauer ausspuckt.
Testbedingungen:
Großes Lob an dich @Andreas und alle die dir auf dem weg geholfen haben.
Wär doch gelacht, wen wir den FiPy nicht auch noch kleinlaut bekommen.
Hi Michael,
Sehr schön!
Bei Dir hat es im Vergleich zu vorher also vor allem der
gebracht? In dem Fall gebe ich das Lob gerne an die Hardware-Gurus unter uns weiter.
Ich frage mich noch, ob gerade für die korrekte Ansteuerung des Pullups der commit Sleep for 80 microseconds after pulling HX711 clock pin to high · hiveeyes/terkin-datalogger@fedbe6f · GitHub relevant ist, der nach dem 0.4.0 Release dazugekommen ist. Hast Du also sicher die 0.4.0 drauf oder den aktuellen HEAD/master aus dem Git repository?
Am Ende ist die leichte Softwareanpassung vermutlich sogar wurscht, weil ja nach dem Einschlafsignal ohnehin nicht mehr mit dem HX711 kommuniziert wird und er auch ohne die Verbesserung der Software alleine durchs Vorhandensein des Pullups nun sauber einschläft.
Mutmaße ich hier richtig?
Aktuelles master also inkl. pause
Ist aber der gleiche stand, von gestern Abend mit dem FiPy. Wenn Du möchtest kann ich das gerne mal rauskommentieren.
Ja sollte wurscht sein wichtig ist nur das das Signal min 80 microsekunden lang ist. und das ist es ja, auch wenn der WiPy in diesem falle vorher schon einnickt.
ja, hast Du nun den pull-up (an PD_SCK) dran oder nicht?
Ja habe ich.
Allerdings einen recht hohen 1MOhm.
10 K gingen nicht, da der HX711 dann nicht immer zuverläßig aufgewacht ist.
Ich vermute, das das Gate nur nach 3V3 hochgezogen wird und im False zustand offen / Hochohmig ist.
