Forum

» » 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.
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 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.

» »
» 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.

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

» 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.

» » 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 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.