Box braucht 8 Sekunden bis sie anläuft nach auflegen der Karte

OK, dann stelle ich die Frage anders. Bei wem dauert es unter 5 Sekunden und mit welchem Setup? Meiner Tochter sind die 5 Sekunden zu lang :slight_smile: Und ich hab schon echt viele DFPlayer durch und frage mich ob es sich lohnt die 10€ für das Set bei Amazon auszugeben oder einen teureren DFPlayer zu kaufen.
Hat hier nicht Mal jemand versucht an die “original” Chips zu kommen? Ist da was draus geworden?

Ich habs jetzt mal mit millis() gemessen: 4.29s braucht meine Setup Routine von Anfang bis Ende. Am Ende wird ein “pling” abgespielt. Das ist inkl. der o.g. 2s delay nach dem init des Players. 393 Dateien (breinigt von dem was in advert und mp3 ist) auf der SD Karte. Firmware ist meine mit allen Features ausser 5 Buttons an.

Das Original Modul bzw. der Chip kommt von hier (wurde aber auch schon an anderer Stelle im Forum gepostet). So zumindest die Rechercheergebnisse… Aber ich bezweifle das es damit schneller läuft. In irgendeiner Doku habe ich mal gelesen das der Player einfach auch Zeit braucht um startklar zu sein.

So, ich habe jetzt auch nochmal bei mir gemessen:
Wenn schon eine Karte drauf liegt dauert es ca. 2,9 Sekunden bis zum ersten Ton.
Habe allerdings auch nicht die aktuelle Dev-Version drauf mit den 2s Delay, sondern eine modifizierte Master-Version.

Ich grab das nochmal aus, weil mich die lange Initialisierung auch beschäftigt.
Hat jemand getestet, die mp3.beginn Funktion an den Anfang des Setup() zu setzen und am Ende die ersten Befehle zum DF Player zu schicken?

Dazu hab ich noch gesehen, das für den Zufallsgenerator 128 Schleifendurchläufe gemacht werden. kann man diese evtl auch reduzieren.

Hinzu kommen die ganzen seriellen Ausgaben, auch die werden sicher Ihte Zeit benötigen. Diese kann man doch über einen #ifdef DEBUG deaktivierbar machen. Genauso wie das lesen der RFID Reader Informationen.

2 Like

Ja, da kann man sicherlich noch was optimieren. Deine Vorschläge klingen vernünftig und könnte man mal antesten.

Um zu erreichen, dass der Zufallsgenerator bei jedem Start anders initialisiert ist, man auch unregelmäßig (z.B. immer beim Auflegen einer Karte) die untersten 8 Bit der seit Start vergangenen Millisekunden auf dem EPROM speichern und diesen Wert mit für die Initialisierung des Zufallsgenerators beim Start nehmen. Dann sind gar keine Schleifen nötig.

Ich hab das mal getestet und folgende setup() Methode gerade in Benutzung

void setup() {
  #ifdef DEBUG
  Serial.begin(115200); // Es gibt ein paar Debug Ausgaben über die serielle Schnittstelle
  #endif
  
  mp3.begin();

  // Wert für randomSeed() erzeugen durch das mehrfache Sammeln von rauschenden LSBs eines offenen Analogeingangs
  uint32_t ADC_LSB;
  uint32_t ADCSeed;
  for(uint8_t i = 0; i < 32; i++) {
    ADC_LSB = analogRead(openAnalogPin) & 0x1;
    ADCSeed ^= ADC_LSB << (i % 32); 
  }
  randomSeed(ADCSeed); // Zufallsgenerator initialisieren
  #ifdef DEBUG
  Serial.println(ADCSeed);
  #endif
  #ifdef DEBUG
  // Dieser Hinweis darf nicht entfernt werden
  Serial.println(F("\n _____         _____ _____ _____ _____"));
  Serial.println(F("|_   _|___ ___|  |  |     |   | |     |"));
  Serial.println(F("  | | | . |   |  |  |-   -| | | |  |  |"));
  Serial.println(F("  |_| |___|_|_|_____|_____|_|___|_____|\n"));
  Serial.println(F("TonUINO Version 2.1"));
  Serial.println(F("created by Thorsten Voß and licensed under GNU/GPL."));
  Serial.println(F("Information and contribution at https://tonuino.de.\n"));
  #endif  
  
  // Busy Pin
  pinMode(busyPin, INPUT);

  // load Settings from EEPROM
  loadSettingsFromFlash();

  // activate standby timer
  setstandbyTimer();

// DFPlayer Mini initialisieren
//  mp3.begin();
//  // Zwei Sekunden warten bis der DFPlayer Mini initialisiert ist
//  delay(2000);
  volume = mySettings.initVolume;
  mp3.setVolume(volume);
  mp3.setEq(mySettings.eq - 1);
  // Fix für das Problem mit dem Timeout (ist jetzt in Upstream daher nicht mehr nötig!)
  //mySoftwareSerial.setTimeout(10000);

  // NFC Leser initialisieren
  SPI.begin();        // Init SPI bus
  mfrc522.PCD_Init(); // Init MFRC522
  mfrc522
  //#ifdef DEBUG
  .PCD_DumpVersionToSerial(); // Show details of PCD - MFRC522 Card Reader
  for (byte i = 0; i < 6; i++) {
    key.keyByte[i] = 0xFF;
  //#endif

  }

  pinMode(buttonPause, INPUT_PULLUP);
  pinMode(buttonUp, INPUT_PULLUP);
  pinMode(buttonDown, INPUT_PULLUP);
#ifdef FIVEBUTTONS
  pinMode(buttonFourPin, INPUT_PULLUP);
  pinMode(buttonFivePin, INPUT_PULLUP);
#endif
  pinMode(shutdownPin, OUTPUT);
  digitalWrite(shutdownPin, LOW);


  // RESET --- ALLE DREI KNÖPFE BEIM STARTEN GEDRÜCKT HALTEN -> alle EINSTELLUNGEN werden gelöscht
  if (digitalRead(buttonPause) == LOW && digitalRead(buttonUp) == LOW &&
      digitalRead(buttonDown) == LOW) {
    #ifdef DEBUG
    Serial.println(F("Reset -> EEPROM wird gelöscht"));
    #endif
    for (int i = 0; i < EEPROM.length(); i++) {
      EEPROM.update(i, 0);
    }
    loadSettingsFromFlash();
  }
  digitalWrite(SpeakerOnPin, HIGH);
  
  // Start Shortcut "at Startup" - e.g. Welcome Sound
  playShortCut(3);

}

Das läuft soweit.
Der 2sec Delay spart natürlich die meiste Zeit ein.
Wie viel ich an den seriellen Ausgaben spare hab ich nicht genauer gemessen.

Ich habe in dem Zuge auch alle seriellen Ausgaben im Programm mit dem #ifdef DEBUG versehen.
Das spart übrigends 27% des Programmspeichers ein. Vielleicht auch das ein oder andere mA an Energie.

Edit: ich hatte vergessen meine eigenen Ergänzungen heraus zu nehmen…das ist heirmit getan.

Habe sporadisch dasselbe Problem:
Es dauert um die 8 Sekunden, bis der TonUINO loslegt. Zusätzlich funktionieren Karten mit Zufallsmodus-Einstellung dann nicht. Konsole sagt auch Com Error 255 und der DFPlayer gibt 0 Dateien im Verzeichnis zurück.
Sporadisch, weil: Nach dem neuformatieren der SD-Karte ist das Problem weg, kommt aber nach 2-3 Tagen wieder. In der Zeit blieb die SD-Karte im TonUINO…können also nicht irgendwoher unerwünsche Dateien hinzugekommen sein. An den Lötstellen kann’s ja eigentlich auch nicht liegen, wenn’s zwischendurch auch mal funktioniert. Frage mich nur, wieso der Player nach 2-3 Tagen anfängt, rumzumucken.

Habe eine kingston-Speicherkarte (Class 4, 16GB). Hatte es auch mal mit einer Transcend (Class 10, 16GB) versucht, bei der hatte ich die Probleme aber auch nach dem formatieren.

Also scheint der Player ziemlich zickig zu sein.
Allerdings kommt ein Austausch bei mir leider nicht mehr in Frage…so wie das ganze zusammengelötet ist, bekomme ich das niemals wieder auseinander :thinking:

Noch etwas zu den Resourcen-Daten auf dem Mac (lösche ich auch immer komplett von der SD-Karte): ja, dot_clean löscht nur die Resourcen-Dateien in den Unterverzeichnissen. Um auch die unsichtbaren Ordner direkt im SD-Stammverzeichnis wegzubekommen, geht wie folgt vor:

  • Terminal öffnen
  • cd[leerzeichen] eintippen, die SD-Karte auf das Fenster ziehen und mit Return bestätigen. Ihr solltet nun im Terminal im SD-Verzeichnis sein.
  • ls -la eingeben. Ihr seht nun wirklich alles, was im Verzeichnis ist. Auch Dateien/Verzeichnisse mit einem Punkt am Anfang des Namens (=> Im Finder versteckt)
  • Jene könnt ihr mit rm -r [name] löschen. -r, weil es sich hierbei eigentlich um Verzeichnisse handeln sollte. Ihr braucht hierbei den Namen nicht komplett einzutippen. Der Punkt, die ersten Buchstaben und dann auf die Tab-Taste drücken

Bei wem tauchen denn die Probleme unter Windows auf? Sieht mehr nach einem Mac und Linux Problem aus. Und als Speicherkarte hatte ich mit meinen SanDisk auch nie Probleme.

Ich habe hier verschiedene DFplayer Platinen, welche ich eigentlich durchgetestet habe um zu schauen ob hier das Brummen bzw. der Einschaltton stärker oder weniger ausgeprägt ist.

Auch hier war ein Modul dabei, welches deutlich länger zum reagieren gebraucht hat. Es wurde dabei immer die gleiche SD-Karte verwendet.

Ich bin mir dabei nicht unbedingt sicher ob die Platine mal zuviel Wärme beim Löten gespürt hat.

Wäre zumindest bei euch mal interessant ob ihr einfach mal tauschen könntet.

Moin,

ich habe heute das bei AZ-Delivery bestellte Set erhalten und sogleich auf einem Breadboard zusammengesteckt. Ich musste leider feststellen, dass ich von dem „8 Sekunden“-Delay betroffen bin und habe bei der Recherche diesen Thread gefunden.

Auf dem DFplayer Mini ist der Chip „YX5200-24SS“ verbaut.

Im Debugger steht folgender Text:

Card UID: E3 FC 19 06
PICC type: MIFARE 1KB
Authenticating Classic using key A...
Reading data from block 4 ...
Data on Card :
13 37 B3 47 02 01 02 1C 8F 00 00 00 00 00 00 00

1
1
== playFolder()
=== disablestandby()

Com Error 129
0 Dateien in Ordner 1
Album Modus -> kompletten Ordner wiedergeben

Habe daraufhin im Sketch geschaut welche Funktion den „Com Error 129“ verursacht.

void playFolder() {
  Serial.println(F("== playFolder()")) ;
  disablestandbyTimer();
  knownCard = true;
  _lastTrackFinished = 0;
  numTracksInFolder = mp3.getFolderTrackCount(myFolder->folder);
  firstTrack = 1;
  Serial.print(numTracksInFolder);
  Serial.print(F(" Dateien in Ordner "));
  Serial.println(myFolder->folder);
  ...

Ursache ist die Funktion „getFolderTrackCount()“.

In der Lib die Funktion gesucht:

uint16_t getFolderTrackCount(uint16_t folder)
{
    drainResponses();
    sendPacket(0x4e, folder);
    return listenForReply(0x4e);
}

An den YX5200-24SS wird das Command „0x4E“ geschickt und vermutlich nach 8 Sekunden mit einem negative response quittiert.

Dann einen Blick in das Datasheet geworfen: Link - Datasheet YX5200-24SS English

Zu meiner Verwunderung musste ich feststellen, dass das Command 0x4E für diesen Chip laut Datasheet nicht existiert.

Könnte einer von euch, der ebenfalls über einen YX5200-24SS verfügt einmal bitte folgendes Sketch testen und eine Rückmeldung geben, ob der gleiche Fehler auftritt?
https://www.file-upload.net/download-13995397/PlayMp3.ino.html
Es handelt sich dabei um ein modifiziertes Sketch aus der Lib.
Zurückgegeben werden soll - falls es denn funktioniert - die Anzahl der Dateien in Ordner „01“.

Der Chip ist nicht per se das Problem. Error 129 ist RX timeout. Die Library wartet 10 Sekunden (nicht 8) auf ne Antwort vom Player und bricht dann ab. Check mal ob dein Player dieses Problem hat:

Ansonsten könnte auch das Kabel ein Problem sein. Breadboard kann problematisch sein.

Hi, danke für die schnelle Rückmeldung. Verlötung schaue ich mir auf jeden Fall noch einmal an. Aber sollte das dann nich eher ein generelles Problem sein? Denn abspielen tut er - abgesehen von dem o.g. Problem - anstandslos.

Was meinst du mit generelles Problem? Guck dir mal Beitrag 10 hier im Thread an. Achte auf den 3. Pin von oben auf der linken Seite. Dort sieht man auch deutlich das der Pin Kontakt zum Schild hat und damit zu GND. Es war also dort auch sehr wahrscheinlich das gleiche Problem wie in der FAQ beschrieben. Nur ist halt der FAQ Eintrag erst später gemacht worden…

Zu der Frage des Kommandos: Ich habe alle drei wichtigen Chip Typen hier (YX, JL und MH-ET LIVE) und alle 3 können das. Sollte also auch bei dir eigentlich nicht das Problem sein.

Es ist nachvollziehbar, dass keine Kommunikation zwischen Nano und DFplayer stattfinden kann, wenn TX durch eine fehlerhafte Lötstelle dauerhaft auf GND gezogen wird.

Bei mir ist es jedoch der Fall, dass der DFplayer grundsätzlich Musik abspielt - jedoch mit dem Command getFolderTrackCount (0x4E) und ebenso getVolume (0x43) und getGlobalTrackCount (0x48) wie ich feststellen musste ein Problem hat.

Mit generelles Problem meine ich also entweder es findet eine Kommunikation statt, oder eben nicht, aber nichts dazwischen.

Wenn du sagst, dass das Command 0x4E bei deinem YX funktioniert liegt die Vermutung nahe, dass das Command in dem oben verlinkten Datasheet einfach nicht dokumentiert ist.

In eine Richtung halt doch. Das Kommando „spiel ab“ kommt an und es wird auch gespielt. Die andere Richtung ist halt das Problem. Das schließt sich nich aus.

Yo, das verlinkte Datasheet ist nicht das beste. Hast du denn jetzt die Lötstelle kontrolliert und mit nem Multimeter durchgeklingelt?

Sorry, denkfehler. TX ist na klar der Rückkanal zum Nano.
Habe die Lötstellen kontrolliert und durchgemessen. Das passt soweit alles.

Tja dann wird’s dünne. Wenn die Verbindung (Jumper Kabel, Breadboard etc.) auch ok ist bleibt nur Defekt am Player selbst oder SD Karte (Format, alle Dateien richtig usw usf). Sonst wüsste ich auch nicht.

Ich habe heute freundlicher Weise einen neuen DFplayer mini zugesendet bekommen, nachdem ich AZ-Delivery das Problem geschildert habe. Modul eingesetzt und es lief bei unverändertem Aufbau auf Anhieb und ohne 8 Sekunden Delay. Demnach muss das erste Modul einen weg gehabt haben.

Hallo, Ich habe mich extra angemeldet, um meine Lösung hier zu Schreiben.

Ich hatte auch das Problem das der Player 8 Sek verzögert hat inkl. Error 129.

Ich habe die defekte Lötstelle sauber vom SD Kartenmodul getrennt. Nun spielt er die Ordner sofort ab. Perfekte Lösungsansätze hier

Mfg Jan

In der #hardware FAQ ist diese Problem auch erwähnt.