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.
Eigentlich ne super Idee! Laß uns das doch mal ausprobieren!
Schaltplanzeichnen ist eigentlich nicht so mein Metier. Also verzeiht bitte, wenn das etwas unkonventionell ist.
USB_DS3231.pdf (16,7 KB)
Diese kleine Platine ist ein Zwischenstecker für den USB-Anschluss. Der DS3231 zieht das Gate für den P-Kanal MOSFET auf low und schaltet damit die VBUS Leitung (und damit die MCU) ein.
Die MCU kommuniziert per I2C mit dem DS3231, stellt darüber die neue Weckzeit ein und zieht sich am Ende selbst den Stecker.
Der Reed Kontakt dient dazu, die MCU außerplanmäßig aus dem Schlaf zu holen. Das hat den Vorteil kontaktlos zu sein - muß man also kein Gehäuse aufschrauben.
Das funktioniert mit jeder MCU, die per USB versorgt werden kann. Das sind in diesem Kontext eigentlich alle. Der Stromverbrauch der MCU oder der Sensoren spielt hiermit dann auch praktisch keine Rolle mehr (bei ‘langsamen’ Meßintervallen).
1 Like
Das finde ich nicht so zielführend, Welche 5 V-Stromquelle sollen wir dafür nutzen? Alle USB-Powerbanks scheiden aus wegen der automatischen Abschaltung. Wie könnten die wieder mit Solar aufgeladen werden? Wieder eine höherer Spannung, die verlustbehaftet gewandelt werden muss.
Dann lieber ein stromsparendes board wie den WiPy und ein SIM800 breakout dort dran mit einem LiPo wie schon oben geschildert.
Hier gab es zum T-Call noch ein paar zusätzliche Aufrufe um Strom im deep sleep zu sparen, die haben wir noch nicht alle bei uns:
Obs was bringt waage ich zu bezweifeln, der Poster spricht immer noch von 950 uA. Das wären sogar mehr wie wir gemessen haben.
Klar ist das mit dem Wandeln doof, aber wir können die 5V für den HX711 verwenden und die Wandlungsverluste können uns auch wurscht sein, wenn wir nichts wandeln, weil wir nichts verbrauchen.
Warum mit Stromverbrauch abmühen, wenn wir den Stecker ziehen können?
Hallo @clemens,
mein aktueller Versuchsaufbau mit einem TTGO-T-CALL, 2x HX711 & 18650LiPO der mittels Solar Panel gespeist scheint seit knapp einem Monat aus zureichen um Messwerte alle 15 Minuten zu übermitteln.
(Die extremen Ausreißer im Dashboard kommen von Tests)
Sofern der Ladezustand unter 75% sinkt - wird die Schlafphase des ESP auf 60min verlängert.
Hier Generische “state-of-the-art” Arduino-Firmware für ESP8266 und ESP32 schon mal kurz skizziert.
3 Likes
misst Du den echten Ladezustand ( schwierig zu messen ) ?
Oder nur die Spannung des Akkus ( x % von 4.2 Volt )?
Ich greif dabei auf die Werte zurück die mir das GSM-Modul liefert
volt_level = modem.getBattPercent();
voltage = modem.getBattVoltage() / 1000.0F;
Hatte das aber auch in der Vergangenheit mal mit Spannungsteiler und Messung,
wobei die Ermittlung mittels Funktion natürlich deutlich komfortabler ist.
Das hört sich gut an! Welches Panel hast du, vermutlich etwas mehr als 0,5 W? :-)