(weitere) low power ESP32 boards


#1

Zu diesem Thema hier gibt es schon einen thread:

Weil die Reise bei den Meßknoten immer mehr in Richtung ESP32 geht, stromsparende (Entwickler-)Boards neben den bekannten Pycom Boards aber noch Mangelware sind, können wir hier vielleicht ein wenig sammeln und dabei sehen, was so daherkommt. Da uns die Energieversorgung sehr wichtig ist, kann sich die Auswahl auf diejenigen beschränken, die diesbzgl. überhaupt erst in Frage kommen würden.

Wichtige Anforderungen:

  • Stabile Versorgung der 2A Spitzen während des Sendebetriebs herkömmlicher GSM Modems. siehe posting weiter unten
  • Minimaler Stromfluß beim Betrieb im Deepsleep Modus für lange Laufzeiten.

#2

Man muss nicht unbedingt auf die Module verzichten, wenn man gerne die anderen Funkstandards dran hätte, aber auf ein SIM800 oder vergleichbares Modul zurückzugreifen, wird vermutlich obligatorisch werden, wenn man an das entsprechende Netz ran will.

Um aber mal über den Tellerrand hinaus auf Boards jenseits von Pycom, Adafruit & Co, zu schielen, habe ich @tonke in diesem Sinne vor kurzem erst auf diese netten Gerätschaften von Olimex hingewiesen:

Da @weef uns schon einmal auf die Grandiosität des UEXT Standards (Spec) aufmerksam machte, will ich diesen Aspekt dabei noch einmal unterstreichen. Damit kann man direkt bei der kompletten Modulauswahl unter UEXT Modules wildern gehen.

Leider versorgt uns das noch nicht mit einem SIM800 Breakout/Whatever Modul mit UEXT Connector, weil Olimex an dieser Stelle leider nur andere (teurere) GSM Modems im Angebot hat, siehe MOD-GSM und MOD-GSM-B. Die beiden Gerätschaften (ESP32 und SIM800) ordentlich elektrisch zu verbinden, müsste aber doch machbar sein? Die Stromversorgung des GSM Modems sollte wie bekannt ohnehin solide ausgelegt werden.


Abwärtskompatibilität LTE-Modems
#3

Ich denke deine Beispiele Olimex und UEXT sind hier nicht zielführend, weil sie für unser Problem keine Lösung bedeuten!

Für mich kommt als Lösung dann nur das Anflanschen eines SIM800-Moduls an einen WiPy oder LoPy in Betracht oder der GPy verbunden mit der Hoffnung auf schnellen Netzausbau 2019f.


#4

Ich hatte eigentlich nur deswegen… Sorry! Das ESP32 Built-in OLED – Heltec WiFi Kit 32 – Robot Zero One, das @RalfL bei Franken - ESP32 mit Micropython - Daten via MQTT verwendet hat, wäre ja auch eine Alternative, genau wie jedes andere Board auch. Wir haben gelernt, dass eine gute Energieversorgung ratsam wäre, während die Anflanschung an die echte Welt doch ohnehin meist über irgendein Extension Board passieren wird?


#6

Ne, eben nicht, weil die meisten DevBoards für unsere Anforderungen im deep sleep zu viel Energie fressen. Bei den ESP32 habe ich bisher nur zwei boards gefunden, die was taugen: Die xPys und den FireBeetle ESP32 von DFRobots.


#7

Achja, ich vergaß. Schade. Ist sowas am Markt wirklich so spärlich gesät? Was ist mit den WEMOS Dingern? Woran kann ich als Laie das denn von außen erkennen, wie gut das Energiebudget im deep sleep mode ist? Hilft hier nur die Evaluierung mit ordentlichem Nachmessen?


#13

Ist hier (bei der Entscheidung für ein Board) irrelevant, da das GSM-Modul direkt mit einem elektronischen Schalter direkt an den LiPo / die Batterie angeschlossen wird. Ich kenne kein Board, das so was onboard ohne das Modem auf dem PCB hat. Das ist entweder auf der SIM800-Platine wie beim GPRSBee oder anderen GSM-Platinen-/shields, oder wir müssen es auf unserer Platine machen.


#14

Die DevBoards haben geringen Stromverbrauch im deep sleep häufig nicht als Anforderung. Wichtiger sind noch ein Display und noch ein Sensor drauf und Stromversorgung von 0,1 V bis Starkstrom (ich übertreibe :-), aber Strom sparen war in der Vergangen heit so gut wie kein requirement. Sieht man auch gut daran, dass das Seeeduino Stalker Board in den letzten Jahren das einzige (!!) mir bekannte board war, das für Einsatzzwecke wie unsere auf dem Markt war.

Mit Adafruit und den nun fast schon standardmäßigen LiPo-Anschlüssen und zumindest 5V-stabilen charging circuits hat sich das etwas geändert. Man ist dann aber schon glücklich, wenn das Ding mal ein paar Tage oder eine Woche ohne Aufladen vor sich hin werkelt. D.h. immer noch keine Funktionalität in unseren Sphären!

Viele Features, die ich auch aus UX-Sicht sinnvoll finde und für ein Dev-Board auch sinnvoll sind nagen halt am Strombudget, eine LED, die einfach nur an ist, wenn Strom anliegt, blinkys, die signalisieren wenn was geschickt wird, robuste Stromversorgungen, die von 5 V bis 12 V oder darüber alles bedienen usw. usf. nice auf der workbench, unnütze und unnötige Stromfresser am Bienenstock.

Da es bisher für 95% der Nutzer keine Anforderung ist wird bei der Entwicklung kein Wert darauf gelegt, das auch nciht gemessen oder auch nicht in der Spec angegeben. Ausnahmen sind die erwähnten xPys und das FireBeetle-board von DFRobots!

Von außen siest du nicht welches Board geeignet ist, mit viel Wissen und Zeit könnte man es über den Schaltplan herausfinden, wenn man alle verbauten Teile kennt. Durchmessen ist natürlich der sichere Weg!

Daher würde ich a priori nicht ausschließen, dass es andere geeignete boards gibt, bedeutet aber noch viel research und für mich wären sie nur interessant, wenn sie dann auch schon LoRa oder GSM on board hätten.


#16

Noch etwas Grundsätzliches zu ESP32 vs. andere Boards (z.B. Cortex M0). Mein Liebling wäre eigentlich der Cortex M0! Ihr wisst schon, I2S-Mics laufen da, die Arduino-FFT haben wir schon verwendet. Hätte gerne z.B. den SODAQ Autonomo genommen, hat eigentlich alles was wir brauchen, ist nur etwas teuer.

ABER! Wenn wir im BOB-Projekt oder auch für uns den Anspruch erheben, dass auch Laien das Ding fahren können und zumindest den APN bei GSM, oder die Waage justieren / tarieren können, dann brauchen wir so was wie ein captive portal, irgend ein UI, das die Leute ohne Arduino-IDE, ohne Bibliotheken zu installieren einfach nutzen können!! Ziel wäre, dass es eine vorinstallierte (von uns, dem Technik-Guru im Imkerverein) Firmware gibt, die für alle gleich ist und APN-Einstellung, Waagen-Justierung, ggf. WLAN-Daten dann der Nutzer selbst machen kann, auch ohne viel technisches know how. Und da sehe ich momentan keine einfache, günstige Alternative zu einem WLAN-Board, daher der ESP32 und nicht der M0.