ESP32 Audio Kit (ESP32-A1S)

Hallo zusammen,

beim Stöbern nach ESP32 Boards bin ich auf dieses Modell hier gestoßen. Da ist eigentlich schon fast alles drauf was man für einen ESPuino braucht. Man müsste nur noch RFID Reader, Neopixel Ring und Lautsprecher anschließen. Der Rest wäre auf dem Board vorhanden.

Die Frage ist nur, wie aufwändig es wäre, die ESPuino Software auf den verwendeten ESP32-A1S und die onboard Komponenten anzupassen. Oder übersehe ich hier irgendwas, was das Board unbrauchbar für einen ESPuino macht?

Viele Grüße,
Alex

Tatsächlich wird dieses Board sogar unterstützt; so halb zumindest :slight_smile: Ich habe vor einer Weile hier dazu was aufgemacht: ESPuino/Hardware-Plaforms/ESP32-A1S-Audiokit at master · biologist79/ESPuino · GitHub
Das war zu einer Zeit, in der am Code nicht soooo viel passiert ist. Dann, Ende November/Anfang Dezember, ist der Code ziemlich gewachsen und damit war das Ganze quasi veraltet. Ich hatte aber auch nicht wirklich Zeit, mich darum zu kümmern. Es hat sich dann glaub kkloesner die Arbeit gemacht und es in meinen Master-Branch integriert. Tatsächlich ist es so, dass wenn man HAL=2 setzt in der settings.h, man dann auch im passenden Config-File (‚settings-espa1s.h‘) landet. Ob das aktuell fehlerfrei läuft, kann ich nicht sagen. Mir fehlt einfach die Zeit, das zu testen. Und da ich das Board für nur bedingt geeignet halte, auch so ein bisschen die Lust (wenn ihr ehrlich bin).

Also man muss mit SINGLE_SPI arbeiten, Widerstände auslöten und an den SD-Kartenslot Drähte anlöten. Das zentrale Problem ist einfach, dass die GPIOs echt knapp sind. Für Batteriebetrieb eignet sich das Board auch nicht, da es selbst im Deepsleep noch satte 30 mA frisst. Habe das Board auf jeden Fall hier. Das hat mir nettweise ein User aus dem „Forum nebenan“ zur Verfügung gestellt.

Was ich noch dazusagen muss: Das hat ja unten eine ganze Reihe an Tastern eingebaut. Diese sind über zwei Wege „angebunden“. D.h. einerseits digital über mehrere GPIOs. Hier ist halt das Problem, dass sie zur Entprellung Kondensatoren am Start haben und die sind für höherwertige Signale (SPI zB) halt schädlich. Man kann die digitale Anbindung durch Entfernen der Widerstände jedoch abkoppeln und sie analog einlesen. Dafür muss man jedoch Spannungsteiler einlöten. Man kann es allerdings auch lassen und die Tasten einfach nicht nutzen :slight_smile: Glaube die Erste von links funktioniert aber weiterhin

Der ESP-A1S selbst kann auf jeden Fall problemlos angesprochen werden. Für diesen braucht es zusätzlich die AC101-Lib und es liegen auch ein paar GPIOs anders. Auch die Amp muss aktiviert werden. Diese ganzen Sachen sind in ESPuino auf jeden Fall berücksichtigt, wenn man HAL=2 setzt. Das Einzige, sofern der Code aktuell kompiliert (kann aber nicht viel sein wenn das nicht der Fall ist), wird der RFID-Reader sein. Ich hatte da immer mal wieder das Problem, dass es beim RC522 zu keiner Fehlermeldung kam, jedoch auch nix passiert ist, wenn man eine Karte aufgelegt hat.

Grundsätzlich denke ich werden sich ja primär Leute für dieses Board interessieren, die nicht löten wollen oder können. Dass man jedoch SMD-Widerstände auslöten muss und auch ein ruhiges Händchen zum Anlöten zweier Drähte an den SD-Slot braucht, macht das Ganze vermutlich wieder ein Stück weit uninteressant.

Ich hatte übrigens gerade gestern Mittag nochmal überlegt, ob ich das Thema hier nochmal proaktiv aufgreife. Dachte mir jedoch ich warte einfach mal ab, ob sich dafür überhaupt noch jmd. interessiert :slight_smile: Denke also ich werde das nochmal machen.

Hallo,
ich habe meine Box mit ESP32-A1S v2.2 aufgebaut. Zu dem Zeitpunkt war die SW noch sehr frisch hier. Leichte Umbauten sind nötig. Um Strom zu trennen verwende ich Pololu Mini. So kann der ESP sich selber abschalten. Weil die Abschaltung nach dem 3V Regler erfolgt und eine LED dauernd leuchtet habe ich 2mA Ruhestrom. Ich verwende 5 Tasten die analog angeschlossen sind. Sehr portsparende Lösung. Jetzt sehe ich, dass sich seitdem bei der SW sehr viel verändert hat. Bin gespannt wie lange es jetzt dauert um alles zum laufen zu bekommen. :blush:

Cool. Da hast jetzt aber für die analoge Lösung SMD-Widerstände einlöten müssen, oder? Welche Größen (Ohm, nicht SMD :slight_smile:) hast da verwendet?

Ich hatte leider nicht mehr so wirklich Zeit, mich um den A1S zu kümmern, weil soviel Anderes zu tun war :woman_shrugging:

Ich habe normale Draht-Widerstände auf der Lochplatine gleich neben den Schalter gelötet. Meine Auswahl ist begrenzt und so habe ich : 1k; 2,2k; 4,7k; 10k und für Absicherung 47k und 10k verwendet.

2 Like

Hallo zusammen,
seit heute läuft bei mir der ESPuino auf dem ESP32A1S Audiokit von AI Thinker. Ich möchte hier meine Erfahrungen schildern, damit der Nachbau einfacher wird.
Im Mikrocontroller Forum A1S Eval findet man einige Infos, wie das Bord vorbereitet werden kann, einige RC-Glieder liegen parallel zu den GPIOs und sind bei hohen Frequenzen störend. Mir hat das Zusammensuchen der passenden Libraries und die richtige Konfiguration einige Stunden gekostet. Auf dem Board befindet sich der ESP32A1S der bereits den DAC (AC101) beinhaltet. Somit ist kein externer DAC wie der PCM1502A notwendig. Zwei 3W Verstärker für 4 Ohm Lautsprecher und ein SD Karteneinschub sind vorhanden. Der Zusammenbau ist ohne viel Bastelei möglich. Die SD Card läuft als SD_MMC. Über die Steckleisten sind 6 GPIOs herausgeführt (Schalter S1 aus, S2-5 an). Verwendet habe ich für den MRFC522 die drei SPI Leitungen (MOSI 23, MISO 19, CLK 18) und als RFID_CS den Pin 5. Dem RST-PIN habe ich den Wert (-1) zugewiesen und mit RST des Boards verbunden (man muss bei dem A1S schliesslich GPIOs sparen). Der Neopixel Ring hat GPIO 0 und der Drehencoder hat CLK 13, DT 22, SW 12. Wobei Pin 12 der Taster ist denn GPIO 12 darf während des Bootens nicht auf GND liegen.
MQTT habe ich nicht aktiviert, der FTP Server kommt mit SD_MMC nicht klar. In „settingsespa1s.h“ muss noch #include „Wire.h“ nachgetragen werden, I2C ist deaktiv wenn es für den MRFC522 nicht benutzt wird. Für PlatformIO User könnte es dann schon alles sein. Wer in Eclipse programmiert bekommt jetzt reichlich Fehlermeldungen. Grund sind die fehlenden Guards in den Header Dateien. Original hat nur „values.h“ welche. Überall ein „#pragma one“ an den Anfang gesetzt löst das Problem. Die Compilerwarnungen die hauptsächlich durch die Json Lib? verursacht werden, können ignoriert werden. Wenn alles passt, hochladen und es läuft sofort! Die Verbindung mit meinem Smartphone hat geklappt, ich konnte die WLAN Zugangsdaten eintragen und hatte nach einem Neustart sofort die „Homepage“ für die weiteren Einstellungen. Alles in allem ein gelungenes Projekt! :smiley:
ESPuino
Gruß
Wolle

6 Like

@Wolle Reden wir von dem Wolle? :slight_smile:
Mit den Pragmas hast du Recht, die muss ich noch reinnehmen.
Ansonsten habe ich, wie oben schon geschrieben, dieses Audio Kit, nachdem ich es initial „hingebracht“ habe, ein Stück weit vernachlässigt. Sind einfach zu viele Baustellen… :slight_smile:

Ja, genau der. Du warst oft auf meinem Github Repo unterwegs und einige der Forenmitglieder vermutlich auch. Ich bin erstaunt, dass das Dein Projekt so umfangreich ist, da steckt viel Arbeit drin. Und die Webseitengestaltung überzeugt! In diesem Stil würde ich mir ein Webradio wünschen.
vG
Wolle

1 Like

Hehe, ich fühle mich geehrt. Ohne Witz! :smiley: Herzlich willkommen!

Das Lob gebe ich gerne zurück und möchte mich an dieser Stelle mal bedanken für die ganze Arbeit, die du in deine Lib gesteckt hast und die dieses Projekt hier überhaupt erst ermöglicht hat. Sind ja in letzter Zeit doch ordentlich viele Support-Anfragen bei dir eingetrudelt via GitHub. Tatsächlich, wie du schon vermutet hattest, kam auch die ein oder andere Anfrage in letzter Zeit aus meinem Umfeld (Umlaute z.B.). Cool!

@Rest: @Wolle habt ihr die Lib zu verdanken, die der ESPuino einsetzt, um eure Audiofiles zu dekodieren.

Hallo Torsten,
vielen Dank für die Blumen :slight_smile: Ich habe etwas mit dem ESPuino gespielt und muss sagen, vieles funktioniert richtig gut, besonders die Idee mit dem Neopixelring gefällt mir. Kein Wunder, wenn Dein Projekt viele Fans hat, nicht nur bei den Kleinen. Mir ist aufgefallen, dass viel RAM verwendet wird. Wenn den Dekodern nicht genügend Speicher zugewiesen werden kann stürzt die Audio-Lib ab. Das wird mit der nächsten Version geändert. Außerden verwalten die Dekoder dann ihren Speicher selbständig im PSRAM, sofern dieser verfügbar ist. So können ~50KByte gespart werden und AAC-SBR kann vernünftig genutzt werden. Für Podcasts oder Dateien die nicht lokal gespeichert sind , z.B auf einer FritzBox, NAS…, gibt es ein Callback audio_eof_stream() ahnlich dem eof bei lokalen Dateien. Damit kann verhindert werden dass der ESPuino in einer Dauerschleife bleibt nachdem der Stream beendet wurde.

3 Like

Na das klingt doch gut. Ja es gibt auch immer mal wieder Webstreams, die problematisch sind. Ich habe den Eindruck, dass dort mehrere Weiterleitungen existieren und das dann irgendwie zu Speicherproblemen führt. Irgendwelche Rockradiosender scheinen hier insbesondere betroffen zu sein - warum auch immer :slight_smile: Momentan haben wir hier ganz klar einen Schwerpunkt zu ESP32-Modellen, die kein PSRAM besitzen. Das liegt einfach darin begründet, dass ich noch kein WROVER-Boarrd gefunden habe, das

  • wenig Strom im Deepsleep braucht
  • eine integrierte Ladeelektronik für LiPo hat
  • SD mit SD_MMC

Das TTGO T8 1.7 ist eigentlich nahe drin, aber der Deepsleep-Verbrauch ist zu hoch. Das Wemos Lolin D32 pro hat im Gegenzug wenig Verbrauch, aber kein SD via SD_MMC. Aber gut, es sind alle GPIOs rausgeführt; man könnte es extern auch „ankoppeln“. Aber insgesamt gibt es ja Bestrebungen, eine eigene Platine an den Start zu bringen und das wird dann WROVER sein.

Das Verhindern der Dauerschleife ist auf jeden Fall gut. Ich hatte ja demletzt schonmal was in deinem Repository aufgemacht und gefragt, ob du eine Möglichkeit siehst, dass man die Kontrolle zurück bekommt, wenn der Stream abgerissen ist. Weil im Batteriemodus kommst du da ohne Reset-Knopf oder Öffnen des Gehäuses nicht mehr raus.

Eine prinzipielle Frage habe ich nochmal. Wenn du etwas rumprobiert hast, ist dir bestimmt aufgefallen, dass es beim Lautermachen/Leisermachen bissl abgehackt klingt, wenn man die Lautstärke via Drehencoder schnell ändert. Siehst du da einen Ansatzpunkt, dass man das etwas „smoother“ machen kann oder geht das prinzipbedingt nicht anders? Ist grundsätzlich vielleicht ne Art und Weise, wie du deinen Code noch nicht gesteuert hast bisher und daher in das Problem noch gar nicht gelaufen bist.

Noch eine Anmerkung zu FTP: Das wundert mich eigentlich, dass SD_MMC mit FTP bei dir nicht ging. Also mit dem Audiokit habe ich das nie getestet, aber grundsätzlich sollte das eigentlich klappen.

Hallo @Wolle , du hattest mir auch schonmal mit PT8211 was implementiert , auch an dieser Stelle nochmals DANKE .

ich habe auf meinem Protoboard einen Wrover mit SD_MMC , FTP läuft einwandfrei .

Ich habe mal eine Frage zu A1S.
Ich verwende ja auf meiner Kopfhörerplatine den PCM5102A in Verbindung mit einem TDA1308 . Das klingt richtig gut . Benutze es auch am RaspberryPi mit Picoreplayer .
Laut Papier hat der AC101 nicht so gute Werte … wie ist dein Höreindruck , hälst du es für sinnvoll deinen besten Kopfhörer daran anzuschließen ? Ich experimentiere für mein neues Board der Einfachheit halber mit dem PT8211 , aber so ein ESP32-A1S wäre noch einfacher . Der Audio-Kit ist für mich uninteressant aber ein eigenes Board damit könnte ich mir vorstellen .

Hi compactflash,
ich glaube, dass der AC101 gar nicht so schlecht ist. Nach meinen Eindruck unterscheidet er sich nicht von den anderen DACs. Die Lautstärke ist bei Kopfhöreranschluss ähnlich. Verzerrungen, die nur durch das Ändern eines Registerwertes beseitigt werden können habe ich nicht beobachtet. Der Nachteil des A1S sind die wenigen vorhandenen GPIOs. Bei dem Board von AI Thinker sind dann noch welche nicht herausgeführt, sondern sind intern verkabelt für die Überwachung der Kopfhörerbuche, dem Einschalten der Verstärker und für eine nicht vorhandene Widerstandskaskade um die Tasten abfragen zu können.
Das mit dem FTP ist nicht so wichtig, vielleicht habe ich eine falsche Lib benutzt, die erste kannte eine Methode nicht (isConnected() wurde nicht gefunden) und die zweite ??? das muss ich mir erst noch genauer ansehen.

@Wolle Schaue mal in die platformio.ini. Du musst die Ftp Lib aus meinem Repository nehmen. IsConnected() wird gebraucht, damit der espuino sich nicht abschaltet beim Transfer.
Aber den muss man anschließend auch erst starten, damit er nicht grundlos Speicher frisst :grin:

Der FTP Server läuft jetzt. Zunächst habe ich versucht den 16KB großen Buffer in den PSRAM zu verlagern. Bei großen Datenblöcken wird die Eingangsqeue zugestopft was eine Geschwindigkeitsreduzierung verursacht. Wenn der Buffer auf 4096 gesetzt wird (das ist die Größe von WiFi und SD Buff) erhöht sich die Geschwindigkeit etwas. Mit einer OneBit SD_MMC habe ich im Upload 355KB und im Download 500KB erreicht. Vielleicht kann man so den FTP Server dauerhaft laufen lassen, ohne ihn zuschalten zu müssen.

Also ursprünglich war der Buffer mal 512b groß. Ich habe ihn dann vergrößert und festgestellt, dass dass damit die Geschwindigkeit ansteigt. Allerdings war das damals nicht auf dem Heap allokiert und so habe ich mir fiese Speicherprobleme eingefallen. Oder sagen wir es mal so: Es war für mich überhaupt nicht ersichtlich, dass es ein Ram-Problem ist. Ich habe den Speicher dann also wieder von 8 auf 4k verkleinert. Glaub damit hatte ich so 150 kB/s rum. Irgendwann kam ich dann auf die Idee, den Speicher auf dem Heap zu allokieren. Weil Heap hat der esp32 irgendwie gefühlt ohne Ende, aber static RAM ist auf knapp über 100k limitiert (warum weiß ich nicht).
Nachdem ESPuino dann auch sdmmc gelernt hatte, hat sich nochmal einiges getan was den Durchsatz angeht. Ich kam auch auf die Idee, vielleicht mal den psram zu benutzen, aber hab’s nicht priorisiert, da psram nur per spi angebunden ist. Ich glaube von @Harry hatte ich dann gelesen, dass er es probiert hatte, das aber langsam war.

Jetzt Frage an dich @Wolle: Was genau hast du jetzt angepasst? Den Heap für FTP von 8 auf 4 reduziert? Also vielleicht verhält sich das bei sdmmc anders, aber bei spi war ein größerer Buffer auf jeden Fall vorteilhaft.

Die schnellste Rate habe ich bisher im Webupload gesehen: Da hatte ich so 370 kB/s rum gemessen. @Harry hatte es ein bisschen gepimpt, so dass ein Code die Daten annimmt und ein weiterer schreibt.

Im FTP Server werden die Daten so übertragen:

  •  nb = file.readBytes(buf, FTP_BUF_SIZE);
    
  • data.write((uint8_t*) buf, nb);
    

nb ist hier der Buffer und bekommt von der SD einen Datenblock und gibt ihn an data, dem WiFi Client, weiter. Beim Upload ist das dann andersrum. WiFi kann nur 4K Blöcke verarbeiten, und dann den nächsten, den nächsten … usw. So denke ich sind 4K das Optimum und ich glaube ursprünglich war FTP_BUF_SIZE 16K eingestellt. Bei mir bringt die Verringerung aus 4096 diesen Geschwindigkeitsvorteil.

Danke für die Infos. Das werde ich dann nochmal testen.
Meine Angaben von oben bezogen sich ausschließlich auf SPI. Mit SD_MMC habe ich da nix mehr gemacht.

Hi @Wolle, vielen Dank für die Infos zur Inbetriebnahme des A1S Boards. Ich finde das Board auch sehr interessant für das ESPuino Projekt. Hardwareseitig habe ich die R66 bis R70 ausgelötet, und die ESPuino Software mit HAL = 2 geflasht. Das Board bootet, hängt in meinem WLAN und spielt MP3s über die Steuerung via Webinterface ab. Der Anschluss des MRFC522 über SPI klappt jedoch leider noch nicht (RFID_CS etc. habe ich in settings-espa1s.h neu definiert): Es werden keine Karten gelesen.
Ich habe nun gesehen, dass Du einen Fork des Projektes angelegt hast (GitHub - schreibfaul1/ESPuino: RFID-controlled musicplayer powered by ESP32); korrespondiert der Fork mit Deiner Beschreibung hier? Dann würde ich diesen Fork mal probieren. Oder soll ich lieber noch etwas warten?
Grüße Johannes