Ich hab das Problem gefunden.
Ich hatte einfach beide Audioausgänge aktiviert, aber das passt dem Chip wohl nicht.
Beim Demosketch wurde immer nur einer der Ausgänge aktiviert.
Heute sollte auch der RC522 Leser ankommen, dann kann ich das auch einbauen.
Müsste man dann nur noch schauen, wie man die Initialisierung etc. dann am besten einbaut.
Ich denke dass man den DAC stumm schalten müsste um unnötige Geräusche zu vermeiden.
Ich werd das heute oder morgen mal in nen Fork packen.
Cool!
Vielleicht kannst hier noch ein bisschen was dazu schreiben. Also auf welche Probleme du gestoßen bist und was man beachten musst. Vielleicht hilft das jmd.
Soo, für heute bin ich erstmal fertig.
Ich hab die Lib für den ES8388 auch angepasst, damit man die vorhandene TwoWire Instanz übergeben kann.
Xento/ESPuino: RFID-controlled musicplayer powered by ESP32 (github.com)
Xento/ESPuino at ESPMuseLuxe (github.com)
Mit diesen Änderungen sollte erstmal die Wiedergabe funktionieren.
Den RFID Reader muss ich noch dran löten.
Ist eigentlich auch vorgesehen, dass der ESP bei fest angeschlossener Stromversorgung nicht in den DeepSleep geht oder erst nach einer längeren Wartezeit?
Man könnte ja einen Pin über USB-VCC auf High ziehen lassen.
Ist nicht vorgesehen. Weil: Was hat man davon (außer mehr Stromverbrauch)?
Naja dann könnte man den Lautsprecher per SmartHome ansprechen um dort zu jeder Zeit was abzuspielen.
Soviel mehr verbrauch dürfte das ja nicht sein.
Letztlich ist die Implementierung der Erkennung, ob die USB-Versorgung angeschlossen ist, an sich erstmal nicht weiter schwer. Und in Abhängigkeit dessen kann man dann was auch immer tun. Überlegt hatte ich schon mehrfach, sowas einzubauen, wobei es mir eher darum gegangen wäre zu detektieren, ob der Akku aufgeladen wird. Weil das könnte man über die GUI dann anzeigen. Aber gut: Das kommt am Ende auf’s Gleiche raus, weil der Akku kann nur aufgeladen werden, wenn USB-Versorgung vorliegt. Also spätestens mit der Complete-Platine, wenn ich sie denn endlich mal fertig habe, wird das kommen.
Aber sowas wie einen ESPuino dauerhaft laufen zu lassen entspricht ehrlich gesagt nicht so meiner Philosophie/Vision von einem RFID-Player, der vorrangig auf Kinder abzielt.
Und ich sehe dann schon Posts kommen von wegen „…funktioniert an für sich gut, aber manchmal habe ich das Problem, dass der ESP so nach sieben bis zehn Tagen nicht mehr ordentlich reagiert…“ und dann kann ich hier anfangen, das Problem nachzustellen. Nene 
. Ist nicht böse gemeint, aber wer das Feature möchte, der kann sich das ja gerne forken und auch hier gerne nen Thread mit Leben füllen. Da bin ich 100% d’accord und total offen für.
Ich bin so ein bisschen davon weg, dass mein Hauptzweig alles können muss, was jemals an Ideen aufkommt. Ich greife immer wieder Sachen auf, aber auch nicht alles. Weil ich sehe mich dann damit konfrontiert, dass ich das alles auch supporten muss. Und wenn ich hinter einem Feature nicht wirklich stehe, dann hält sich meine Support-Lust so ein bisschen in Grenzen, wie ich auch schon feststellen musste (A1S ist so ein Thema). Das ist aber eigentlich nicht die Art und Weise, wie ich ESPuino gerne präsentieren möchte, weil das speziell auch für Neuuser intransparent ist.
Aber wie gesagt: Bau’s gerne in deinen Fork ein und referenziere/beschreibe es - ist ja keine Diktatur hier 
.
Hmm ich musste gerade feststellen, dass die RC522 Module nicht so doll aufgebaut sind …
Da muss man scheinbar erst nen Loch in die Platine bohren, da der Pin 1 auf GND gelegt ist.
Ist es denn möglich den RFID Leser mit der SD Karte zusammen auf einen SPI Port zu legen?
Tatsächlich ist mit Single-SPI in ESPuino sowas eingebaut, da insbesondere mit den A1S-Audiokit das Problem besteht, dass zu wenige GPIOs verfügbar sind. Um es kurz zu sagen: Ich kann nur dringend davon abraten! Also erstmal besteht, wenn man SD per SPI anbindet schonmal grundsätzlich das Problem, dass der Datendurchsatz auf die SD-Karte nur etwa halb so hoch ist. Davon ab gibt es einen ungelösten Bug, dass Uploads auf die SD-Karte plötzlich abreißen und man davon nix mitkriegt (da haben schon mehrere Leute einiges an Zeit investiert, um das zu lösen - mag aber sein, dass das mit Arduino2 gelöst ist). Aber darüber hinaus gibt es ganz grundsätzlich das Problem, dass sich der RC522 und SD am gleichen SPI-Bus nicht richtig vertragen. Ich hatte es schon laufen, aber tatsächlich funktioniert das nicht verlässlich. Die vermutlich einzige Lösung ist, sich einen RC522 für i2c zu besorgen. Der „billige“ RC522 soll das zwar eigentlich können, kann es jedoch aufgrund eines Verdrahtungsfehlers (wenn ich mich recht entsinne) nicht.
Ok, ich gebs auf mit dem RC522 …
Hab jetzt zwei von den 3 Readern geschrottet …
Beim einen hab ich zu tief gebohrt nachdem der Pin immer noch Kontakt hatte.
Beim zweiten wollte ich den Chip entlöten und dann von oben die Bahn cutten.
Entlöten ging so weit allerdings bekomme ichs nicht hin den wieder richtig zu positionieren und wieder einzulöten und außerdem weiß ich auch nicht ob der Chip durch Entlöten nicht möglicherweise zu heiß wurde.
Ich hab jetzt 3 PN532 geordert, den kann man über nen DIP Schalter den Modus einstellen.
Daher ist der denke ich mal generell sehr interessant.
Vielleicht komme ich die Tage schon dazu das mal im Code einzubauen, Testen könnte ich erst am Mittwoch.
Weil er schön klein ist habe diesen Reader auf meinem Neopixelring verbaut. Habe I2C mit Espuino nicht ans Laufen gebracht . Ein Demo-Sketch hat mit I2C funktioniert.
Dann hatte ich nochmal 2 nachbestellt , habe aber Ersatztypen bekommen . Etwas größer , ohne die Brücken auf der Rückseite und in schwarz. Da ich die Platine verkleinern kann habe ich es nicht reklamiert und ich brauche auch kein I2C. Und der Preis , ich habe etwa 5 € je Stück bezahlt. Ich glaube auch RobotDyn ist vom Markt verschwunden , zumindest ist die Domäne geändert. Auch bei Ali gibt es die Produkte nicht mehr.
Soo, das lesen der Karten scheint erstmal zu funktionieren.
Allerdings erkennt er die Karte noch nicht komplett.
Ich hab mir die Kartenid mal per Hand umgerechnet, da in der GUI nichts automatisch eingetragen wurde.
RFID-Karte erkannt: 63-93-4f-2e
ws[/ws][1] text-message[87]: 099147079046
#/sample4.mp3#0#1#0
rfidAssign
EDIT: Ich hatte eine Stelle vergessen, wo ich noch den neuen RFID ReaderTyp hinzufügen musste.
Die Bibliothek die ich aktuell verwende ist aber irgendwie nicht so richtig PlatformIO tauglich.
Ich musste da noch Pfade in den Includes der lib anpassen damit es lief.
Was auch noch nicht so doll ist, ist das beim Start eines Titels bzw. Playlist meistens ein Knacken zu hören ist.
Ich vermute mal, dass sich das beheben lassen würde, wenn man die Stummschaltung des DACs erst aufhebt, wenn das Playback schon läuft.
Gabs mit sowas schonmal Probleme?
Ich hab mal nen kurzes Video der Geräusche gemacht:
https://youtube.com/shorts/jdqFgqVVW-0?feature=share
Ich kenne Störgeräusche nur beim Einschalten.
@compactflash Du bist doch der „Meister der Störgeräusche“ - was meinst du?
Sowas hatte ich noch nicht , bei mir war es auch beim Einschalten und beim Titelsprung , aber mit der aktuellen Version ist es weg . Und immer wieder möchte ich auf den schlechten Kontakt des Akkusteckers hinwiesen , das waren 75% meiner Probleme .
Versuche mal die Datenrate der MP3´s zu reduzieren , ich benutze nicht höher als 160kbps meist nur 128. Wie es mit dem aktuellen Code ist habe ich noch nicht getestet,
Also das Geräusch kommt nur, die eigentliche Wiedergabe noch nicht läuft.
Wenn der Track schon läuft, also schon „richtiger“ Ton raus kommt, dann kommt das Geräusch nicht.
Ist beim Webradio genauso.
Scheint ja nur beim Kartenlesen zu sein . Hast du mal im SPI-Mode probiert ?
Ist es möglich den Audioteil mit einer eigenen Spannung zu versorgen, wenigstens testweise ? Ich war manchmal schon soweit für Audio ein eigenes Netzteil zu spendieren ,die Spannung aus den ESP´s ist ganz schön verseucht , evtl. mit Elko + 100nF parallel am DAC und Endstufe an 3,3Vund GND testen.
Ich glaub nicht, dass es am Lesen der Karte liegt, wenn die Wiedergabe läuft, dann stoppt diese zwar kurz, aber es kommt kein Geräusch.
Nur wenn ich die Karte nochmal lesen lasse bevor die eigentliche Wiedergabe kommt.
SPI Mode habe ich noch nicht probiert, da müsste ich erstmal schauen, welche Pins überhaupt noch frei sind.
Ich hab irgendwie den ES8388 im Verdacht, dass der das Geräusch macht, wenn der über I2S das erste Signal bekommt und das irgendwie noch nicht richtig „gültig“ ist.
Ist ja beim Webstream auch so. Wenn ich Pause drücke und dann scanne kommen die Geräusche.
Läuft die Wiedergabe bereits und ich scanne kommen keine.
Hier ist der aktuelle Stand der Implementierung des PN532 Readers.
Bin gerade im Urlaub und leider ist mir mein USB Kabel kaputt gegangen, daher kann ichs gerade nicht auf dem Gerät testen.
Ich glaub die Erkennung, dass immer noch die gleiche Karte auf dem Reader fehlt noch, ansonsten sollte das schon laufen.
So Sachen wie IRQ oder die Optimierung des Stromverbrauchs müsste man sich vielleicht auch noch anschauen.
Xento/ESPuino at PN532 (github.com)
Für die Implementierung des ES8388 wollte ich noch schauen, ob ich mit ner Stumschaltung die Knackers wegbekomme, aber das kann ich erst testen, wenn ich nen neues Kabel habe.
Vielleicht könnte ja schonmal wer über die Ansätze der Implementierung schauen, ob das so ins Konzept passt.
Wegen den komischen Geräuschen am Anfang: Gehe mal in die Platformio.ini und ersetze mal
https://github.com/schreibfaul1/ESP32-audioI2S.git
durch
https://github.com/schreibfaul1/ESP32-audioI2S.git#b2b5312
Dann neu kompilieren und hochladen. Ich habe demletzt festgestellt, dass ich da auch Probleme mit solchen Geräuschen habe und meine Vermutung ist, dass das in den letzten Wochen in die Lib reingekommen ist.
Danke, werd ich am Freitag oder am Samstag mal ausprobieren.
Ich hab da auch noch nen Vorschlag für einen Offline Modus wo man dann über den AP trotzdem auf den ESPuino kommt.
Vielleicht könnte man auch einen Dualen Modus einbauen, also AP und Client in einem.
Hier im Urlaub hab ich zwar WLAN, aber die Geräte sehen sich untereinander nicht.