Energetische Sanierung Tonuino - Stromverbrauch halbiert

Nick-Spick · 17. April 2021 um 22:26

Erstmal vielen Dank an die Community für die rundum sorglos Lösung für den frustfreien Nachbau. Die größte Herausforderung lag in der Umsetzung eines passenden Gehäuses. Die Elektronik, einfach wie Malen nach Zahlen. Software lief auf Anhieb. Aber das wäre doch zu einfach gewesen ;o).

Entsprechend möchte ich meinen Beitrag mit einem Ansatz zur energetischen Sanierung leisten.
Aufhänger war der gefühlt hohe Ruhestrom der Schaltung von fast 70 mA in PAUSE, fürs Nichts tun gegen knapp 82 mA im PLAY (ohne Lautsprecher). Und der Ehrgeiz günstigen Werbegeschenk Powerbanks (im Folgenden PB) mit knapp 2000 mAh aus der Restekiste ein sinnvolles Dasein zu geben.
Auch aus Gewichtsgründen. Eine Box, die mit 250g PB im Parkett einschlägt hinterlässt andere Spuren wie eine mit 60g PB.
Hinzu kam die Diskussion über Pegelanpassungen wegen sporadisch defekter RFID Module (3,3V Spannungsversorgung aber 4,xV auf den IO Signalen?!) und Störgeräusche des DF-Players hier im Forum, weil auch der nicht wirklich 5V Nennspannung hat, gern mal brummt und beim Einschalten so ein „nettes“ Zirpen von sich gibt.
Siehe: Brummen aus dem Lautsprecher

Schon deswegen macht es Sinn, die Spannungslevel abzusenken und zu vereinheitlichen. Und Strom spart es auch.

Damit hatte ich dann auch Blut geleckt, auf der Jagt nach Laufzeit und mA.
Letztlich gibt es 3 Ansätze:
1.) Abschalten was man grad nicht braucht. Und grad ist eben jetzt, und nicht wieder in 250 ms. Also dynamisch abschalten.
2.) Spannung runter, weil die hohe Spannung treibt teils sogar exponentiell die Ströme hoch und macht wie oben erwähnt auch diverse Probleme.
3.) ggf. Taktfrequenz runter. Wir haben ja quasi ewig Zeit. Was soll der Stress ;o).

Bestandsaufnahme zur Stromaufnahme Originalaufbau:
Arduino NANO (mit passivem USB-Treiber, also ohne laufende Kommunikation) + MP3-Player + RFID Reader bei direktem Anschluss über 5V Pin mit 5V aus USB Powerbank @16 Mhz
PAUSE: ca. 68,8 mA
Im PLAY: ca. 82 mA (Lautsprecher bewusst abgezogen, weil die Last bei jedem anders sein wird).
Dabei entfallen auf:

Arduino Nano:	 	ca. 38,8 mA	(davon ca. 4 mA USB Treiber IC, ca. 2,5 mA LED's)
NFC Modul: 			ca. 15,8 mA	(+6 mA wenn die Karte aufliegt)
MP3 Modul in Pause:	ca. 14,1 mA	(Davon ca. 6 mA Ruhestrom des Verstärker ICs)
MP3 Modul in Play:	ca. +12,7 mA

Für das Erfassen der Differenzen, habe ich einfach den Vcc des jeweiligen Moduls getrennt. Der NANO hatte also belastete IO Treiber, auch wenn keiner drauf reagiert. Gemessen immer auf 5V Ebene direkt am Ausgang der PB.

Was auffällt:
Der Unterschied zwischen PAUSE, also dem Warten auf Bedienung, und Betrieb im PLAY sind gerade mal 12 mA. Der Grundbedarf fürs nichts tun ist mit knapp 70 mA relativ hoch.

Zu Lösungsansatz 1.) Dynamische Abschalten:
Funktional betrachtet brauchen wir im PLAY nur das MP3 Modul (ca. 27 mA). Den Rest der Komponenten (ca. 55 mA) können wir temporär abschalten und nur gelegentlich wieder wecken um z.B. alle 250 ms nach neuen Bedienhandlungen oder einer Karte zu schauen. Der Player läuft derweil unabhängig weiter.

Einsparpotential bezogen auf Ansatz 1.):

14 mA durch Abschalten des Players im Standby (davon entfallen ca. 6 mA allein auf den Standby des Verstärkers).
Durchgängig 55 mA für einen Großteil der Laufzeit, durch Nutzung von Schlaffunktionen, weil es reicht, alle 250 ms, für wenige ms nach dem Rechten zu schauen.
Statisches Abschalten nicht benötigter Prozessorfunktionen (z.B: Timer, Watchdog, Interne Spannungsreferenzen usw.) und nicht benötigter Peripherie (USB Treiber, LED’s)

Ums kurz zu machen:

Dynamisches Abschalten des DF-Players scheidet aus: Die Initialisierung dauer deutlich zu lange ( >> 1s). Der Sleep Befehle ist eine reine Tastensperre. An der Stromaufnahme ändert sich nichts. Lediglich Disable DAC bringt gute 3 mA. Nachteil: Egal was man abschaltet, er vergisst die letzte „Pause“. Man kann also auch gleich den Tonuino komplett abschalten und neu starten. Hier bietet es sich also nur an nach Titelende den DAC auszuschalten, damit man das Pausieren bei PAUSE weiter funktioniert.
Dynamisches Abschalten des Verstärkers (6 mA) im STOP oder PAUSE: Funktioniert hervorragend. Keine Initialisierungsgeräusche, keine Rauschen in Pausen. Einschaltverzögerung ca. 500 ms vor Track start ist vertretbar. Zudem löst es diverse lästige Eigenschaften des DF-Players nachhaltig.
Dynamisches Abschalten des RFID Readers: Funktioniert hervorragend. RFID Power UP -> Karte auselesen -> Karte merken -> Karte Abmelden -> RFID Power Down. Nach 250 ms wieder von vorne. Spart satte 16 mA + 6 mA wenn die Karte grad drauf liegt.
Dynamisches Abschalten des NANO (Deep Sleep): Funktioniert hervorragend. Entsprechenden Code Modifikationen (Loop fähiges Programm) vorausgesetzt. Watchdog Wakeup -> Tasten auslesen -> RFID Lesen -> Programm einmal durchlaufen -> Tiefschlaf für 250 ms. Spart satte ca. 30 mA. Die Restlichen 8 mA entfallen auf LED’s, Spannungsregler und USB Treiber IC.
Nicht benötigte Prozessorfunktionen abschalten: Funktioniert hervorragend. TIMER 1/2, Watchdog, AD-Wandler, interne Spannungsreferenz, TWI aus. 3 Zeilen Code im Setup -1,5mA.
LED’s Abschalten: Geht einfach, lohnt sich aber nur bei der LED des RFID Readers. Die zeigt letztlich keinen Status an und ist verzichtbar und relativ hungrig. Ein Schnitt mit dem Teppichmesser zwischen LED und Vorwiderstand => -1,3 bzw. -2,5 mA. Die vom DF-Player und dem Nano liegen unter 1 mA und sind für die Diagnose hilfreich. Das lohnt nicht.
USB Treiber IC abhängen oder über USB versorgen: Technisch aufwendig. Wenig Ertrag, da Leckströme über RX und TX aus dem ATMEL das Ergebnis stark schmälern.

Zu Lösungsansatz 2.) Spannungsabsenkung:
Mit Blick aufs Datenblatt des ATMEL, zeigt sich, dass der Stromhunger des ATMEL mit der Spannung quadratisch ansteigt und mit der Frequenz linear. Das gilt letztlich auch für den MP3 Decoder auf dem DF-Player. Auch auf Nebenverbraucher wie LED’s wirkt sich eine Spannungsabsenkung günstig aus. Im Hinblick auf die Pegelanpassungsprobleme kommt uns das gerade recht. Gehen wir generell mit der Spannung runter, sparen wir ordentlich Strom und sind zudem die Pegelgefälle (und die Probleme die damit einhergehen) los.
Um den Effekt zu verdeutlichen: Wenn man die 5V USB PB statt über den 5V Anschluss über den Vin Anschließt, und damit über den Spannungsregler geht, kassiert man einen Spannungsabfall auf ca. 3,9 V für alle Komponenten. Damit fällt der Stromhunger bereits von ca. 69 mA in PAUSE um knapp 14 mA. -20% für lau. Klar der Spannungsregler regelt dann nicht mehr, der schaltet auf Durchzug. Aber das ist bei eine geregelten Eingangsspannung von 5V über die PB auch gar nicht relevant.

Das schöne bis hier hin: Man muss an dem aktuellen Aufbau prinzipiell fast nichts ändern. Bis auf die Abschaltung des Verstärkers und die Speisung über VIN sind das alles Softwarefunktionen. Und schon damit kommt man auf unter 30 mA eff. Strombedarf mal eben halbiert.
Die Verstärkerabschaltung ist für den Tonuino AIO auch schon vorhanden, und für den Klassik lässt es sich (leicht) nachrüsten. Siehe Bild im Anhang und Beschreibung am Ende.

ABER ich empfehle:
-> > 200µF DIREKT am Spannungseingang des DF-Players
-> KURZE Leitungen von PB -> Nano -> DF-Player. KURZ bedeutet <10cm zur PB. Zwischen Nano und DF-Player so kurz wie möglich.
-> Richtige Kupferleitung mit mehr Querschnitt
Warum: Es hat sich immer wieder gezeigt das der DF-Player sensibel gegen Unterspannung ist. Minimum laut Datenblatt 3,1 V. Wenn der Verstärker einen Basshub macht und spontan „ordenlich“ Strom zieht, gräbt er dem MP3 Decoder kurz die Spannung ab. Der steigt aus, mit den üblichen Symptomen. Daher ist für Ansatz 2 eine solide Spannungsversorgung des Players wichtig.

Ich habe das auf die Spitze getrieben:
Einen 3,3 V Spannungsregler im NANO eingesetzt. Ziemlicher Fummelkram. Aber man kann natürlich auch einen externen Regler über den 5 V Eingang verwenden. Das bringt dann nochmal ca. 8 mA auf < 35 mA im PLAY und < 23 mA in PAUSE und hat gereicht, um die PB in PAUSE in die Abschaltung zu treiben. Mein Tonuino bräuchte jetzt einen Neopixel, um am Leben zu bleiben. Aber der liefe jetzt Strombedarfsmäßig quasi umsonst mit.
Bei der Absenkung auf 3,3 V habe ich jedoch das Verstärker IC vom MP3 Decoder abgekoppelt und direkt mit 5 V versorgt, um volle Leistung am Verstärker zu behalten und die oben beschriebene Wechselwirkung bei Spannungsschwankungen zu unterbinden. Siehe Bild anbei und Beschreibung am Ende.

Zu 3.) Taktfrequenz reduzieren 16 auf 8 MHz:
Bei der Taktfrequenz könnte man nun abwägen. Höherer Takt heißt gleiches Programm in kürzerer Zeit, heißt längere Power Down Phasen. Mehr Ersparnis. Oder langsamer Takt, weniger Strom, aber längere Programmlaufzeit. Was mehr wiegt, schwer zu sagen. Der ATMEL ist bei 3,3 V bis max. 8 MHz spezifiziert. Bei mir laufen die 16 MHz stabil. Lass ich so.

Nachfolgend für interessierte meine Messdaten:
Die Tabelle ist so zu lesen, dass von oben nach unten zusätzliche Maßnahmen ergriffen wurden. Soweit nicht anders angegeben, mit statisch aufliegender RFID Karte und ohne Lautsprecher. Verstärker wie nachfolgend beschrieben vom MP3-Decoder getrennt und direkt an 5 V der PB.

Stromwerte in mA:						Playing		Paused		AmpOff		DACDisable
Original via 5V USB aktiv				82,0		75			71,5		68,5
Original via 5V USB inaktiv				77,5		71,4		67,8		65,0			
Original 5V via VIN (3,9V) USB aktiv	69.0		61,4		57,9		55,0
Original 5V via VIN (3,9V) USB inaktiv	66,1		58,4		54,8		51,9
PRR, ADC, Timer, Watchdog OFF			64,9		57,0		53,3		50,4		

Bei 5V via VIN (Spannungsabfall auf 3,9V)
RFID LED OFF							61,5		53,8		50,0		47,1
NANO POWER LED							60,7		53,1		49,3		46,3
NFC SwPower Down 2s Pause*				34,5		26,2		21,8		18,8
ATMEL Power Down 2s Pause*				28,8		20,3
NFC + ATMEL PW Down 120ms**				35,5		27,2		-			-
USB Treiber separiert					31,5 		23,5

Mit 3,3V Spannungsregler
3,3V Spannungsregler					62,4		55,1		51,0		47,8	
3,3V RFID LED OFF						61,2		53,8		49,7		46,5
3,3V ohne RFID Karte					54,8		47,1		42.9		39,7
NFC SwPower Down 2s Pause*				32,5		24,8		20,3		17,1		
ATMEL Power Down 2s Pause*				27,8		20,0		15,5		12,3
NFC + ATMEL PW Down 120ms**				34,6		27,0		22,8		19,9

*) Power Down auf 2s gestreckt um quasi statisch Messung machen zu können
**) Messtechnisch nicht sauber erfassbar. "Effektivwert"? auf dem Multimeter.

Fazit Stromreduktion je Maßnahme:

Differenz via 5V zu VIN			ca. 13 mA
USB Treiber 					ca. 3-4 mA	
Differenz Play / Pause 			ca. 7 mA
Verstärker abschalten			ca. 3,5 mA		(Verstärker immer direkt an 5V PB)
DAC Abschalten					ca. 2,9 mA
DF-Player Sleep					kein Effekt
PRR, ADC, Timer, Watchdog OFF	ca. 1,5 mA
Absenkung 3,3V					ca. 2,5 mA
RFID LED OFF					ca. 2,5 mA@5V; 1,3 mA@3,3V
NANO Power LED					ca. 0,7 mA@5V;
SwPowerDown RFID & ATMEL		ca. 26.6 mA?! Eff.

Umbau DF-Player für Verstärker Abschaltung:
Das Verstärker IC unterstützt einen Powerdown Mode über einen Shutdown Pin. In folgendem Block sehr schön beschrieben. Blitter Nasty: DFPlayer MP3 module - high quiescent power consumption and clicks when power applied and removed - FIX!.
Ich habe die Variante erweitert und den 0 Ohm Widerstand nicht auf das Nachbar Pad zur Verbindung mit Busy gelötet, sondern zur freien Verwendung heraus geführt. Der Pin 9 (IO1) des DF-Players und dessen Vorwiderstand liegen verführerisch nah neben der alternativen Platzierung des 0 Ohm Widerstandes. Den Pin 9 benötigt der Tonuino zudem nicht. Man kann also sehr einfach den Shutdown für dem Verstärker auf PIN 9 legen und somit für den NANO zugänglich machen. Man muss hierzu nur den Vorwiderstand für Pin 9 (IO1) des DF-Players entfernt und den 0 Ohm Widerstand auf der alternativen Platzierung um 90° drehen.

Umbau DF-Player getrennte 5V Versorgung Verstärker IC:
Auch hier liegt der 5V Pin des Verstärker IC’s direkt gegenüber dem Vorwiderstand von Pin 11 (IO2). Prädestiniert, um die Spannungsversorgung des IC’s über Pin 11 heraus zu führen. Auch der Pin wird vom Tonunino nicht verwendet. Hierzu habe ich den Vorwiderstand von Pin 11 (IO2) des DF-Players entfernt und eine Brücke zum IC eingesetzt.
Dazu folgende Schritte durchführen:

Zur Trennung der Spannungsversorgung von Decoder IC und Verstärker IC genügt es die im Bild markierte VIA z.B. mit einem feinen scharfen Bohrer per Hand leicht raus zu drehen. Mit Durchgangsprüfer prüfen! Dann sind die Potential getrennt. Decoder IC und Verstärker IC können dann auf zwei getrennten Spannungsebenen laufen.
Vorwiderstand von Pin 11 des DF-Player Moduls entfernen
Pin 6 vom Verstärker IC auf das frei gewordene Pad des Pin 11 des DF-Player Moduls brücken.
Bei der Gelegenheit gleich einen 10 µF + 100 nF gestapelt als Block Kondensator zwischen Pin 6 (Vcc) und Pin 7 (GND) des Verstärker IC platzieren. Johannes hatte das in seinem Beitrag eingebracht. Das mit dem Stapeln von 10 µf und 100 nF macht zwar bei einer Bauteiltolleranz von 10% auf den ersten Blick keinen Sinn. Aber ich habe mir erklären lassen, dass der 10 µF keine guten Hochfrequenzeigenschaften hat. Der ist also quasi nur fürs Grobe. Daher gibt man ihm noch mal einen kleinen 100 nF dazu, der sich dann um hochfrequente Störungen kümmert. Wieder was gelernt.
Den Pin 11 legt man dann direkt auf die 5 V der USB Power Bank. Dabei auf kurze Wege und dicke Drähte achten. Ich habe zusätzlich direkt an PIN 10 und PIN 11 des DF-Players noch einen 200µF Kondensator platziert.
Der Original VCC Pin 1 des DF-Players wird dann mit der reduzierten Spannung versorgt. Auch hier habe ich noch extern direkt am Pin 47 µF zur Stabilisierung spendiert.

Inspiriert von Johannes habe ich dann noch den DF-Player etwas optimiert.
Siehe: Brummen aus dem Lautsprecher

Erhöhung des Bypass Kondensators für Unterdrückung von Pop und Klick geräuschen beim Einschalten (Huckepack +10 µF +100 nF) wie von Johannes vorgeschlagen. Verzögert das Einschalten des Verstärker IC’s auf ca. 900 ms. Habe es daher später auf 4,7 µF +100 nF korrigiert, um den Vorgang schneller zu gestalten.
10 µF Block Kondensator direkt am Verstärker IC zwischen VCC und GND zur Stabilisierung + 100 nF huckepack für Entstörung (siehe oben).
Halbierung der Verstärkung durch Reduktion des Feedback Widerstandes 51K auf die Hälfte (einfach noch mal 51K huckepack drauf). Vorteil dieser Variante gegenüber dem Vorschlag von Johannes ist, dass man den Hochpassfilter am Eingang nicht verstimmt. Generell reduziert diese Maßnahme das Rauschen und ermöglich auch nächtliche Einschlafgeschichten in Flüsterlautstärke auf Volume Stufe 1.

Details zum Umbau siehe Bild anbei.

In Summe: Es gibt Einsparpotential. Ggf. auch was für die neue TONUINO Software?

raznz_snasna · 18. April 2021 um 06:30

Super Ausführungen und nachvollziehbar.

Dem kann ich aber nicht folgen. Wieso soll der nano schalten? Wenn ich im 250ms Takt schaue ob er noch spielt und dann erst a schalte, könnte er 249ms sinnlos verstärken.
Intern verlötet ist er da einfach live.

53b272d41c · 18. April 2021 um 07:05

Danke, sehr schöner Beitrag

Thomas-Lehnert · 18. April 2021 um 08:36

Wow, da hast du aber ganz schön in der Tiefe geforscht. Ich finde das sind sehr interessante Möglichkeiten, die bei voller Ausnutzung schon ein paar Stunden längere Laufzeit bringen. Das sollte besonders für die Nutzer von kleinen Akkus bzw Powerbänken oder Batteriespeisung interessant sein. Auch super dargelegt, wie man den DF-mini verbessern kann. Respekt, gute Arbeit.

stephan · 18. April 2021 um 09:27

Und das ist ja auch das Ziel hier.

Für viele Anfänger ist es aber genau das nicht. Ich habe großen Respekt für deine Recherche und wenn man weiß was man tut kann man da sicher - wie @Thomas-Lehnert schon sagte - die ein oder andere Stunde Laufzeit raus kitzeln. Ich möchte aber auch nicht unerwähnt lassen (und das völlig wertfrei), daß ein TonUINO im Gegensatz zu anderen Projekten schon ziemlich wenig Strom verbraucht. So wenig das ja viele damit zu kämpfen haben daß Powerbanks überhaupt an bleiben etc. Wie dem auch sei, ich finde solche Impulse gut, aber sehe solche Modifikationen dann doch eher für Fortgeschrittene. Das, finde ich, hätte erwähnt werden sollen.

Wir haben hier halt eine Lösung die einfach funktionieren soll. Daß die nicht in allen Belangen optimal ist, ist ja völlig klar.

Thomas-Lehnert · 18. April 2021 um 11:41

Nunja, ich denke Mal, dass das Stummschalten des Verstärkers über die Modifikation an Pin 9 so gedacht ist, dass der Verstärker immer dann Ausgeschaltet wird,wenn er nichts abspielen muss. Das macht schon Sinn. Da ist es auch egal ob die Abschaltung eine Viertel Sekunde früher oder später erfolgt.

raznz_snasna · 18. April 2021 um 12:30

Aber immer wenn er nichts abspielt, ist der Busy high.
Und kann genau so genutzt werden

Bastelmatz · 18. April 2021 um 12:52

Eine sehr interessante Untersuchung. Danke für das Teilen.

Für mich stellt sich die Frage, was ich davon ohne Hardware-Anpassungen und ohne spürbare Einflüsse auf die Bedienung umsetzen kann? Frei nach dem Motto „mit wenig Aufwand, viel Ertrag“ wäre meine Top 3 folgende:

Dynamisches Abschalten des NANO (Deep Sleep) [~30mA]
Dynamisches Abschalten des RFID Readers [~16mA]
Dynamisches Abschalten des Verstärkers im STOP oder PAUSE [~6mA]

Gibt es dazu evt. auch Code-Bespiele, wie dieses Abschalten aussieht? (sry, gerade wenig Zeit zum googeln).

Beim Abschalten des Nano bin ich mir noch nicht sicher, inwiefern sich das mit LED-Animationen oder Rotary-Encodern verträgt. Der RFID Reader ist wohl weniger kritisch.

Welche lästigen Eigenschaften wären das?

Thomas-Lehnert · 18. April 2021 um 14:06

Ist richtig, aber damit ist man auf diesen einen Fall fixiert um den Verstärker abschalten zu können. Ein Abschalten über die Software, z.B. Unterdrückung Einschaltgeräusch oder bei Anschlusss eines Kopfhörers ist dann wiederum nur mit zusätzlicher Hardware (MOSFET’s) möglich. Diese kann man sich bei dieser Lösung sparen. Bei der AiO wird das ja schon so gemacht.

Nick-Spick · 18. April 2021 um 21:49

Schönen Guten Abend,

danke für die Anerkennung. Ich fand spannend was möglich ist, und gemeinsam kann man ja was draus machen.

@stephan: Ja, ist advanced. Sieh es als Inspiration für den nächsten Fork ;o). Über die PB Probleme hatte ich gelesen. Aber wie vieles könnte man die verschiedenen E-Sparfunktionen als DEFINE aktivieren. Dann kann jeder so weit gehen, wie es ihm passt. Alleine implementieren wird sich das keiner. Das gibt die aktuelle Programmstruktur gar nicht her. Aber @Thorsten backt ja schon eine neue Software. Vielleicht reizt es ihn.

Nun, wie du richtig erkannt hast, die Schlaffunktionen für NANO und RFID Reader sind die dicken Fische. Das ist reine Software. Die Sache mit dem Verstärker habe ich beschrieben. Wenn man den DF-Player frisiert hat, ist es eben eine IO Verbindung mehr. Den Shutdown raus zu legen scheint mir auch weniger Aufwand als die externen FET Beschaltungen. Beim AIO ist es eh schon drin.
Die getrennten Spannungsebenen für MP3 Decoder und Verstärker machen denke ich nur in einem AIO Konzept mit fertiger Leiterplatte Sinn, weil da die Spannungsversorgung zunehmend heikel wird. Das muss das Design abfangen.

Was die Bedienbarkeit angeht, ist das denke ich kein Problem. In meiner Bastelversion hatte ich pauschal für die Relevanten Tasten und Busy bereits den Pin Change Interrupt aktiviert. Bei jeder Statusänderung wacht der NANO sofort auf. Die Pausenzeit des Watchdog (am Ende 120 ms) ist also eine Worst Case Zeit. Die er maximal schläft, bevor er den Reader einschaltet und schaut ob die Karte noch da ist.

Die Frage habe ich befürchtet ;o). Mein Bastelcode taugt nicht zu Veröffentlichung. Das Kernproblem ist die Integration in den Original Code. Ich habe erstmal einen Fork Loopfähig gemacht, damit ich nicht ständig in irgendwelchen Schleifen verhungere. Aber da habe ich mich bereits vor dem Adminmenü gedrückt. Wenn das im Standard gegeben wäre, wäre der Aufwand gar nicht mehr so groß.
Nach jedem Durchlauf rufe ich dann die Schlaffunktionen auf.
Die Schlaffunktion für den RFID ist im Befehlssatz der MFRC522 Lib enthalten. Für die Schlafmodi des ATMEL empfehle ich die LowPower Lib. Sehr einfach in der Handhabung.
Für den MP3 und RFID habe ich zwei eigene Klassen geschrieben. Die erben erstmal alle Methoden vom Original. Somit reichen sie im ersten Moment alle Methodenaufrufe einfach durch. Im zweiten Schritt habe ich dann für die relevanten Funktionen (z.B. Play, Pause, Stop bzw. Read & Write), die Methoden überladen und hier die Ein-/Abschaltung des Verstärkers bzw. RFID Readers integriert, bevor diese den Aufruf dann an die original Methode weiter reichen. Der Vorteil an diesem Vorgehen ist, dass ich im Original Code dann nur bei der Objekt Deklaration auf meine Klasse verweisen musste. Aber in der Testphase habe ich das leider nicht ganz konsequent verfolgt (verfolgen können). Für Quick & Dirty OK. Ich kann dir das gerne mal schicken.
Wenn man das ordentlich implementieren will, wird man den Code großflächig überarbeiten müssen. Es macht Sinn die ganzen Player und Card Aktionen in diesen erwähnten Klassen zu kapseln, so das man das Power- und Datenmanagement innerhalb der Klasse intelligent abwickeln kann. Das sollte nicht Aufgabe des Hauptprogramms sein. Der Aufwand schreckt mich noch ab. Außerdem bleibt dann kein Stein mehr auf dem Anderen. Macht also nur Sinn, wenn die Hauptakteure die regelmäßig Änderungen und Erweiterungen einbringen sich für das Thema begeistern können. Sonst wird die Code Pflege zu aufwändig.

Ich habe dazu mal die Library ClickEncoder verwendet. Dies basiert auch auf dem Pin change interrupt. Damit läuft sie an allen Pins gleichermaßen und kann auch einen Beschleunigungswert ableiten. Die sollte kein Problem sein.
Bei LED Animationen bin ich raus. Aber generell hängt das stark von der Dynamik deiner Animation ab. Für die laufende kurze Animationen kannst du natürlich die Schlafzeit kürzen, oder auch erstmal den NANO weiter laufen lassen. Ich meine auch, dass die PWM Ausgänge in „leichteren“ Schlafmodi weitgehend unabhängig weiter laufen können. Muss man sich anschauen.

Thomas hat es schon auf den Punkt gebracht. Die berüchtigten Einschaltgeräusche. Oder ein Zirpen wenn der Nano mit dem MP3 Decoder Kommuniziert. Manche haben im Forum auch von einem hörbaren Rauschen in Pause berichtet.

@raznz_snasna : Hallo Stefan, stimmt schon, die Hardwarevariante hätte ihren Scharm. Habe das auch ausprobiert. Problem ist die Einschaltverzögerung des Verstärkers. Die liegt bei 1 µF Bypass Kondensator bereits bei ca. 100 ms. Das führt dazu, dass die Ansagen vorne abgeschnitten werden. Wenn du den Player einfach mal zählen lässt: Eins, Zwei, Drei, dann hörst du durch diesen Effekt nur noch: nz, wei, rei. Daher ist die zeitliche Koordination über den Nano erforderlich. Mit den Optimierungen von Johannes (Bypass 11µF) geht das Delay noch höher, ca. 900 ms. Das Delay an sich stört nicht wirklich, vorausgesetzt das Timing stimmt. Hinzu kommen die von Thomas beschriebenen Vorteile in der Flexibilität.

Wenn er ein paar ms länger läuft, ist es kein Beinbruch. Aktuell läuft er vollgas durch. In der Messwerttabelle siehst du, dass ich am Ende die Pause auf 120 ms gekürzt habe, um die Reaktion auf den Card Reader zu verbessern. In meiner aktuell noch sehr gebastelten Software lasse ich den Nano auch über den Pin Change Interrupt auf allen relevanten IO wecken. Wenn man in den 125 ms Tiefschlaf auf eine Taste geht, oder der Busy wechselt, wacht der Nano auch sofort auf.

Wenn man das sauber implementiert, hat das Thema denke ich interessantes Potential, auch für die Breite. Ich lauer da auf Torstens nächsten Wurf.

Einen Haken hat die Sache mit dem Deepsleep. Millies schläft auch. Für Timings die über einen Zyklus hinausgehen muss man sich also was überlegen.

K-Audio · 19. April 2021 um 07:37

Sehr spannend, freut mich das Du dir die Mühe gemacht hast. Es ist natürlich genau wie @stephan gesagt hat, für den Normalo (wie ich) zu viel. Aber es ist ja anscheinend auch ohne viel Aufwand Sparpotenzial da

Manuel · 20. April 2021 um 09:43

Kurz zusammengefasst heißt das:

man muss den 0 Ohm Widerstand (Amplifier Shutdown Pulldown 0 Ohm aus deinem Bild) entfernen
der Widerstand am Pin 9 (rechter unterer Widerstand auf deinem Bild oberhalb der 9) entfernen
den zuvor ausgelöteten 0 Ohm Widerstand an Pin 9 einlöten, jedoch dann um 90 Grad gedreht zum ursprünglichen Widerstand.

Korrigiere mich wenn etwas fehlt.

Nick-Spick · 20. April 2021 um 11:15

Yep, passt.
20 Zeichen.

fry2k · 27. April 2021 um 19:34

Auch von mir herzlichen Dank fürs Teilen deiner sehr ausführlichen Forschungsarbeit!
Ich habe immer noch einen Ultra-Portablen TonUINO für Unterwegs auf meiner Liste und da limitiert die Größe der Powerbank. Da kommt die Optimierung des Stromverbrauchs sehr gelegen. Die Spieldauer ist jetzt schon sehr gut bei diesem Projekt, aber gegen 20% mehr Laufzeit für kaum Arbeit, da sag ich nicht nein.

Ich hab hier zwei TonUINOs und hab sehr unterschiedliche Stromverbräuche gemessen. Ich hab recht schnell rausgefunden, dass ich zwei unterschiedliche Versionen vom RFID Leser habe. Einen 2 Jahre „alten“ von AZ-Delivery und einen neueren von Aliexpress. Sie Unterscheiden sich anhand der verbauten Bauteilen. Die vom neuen sind noch kleiner, siehe Bild.

Hier mal ein paar Messungen von mir, auch ohne Lautsprecher.

ohne RFID: 40mA
original pause (alter RFID): 78mA
original play mit aufgelegter Karte (alter RFID): 82mA
original play ohne aufgelegter Karte (alter RFID): 82mA
original pause (neuer RFID): 61.5mA
original play mit aufgelegter Karte (neuer RFID): 68mA
original play ohne aufgelegter Karte (neuer RFID): 66mA

Ich hatte von dem neuen RFID Modul noch eins in der Kiste und hab dann das alten direkt getauscht. Somit konnte ich dann endlich mit der Optimierung anfangen. Ich verwende Thorstens Platine und dort ist leider der VIN nicht als Pin ausgeführt. Also hab ich kurzerhand provisorisch einen Jumperstecker von oben auf den Arduino gelötet, damit ich meine Stromversorgung umstecken konnte. Ich verwende aktuell den 5V Pin für die Stromversorgung.

Zu meinem erstaunen brachte die Änderung vom 5V Pin auf den VIN auch bei mir wirklich sehr viel:

pause: 52mA
play: 57mA
play ohne Karte: 55mA

Allein diese 2 einfachen Anpassungen haben mir 25mA gebracht! Von der Funktionalität läuft bei mir alles wie gehabt. Die Powerbank schaltet zum Glück nicht ab. Auch der Sleep Timer funktioniert weiterhin und nach meinen eingestellten 5 Minuten schaltet sich der Arduino aus und kurz danach schaltet die Powerbank ab.

Die Anpassung der Software klingt sehr sinnvoll, wenn man nur alle n ms den RFID Leser prüft. Da hätte ich auch sehr großes Interesse, wenn sich dafür ein Fork findet oder es einen Weg in die original Firmware findet. Das Umlöten vom MP3 Modul ist mir persönlich zu aufwändig.

Nick-Spick · 27. April 2021 um 20:30

@fry2k
Billig zu haben wäre noch die LED des RFID Readers. Ein Schnitt zwischen D1 und R1. Die LED bringt ja so nix für die Diagnose.

Was die Software angeht bräuchte ich noch Unterstützung. Kann zwar meine Schnittstellen Klassen breitentauglich aufbereiten. Dann ist das Energiemangement von Card-Reader und Player abgedeckt.
Ich suche nur noch einen Fork, bei dem wenigstens der Normalbetrieb zyklisch die Loop durchläuft, damit man zyklisch schlafen gehen kann. Beim Admin Menü ist es sogar von Vorteil, wenn die Komponenten durchgehend aktiv bleiben.

Bastelmatz · 7. Mai 2021 um 10:26

@Nick-Spick : Danke für deine ausführliche Antwort. Habe sie leider erst jetzt entdeckt/gesehen.

Bez. 5V an VIN:
Die Einsparungen durch die Spannungsreduzierung mit dem 5V am VIN Pin klingen interessant. Ist mir beim ersten Durchlesen gar nicht so aufgefallen. Da war ich wohl auf Software fixiert. Aber diese einfache Hardware-Anpassung scheint mir sinnvoll.

Der Nano arbeitet dann mit 3,9V, sprich am 5V-Pin liegen nur ca. 3,9V an, richtig?
Kommt der damit zurecht? Ich dachte am VIN muss man mind. 7V anlegen!?

Den DFPlayer kann man dann trotzdem am 5V-Pin des Nano verbinden, weil der DFPlayer nur 3,8/3,9-5V (?) braucht.
Andere Komponenten, die 5V brauchen, müsste ich dann mit dem VIN-Pin verbinden (wo je jetzt 5V reingehen), richtig?

Hmm, man könnte doch zumindest die Anzahl der Sleeps zählen. Da man die maximale Länge des Sleeps festlegt, kann man dann eine eigene Zeitvariable nutzen

     Millis() + (maxSleepTime * sleepCount)

So hätte man (in etwa) die aktuelle Zeit.
Wenn ein Ereignis eintritt (Buttonclick, Busy-Change, …) wird dann freilich etwas mehr vergangene Zeit suggeriert (oder man nimmt statistisch maxSleepTime/2) und die zugehörige Abarbeitung vorgezogen/beschleunigt.

Nick-Spick · 8. Mai 2021 um 21:16

Hi Matz,

Ja. Der DF ist für minimal 3,2V spezifiziert. Der USB Treiber für 3,3V und der RFID Reader für 3V. der ATMEL darf sogar unter 3V. Wobei mit fallender Spannung die Taktfrequenz reduziert werden müsste (siehe Initialpost). Praktisch läuft er für das was wir treiben auch mit 16Mhz klaglos. Mit 3,9V also kein Problem.
Es macht aber Sinn, dem DF-Player an die Spannungsversorgung noch nen dicken Elko mit > 200µF zu geben, weil der gegen Spannungsschwankungen sensibel reagiert (siehe Initialpost).

Siehe:

Laut Datenblatt 3,2 bis 5V. Je kleiner die Spannung, desto wichtiger, dass sie Stabil ist (ggf. Regler + Elko, kurze Leitungen usw.).
Ich habe in meinem Aufbau den 5V Regler auf dem Nano durch einen 3,3V Regler ersetzt und direkt am DF 200µF zum Abblocken von Spannungsschwankungen. Man könnte auch den VIN frei lassen und einen externen 3,3V Regler als Einspeisung an den 5V hängen,
Aber mit den Trick mit 5V über VIN gewinnt man schon so viel, das sich der Aufwand nicht wirklich lohnt.
Diese vorgehen hat auch den Vorteil, dass du keine Problem mit dem USB Anschluss auf dem Nano bekommst.
Beispiel: Mal angenommen, du stellst alles auf 3,3V über einen externen Spannungsregler um, und irgendeiner der Verbraucher ist nicht 5V Tolerant. Und du steckst den USB Stecker in den Nano, dann hebt dir der USB dein Boardnetz plötzlich auf 5V an, und die betreffende Baugruppe kann Schaden nehmen.
Wenn du aber die Originalbeschaltung so lässt, das alle 3,3V Baugruppen an dem 3,3V Ausgang hängen, und nur VIN unterversorgst, dann richtet die Versorgung mit 5V über den USB keinen Schaden an.

Ja, auf den ersten Blick schon.
Bei dem Mix von Spannungsebenen musst du vorsichtig sein. Das ist beim Tonuino mit dem 5V Nano und dem 3,3V RFID Reader schon grenzwertig, auch wenn die Praxis belegt, dass es tut. Als ich mein System durchgängig auf 3,3V umgestellt habe, war auffällig, wie viel dunkler die LED auf dem RFID Reader wurde, obwohl der auch vorher schon mit 3,3V lief. Scheinbar kamen dazu aber noch relevante Ströme über die Signalleitungen. Ich habs nicht ausprobiert, aber allein das Abziehen der Datenleitungen der SPI Schnittstelle dürfte diesen Effekt schon zeigen. In jedem Fall zeigt, es, dass da was nicht ganz sauber ist.

Wenn du also andere Komponenten auf 5V laufen lässt, darf es keinen Rückkanal geben. Diese Anderen Komponenten dürfen also keine 5V auf den Nano zurück schicken, sonst killt das die Digitaleingänge.
Wenn du also vom Nano mit einem DO auf eine 5V Baugruppe gehst, passiert da nichts, weil der Nano mit den 3,9V der 5V Baugruppe nichts antun kann. Umgekehrt aber schon. Daher dann nur in eine Richtung, und mal mindestens 1k Ohm dazwischen schalten.

Ja, so könnte man es machen. Problem ist dann aber, dass millis z.B. auch in den JC_Buttons fürs Entprellen & Longpress genutzt wird. Und die bekommen von deinem Aufschlag nichts mit. Da muss man dann die Zeitangaben verkürzen.
Ich sehe da zwei Möglichkeiten.
1.) Man rechnet generell für längere Zeiten in Sleep Zyklen, und lässt millis für alles aus dem Spiel, was über eine Loop Durchlauf hinaus geht.
2.) Ich werde vermutlich den millis Programmcode um eine Funktion „AddMillis(time)“ ergänzen. Die rufe ich nach jedem Wakeup auf und die schlägt dann direkt im millis die 128ms auf die Zählervariable. Dann bekommen es auch alle mit. Die von dir beschriebene Ungenauigkeit muss man dann in Kauf nehmen. Aber das sollte für uns auch keine Rolle spielen.

Wichtig ist nur, dass man mit dem Sleep keine laufende Kommunikation der Softserial oder des SPI unterbricht. Sollte aber kein Problem sein, weil der Code aktuell sowieso auf die Kommunikation wartet.