Hallo,
ich würde gerne von diversen Pflanzen den Feuchtigkeitsgehalt der Erde
messen und diesen per WLAN weiter melden. Mit diesen Daten könnten dann
Alarme oder Steuerungen aktiviert werden. Aber zuerst geht es nur um die
Feuchtigkeitsmessung - vermutlich mit kapazitivem Sensor - und der
Datenweiterleitung übr WLAN mittels ESP8266 oder ESP32.
Hauptaugenmerk soll auf einer möglichst langen Batterielaufzeit liegen.
Bestenfalls soll eine kleine Batterie für min. ein Jahr ausreichen.
Natürlich kann man das durch die Länge und Anzahl der Messvorgänge
beeinflussen.
Daher reduzieren wir das am Besten auf einen Messvorgang, um das zu
vereinfachen.
Wäre es Stromsparender, die gesamte Arbeit (Messung und WLAN-Versand)
durch einen ESP8266 oder ESP32 zu erledigen? Oder sollte man das auf
einen ATmega + ESPxxxx aufteilen? Ggf. auch Etwas anderes als einen
ATmega?
Stand Jemand schon mal vor dem gleichen Problem und kann dazu Hinweise
geben, wie es gemacht werden sollte, wenn die Schaltung möglichst wenig
mA verbrauchen soll?
Grüße
Artur
Löse Dich von dem Bastelkrams!
1. WLAN und Stromparen geht nicht. Ein Jahr mit einer Batterie und WLAN
ist illusorisch. Es sei denn, Du nimmst eine fette Laternenbatterie.
Wenn Du Strom sparen willst, nimmst Du IEEE 802.15.4 bzw etwas darauf
aufsetzendes wie Zigbee, Thread, 6LowPan etc. Damit kommt das Jahr in
Reichweite. Das ist auch die Technologie, die z.B. bei den Philips Hue
und anderen Lampen verwendet wird.
2. AVR ist nicht die ideale Plattform, wenn es um Stromsparen geht. Das
ist alte 5V-Technik. Du willst mit der Betriebsspannung möchlichst weit
herunter, weil diese quadratisch in die Verlustleistung eingeht. Heißt:
Halbe Spannung -> viertel Leistung. Ja, ich weiß, es gibt auch einige
AVRs, die das auch können. Andere können das aber besser.
3. Die ganzen IEEE 802.15.4 Chips haben einen frei programmierbaren
Applikationsprozessor, so dass ein extra Prozessor unnötig und
kontraproduktiv ist.
Meine Vorschläge:
1. TI mit der CC25** oder CC26** Serie.
2. SiLabs, z.B. sowas hier
https://www.silabs.com/documents/public/data-sheets/mgm13s-datasheet.pdf
3. NordicSemi
https://www.nordicsemi.com/Products/Low-power-short-range-wireless/nRF52840
Da siehst Du, dass die Leute nicht mit mA, sondern auch mit µA rechnen.
Ja, ich weiß, ist alles Neuland für Dich, aber da musst Du halt durch.
fchk
Nimm doch als Grundlage einen emonTH, und da einfach den
Feuchtigkeitssensor dran. Auf der anderen Seite einen Raspberry mit
einem RaspyRFM Modul oder einen USB Stick mit RFM69.
Frank K. schrieb:> 2. AVR ist nicht die ideale Plattform, wenn es um Stromsparen geht. Das> ist alte 5V-Technik.
Theorie und Praxis: Ein AT328 @ 5 Volt Arduino *) geht im Schlafmodus
auf wenige µA herunter. Wenn das Ding 10µA nimmt, sind das knapp 90 mAh
pro Jahr, die tun nicht weh.
Natürlich kann mit anderen Controllern weniger erreicht werden, das
Ideal bringt aber nichts ein, weil die Selbstentladung der Versorgung
höher liegt.
*)
http://www.home-automation-community.com/arduino-low-power-how-to-run-atmega328p-for-a-year-on-coin-cell-battery/> WLAN und Stromparen geht nicht.
Das ist wirklich eine Rechenaufgabe, weil der Aufbau der Verbindung aus
dem Schlaf heraus deutlich länger dauert als die eigentliche
Datenübertragung.
Manfred schrieb:> Wenn das Ding 10µA nimmt, sind das knapp 90 mAh> pro Jahr, die tun nicht weh.
Ich meine, dass die Stromaufnahme tatsächlich sogar nur um 1µA sei.
Wohingegen ESP8266 und ESP32 mehr als 10µA (viele haben um 25µA
gemessen) aufnimmt. Dann sollte man noch bedenken, dass es ESP8266 nur
einen ADC Eingang hat.
Ich würde einen AVR Mikrocontroller verwenden (der hat viele analoge
Eingänge) und daran einen ESP8266 mit AT-Firmware, der in den Pausen
ganz Stromlos geschaltet wird. Der AVR hängt direkt an der Batterie, der
ESP8266 bekommen einen Spannungsregler, welcher vom AVR ein/aus
geschaltet wird.
Was du auch bedenken solltest: Die ESP Chips brauchen zum Aufwachen sehr
viel länger, als ein einfacher AVR (egal ob mit oder ohne WLAN), und
verbrauchen dabei entsprechend viel Strom. Das Aufwach-Intervall ist
beim ESP8266 maximal 70 Minuten.
Es müssen, wahrscheinlich, doch auch nicht jede Stunde die Messwerte
übermittelt werden.
Einmal am Tag und wenn Schwelle unter oder überschritten wurde könnte
doch reichen und spart massig Energie ein.
Viel größere sorgen würde mir die Langzeitstabilität des Sensors im
Boden machen.
Ist aber auch nur so ein Gefühl, keine Erfahrung.
Viel Erfolg mit dem Projekt
Frank K. schrieb:> 2. AVR ist nicht die ideale Plattform, wenn es um Stromsparen geht. Das> ist alte 5V-Technik. Du willst mit der Betriebsspannung möchlichst weit> herunter, weil diese quadratisch in die Verlustleistung eingeht.
Du vergisst die Taktfrequenz als ganz entscheidenden Hebel für die
Stromaufnahme und die geht linear ein.
Was meinst du mit "5V-Technik", wenn der AVR z.B. mit 2V läuft?
Wolfgang schrieb:> Frank K. schrieb:>> 2. AVR ist nicht die ideale Plattform, wenn es um Stromsparen geht. Das>> ist alte 5V-Technik. Du willst mit der Betriebsspannung möchlichst weit>> herunter, weil diese quadratisch in die Verlustleistung eingeht.>> Du vergisst die Taktfrequenz als ganz entscheidenden Hebel für die> Stromaufnahme und die geht linear ein.
Sicher. Ein höherer Takt heißt aber auch, dass der Prozessor Beim
Erledigen einer definierten Aufgabe schneller seinen Ruhezustand
erreicht. Die korrekte Antwort heißt "Wie viel mJ braucht eine bestimmte
Aufgabe?" Dazu gibt es zahlreiche Papers, z.B.:
https://www.silabs.com/documents/public/application-notes/an0027.pdf
Viele EnergyMicro (jetzt SiLabs) Boards haben Hardware zur
Verbrauchsmessung mit drauf. Damit kann man schon einiges an
Erkenntnissen selber gewinnen. Und genau deswegen wäre das für die
aktuelle Fragestellung eine geeignetere Plattform.
> Was meinst du mit "5V-Technik", wenn der AVR z.B. mit 2V läuft?
Den Halbleiterprozess. Wobei auch das ein komplexes Thema ist.
Viele Leute hier verteidigen den AVR, weil sie einfach nichts anderes
kennen. Sicher kommt man damit auch recht weit - keine Frage. Für Profis
wie meinereiner (ich mach Elektronik- und Embedded Software Entwicklung
seit 35 Jahren und seit 25 Jahren im Hauptberuf) ist diese Architektur
aber inzwischen uninteressant, weil es besseres gibt.
Und auch für die Problemstellung des Fragestellers gibt es geeigneteres,
insbesondere bessere Funktechnik. Muss ihm halt nur mal jemand sagen.
fchk
Thomas schrieb:> und behauptet was von 20 uA
Ich würde es nachmessen.
Denn beim Punkt Stromaufnahme hat Espressif jahrelang gelogen, dann
später extrem beschönigt (alle Angaben im DB des ESP8266 beziehen sich
auf 3,3V 25°C, aber den minimalen (nicht maximalen) Ruhestrom geben sie
für dazu optimal passende Extrem-Bedingungen an).
Seriöse Hersteller geben den maximalen Ruhestrom unter normalen
Bedingungen an - nur so nebenbei bemerkt.
Dazu kommt, dass die Hersteller/Händler von Modulen die kleinsten Zahlen
(aus dem ältesten preliminary draft Datenblatt) für den nackten Chip
einfach für ihr ganzes Board übernommen haben. Als ob die Bauteile um
den Chip herum keine Ruhestromaufnahme hätten.
Nun geht es hier nicht um den ESP8266 sondern um den ESP32, den es im
übrigens in vielen Varianten gibt. Aber ich erwarte nicht, dass diese
Welt plötzlich ehrlich geworden ist.
Ich denke schon dass man dem Hersteller von diesem TinyPico glauben kann
dass er den Stromverbrauch richtig gemessen hat. Aber selber messen muss
man sowieso...
Kolja L. schrieb:> Viel größere sorgen würde mir die Langzeitstabilität des Sensors im> Boden machen.
Das!
Ich würde erstmal versuchen überhaupt einen zuverlässigen Feuchtesensor
zu bauen bzw zu ermitteln wie so etwas überhaupt beschaffen sein muß
damit er zuverlässig funktioniert (Hint: das kapazitive Gedöns das den
Leuten immer als erstes durch den Kopf schwirrt hat noch nie bei
irgendwem zuverlässig über längeren Zeitraum funktioniert), dann erst
wenn dieses Problem gelöst ist würde ich anfangen zu planen wie man das
ganze Gebilde dann mit Batterie und Funk ausstatten kann.
Frank K. schrieb:> WLAN und Stromparen geht nicht.
Unter bestimmten Voraussetzungen geht es sehr wohl.
Senden nur dann, wenn sich die Daten ändern (außer der stündlich
Alivemeldung mit Batteriestatus, hier kann auch der Messwert mit
übertragen werden).
Stromsparender Co Mikrokontroller, der den ESP 8266 an und weg schaltet
und die Messungen durchführt. In meinen Fall ein MSP430G2553. Die
Sensoren sind seit März in Betrieb und habe seit dieser Zeit über je
5600 IP/UDP Telegramme (Beispiel siehe Screenshot) versendet. Die
Batteriespannung liegt noch bei 3383mV.
Zwei Lithiumprimärzellen LS14500 mit je 2600mAh bei 3,6V
Ich habe 10 Sensoren im Dauereinsatz.
Ich gespannt wie lange die Batterien noch durchhalten.
Wenn man Energie sparen will, muss man einfach nur abschalten!
Klingt etwas komisch ist aber so.
Also genau überlegen, ab man Messwerte im µS-Bereich braucht, oder ob es
reicht alle 1/4 Stunde nachzusehen.
Es gibt mittlerweile einen Low-Energy Funker, der zwar ursprünglich für
geringe Datenvolumen gedacht ist, aber auf einen gelegentlichen
Feuchtewert, trifft das wohl zu.
Grundsätzlich ist alles, was auch nur im Entferntesten mit Funk zu tun
hat, energiehungrig.
Lass alles, was sich Anzeige schimpft außen vor. Bist Du mehr der
Augenmensch, so spendiere Deinem Design wenigstens einen "Guck-Taster",
der eine Unterbrechung auslöst und einen Zeiter, der dem Jammer
möglichst bald ein Ende bereitet.
Schon im Design darauf achten, dass man bei allem, was da ist, den
Stecker ziehen kann. Gibt es keinen effektiven Disable, so muss halt ein
FET einspringen, der den Saft abdreht.
Eine CPU mit sleep modes, die auch den Namen verdienen, nutzen. Letzere
auch sinnvoll implementieren. Hier ist das Problem dass man oft Fehler,
in diesem Bereich, nicht bemerkt. "Es geht ja" - wenn nur die Batterie
länger halten würde.
In diesem Zusammenhang werden auch gerne die Zieh-Hochs vergessen und
die Ein-/Ausgänge, die (gerade) nicht gebraucht werden.
Also wie im ersten Satz gesagt: Abschalten was geht und nicht versuchen
irgendwelche Geschwindigkeitsrekorde zu brechen.
Sebastian S. schrieb:> Grundsätzlich ist alles, was auch nur im Entferntesten mit Funk zu tun> hat, energiehungrig.
Grundsätzlich ist hauptsächlich der Empfang energiehungrig. Der Sender
kann meist ausgeschaltet sein und einen Empfänger braucht man für viele
Dinge nicht.
WLAN ist da etwas großzügig mit bidirektionaler Kommunikation, alleine
schon durch den Protokolloverhead.
Was spricht gegen einfachere Sender, die z.B. per MQTT-SN die Daten über
einen zentralen Gateway ins WLAN schicken?
Bernd K. schrieb:> Ich würde erstmal versuchen überhaupt einen zuverlässigen Feuchtesensor> zu bauen bzw zu ermitteln wie so etwas überhaupt beschaffen sein muß> damit er zuverlässig funktioniert
Das Thema wurde doch schon öfter diskutiert, z.B. Druckmessung per
Tensiometer
Beitrag "Re: Schaltplankontrolle - Tomatenbewässerung"
Wolfgang schrieb:> Bernd K. schrieb:>> Ich würde erstmal versuchen überhaupt einen zuverlässigen Feuchtesensor>> zu bauen bzw zu ermitteln wie so etwas überhaupt beschaffen sein muß>> damit er zuverlässig funktioniert>> Das Thema wurde doch schon öfter diskutiert, z.B. Druckmessung per> Tensiometer> Beitrag "Re: Schaltplankontrolle - Tomatenbewässerung"
Korrekt. Ich wollte mit dem Zaunpfahl genau in diese Richtung winken.
Wolfgang schrieb:> Grundsätzlich ist hauptsächlich der Empfang energiehungrig.
Daher ist es wichtig Aktoren und Sensoren zu trennen!
Bei Sensoren, z.B. Einbruchs.- und Klimasensoren, wird nur gesendet wenn
sich etwas ändert. Empfangen wird nur unmittelbar nach dem Senden um die
Empfangsbestätigung abzuwarten und auszuwerten um gegebenenfalls mit
einer Wiederholung der nicht quittierten Meldung zu reagieren. Der TxRx
Modul ist die meiste Zeit inaktiv. Anders das Gegenüber, welches immer
empfangsbereiten sein muss. Reine Sensormodule lassen sich leicht mit
Batterien betreiben.
Das Gegenüber, z.B. ein Raspberry, hängt meisten an der Netzversorgung
und ist meist für mehrere Sensoren zuständig.
Anders sieht es mit Aktoren, z.B. Sirenen und
Netzversorgungszwischensteckern aus. Hier müssen die Empfänger ständig
aktiv sein. Aber hier brauchen die anzusteuernden Komponenten ebenfalls
viel Strom, müssen aber meist nicht mit Batterien betrieben werden.
Sebastian S. schrieb:> Eine CPU mit sleep modes, die auch den Namen verdienen, nutzen. Letzere> auch sinnvoll implementieren. Hier ist das Problem dass man oft Fehler,> in diesem Bereich, nicht bemerkt. "Es geht ja" - wenn nur die Batterie> länger halten würde.
Daher ist es wichtig, dass der MC nicht nur im Sleep Modus sehr sparsam
ist, sondern auch im Betrieb um Überwachungsfunktioen durchführen zu
können. Der MC lässt sich meist über die Sensoren, wie z.B. Reedkontakte
und Bewegungssensoren, mittels Interrupt aus dem Schlaf holen.
Sebastian S. schrieb:> In diesem Zusammenhang werden auch gerne die Zieh-Hochs vergessen und> die Ein-/Ausgänge, die (gerade) nicht gebraucht werden.
Das ist ein sehr wichtiger Punkt beim Energisparen. Die internen
Pullups des MSP430G haben etwa 47k Ohm, können aber nicht
weggeschaltet werden, sonst könnte der MC nicht jederzeit aufgeweckt
werden oder es sind, im Ruhezustand, geschlossene Reedkontakte im
Spiel.
Hier hilft es nur die internen Pullups abzuschalten und externe Pullups
mit z.B. 1M Ohm zu verwenden sonst würden alleine die Pullups mehr Strom
als der schlafende MC benötigen. Da diese Signale nicht sehr schnell
sein müssen, kann mit einem Kondensator ein Tiefpass geschaltet werden.
Aber Achtung ein kleiner Widerstand in Serie zum Kontakt verhindert eine
kurzschlussartige Entladung dieses Kondensators beim Schließen des
Reedkontaktes. Der Kontakt wird es mit höherer Lebensdauer danke.
Wolfgang schrieb:> Grundsätzlich ist hauptsächlich der Empfang energiehungrig.
Nur bei völlig "dummen" Protokollen. Eigentlich gemeint ist: bei
Protokollen, bei deren Entwurf diese Problematik nicht berücksichtigt
wurde.
Allerdings: die cleveren Protokolle erfordern wiederum, dass der
"Empfänger" auch senden kann und zusätzliche, dass er eine halbwegs
zuverlässige Zeitbasis besitzt, die leider energetisch auch nicht für
lau zu bekommen ist. Ist aber immer noch sehr viel billiger als
"Dauerlauschen".
Schon Module wie der RFM12 haben vor vielen Jahren diese Anforderungen
erfüllt...
temp schrieb:> Die Dinger verwenden BLE und wie man ohne App die Dinger auslesen kann> wurde auch schon analysiert. Hab das hier zum Testen mit einem ESP32> Board am laufen. Das kann dann per BLE die Sensoren abfragen und die> Ergebnisse per WLAN weiter senden.> https://github.com/sidddy/flora
Unter den Umständen klingen die Teile dann natürlich Top!
