DFPlayer verschiedene Versionen

In der DEV wird damit bestätigt, dass die Modifierkarte erkannt wurde. Wenn man dann ein längeres Hörspiel vorher pausiert hat, wäre der Fortschritt ohne Advert dann weg. Wobei die Lösung mit dem Starten und Pausieren sicher nicht optimal ist. Bei mir funktioniert das mp3.pause eigentlich nie.
Du nutzt ja um die Sperre zu bestätigen die LED, das wäre zumindest für alle die ohnehin eine einbauen sicherlich die bessere Alternative.

Ja,das hast du richtig erkannt. Die verschiedenen Chips der Df-Player reagieren sehr unterschiedlich darauf. Deshalb habe ich das auch so mit dem synchrohalten des mp3 und advertordner .

Hallo, ich habe ähnliche Probleme mit meinem MH2024-16SS.

In der SPEC habe ich gelesen, dass die Checksum optional ist.
Testweise habe ich die Checksum-Berechnung mal in der Library entfernt DFPlayer-noChecksum.

Bingo!

Mit diesen Patch funktioniert der Chip schon sehr gut! Der Arduino liest sogar die korrekte Anzahl an MP3s in einem Folder aus.
Das Einzige, was mir beim Testen aufgefallen ist, dass der Arduino immer noch Probleme hat, zu erkennen, wenn ein Lied vorbei ist.

Testet den Patch gerne mal aus, bevor ihr die Chips wegwerft.

PS: Ich nutze die Tonuino-Version von Stephan Eisfeld.

2 „Gefällt mir“

Das Problem mit dem OnPlayFinished ist mir auch schon aufgefallen.
Der alte Chip „sendet“ am Ende eines Tracks ein Signal in der Form 7E FF 6 3D 0 0 ...... das Signal vom neuen sieht bei mir in dieser Art und Weise aus 7E FF 6 4C 0 0 ......
Das müsste eigentlich das gleiche sein, wie die Antwort auf die Abfrage wieviele Tracks im derzeitigen Ordner sind.
Ein einfaches Ändern des Wertes für OnPlayFinished von 3D in 4C in der Library hat für mich aber noch keinen Erfolg gebracht. Ich suche noch…

Edit: es musste 3D heißen, 3F war falsch

1 „Gefällt mir“

Und weiter geht’s in der DFPlayer Chip Forschungsgruppe … :slight_smile:

Der Tipp mit der Checksumme hat wirklich viel geholfen. Danke @bw87.

Jetzt klappt zumindest das normale Abspielen (inkl. FinishEvent) und Anzahl der Dateien im Ordner auslesen. :sunglasses:

@kobayashi_maru: Um überhaupt zur Abarbeitung der Antwort (und somit der Erzeugung des Finish-Events) zu kommen (d.h. readPacket = true), musste ich noch die Endcode-Abfrage ändern, um den PacketHeader Fehler (0x83, dez. 131) zu umgehen. Scheinbar ist der Endcode bei empfangenen Daten nicht 0xEF (wie beim Senden) sondern 0xFE !
Daher habe ich folgende Zeile angepasst: in[DfMp3_Packet_EndCode] != 0xfe *

  • *Edit: Womöglich werden hier die beiden Checksummen Bytes mit zurückgesendet!?
    Also das 0xFE ist evt. das 1. Byte der Checksumme und nicht der Endcode!?

Danach habe ich, wie du schon geschrieben hast, noch in der Eventabfrage unter case 0x3d: noch ein case 0x4c: hinzugefügt.

Was bei mir noch nicht funktioniert ist das Abwarten, bis ein Titel zu Ende gespielt ist. :frowning:
Irgendwas in der mp3.loop() ist da noch nicht koscher bzw. deaktiviert sich der busy Pin nicht. Der bleibt in der Warteschleife hängen.

Was ich beobachtet habe:

  • Der Busy Pin bleibt nach dem Ende eines Titels aktiv (leuchtet)
    • Sowohl bei Advertisement, MP3 als auch normalen Titel
  • Advertisement und MP3 liefern kein FinishEvent

Somit bekomme ich nicht mit, ob Advertisement oder MP3 Track fertig sind.

Ist das nicht aber Kommando 0x4E (dezimal 78) ?

Ja, da habe ich mich vertan, sry. Ich hatte im Code von @bw87 nicht gesehen, dass das empfangene Byte-Array nicht verkleinert war.
Im Grunde reicht also eine neue Variable _ignoreCheckSum um die Verarbeitung umzuschalten:

	if (_ignoreCheckSum)
	{
		out[DfMp3_Packet_HiByteCheckSum] = 0xEF;
		out[DfMp3_Packet_LowByteCheckSum] = 00;
		out[DfMp3_Packet_EndCode] = 00;
	}
	else
	{
		setChecksum(out);
	}

statt

	setChecksum(out);

sowie die bereits genannte Anpassung für das FinishEvent

	case 0x3d: // micro sd
	case 0x4c:

Du hast recht, da hab ich mich vertan.
das 4C müsste die Antwort auf die Anfrage nach der Nummer des derzeit abgespielten Track im aktuellen Ordner auf der SD sein.

Das hat bei mir leider keinen Erfolg gebracht, das OnPlayFinished wird weiterhin nicht erkannt/verarbeitet.

Da konnte ich allerdings bei meinem Player am Ende vom Advertisement eine Ausgabe in der Form 7E FF 6 4E 0 0 ...... abgreifen.

Ich habe es bei MP3 Track hinbekommen. Ich musste nur ein delay nach dem initialen Starten des DFPlayers hinzufügen. Jetzt werden für MP3 Tracks auch FinishEvents erzeugt.

Nur Advertisement kommen keine, aber das lässt sich verschmerzen … ich habe bei den meisten Aufrufen das Warten auf das Ende entfernt.

Abgesehen davon läuft der Chip MH2024-16SS jetzt problemlos. Schön das sich der Elektroschrott vermeiden ließ.

Bei mir läuft der Chip auch gut seit gestern Abend. Tolle Zusammenarbeit hier! :slight_smile: Für mich ist der Chip mit den Änderungen so zu 100% nutzbar:

  1. Checksum müssen raus aus der Library und
  2. es muss der zusätzliche Case beim FinishEvent eingebaut werden.

Was ich noch beobachtet habe ist, dass die ersten Abfragen von der SD-Karte immer timeouts liefern:

SERIAL MONITOR:

17:37:48.685 → init mp3
17:37:51.652 → start 1
17:37:51.652 → max 25
17:37:51.652 → menu 1
17:37:51.685 → eq normal
17:37:51.719 → files rx timeout error

CODE:

Serial.println(F(„init mp3“));
mp3.begin();
delay(2000);
Serial.print(F(" start „));
Serial.println(preference.mp3StartVolume);
mp3.setVolume(playback.mp3CurrentVolume = preference.mp3StartVolume);
Serial.print(F(“ max „));
Serial.println(preference.mp3MaxVolume);
Serial.print(F(“ menu „));
Serial.println(preference.mp3MenuVolume);
Serial.print(F(“ eq „));
Serial.println(mp3EqualizerName[preference.mp3Equalizer]);
mp3.setEq((DfMp3_Eq)(preference.mp3Equalizer - 1));
Serial.print(F(“ files "));
Serial.println(mp3.getTotalTrackCount(DfMp3_PlaySource_Sd));
pinMode(mp3BusyPin, INPUT);

Wenn ich

mp3.getTotalTrackCount()

direkt ein 2. Mal dahinter aufrufe, kriege ich eine 0 als Antwort.
Erst beim 3. Aufruf hintereinander bekomme ich wiederholt den richtigen Wert.

Ein längeres delay nach dem mp3.begin() hat auch nicht geholfen.

EDIT: Problem gelöst. Es liegt an den mp3.setVolume und mp3.setEq Aufrufen. Der Chip braucht anscheinend etwas Bearbeitungszeit. Mit einem delay(1000) jeweils dahinter, arbeitet alles zuverlässig.

Ja, das habe ich auch. Allerdings noch mit einem mp3.start() dazwischen, da ich anschließend einen Start-MP3-Sound abspiele.
Sinn gemäß

setVolume(value);
setEqualizer(value);
start();
// give DFPlayer some more time to init (otherwise finish event of MP3 track is not generated)
delay(1000);
// play startup sound
playMP3AndWait(261);

Was ich noch festgestellt habe:

  • Wenn ich nach meiner Startfolge (s.o.) getFolderTrackCount(folder) sende, wird der Busy-Pin/Zustand wieder inaktiv. Ohne dieses Kommando bleibt der Busy-Pin/Zustand aktiv!

Ich hatte versucht, dass in/vor die Warteschleife zu integrieren, um Advertisement Titel abwarten zu können. Aber das Senden führt in diesen Fällen zu einem rx timeout 0x81 (129) Fehler. Schade.

So, auch bei mir läuft der 16SS jetzt mit der DEV!
Hatte den „Fehler 30“. Das ist der, der 30cm vor dem Bildschirm entsteht :rofl:
In der DF library musste ich noch nicht einmal die checksum rausnehmen. Bei mir hat der zusätzliche case ausgereicht.
Im sketch habe ich jeweils ein delay(100); unter mp3.setVolume(volume); und mp3.setEq(mySettings.eq - 1);eingefügt.
Da er bei mir die erste Ansage zum Adminmenü verschluckt hatte, habe ich noch ein delay(100); hinter mp3.pause(); in der void adminMenu(bool fromCard = false) { ergänzt.
Zu guter Letzt hat ein delay(10); ja 10, am Ende der void waitForTrackToFinish() { , also vor der schließenden }, die Fehlermeldungen nach mp3.playMp3FolderTrack beseitigt.

hallo
gibt es dazu eine Anleitung für TonUino Neulinge?
ich habe nun auch den MH2024K-16SS Chip bekommen :confused:

ich habe die TonUINO Version 2.1 und 5 knöpfe verwendet.
sobald ein Lied fertig ist bleibt die Wiedergabe hängen und es muss manuell der nächste Song gestartet werden.

was muss ich am Code anpassen damit es funktioniert und in welcher Zeile ca?

gibt es die Möglichkeit die Version des DFPlayer in den Anfang zu schreiben wie bei „#define FIVEBUTTONS“ damit auch Anfänger leicht den code anpassen können, oder muss dafür dann ein komplett anderer code verwendet werden?

Leider kann man scheinbar nicht einfach sagen „der neue Chip“. Es sind wohl, trotz gleicher Bezeichnung, schon mehrere unterschiedliche (Software-) Versionen unterwegs, so dass es im Moment die Musterlösung nicht zu geben scheint. Wie oben im Faden geschrieben, haben ja bei mehreren unterschiedliche Wege zum Ziel geführt.
Teil der Lösung war aber immer auch eine Veränderung an der DF-Player lib. Diese Datei siehst du in der Arduino IDE leider nicht einfach so, wenn du die Tonuino.ino öffnest.
Die betreffende Datei „DFMiniMp3.h“ muss separat geändert werden. Mindestens muss dort nach case 0x3d: // micro sd gesucht werden und das 3d durch 4c ersetzt werden.

3 „Gefällt mir“

Moin!
Bist du mit dem DF-Player schon weiter gekommen?
Ich versuche mal, dir hier einen Weg aufzuzeigen.
Hier kannst du eine schon leicht für einen 16SS DF-Player angepasste Version der DF-Player lib herunterladen.
Auf den Link mit rechts klicken und „speichern unter“ auswählen.
Als Speicherort nimmst du den Ordner in dem du die Tonuino.ino gespeichert hast.
In der Arduino IDE öffnest du dann deine Tonuino.ino und änderst in der ersten Zeile #include <DFMiniMp3.h> in #include "DFMiniMp3.h" das dann so erstmal abspeichern und die IDE schließen.
Wenn du jetzt die Tonuino.ino wieder mit der IDE öffnest, solltest du einen zweiten Reiter neben dem Tonuino sketch sehen. In dem zweiten Reiter kannst du nun die DF-Player lib bearbeiten. Dort in Zeile 523 müsstest du den von mir angesprochenen case finden, Hier dann, wie geschrieben, die 3d in 4c ändern.
Im Reiter mit der Tonuino.ino fügst du dann unter Zeile 757 mp3.setVolume(volume); und 758 mp3.setEq(mySettings.eq - 1); jeweils ein delay(1000); ein.
Dann speichern, auf den Tonuino laden und testen.
Vielleicht bringt das für dich schon den Erfolg.

4 „Gefällt mir“

hi
danke für die Tipps!
jetzt klappt es :smiley:
nur die box knackt manchmal wenn ich was mache und danach ist die Lautstärke viel lauter und lässt sich nicht mehr runter regeln.
woran das liegt konnte ich noch nicht feststellen oder reproduzieren

ich habe wie weiter oben beschrieben 100 benutzt da mir 1sec etwas lange vor kommt

1 „Gefällt mir“

Ich habe die 1000 von @bw87 vorgeschlagen, da ich vermutet habe, das dein Player die gleiche Software-Version haben könnte wie seiner.
Bei meiner Version, fallen die Änderungen ja im ganzen etwas anders aus.
Du hast recht, es ist recht lang, aber vielleicht sind die von dir gewählten 100 einfach zu kurz.
Versuch einfach mal die 1000 und sieh was passiert.
Dann kannst du dich ja immer noch nach unten tasten?!

Hallo, ich habe mal beide Fixes (checksum, fehlender case) in einen eigenen branch zusammen veröffentlicht, damit es für Neuankömmlinge einfacher wird, diese einzubauen:

2 „Gefällt mir“

Hallo,

Haben sie versucht, das feedback zu aktivieren, um diese Verzögerungen nicht hinzuzufügen?

Ersetzen sie in sendPacket die 00 nach dem befehl durch 01. Dann am ende der funktion if (command != 0x0c) listenForReply(0x41);

Ich hoffe, Google Translate ist nicht zu schlecht, um ins Deutsche zu übersetzen :slight_smile:

Tatsächlich löst es nicht alle Timing-Probleme und die Art und Weise, wie die Bibliothek implementiert ist, die Pakete können nicht in der richtigen Reihenfolge ankommen und Fehler verursachen (es ist ein Durcheinander, wenn die SD-Karte während des Schreibens und der Bestätigung erkannt wird).

Hallo,
Mit Feedback und ohne Checksum funktioniert der Chip MH2024-16SS relativ gut.
Allerdings funktioniert das Abspielen aus dem „mp3“-Verzeichnis nicht richtig (Kommando 0x12).
Hier wird immer nur die 42. Datei abgespielt - egal welche Datei angegeben wird .
Das gleiche Verhalten ergibt sich auch mit dem Kommando 0x03 (globale Tracks abspielen).

Ich habe auch noch Probleme mit dem Busy-Pin.
Dieser wird beim Abspielen von High auf Low gesetzt - nach dem Abspielen bleibt dieser jedoch auf Low… erst nach einem Reset (0x0c) oder einer Pause (0x0e) wechselt der Pin wieder auf High.

Bei diesem Chip kann man allerdings auch das Verzeichnis 00 verwenden.