Das Baud = 57600 ist das Problem. Mit 8Mhz macht das schon unschöne 2% Fehler.
Mit Quarz könnte er mit 461khz arbeiten. Per Osccal Abgleich mit 921,5 khz.
Auch könnte er "schlafen" solange nichts zu tun ist. Jedoch ist mit der Mode nicht klar bei dem während des Schlafes der Uart funktioniert. Nur Idle?
Möglicherweise geht auch Power-Down wenn Pin D.0 (RX) mit D.2(Int0) verbunden wird.
Den Adc nur starten wenn er gebraucht wird (nach den Getadc ein Stop ADC)
Der AC wird auch nicht benötigt (ACSR=128)
Solange PortC nur Analog benutzt wird DIDR1=63 (alle Digital Treiber aus)

Alle 4ms. Ist das nötig? Das bringt eine enorme Datenflut zu dem Empfänger. 16ms wäre die kleinste Schlafzeit (per Watchdog-Weckung)
Nicht seltsam. 2% sind nur unschön, ab 5% gibts vereinzelt Bitfehler.

1,84 Mhz ist der kleinste den ich auf die schnelle finden konnte? 1/4 davon würde auch gehen. Wobei sich die Frage stellt, ob der Quarz nicht mehr Strom braucht als der interne Generator?

PS "Ultra" Dirty ist es den TX der zweiten Station als Ladeleitung zu mißbrauchen. So hatte ich ein Accu eines Thermometers über einen Laptop geladen.

Klar . Zum Test 1Mhz intern und 62,5kBbaud (falls Du einen Empänger hast der das kann)
Mit Osccal = Osccal - 16 (grobabgleich) sollte er dann mit 57600 sprechen.

Zum Test kann er ja an einen Ttl2Usb an den PC.
Bei mir arbeiten die internen von -10 bis 40°. Damit verstehen die sich untereinander und auch mit dem PC (falls der an ist). Ihr Clock wurde runter gesetzt (auf ca 922kHz) damit sie die Baudraten bis 115200 so schaffen das auch der PC mitreden kann.
PS Basiert das Bluetooth Modul nicht auf einen ESP? Der kann beliebige Baudraten. Bruchzahlige würde der Mega gut hin bekommen mit 1MHz 125kBaud oder 62500Baud. (Bei 4Mhz bis 500kBaud)

PPS Beim Blinken werden fast 100 Werte nicht gesendet. Ist das akzeptabel? Anderenfalls kann das Senden in einer Timer Isr ausgeführt werden. Die kann auch zum wecken genutzt werden. Soweit ich weiß aber nur bei Idle (ca halber Strom) .

Hallo Ralf,
ich würde den Power-Save Mode nehmen und einen 32KHz Quarz an die entsprechenden Pins hängen.
Timer2 kannst du dann zum Aufwecken nehmen.
Dadurch kannst den Stromverbrauch während des Waitms 4 auf einige µA runterbringen, also zu vernachlässigen.
Während der 1ms, die GETADC() und das Printen benötigt, verbraucht er dann die 1,7mA.
Der tatsächliche Verbrauch insgesamt liegt dann bei 1,7mA/5, also etwa 0,34mA.

Du kannst übrigens noch etwas rausholen, wenn du die baudrate auf 115200 bei 3,6864MHz Takt setzt.
Allerdings braucht dabei die Konvertierung der Spannung in die Ausgabe so lange, dass das Print für die Berechnung unterbrochen wird.
Dies kannst du vermeiden, indem du die max 4 zeichen selber berechnest.
Da immer zwei zeichen bei der Ausgabe gepuffert werden, tritt so keine verzögerung auf.
Damit kommst du dann auf einen Sendezeit von 0,68 Sekunden, also schon nur noch 1/6 der Gesamtzeit, somit weniger als 0,3mA insgesamt.

Das sind die selben die auch einen Baudquarz bekommen würden.
Und per Osccal auf 3,6864Mhz zu kommen ist "abenteuerlich" - unmöglich?

Die Konvertierung kann mit $lib "mcsbyteint.lib" auf ein Drittel verkürzt werden.
Leider "schlampt" der Simulator mit dem Adc. (40Takte ist Quatsch es wären ca 5000).
Die Zeit könnte zur Ausgabe genutzt werden :

Dann muß er aber ausgesprochen haben bevor er schlafen geht.
Mit einer UTXC-Isr? Oder einer _RS_Bufcountw0 Abfrage?

Wie würde er das "I" empfangen? Im Tiefschlaf höhrt der Uart nichts ?
Im Idle wohl? Aber dann wäre die Ersparnis nur wenig
Kann dem HM11 klargemacht werden das es nur sprechen darf (das I ) sobald es was hört?

Stiimmt, die ...8 haben ja so eine seltsame Pinbelegung.
Bei einem M16 kein Problem.
Aber ich würde jetzt den internen RC des M328P auch noch nicht vergessen.
Mit einem M88P habe ich gerade mal versucht, 115200 zu schicken. Dazu musste ich den OSCCAL recht weit runterdrehen.
Aber im Bereich von 5 - 25 hat hterm zuverlässig Daten bekommen.
Muss man mal ausprobieren, ob die Stromersparnis damit klappt.

Um im PowerSave den UART zu empfangen, muss man doch nur den PCINT des RX-Pins aktivieren.

Hallo!

Darf man fragen, welche Messwerte das sind?
bzw von was sind die Daten?
Gibt es Beschränkungen bezüglich Temperatur, Größe oder Gewicht der Schalung?

LG

Das ist aber so richtig viel weit. Auf wie viel % Takt musste der den runter?
Ich hab gerade einen M8 getestet. Der geht runter bis ca 45% und hoch auf ca 180%
(bei 187 normal 1Mhz, und 170 für 921,5kHz)

Von 8MHz auf 3,6864MHz.

Dann kommt das ja hin - ist auch wirklich weit. Keine Probleme mit dem EEprom bekommen? Irgendwo wird gewarnt das man die nicht zu sehr "tunen" soll

Ein Tiny kann während der Laufzeit seinen Takt (per Teiler 1,2,4,8Mhz) ändern. Der 328 auch? Ich hab nichts passendes gefunden. Selbst der div8 aus den Fuses ist nicht in einem Register hinterlegt?

Grundsätzlich kann man die AVR bis zu quasi 0 Hz runter takten. Nur bei 0 Hz taktet natürlich nix mehr. Auch klar.
Man kann aber einen entprellten Taster zum Takten nehmen. Das geht. Soviel zur tiefsten Taktrate.

Da aber ein UART im Spiel ist, braucht es einen Minimum Takt, um die gewünschte Baud-Rate zu erreichen.

Typischerweise wird der Takt immer durch 16 geteilt, danach kommt das Baudrateregister.
Bedeutet im Umkehrschluss, wenn ich Baudrateregister (Teiler = 1) einstelle, dann sollte man das 16-fache der Baudrate als Minimum-Takt haben.

Also bei 57600 Baud braucht es dann minimum 57600 x 16 = 0,9216MHz. Nur solche Quarze gibts wohl kaum. Dann nimmt man ein Vielfaches davon (x2, x3, x4 ... usw.), was man über den Baudrateteiler einstellt. z.B. Teiler = 4. Dann kommt man auf das Baudratequarz 3,686400 Baud. Vielleicht findest du was mit x2 oder x3?

Es gibt noch ein Flag bei der Uart-Baudrate x2. Wenn man das setzt, muss man die gewünschte Baudrate *8 als Mindesttakt ansehen. Dann kommt noch der Baudrate-Teiler.

Mit diesem Wissen kann man sich ne Tabelle (Excel) machen und die möglichen Quarze finden.

Ich würde aber in jedem Fall ein Quarz nehmen, um die Übertragung nicht durch drifftende Oszillatoren (wie den internen RC-Oszillator) zu gefärhden.

Wäre da nicht ein Attiny13a eher passend? Der könnte unter dem Ht11 "verschwinden"
Die Übertragung "verträgt" einiges an Drift (siehe #11).
Notfalls könnte er auch die Batterie überwachen und ein wenig nachregeln.
Oder wenn er ganz penibel sein will den Empfang abzählen

Mir kannst ja egal sein. Ob der Code nachher sauber läuft. Ich gebe hier nur gute tipps.
Ein Quarz oder Schwinger ist immer besser als der interne RC-Oszillator, der
nach Datenblatt von Spannung und Temperatur abhängig ist.
Ist auch weniger Aufwand als im nachhinein Spannung zu messen und Temperatur und das versuchen zu kompensieren.
Das wäre nur Symptombehandlung.

War da nicht mal irgendwo ein Thread, wo man den RC-Oszillator als Temoeraturmesser wegen der Temperaturabhängigkeit verwendet hat?