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?
1 Like
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.
Akkulaufzeit
Einleitung
Zwischenbilanz
State of the onion
Die aktuelle Ausbeute sind ~17,75 Stunden Akkulaufzeit.
Folgende Details sind dabei fürs Kontrollzentrum interessant:
- Firmwarestand 0.5.0dev-b0e7c9de.
- Nackter FiPy ohne externe Sensoren auf Expansion Board v3.1.
- Pseudo-Meßzyklus: Alle 60 Sekunden, mit Deepsleep.
- Logging gebändigt: Nur Aufwach-Hello und Deepsleep-Byebye kommen durch.
- RGB-LED gezähmt: Nur zweimal kurz grün beim Start des Datenloggers statt dauerhaft alle 4 Sekunden als Heartbeat.
- Einstellungen für Voltage Divider via Expansion Board an Pin 16 justiert:
2 x 1000 kOhm, 11dB attenuation.
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.
1 Like
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:
- Datalogger 0.4.0
- WiPy 3.0
- Firmware 1.20.0.rc11
- Clemens Solar Board V0.0.14 ohne Solarregler!
- Bosche H40
- Hx711 mit pullup
- 6X DS1820
- 1x BME280
- WLAN an und verbunden
- keine Datenübertragung aktiv
- Eingangsspannung 4.2V
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.
1 Like
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.
Im Sinne von
wollte ich an dieser Stelle nochmals auf Low power ESP32: Software tweaking (less hardware) verweisen, vor allem aber explizit auf die Inhalte bei Schaltbare Stromversorgung für Verbraucher bei Pycom Modulen hinweisen.
Vermutlich machen wir gerade alles richtig alles besser als bisher, aber Luft nach oben ist bekanntlich immer ;]. Remember: I’m not the hardware guy here, so don’t believe me anything about that topic and think for yourself first ;].
Danke an alle fürs mittun!
Was ich hierzu noch im Hinterkopf hatte: Set Level of GPIO at sleep. Es scheint eine Funktion rtc_gpio_set_level() zu geben. Kann man damit etwa mit der RTC-Einheit emulieren, was wir gerade mit dem Hinzufügen des Pullup erreicht haben oder ist das kompletter nonsense?
emulieren? wie kommst Du denn dadrauf? ;) nein. rtc_ meint in diesem Kontext die “backup domain” oder “RTC domain”, eben alles, was im deep sleep noch mit Strom versorgt wird. Einige GPIOs sind in der backup domain, daher lassen sich deren level und states ‘einfrieren’ vor und für den deep sleep.
Sollte der PD_SCK also an einem in der RTC domain befindlichen GPIO sein, könntest Du das auch in sw machen. Wenn aber extern dann auch noch ein PU ist, dann liegen die parallel, und je nach Wert des externen Widerstands wird der Gesamt-R vielleicht zu klein für den ESP32 und seine Fähigkeit, diesen pin dann auch noch nach LOW zu ziehen.
Interne pull-ups (und -downs) sind ‘weak’ und schwanken in weiten Bereichen auch im gleichen device: ab 20k bis 80k oder manchmal 100k findet man. Ein externer Widerstand dazu sollte also auch weak sein, also hier nie kleiner als 20k, besser 50k oder 100k, fast egal. Auch 1M gehen, sind aber nicht allzu störfest.
Auf diese Weise würde ein ausreichend großer externer PU nie stören, wenn eine entsprechende Funktion in der fw dennoch eingebaut wäre; die fw kann von der Annahme ausgehen, daß es egal ist, ob ein externer R an PD_SCK ist oder nicht, sobald die von Dir erwähnte Funktionalität erschlossen sein sollte.
Solange das nicht der Fall ist, oder PD_SCK an einem nicht in der backup domain befindlichen GPIO: dann hilft hier nur ein externer weak pull-up.
1 Like
Danke, @weef!
GPIO state im deep sleep einfrieren
Herzlichen Dank für die genaue Beschreibung und die Aufklärung über RTC == “backup domain”. So in der Art meinte ich das, “emulieren” war unglücklich gewählt, weil mir der passende Jargon und v.a. das Fachwissen leider gänzlich fehlt.
Wir könnten also alternativ zum externen Pullup anstreben, jenes Feature hier zu benutzen?
Zusammenspiel zwischen internem “hold” und externem PU
Praktisch!
Fazit
Ich würde das softwareseitig so erschließen, wenn niemand Veto einlegt. Hardwareseitig: Kümmern sich diejenigen um dieses Detail, die hier mitlesen und sich zuständig fühlen? Danke!
Voraussetzung dafür ist, daß PD_SCK an einem der genannten GPIO ist:
Das sind laut Angabe also P2-P20 modulo P5, P7, P11 und P12.
=> Scheint so:
Damit hätten wir also vermutlich “How could this ever have worked?” bestens aufgeklärt. Danke!
Würde ich erst mal mit Vorsicht genießen die Aussage! Den ADS und auch den HX711 nutze ich ohne externe pull-ups! Beim ADS hatte ich den Stromverbrauch gemessen und der war ok, was ich damals - mehr aus Vorsicht als aus Wissen gemacht habe - den ADS mit einem normalen Pin mit Strom versorgt, dann kann man den kompletten Zweig abschalten. Meinen HX711 mit dem ESP8266 bzw. ESP32 und dem C-Code muss ich nochmal durchmessen!
Doof sind immer Pins, die high einen sleep mode oder “ausgeschaltet” triggern. Diese brauchen dann für unsere Verhältnisse recht viel Strom.
Die Aussage ist natürlich völliger Schrott, mea culpa.
Vielen Dank für diese Erklärung, @weef. Irgendwann kann ich sogar die Hardware verstehen.