steige gerade immer tiefer in das Projekt ein und bin total happy was schon alles geht.
Aktuell fallen mir die folgenden Probleme auf:
das zurückspulen scheint nicht mehr zu funktionieren. Die Position wird eigentlich dem File richtig mitgeteilt, es funktioniert aber scheinbar nur vorwärts… Hat damit jemand in letzter Zeit Erfahrungen mit gesammelt?
das TTS beim IP-Vorlesen ist total zerhackt. Über komische Nebeneffekte (Vorlesen während eines Liedes und dann „pause“ drücken) bekommt man es verständlich. Kann mir jemand helfen das zu fixen? Bin aktuell noch am herausfinden was da wohl dazwischen funkt.
Vielen Dank für all die Arbeit und dieses tolle Weihnachtsgeschenk für meine Kids!
Das jumpOffset definiert man in der settings.h und das stecke ich hier einfach rein - im Falle von „backwords“ halt als negativen Wert.
Hmm, ich bin ja die ganze Zeit so ein bisschen davon ausgegangen, dass das ein Problem mit der Synthese ist. Vielleicht ist das Problem ja irgendwie, dass ESPuino sich hierbei im Modus Pause befindet. Und wenn das der Fall ist, dann wird Zeit in jeder Loop verbraten, damit der Audiotask nicht gegen die Wand fährt:
Vielleicht kannst du da mal ein Serial.println reinmachen und schauen, ob dieses println ausgeführt wird, wenn die Aktion CMD_TELL_IP_ADDRESS läuft. Das wäre zumindest eine mögliche Erklärung.
Brauchst gar nicht schauen, das passiert auf jeden Fall
Dann weiß ich gerade nicht, warum das am Anfang gelaufen ist
Schau mal, ob das so geht:
if (gPlayProperties.playlistFinished || gPlayProperties.pausePlay) {
if (!gPlayProperties.currentSpeechActive) {
vTaskDelay(portTICK_PERIOD_MS * 10); // Waste some time if playlist is not active
}
} else {
System_UpdateActivityTimer(); // Refresh if playlist is active so uC will not fall asleep due to reaching inactivity-time
}
Das sieht total plausibel aus. Vielen Dank dir für die Antwort!
Werde das später einbauen und testen.
Wegen dem zurückspulen: ESPuino macht da soweit ich es nachvollziehen konnte alles richtig. Es wird die richtige Position im file gesetzt, allerdings scheinbar ohne Auswirkungen. Oder es wird halt kurz darauf von etwas anderen wieder zurück gesetzt. Ich versuche das Mal noch weiter zu debuggen wann und ob die Position springt. Schließlich geht bei vorwärts ja alles wie es soll…
Hat funktioniert! Soll ich dazu einen PR erstellen, oder pusht du das selbst?
Habe auch nochmal eine Erkenntins zu dem Spulen! Ist ein Bug in der Audio.cpp
Dort wird der Buffer bei setTimeOffset nicht berücksichtig. Wenn ich den hinzufüge („- inBufferFilled();“) dann klappt es!
Jetzt meine Frage, da ich noch ganz neu in dieser Art von Projekt bin:
Kann man einen PR für einen Bugfix in dieser Lib erstellen? Oder wie macht man das üblicherweise?
Entschuldigung sollte das eine dumme Frage sein …
Auf diese Art funktioniert es jetzt:
bool Audio::setTimeOffset(int sec){
// fast forward or rewind the current position in seconds
// audiosource must be a mp3, aac or wav file
if(!audiofile || !m_avr_bitrate) return false;
uint32_t oneSec = m_avr_bitrate / 8; // bytes decoded in one sec
int32_t offset = oneSec * sec; // bytes to be wind/rewind
uint32_t startAB = m_audioDataStart; // audioblock begin
uint32_t endAB = m_audioDataStart + m_audioDataSize; // audioblock end
if(m_codec == CODEC_MP3 || m_codec == CODEC_AAC || m_codec == CODEC_WAV || m_codec == CODEC_FLAC){
int32_t pos = getFilePos() - inBufferFilled();
pos += offset;
if(pos < (int32_t)startAB) pos = startAB;
if(pos >= (int32_t)endAB) pos = endAB;
setFilePos(pos);
return true;
}
return false;
}
Noch eine andere Sache: Ich habe für das Hauptrepo zwei PR erstellt.
Einmal zwei Bugs mit der LED-Anzeige im Kontext Lautsärken-Änderung und einmal das Verhalten, dass wenn von Bluetooth-Lautsprecher-Modus aus auf eine Musik-Karte reagiert wird, diese gleich auch beim Reboot verwendet wird.
Wenn die Art nicht passt oder ich da entsprechend nacharbeiten soll, einfach Bescheid geben, dann ändere ich das. Passt auch wenn das nicht in den master kommt, wollte die Änderungen aber nicht für mich behalten…
Nee, das passt schon. Ich habe nur in letzter Zeit viel Zeit in Sachen Hardware verbraten (Neudesign, Kram löten), so dass mir oft die Lust fehlt, noch weitere Zeit für Software zu investieren.
Noch eine Frage:
Habe gerade den LPCD in Betrieb genommen, dieser wird aber aktuell immer getriggered. Mal unmittelbar, mal nach bis zu 10 s.
Im Log steht als Trigger immer ein Push-Button, das kann aber an dem Portexpander liegen. Oder?
Ist das ein bekanntes Problem?
Habe die fw auf 4.1 und die Juper 1 (2-3) und Jumper 4 gesetzt…
Als ich das vor ein paar Wochen zuletzt getestet habe (ich selbst nutze LPCD nicht), hat es funktioniert. Kannst ja mal versuchen, einen 10k-Widerstand am PN5180 zwischen IRQ und 3.3 V einzulöten. Vielleicht bringt das was.
Richtige Zuordnung RFID_IRQ am Besten an einem echten GPIO (nicht am Port-Expander)
PN5180 Leser muss dauerhaft mit Strom (3.3/5V) versorgt sein, auch im deep-sleep Modus
Arduino 1.0.6 (Bei 2.x gibt es Probleme weil der Zustand nicht gehalten wird)
Pullup-Widerstand ist meiner Erinnerung nach nicht notwendig (Kann es jetzt auf die Schnelle nicht genau sagen)
Was zeigt die serielle Debugausgabe? Poste das mal hier…
Edit:
Der PN5180 wirft immer mal wieder einen IRQ, der ESP32 wacht auf, prüft auf eine vorhandene RFID-Karte. Falls nicht vorhanden legt er sich wieder schlafen. Das wäre also normal…
OK, das mit dem Port-Expander sollte passen, „Push-Button“ Eintrag wäre also OK.
Bitte mal messen on der PN5180 ständig mit Spannung versorgt wird. Als zusätziche Kontrolle kannst Du eine LED mit Vorwiderstand am PN5180 IRQ anschließen.
Vielen Dank! Wenn also das aktuelle board verwendet wird und der IRQ auf den PortExpander geht, dann kann auch nicht differenziert werden, dass gerade gar kein IRQ vom Reader kam und somit startet er direkt?
Im Debug steht immer, dass er einen userbutton erkannt hat und deshalb startet.
Das ist korrekt. Das wird über den Port-Expander erkannt wie ein normaler Tastendruck. Geht nicht anders.
Wenn du das nicht willst, dann verwende PE.115 für Power (anstelle GPIO32) und stattdessen GPIO32 für den IRQ von RFID.PN5180. JP4 musst du dafür öffnen und einen Draht von PN5180.IRQ auf ext.13 löten.
Musst dann im Settings-File halt den IRQ-Pin anpassen (im Falle von Port-Expander ist der wurscht) und auch den GPIO für Power auf 115 ändern.
=> Habe ich nicht getestet, aber müsste so klappen.
Werde es heute Abend nochmal versuchen.
Zum Verständnis aber nochmal kurz:
Wenn der IRQ auf dem portexpander liegt, dann ist der GPIO ja größer als MaxGpio und somit ist die Erkennung nicht möglich. Damit würde der IRQ vom Portexpander anschlagen aber nicht erkannt werden, dass es eigentlich der RFID-Reader war.
Somit würde er starten da ein „userbutton“ erkannt wurde obwohl es nur der falsche Alarm vom RFID-Reader war.
Oder verstehe ich hier das Konzept oder eine Einstellung noch nicht?
Also der ESP32 besitzt GPIOs von 0 bis 39. Um das Ganze (GPIOs und Eingänge vom PE) uniform zu behandeln, habe ich jedoch festgelegt, dass innerhalb von 100 bis 115 die PE-Pins liegen. Das Übersetzen von 100 bis 115 macht Port.cpp. Wobei natürlich aber klar sein muss, dass ein Pin eines Port-Expanders bei weitem nicht so viel kann, wie ein GPIO. Aber für sowas wie Buttons (oder IRQs) ist es natürlich kein Problem.
Setzt man nun den GPIO für PN5180.IRQ auf z.B. 32, dann „sagt“ ESPuino dem ESP32: Ok, also wenn du in Deepsleep gehst, dann höre auf GPIO32 und wenn da was passiert, dann wache auf. Es gibt dann also einen GPIO zum Aufwecken per Taster (z.B. 36) und noch einen per PN5180.IRQ (32). Und im Code kann ich natürlich erkennen, ob das 32 oder 36 war. Und wenn es dann 32 ist, dann kann ich schauen, ob es ein Falschalarm war oder nicht.
Wickelt man das über den PE ab, dann ist das anders. D.h. alle Pins sind per Default Eingänge (Ausgänge muss man aktiv konfigurieren). Und ändert sich der Spannungsregler von HI auf LO, egal bei welchem Eingang, dann wirft der PE einen Interrupt, der dann von GPIO36 ausgelesen wird. Welcher Pin jedoch für den IRQ letztlich verantwortlich war, das weißt du nicht. Und das sorgt eben dafür, dass alle Eingänge gleichberechtigt den ESP32 aufwecken lassen können. Und deswegen kann man sich das Eintragen des PN5180.IRQ im Settings-File beim Port-Expander (nur dort!) auch sparen (schadet aber auch nicht), weil es wird eh nicht ausgelesen.
ESPuino verwendet, Stand jetzt, ESP32-Arduino 1.0.6. Wenn man auf v2 gehen will, dann muss man das aktiv in platformio.ini umstellen.
Vielen Dank dir.
Zusammen mit der Info von oben, dass der RFID regelmäßig falsche IRQs wirft schließt das die sinnvolle Verwendung über den Portexpander dann aus.
Also auftrennen von JP4 und auf einen anderen freien und kompatiblen GPIO umlöten (z.B. GPIO 0 von dem großen Stecker)…
…
passt. Danke