You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Unexpected responses by various functions/queries #8
first off: Many thanks for your great work with this project! I am currently trying to set up my DFPlayer Mini using your library and test files and hope that you could help me as I am slowly loosing my mind with this module.
Until now, I attempted to hard code the UART communication in the main.py on the ESP32, but thanks to a friendly Redditor stumbled upon your library. The issue I have now is that I only receive very weird responses from the module.
I also tried other values for vol, also without avail.
play(1,1)
For play(), I so for only got a -1, which to my understanding implies a communication error. Given that the other communications seem to work just fine, I am utterly confused what could be the issue at hand.
I am attaching the scripts I am running on my ESP32 for reference.
Hey there, cool project you are working on!
There where a few things that confused me with your issue.
For example the play() function does not have a return value...
First thing I always recommend is formatting the SD card and then copy the sample files provided here, avoiding any unnecessary file operations on the card.
Next check if the play() function works proving you can successfully send commands to the module.
Next check if any of the functions with a return value works proving you can successfully receive data from the module.
In your case however the output of the get_files_in_folder() has me thinking there is some sort of cross talk (connection) between the RX and TX lines. The message send to the module has the folder number as 6th byte. In the returning answer the 6th byte is supposed to be the number of files in that folder. So I think the ESP32 might get kind of an echo of it's own output. So check our wiring and if you can't find anything maybe post a picture and a diagram of your circuit.
Greetings from south Germany.
Hi @redoxcode, thanks for the quick reply and greeting from München!
As for your comments:
You are (obviously) right that play() does not have a return value, that's my bad for not being clear. What I am doing is running df.is_playing() just after boot up and then again after play(1,1). Both times, is_playing() returns -1 (see terminal snippet blow). The play() function itself does not seem to do anything for me, at least I neither receive an error nor any other response.
For additional reference, please see this snippet from my Terminal when running the code I shared above:
Starte Musiksystem...
Gefundene Dateien in Ordner 1: 1
Gefundene Dateien in Ordner 2: 2
Gefundene Dateien in Ordner 3: 3
Gefundene Dateien in Ordner 4: 4
Aktuelle Lautstärkeeinstellung: 0
Bereit – halte RFID-Tag vor.
UID erkannt: 429B9504
Spiele Titel 1
Playback erfolgreich gestartet: -1
Regarding the SD, I did exactly what you are recommending (fresh format and then added the sample files as is from a git clone). What I realized when opening the mp3s in the folders on Windows (Media Player and VLC), that the file had a duration of 0:00 and could not be analyzed for its codec (which I understand is crucial for the DFPlayer Mini). Might that be the issue here?
I do see your theory of cross talk / echoing, especially considering that when I tried hard coding the UART communication, all I got was an echo of my queries/commands in the terminal, as well. However, I double-checked the wiring of RX/TX and can't see any issues. Both wires are directly soldered to Pins 16/17 and plugged into the DFPlayer (Dupont connector) without any intersection between the both of them... I am attaching a picture of the whole circuit here, which I hope is not too confusing (RX/TX are orange and yellow; this is my first more complex project, so please bear with me). Please note that the DFPlayer is attached to my 3D printed frame upside down, so the lower left pin on the picture is indeed VCC. Also: I do get a very brief red LED flash on the DFPlayer as well as a short "bop" from the speaker at boot up, which does not come on afterwards, though.
Maybe it's me, but can you double check you didn't mix up RX and TX lines.
From your code it looks like TX of the ESP is on pin 16 and has the color orange.
TX of the ESP should connect to RX on the DFPlayer.
RX on the DFPlayer is the pin next to VCC and it looks like that corresponds to the yellow wire in your pic.
So I think you connected RX->RX and TX->TX while it should be RX->TX and TX->RX.
But maybe I see things wrong.
Please note that the test files are very short. Just the words "one", "two", "Three", ...
So maybe that's why they show with a duration of 0:00. They should play with vlc.
Thanks for your time and help! I just double and triple checked the wiring: If I switch the connections of RX and TX, communication with the DFPlayer stops completely, the script just freezes - same applies if I switch the Pin-numbers in the code...I hope you can see why I am getting increasingly desperate here...
On another note: I bought this player off BerryBase here - is that a potential issue? The site refers to the DFRobot documentation, so I cannot really see how, but just want to make sure.
I don't see why that should be an issue. I got mine from a random company in china.
You need to systematically hunt that bug down. Maybe you need to disassemble your project again and try the DFPlayer on a different micro controller. Also check the soldering of the pins on the DFPlayer board.
I don't think there is an issue with the code.
Let me know when you find the issue!
I agree - this is why I tried around a little bit, ultimately switching to this library here. Don't ask me why but this one seems to work, I can finally hear "One" "One" "One" sounding from my build! Whilst my curiosity kills me to find out what the issue with your library was, I am just happy to get it working for now. Many thanks for your support!
Glad you got something working!
One difference for sure is, that the library you linked doesn't contain any functions where information is transmitted from the PFPlayer back to the ESP. So only the TX line is ever used.
However I also see this line self.cmd(0x3F) # send initialization parametres that is missing in my library.
I never needed that, but maybe there are some variants that need it? Actually it is in the documentation.
I will do some testing and maybe add that.
Meanwhile something like this might work:
importtimefromdfplayerimportDFPlayerdf=DFPlayer(uart_id=1,tx_pin_id=4,rx_pin_id=5)
#wait some time till the DFPlayer is readytime.sleep(0.2)
df.send_cmd(0x3f) #the missing init commandtime.sleep(0.2)
#do stuff
Okay so I tried adding this and it somehow sent my ESP32 into an eternal loop of rebooting - had to reflash the whole thing. Very strange all in all, I can't see a single reason why my build reacts this weirdly. In any case, I don't really need any data transmitted from the DFPlayer (although it would've been nice to have). I am curious to see whether you can get to the ground of things! Best of luck!
Activity
redoxcode commentedon Nov 2, 2025
Hey there, cool project you are working on!
There where a few things that confused me with your issue.
For example the play() function does not have a return value...
First thing I always recommend is formatting the SD card and then copy the sample files provided here, avoiding any unnecessary file operations on the card.
Next check if the play() function works proving you can successfully send commands to the module.
Next check if any of the functions with a return value works proving you can successfully receive data from the module.
In your case however the output of the get_files_in_folder() has me thinking there is some sort of cross talk (connection) between the RX and TX lines. The message send to the module has the folder number as 6th byte. In the returning answer the 6th byte is supposed to be the number of files in that folder. So I think the ESP32 might get kind of an echo of it's own output. So check our wiring and if you can't find anything maybe post a picture and a diagram of your circuit.
Greetings from south Germany.
lukoukou commentedon Nov 2, 2025
Hi @redoxcode, thanks for the quick reply and greeting from München!
As for your comments:
For additional reference, please see this snippet from my Terminal when running the code I shared above:
Regarding the SD, I did exactly what you are recommending (fresh format and then added the sample files as is from a git clone). What I realized when opening the mp3s in the folders on Windows (Media Player and VLC), that the file had a duration of 0:00 and could not be analyzed for its codec (which I understand is crucial for the DFPlayer Mini). Might that be the issue here?
I do see your theory of cross talk / echoing, especially considering that when I tried hard coding the UART communication, all I got was an echo of my queries/commands in the terminal, as well. However, I double-checked the wiring of RX/TX and can't see any issues. Both wires are directly soldered to Pins 16/17 and plugged into the DFPlayer (Dupont connector) without any intersection between the both of them... I am attaching a picture of the whole circuit here, which I hope is not too confusing (RX/TX are orange and yellow; this is my first more complex project, so please bear with me). Please note that the DFPlayer is attached to my 3D printed frame upside down, so the lower left pin on the picture is indeed VCC. Also: I do get a very brief red LED flash on the DFPlayer as well as a short "bop" from the speaker at boot up, which does not come on afterwards, though.
redoxcode commentedon Nov 2, 2025
Maybe it's me, but can you double check you didn't mix up RX and TX lines.
From your code it looks like TX of the ESP is on pin 16 and has the color orange.
TX of the ESP should connect to RX on the DFPlayer.
RX on the DFPlayer is the pin next to VCC and it looks like that corresponds to the yellow wire in your pic.
So I think you connected RX->RX and TX->TX while it should be RX->TX and TX->RX.
But maybe I see things wrong.
redoxcode commentedon Nov 2, 2025
Please note that the test files are very short. Just the words "one", "two", "Three", ...
So maybe that's why they show with a duration of 0:00. They should play with vlc.
lukoukou commentedon Nov 2, 2025
Thanks for your time and help! I just double and triple checked the wiring: If I switch the connections of RX and TX, communication with the DFPlayer stops completely, the script just freezes - same applies if I switch the Pin-numbers in the code...I hope you can see why I am getting increasingly desperate here...
lukoukou commentedon Nov 2, 2025
On another note: I bought this player off BerryBase here - is that a potential issue? The site refers to the DFRobot documentation, so I cannot really see how, but just want to make sure.
redoxcode commentedon Nov 2, 2025
I don't see why that should be an issue. I got mine from a random company in china.
You need to systematically hunt that bug down. Maybe you need to disassemble your project again and try the DFPlayer on a different micro controller. Also check the soldering of the pins on the DFPlayer board.
I don't think there is an issue with the code.
Let me know when you find the issue!
lukoukou commentedon Nov 2, 2025
I agree - this is why I tried around a little bit, ultimately switching to this library here. Don't ask me why but this one seems to work, I can finally hear "One" "One" "One" sounding from my build! Whilst my curiosity kills me to find out what the issue with your library was, I am just happy to get it working for now. Many thanks for your support!
redoxcode commentedon Nov 2, 2025
Glad you got something working!
One difference for sure is, that the library you linked doesn't contain any functions where information is transmitted from the PFPlayer back to the ESP. So only the TX line is ever used.
However I also see this line
self.cmd(0x3F) # send initialization parametresthat is missing in my library.I never needed that, but maybe there are some variants that need it? Actually it is in the documentation.
I will do some testing and maybe add that.
Meanwhile something like this might work:
lukoukou commentedon Nov 2, 2025
Okay so I tried adding this and it somehow sent my ESP32 into an eternal loop of rebooting - had to reflash the whole thing. Very strange all in all, I can't see a single reason why my build reacts this weirdly. In any case, I don't really need any data transmitted from the DFPlayer (although it would've been nice to have). I am curious to see whether you can get to the ground of things! Best of luck!