Forum

Servus Zusammen,

Ich hab mir einen ATMega328p (8MHz interner Oszillator) mit einem 433MHz-Funkmodul (H34A) und einem DHT22 zusammengelötet und das ganze mit 3xAAA versorgt. Der µC liest den DHT22 jede Minute aus und sendet die Messwerte via 433MHz an einen Empfänger (die Daten werden 3 mal im Abstand von 250ms übertragen).

Das ganze hat jetzt mit einem Satz Batterien so rund sechs Monate funktioniert. Der erste Messwert in der DB ist von 2019-11-13 01:43:41.0 und der letzte Messwert ist von 2020-05-06 21:05:42.0.

Für den ersten Versuch finde ich das schon mal nicht schlecht. Allerdings frage ich mich ob da noch mehr geht um die Batterielebensdauer zu verlängern. Also ganz abgesehen davon, einfach das Intervall der Messungen zu vergrößern und damit den µC noch länger schlafen zu legen. Macht es hier Sinn nach weiteren Optimierungsmöglichkeiten zu suchen ohne das Messintervall zu vergrößern?

Gruß
Bastelix

Ich habe mal eine andere Bibliothek ausprobiert ( https://github.com/zeitgeist87/RFTransmitter ) und kommt damit beim senden auf Peaks um die 6mA bis 8mA laut DMM (genauer messen kann ich das leider nicht ohne viel Aufwand für die Messung zu betreiben, was dann auch wieder Fehleranfälliger wird - wird die Langzeitmessung über die Batterielebensdauer genauer zeigen).

Die Nutzdaten habe ich auch optimiert und komme jetzt auf 3 Byte statt den vorherigen 9 Byte. Damit habe ich aber noch keine Messung durchgeführt, das steht noch auf der Agenda. Ebenso die Reichweitentests, wobei ich mir da eher keine Sorgen mache, da mein Empfänger eine recht empfindliche J-Antenne verwendet

Um den Stand-By-Verbrauch habe ich mich auch noch nicht gekümmert, erstmal soll das funken weniger Strom verbrauchen.

Übrigens, wer die RFTransmitter-Lib bei 8MHz verwenden will sollte die pulseLength auf 200 setzten (Sender und Empfänger), mit 100 (default) und 150 kann nur ca. jedes zwölfte Datenpaket decodiert werden.

Update 2020-06-07: Hab jetzt die kleineren Nutzdatenpakete verwendet. Bringt im Peak natürlich nichts, aber auf die Laufzeit sollte es eine Auswirkung haben.

Update 2020-06-30: Ich hatte da noch einen Bug. Ich habe immer die maximal mölgiche Länge der Payload übertragen, anstatt nur die wirklichen Nutzdaten. Hab mir jetzt auf Basis von dem RFTransmitter/RFReceiver-Libs selber etwas geschrieben und kommt jetzt im Peak (trägheit vom DMM berücksichtigen) auf 4,5mA - manchmal ganz sehr kurz auch noch 8,2mA. Mal schauen was die Langzeitmessung mit Batterien bringt.

Noch ein Vorteil der RFTransmitter/Receiver-Lib und meiner darauf basierenden Implementierung - der Code passt auch in einen ATTiny45 (incl. Code für den DHT22), was eigentlich nochmal ein paar mA sparen könnte - hab ich aber noch nicht ausprobiert, bisher nur compiliert.
Ich schau jetzt mal wie es sich mit der Reichweite verhält und dann gehts weiter

Update 2020-06-30 (mal vor 0:00Uhr ): Leider zu früh gefreut, die Reichweite ist eher suboptimal im Vergleich zu RH_ASK. Die Fehlerrate geht leider recht schnell hoch sobald ein paar Wände dazwischen sind. Da hilft auch eine Yagi-Antenne beim Empfänger nicht wirklich viel Die Sendeleistung durch mehr Spannung am Sender (bis 12V) möchte ich nicht erhöhen da ich ja eigentlich Strom sparen will. Ich experimentiere weiter...

Update 2020-07-10 (nach 0:00 Uhr ): Hab mir in den letzten Tagen mal den Code von Radiohead genauer angeschaut und den Part für die ASK-Modulation extrahiert, den Memory-Footprint verkleinert und den unnötigen Overhead (der für andere Funk-Protokolle benötigt wird) entfernt. Reichweite sieht gut aus. Die Übertragung ist, wie gewohnt, sehr stabil. Denke auf der Basis werde ich weitermachen. Die Modulation ist zwar nicht so stromsparend aber ein guter Kompromiss bezüglich Antennengröße vom Sender, Spannung für den Sender, etc. (Zumindest im rahmen meiner Kenntnisse. Gut möglich, dass jemand mit mehr Ahnung von Funk und Timing da mehr rausholen kann)
Da der RadioHead-Code unter GPL und einer kommerziellen Lizenz steht habe ich mal den Lizenzgeber (anscheinend die Firma vom Autor) angeschrieben wie ich das handhaben soll wenn ich den angepassten Code veröffentlichen möchte.

» » Bei den Nutzdaten könnte ich noch etwas optimieren, da schicke ich grad
» » zwei float über den "Äther" - 4 Byte für Temperatur bzw. Luftfeuchte
» muss
» » es bei den Messbereichen eigentlich nicht sein (wie gesagt, da hab ich
» es
» » mir erstmal leicht gemacht)
»
» Es lohnt sich sicherlich zu sparen.
So, ich hab die Nutzdaten von 9 Byte auf 3 Byte reduziert. Bin mal gespannt was der Test auf der Hardware zeigt.
Beim Overhead bin ich noch am überlegen, ob ich da auch noch ein paar Bit einsparen kann. Aber erstmal schauen was die 6 Byte weniger bringen

» Ich habe hier µC die im Ruhezustand etwa 1µA verbrauchen, da sind 10µA
» schon merkbar.
Klar, wenn der µC nur 1µA braucht sind 10µA schon verdammt viel. Mein µC verbraucht im Moment noch wesentlich mehr und da das Messintervall eine Minute beträgt schenken sich die 10µA für ca. 59s gegenüber den 1mA für ca. 1s nicht viel (ganz grob geschätzt). Wenn ich das Messintervall vergrößere muss ich das nochmal genauer durchrechnen, da gibt es einen Punkt ab dem sich das komplette Abschalten vom Sensor verbrauchstechnisch rentieren wird.

» » Der Sensor hängt direkt an + oder wird er über einen Portpin mit Strom
» » versorgt?
» Der Sensor hängt direkt an + hab mir auch schon überlegt ob ich den via PIN
» versorgen will, aber der Sensor braucht kurz 1mA wenn ich ihn anstecke und
» im Power-Down-Modus nur 0,010mA. Macht also in meinen Augen nur Sinn, wenn
» ich das Messintervall (drastisch) vergrößere.

Ich habe hier µC die im Ruhezustand etwa 1µA verbrauchen, da sind 10µA schon merkbar.

» »
» https://www.airspayce.com/mikem/arduino/RadioHead/classRH__ASK.html#details
»
» Does not use the Arduino UART. Messages are sent with a training preamble,
» message length and checksum. Messages are sent with 4-to-6 bit encoding for
» good DC balance, and a CRC checksum for message integrity.
»
» Klingt nach ziemlich viel Overhead. Wieviel ms dauert denn ein Paket bei
» dir?
Ich hab mal das Oszi an den Data-Pin vom Sender gehängt. Das sind ziemlich genau 150ms für eine Übertragung.

Ich bin mir grad nicht sicher wie zuverlässig die Messwerte vom DMM bei den kurzen Strom-Peaks sind. Macht es da Sinn den Sptzen-Strom mit dem Oszi zu messen oder mir einen Daten-Logger dafür zu basteln?

» Es lohnt sich sicherlich zu sparen.
Dann gehe ich das mal an.

» Der Sensor hängt direkt an + oder wird er über einen Portpin mit Strom
» versorgt?
Der Sensor hängt direkt an + hab mir auch schon überlegt ob ich den via PIN versorgen will, aber der Sensor braucht kurz 1mA wenn ich ihn anstecke und im Power-Down-Modus nur 0,010mA. Macht also in meinen Augen nur Sinn, wenn ich das Messintervall (drastisch) vergrößere.

» » » Auch den AC? Der ist im Standardfall glaub ich auch an.
» » AC höre ich diesbezüglich zum ersten mal. Wofür steht beim ATMega328p
» die
» » Abkürzung?
»
» Damit meine ich den Analog-Comparator.
Dann hab ich richtig geraten. Dazu gibt das Datenblatt auf die schnelle nicht so viel her. In der avr-sleep.h sehe ich dazu
// 2313/4313 has no A/D-Converter only a analog comperator, but we can disable that, too.

Ich verwende zum abschalten des ADC einfach ADCSRA &= ~(1<<ADEN) und hab jetzt auch mal ADCSRA = 0 ausprobiert (auch auf die schnelle im Netz gefunden), was aber keinen messbaren Unterschied beim Stromverbrauch macht.

» » der hohe Sandby-Verbrauch
»
» Ist doch gar nicht so entscheidend. Der macht ja nur etwa 15% des
» Gesamtverbrauchs aus.

Hat aber Wirkungsgrad 0%.

» » Auch den AC? Der ist im Standardfall glaub ich auch an.
» AC höre ich diesbezüglich zum ersten mal. Wofür steht beim ATMega328p die
» Abkürzung?

Damit meine ich den Analog-Comparator.

» » Auch den AC? Der ist im Standardfall glaub ich auch an.
» AC höre ich diesbezüglich zum ersten mal. Wofür steht beim ATMega328p die
» Abkürzung?
»
» » Wie weckt der Controler wieder auf? Falls du den WD dafür nicht
» verwendest,
» » kannst du den auch noch abschalten.
» Ich verwende den Watch Dog Timer, der holt den µC alle 8000ms aus dem
» Tiefschlaft und zählt via Interrupt einen Counter hoch.
»
» » Nur als Anregung: Mit einem TPL5000 und einem low Power Inverter kann
» man
» » eine tolle Interrupt0/1 Source erstellen, der soll wohl nur 30 nA
» » verbrauchen. Überprüft hab ich das aber nicht.
» Hab ich mir mal notiert. Wenn es an Version 0.0.2 oder 0.0.3 der Platine
» geht werde ich mich vielleicht mal näher damit beschäftigen.
»
» » Da lob ich mir den Assembler :->
» Jedem Tierchen sein Pläsierchen
»
» » Ich denke der hohe Sandby-Verbrauch liegt hier noch im Argen. Vlt.
» nochmal
» » bei den Pegeln der Pins im Power down nachschauen, da schleichen sich
» » leicht Fehler ein.
» Kann man da mit den Pins in der Größenordnung was falsch machen?
» So oder so - die Pin-Beschaltung werde ich heute Abend nochmal prüfen

Der Sensor hängt direkt an + oder wird er über einen Portpin mit Strom versorgt?

» https://www.airspayce.com/mikem/arduino/RadioHead/classRH__ASK.html#details

Does not use the Arduino UART. Messages are sent with a training preamble, message length and checksum. Messages are sent with 4-to-6 bit encoding for good DC balance, and a CRC checksum for message integrity.

Klingt nach ziemlich viel Overhead. Wieviel ms dauert denn ein Paket bei dir?


» Bei den Nutzdaten könnte ich noch etwas optimieren, da schicke ich grad
» zwei float über den "Äther" - 4 Byte für Temperatur bzw. Luftfeuchte muss
» es bei den Messbereichen eigentlich nicht sein (wie gesagt, da hab ich es
» mir erstmal leicht gemacht)

Es lohnt sich sicherlich zu sparen.

» Auch den AC? Der ist im Standardfall glaub ich auch an.
AC höre ich diesbezüglich zum ersten mal. Wofür steht beim ATMega328p die Abkürzung?

» Wie weckt der Controler wieder auf? Falls du den WD dafür nicht verwendest,
» kannst du den auch noch abschalten.
Ich verwende den Watch Dog Timer, der holt den µC alle 8000ms aus dem Tiefschlaft und zählt via Interrupt einen Counter hoch.

» Nur als Anregung: Mit einem TPL5000 und einem low Power Inverter kann man
» eine tolle Interrupt0/1 Source erstellen, der soll wohl nur 30 nA
» verbrauchen. Überprüft hab ich das aber nicht.
Hab ich mir mal notiert. Wenn es an Version 0.0.2 oder 0.0.3 der Platine geht werde ich mich vielleicht mal näher damit beschäftigen.

» Da lob ich mir den Assembler :->
Jedem Tierchen sein Pläsierchen

» Ich denke der hohe Sandby-Verbrauch liegt hier noch im Argen. Vlt. nochmal
» bei den Pegeln der Pins im Power down nachschauen, da schleichen sich
» leicht Fehler ein.
Kann man da mit den Pins in der Größenordnung was falsch machen?
So oder so - die Pin-Beschaltung werde ich heute Abend nochmal prüfen

» » Radiohead Arduino-Bibliothke
»
» Gibts da Dokumentation?
Hier die Bibliothek http://www.airspayce.com/mikem/arduino/RadioHead/
Hier für den Treiber den ich verwende https://www.airspayce.com/mikem/arduino/RadioHead/classRH__ASK.html#details

» » Da mache ich es mir auch relativ einfach. Ich schicke einfach
» » die C-Structs für die Messwerte über den Äther.
»
» Wieviele Bit Roh- und Nutzdaten sind das?

Rohdaten: 152 Bit (7 Byte Header, Länge FCS und dann die 12 Byte Nutzdaten, sofern ich mich nicht verrechnet habe)
Nutzdaten: 96 Bit (12 Byte)

Bei den Nutzdaten könnte ich noch etwas optimieren, da schicke ich grad zwei float über den "Äther" - 4 Byte für Temperatur bzw. Luftfeuchte muss es bei den Messbereichen eigentlich nicht sein (wie gesagt, da hab ich es mir erstmal leicht gemacht)

» der hohe Sandby-Verbrauch

Ist doch gar nicht so entscheidend. Der macht ja nur etwa 15% des Gesamtverbrauchs aus.

» » Das ist sehr viel. Analogteil ausgeschaltet?
» Ich habe heute nochmal den µC neu gebrannt um sicherzustellen, dass der ADC
» abgeschaltet ist. Keine Änderung bei der Stromaufnahme im Ruhemodus.

Auch den AC? Der ist im Standardfall glaub ich auch an.

» » Welche Sleep-Mode verwendest du denn?
» Ich verwenden die avr-sleep Bibliothek für Arduino, der sleep-mode ist
» SLEEP_MODE_PWR_DOWN. ADC, SPI, USART0 und TWI sind auch abgeschaltet. Alle
» nicht verwendeten PINs setzte ich auf INPUT_PULLUP.

Wie weckt der Controler wieder auf? Falls du den WD dafür nicht verwendest, kannst du den auch noch abschalten.
Nur als Anregung: Mit einem TPL5000 und einem low Power Inverter kann man eine tolle Interrupt0/1 Source erstellen, der soll wohl nur 30 nA verbrauchen. Überprüft hab ich das aber nicht.

» » Den Takt von 8 MHz auf 1 MHz setzen reduziert den Strom bei 4 V um etwa 3
» mA im aktiven Zustand. Kann sich je nach Anwendung lohnen.
» Wen ich das noch richtig im Kopf habe kann es Probleme mit der
» ASK-Bibliothek geben, wenn der µC nur mit 1MHz läuft. Ich habs mal
» ausprobiert und über fünf Minuten keine Messwerte empfangen.

Da lob ich mir den Assembler :->

» » Naja, der Sender braucht da im Schnitt viel mehr. Da kann man wohl
» deutlich mehr rausholen, z.B. durch eine sparsamere Modulation.
» Für die Übertragung verwende ich die Radiohead Arduino-Bibliothke (analog
» zum Empfangen auf einem andren µC) mit RH_ASK. Da mache ich es mir auch
» relativ einfach. Ich schicke einfach die C-Structs für die Messwerte über
» den Äther. Da könnte man vermutlich schon an der übertragenen Datenmenge
» noch etwas optimieren und dann halt beim Auslesen etwas mehr Aufwand
» betreiben. Aber ich glaube das macht auch nur ein paar µA/ms aus. Ist das
» ASK-Modulationsverfahren so stromhungrig? Welche alternativen gäbe es?
» Wobei ich mir im Moment nicht zutraue in endlicher Zeit eine andere
» Modulation selber zu implementieren, falls das mit der eingesetzten
» Hardware überhaupt gehen würde.
»
» Ich hab das ganze auch nochmal ohne Sleep-Mode auf den µC gebrannt und dann
» frisst die Platine stolze 4,88mA im Ruhemodus.

Ich denke der hohe Sandby-Verbrauch liegt hier noch im Argen. Vlt. nochmal bei den Pegeln der Pins im Power down nachschauen, da schleichen sich leicht Fehler ein.