Mein FiPy bootet immer wenn er Strom bekommt, danach werden Sensoren, WLAN und Modems initialisiert. Ich stecke ihn jetzt ja auch in den PC oder über Nacht an eine Powerbank und es funktioniert.
Automatisiertes An- und Ab-Schalten sollte auch funktionieren.
Hier geht es um den TTGO T-Call mit SIM800, bei dem es leider nicht so einfach wie beim FiPy ist, ggf. ist ein Hardware-Design-Fehler daran Schuld.
Leider hat @clemens recht - der T-Call startet nicht, wenn man ihn einfach nur an den Strom steckt. 
Er verbraucht zwar Strom, aber er läuft erst los, nachdem man den Reset-Knopf gedrückt hat. Das passiert übrigens nicht, solange man ihn per USB versorgt. Da könnte man meinen, das das die Lösung ist. Leider nur halb. Mit USB funktioniert der Deepsleep nicht richtig. Da kommen dann die Ströme raus, die ich oben gemssen habe.
Deepsleep in 3 verschiedene Anschlussvarianten:
- per USB am PC: 19,2mA
- per USB am Akku: 8mA
- direkt per JST am board: 620uA
Das war der Fehler - so angeschlossen liegt man mit uPy in den selben Regionen wie mit Arduino-code.
Mit den Komponenten kann man das im Grunde genommen nur so lösen, wie Clemens grade vorgeschlagen hat. Das man beim TPL5110 die Zeiten nur fix einstellen kann ist zwar nicht hübsch, aber für die Einfachvariante wohl tragbar.
2 Likes
Sollten wir hier vor dem Deepsleep noch weitere GPIOs auf hold() setzen / einfrieren, ähnlich wie bei der Ansteuerung des HX711, bevor wir das Gerät schlafen legen? Im Datenblatt stehen scheinbar
Ich frage natürlich auch, ob das dann nicht auch beim FiPy weiteren Strom sparen könnte, wenn wir da bisher noch etwas nicht ganz richtig bzw. unvollständig implementiert haben.
ja, vielleicht auch dereinst-demnächst, das ist dann der Feinschliff - aber im Moment ist die Tatsache, daß sie als PMIC einen IP5306_I2C (oder wie auch immer die Nicht-LED-Variante heißt) ausgewählt haben, deutlich mehr Spaßbremse.
Die beschriebenen Probleme mit dem Nicht-wieder-starten-nach-power-restore-Verhalten rühren von der Herkunft dieses IC als power bank controller.
Translated section of IP5306 datasheet: "IP5306 can recognize long key and short key operation, PIN5 pin is vacant when the key is not needed. ● The button lasts longer than 50ms, but less than 2s, it means […]
TinyGSM example wont start from battery · Issue #8 · Xinyuan-LilyGO/LilyGo-T-Call-SIM800 · GitHub
- Change IP5306 "KEY"circuit so that it auto-starts upon VBAT input. If voltage goes very low IP5306 will shutdown and it then needs a reset button press to wake up. This is not good for unattended deployments with solar charging batteries.
Suggestion for next revision · Issue #13 · Xinyuan-LilyGO/LilyGo-T-Call-SIM800 · GitHub
PIN5 pin is vacant when the key is not needed.
… und wenn man die Leiterbahn zum pin trennt - schaltet der sich dann allein wieder an nach ‘power restored’ ?
pin5 (key) ist ja beim T-Call mit dem reset button gekoppelt, dann hängt da noch VCC3V3 dran, so und jetzt steig ich aus, die ist doch nur vorhanden, wenn der IP5306 läuft?? Das ist vermutlich auch der Fall, wenn der T-Call am USB angeschlossen ist, da brauche ich nämlich reset nicht drücken, nur wenn der T-Call über LiPo wieder angeschlossen wird (‘power restored’) muss ich zwingend reset (und damit den PI5306) triggern damit das Gesamtsystem hoch läuft.
Wie haben hier zwei Probleme:
- Wie löse ich ein reset für den IP5306 aus, wenn der T-Call komplett vom Strom getrennt ist, z.B. durch einen Timer / externe RTC mit FET
- Was passiert nach einer längeren Schlafzeit, können wir ihn wieder reaktiveren?
Generelle Überlegung:
- Könnten wir den Vin pin des IP5306 mit aktuell VBUS / den 5 V-Zweig des USB als Eingang für den LiPo nehmen? Um das Einschalt-Problem via reset zu umgehen? Vermutlich nicht!
- Macht es Sinn mit einem deep sleep-Verbrauch von 800 uA das Ding mit Batterie / Solar zu versorgen oder sollen wir uns auf was anderes konzentrieren?
Zum Thema basic battery reading gibt es hier ein posting: How to power the board? · Issue #29 · Xinyuan-LilyGO/TTGO-T-Call · GitHub, gemessen wird an pin35, der einen 100 k / 100 k voltage divider hat, (6 V source würden dann 3 V output liefern, oder 4,2 V source 2,1 V output).
Der Faktor 2380 unten wurde empirisch ermittelt. Im posting steht 2350, was bei mir mit Nachmessen nicht so gut gepasst hat.
void setup() {
// Set console baud rate
Serial.begin(9600);
delay(10);
}
void loop() {
// basic voltage reading
int batteryLevelRaw = analogRead(35);
float voltage = batteryLevelRaw / 2380.0 * 4.20;
Serial.print("basic battery lavel: ");
Serial.println(voltage);
delay(1000);
}
Über die (Un-)Genauigkeit des ADCs beim ESP hat @weef schon an anderer Stelle geschrieben, diese Grafik sagt schon sehr viel: [Answered] What are the ADC input ranges? - ESP32 Forum, daher ist es wohl auch egal, ob der Faktor nun 2380 oder 2350 oder doch was anderes ist.
Siehe auch: ESP32 Analog Input with Arduino IDE | Random Nerd Tutorials
https://github.com/m5stack/M5Stack/issues/156#issuecomment-487809103
Once the IC has gone into standby (deepSleep device for more than 30 seconds), you cannot wake it without connecting power. Such a shame this IP5306 was chosen for the M5.
Das kann ich so für den T-Call nicht bestätigen. Auch nach 60 Sekunden deep sleep wacht der wieder auf, auch 5 Minuten funktionieren, jetzt teste ich 30 Minuten … [edit1] geht auch! Bei 2 Stunden hatte ich erst mal ein Problem, 7.200 Sekunden x 1.000.000 us sind 7,2 Milliarden, da ich diese Konstanten aus einem Beispiel heraus per #define festgelegt hatte funktionierte der deep sleep nicht, mit 30 Minuten, d.h. 1,8 Milliarden us ging noch.
// timekeeping / deep sleep
#define uS_TO_S_FACTOR 1000000 /* Conversion factor for micro seconds to seconds */
#define TIME_TO_SLEEP 30 /* Time ESP32 will go to sleep (in seconds) */
[...]
// Put ESP32 into deep sleep mode (with timer wake up)
// Configure the wake up source as timer wake up
esp_sleep_enable_timer_wakeup(uS_TO_S_FACTOR * TIME_TO_SLEEP);
esp_deep_sleep_start();
Ich denke, dass default eine uint32_t verwendet wird, für die der 2 Stunden-us-Wert zu groß ist, nun habe ich statt dessen const uint64_t TIME_TO_SLEEP = 7200LL; verwendet … [edit2] und auch das funktioniert gut!
Warum kann der T-Call auch nach über 30 Sekunden aufgeweckt werden? Hat es was mit
if (en) {
Wire.write(0x37); // Set bit1: 1 enable 0 disable boost keep on
zu tun, dass es funktioniert?
1 Like
Hmm, irgendwie ist das doch alles viel zu kompliziert. Der Vorteil des T-Call ist ja nur, das das SIM800 board integriert ist. Wäre es das nicht, gäbe es eine zusätzliche Verkabelung. Wegen der o.g. Probleme braucht man aber mindestens ein zusätzliches Bauteil, was den ganzen Vorteil wieder zunichte macht. Da kann man auch gleich ein Breakout board mit dem SIM800 nehmen und einen geeigneten uC, der vernünftig schläft.
So ein board kostet 3€ beim Chinesen. Wird 2G irgendwann doch mal abgeschaltet, kann man es einfach durch ein SIM7000 board ersetzen, das dann auch nur noch 3€ kosten wird (und nicht wie momentan 30).
… und einen P-channel MOSFET, Transistor, einen voltage divider für die level-Angleichung … ja, kann (muss) man dann machen, ist nur ein Versuch das auch einfacher hinzubekommen …
Oder man nimmt ein stromfressendes und 3V3 oder gar 5V kompatibles SIM800-Modul, das könnte dann auch mit einem Uno oder was auch immer laufen ;-) und einen timer, der alles komplett stromlos schaltet.
Seit einigen Tagen läuft ein T-Call, der die LiPo-Spannung misst, diese per GSM an einen Server überträgt und dann aktuell für 2 Stunden in den deep sleep geht. Da mir nach ein paar Tagen der LiPo “zu voll” vorkam, habe ich nochmal genauer nachgemessen und siehe da, es geht noch was!
Bisher habe ich die 850 uA immer direkt nach dem Eintritt in den deep sleep gemessen. Wie es ausschaut führt das SIM800 oder der IP5306 oder was anderes auf dem board noch ein Eigenleben bzw. schläft nicht sofort tief ein. Jedenfalls hatte ich jetzt etwas mehr Geduld und mal ein Zeit länger gemessen: Knapp 40 Sekunden nachdem sich der Microcontroller in den Tiefschlaf verabschiedet hat (850 uA) geht der Stromverbrauch nochmals runter, und zwar auf ziemlich genau 500 uA! Das ist zwar nicht das was ich mir wünschen würde, aber damit könnte man bei Solarbetrieb und wenigen updates pro Tag vielleicht leben!
2 Likes
Andere Frage: hier geht es prinzipiell um eine möglichst einfache Waage, aber mit der Voraussetzung, das kein Strom und WLAN vorhanden sind.
Da es bei den Hobbyimkern doch so einige gibt, die ihre Beuten im Garten stehen haben, sollten wir nicht dann auch das Szenario ‘einfache Waage aber mit WLAN & Strom’ betrachten?
An der Waage ändert sich dadurch nichts, aber auf der Elektronik- & Softwareseite wird dadurch doch vieles simpler.
Gehört dann natürlich nicht in diesen Thread.
1 Like
Dafür haben wir hardwareseitig schon diverse Lösungen:
- BOB-Platine für FiPy - #195 by didilamken und Installation und Inbetriebnahme des Bee Observer Sensor-Kit
- BOB-Platine (Clemens)
- Open Hive WiFi Solar / Adafruit HUZZAH (noch mit DHT statt BME280)
- oder man nimmt für “Waage only” irgendein ESP32 dev-Board und schließt den HX711 wie oben per Kabel an
Weiter hätte ein Grundmodul mit ESP32 auch immer die Möglichkeit Daten via WLAN zu schicken. Wir haben aber auch beim BOB-Projekt gesehen, dass viele die ihre Bienen im Garten “hinterm Haus” stehen haben dann doch Probleme mit dem WLAN-Empfang haben oder doch kein Kabel zu den Bienen legen wollen, das auch bei Regen und Schnee 24/7 und 365 draußen liegen soll.
Was – denke ich – noch ein häufiges setting sein könnte: Datenversand per WLAN und Stromversorgung autark per Solar oder mit low power und Batterie, die man 1 bis 2x im Jahr wechselt. Oder eben gleich LoRa / TTN wenn WLAN mit Richtantenne und repeater dazwischen nicht geht.
Wenn man bei der Auswahl des ESP32-Moduls etwas aufpasst kann man so gut wie alle auch mit 5 V oder sogar mehr versorgen, d.h. statt eines Solarbetriebs sollte immer auch eine Stromversorgung am einfachsten über einen 5 V USB-Lader möglich sein.
Kurz: Ein ESP32-basiertes SIM800-System mit Solar kann immer “downgegraded” werden, wenn doch Strom und WLAN vorhanden ist. Wir brauchen (zusätzlich)
- etwas code um die Daten statt per GSM mit WLAN zu versenden
- einen Anschluss auf der Platine, um statt des LiPos 5 V von einem Netzteil anschließen zu können. Dafür habe ich mir einen Stecker aus einem USB-Ladekabel gebastelt, den Micro-USB-Stecker abgeschnitten und statt dessen einen JST-Stecker angecrimpt, dann kann ich statt eines LiPos diesen USB-Stecker verwenden. Möglich wären auch Feder- oder Schraubklemmen auf einer Platine (wie beim BOB-HAT von Didi, ist dann nur nicht verpolungssicher) oder gleich eine USB-Buchse, wie wir sie ja beim T-Com haben, da ist nur das Problem, dass ein nacktes Kabel oder ein JST-Stecker besser duch eine wasserdichte Kabeldurchführung gehen als ein Micro- oder USB-C-Stecker.
Die von Dir genannten Alternativen sind aber alle nicht qualifiziert als ‘einfach’ - nach Deiner Definition. 
Ist das nicht genau andersrum? Die Firmware kann momentan Daten per WLAN aber nicht per GSM vesenden.
Ja, das stimmt, wenn man “eigene Platine” ausschließt dann sind die oben gelisteten nicht “einfach” außer
Je nachdem von welcher firmware man ausgeht. Der Micropython-Code / Terkin datalogger kann aktuell nur WLAN, mein Arduino C-Code kann WLAN und GSM aber nur mit der alten SODAQ-GSM-lib. Mein kleiner Testsketch überträgt momentan die Batteriespannung per TinyGSM-lib.
Meinen bisherigen Arduino-C-Sketch auf die TinyGSM umzustellen würde ich mir zutrauen, auch den BME280 da statt des DHT einzubauen bekomme ich hin. Bei MicroPython habe ich gerade zu viele Bauchschmerzen nach den Erfahrungen des letzten Sommers, da hat selbst Andreas geschwitzt und viel Arbeit und Nerven investiert und mit unverhergesehenen Problemen und buggy firmware gekämpft.
Ich bin auf die GoalZero Guide 10 Plus PowerBanks umgestiegen, bisher habe ich es aber noch nicht vollbracht, den Status der LED als Metric zu verschicken (vgl. “Power Legend”), was aber möglich sein sollte
Verfolgen wir das hier weiter oder ist das Projekt tot?
Ich halte das eigentlich noch für sinnvoll. Der einzige Punkt, von dem wir uns wohl verabschieden müssen, ist, das wir ganz ohne Platine auskommen.
Es ist hier im thread ein “zweiteiliges” Projekt
- Minimal Hardware Design GSM-Stockwaage
- mit TTGO T-Call
Teil 1 sollten wir auf jeden Fall weiter verfolgen, über Teil 2 nochmal sprechen. Wir sind zwar beim Messen schon auf einen Stormverbrauch gekommen von …
… im Prinzip stelle ich mir aber imme noch die Frage:
Auch das Abschalten mit einem externen timer ist beim T-Call keine Alternative, da er nach einem Neustart nicht hoch läuft:
Der “neue” T-SIM scheint mit um die 1 mA im deep sleep keine bessere Alternative zu sein.
Da die Hardware vorhanden ist und auch die Software mit Unlocking and improving the Pythings SIM800 GPRS module for MicroPython steht sollten wir zumindest mal einen Prototypen zusammenbauen, wir hier schon skizziert, aber ohne den TPL5110, um zu schauen, wie lange der aktuell mit Solarunterstützung – eher das 2,5 W-Panel als was kleines – und einem moderaten update-Intervall von vielleicht mal bei alle 3 Stunden starten, durch hält.
Hab das gerade nochmal ausprobiert. Der EN darf tatsächlich beim Wiedereinschalten der Batterie nicht geschlossen sein, sondern muss danach einmal kurz (<1s) geschlossen werden. Sehr seltsam.
Noch seltsamer: bei 2x drücken kann man den T-Call wieder ausschalten. ???
Kann mir bitte einer der Elektrokundigen sagen, ob der EN noch irgendwo nach außen geführt wird? An dem Taster herumlöten fällt definitiv nicht mehr in die Kategorie ‘einfach’.
Alternativ könnte man den T-Call noch per USB versorgen und da die VBUS Leitung schalten. Machts aber auch nicht einfacher.