DFPlayerMini cheat sheet

Recently I had the chance to incorporate the DFPlayer Mini into a project. It’s a super cute MP3 player that is great for Arduino powered projects. The only problem being with the documentation. It is a little spotty and I had to work pretty hard to get around a few issues. So here is a little cheat sheet to help you along:


This is a companion discussion topic for the original entry at http://reprage.com/post/dfplayer-mini-cheat-sheet

Hi there. You connected the Speakers really to IO_1 and IO_2 ?? I think the schematic you posted is incorrect, right? the speakers had to be connected to SPK1 and SPK2 ? Please let me know. Thx

Yup, you are correct. I have made a mistake in my schematic - the speakers should be connected to SPK1 and SPK2 (the matching pins on the opposite side of the board). Thanks for letting me know. EDIT: I will get this fixed up, schematic updated.

So your wiring diagram shows ground being connected to each of the speakers. With a similar setup to your diagram, I can’t seem to get my arduino pro mini to start when powering from RAW / GND. It’s like there is a short and it turns off immediately. Now it does work if I power from the FTDI interface (not sure why this is the case).

Haven’t tried this yet, but when I look at other wiring diagrams for example from DFRobot, the SPK1 is connected to speaker positive and SPK2 is connected to speaker negative … no ground wires are connected to the speaker(s). So I am assuming this is an issue and will switch to have SPK1 to positive of both speakers and SPK2 to negative of both speakers to see if that corrects the issue. Wondering if you have seen anything similar and/or are you getting stereo or some other benefit from the wiring the ground to the speakers?

Yeah, I started out using DAC_L and DAC_R for stereo output (in my case I was driving headphones headphones). But the line noise was terrible. Wiring SPK1 and SPK2 like in the schematic above allowed me to keep stereo output and get way less line noise. (The other examples you have seen will only be mono).

I haven’t experienced your shorting issue, my input supply was 5 volts and I drew power directly from a 5V DC-DC converter for both the Pro Micro and the DFPlayer Mini (along with the other components I was using).

Do not connect the speakers in this way.

I tested it with two 4 Ohm speakers.

My DFPlayer has 3.3 volts and then draws more than 400 mA and is too hot in no time. (400 mA was the set current limitation of the power supply)

It is possible that not all modules are the same, or that it wil works with high-ohmic headphones, but if you want to destroy your module, go ahead you have been warned.

Mvg Jan.

1 Like

The DFPlayer uses a 8002 8-pin power amplifier to drive the speaker terminals. It is a mono amplifier and is designed to connect the speaker terminals to the two SPK terminals only. Although the speaker will appear to operate when one of the terminals is connected to GND, the problem is that the SPK output terminals are both biased at approc Vcc/2. So if the DFPlayer is powered at 5vdc and an 8 ohm speaker is connected from one of the SPK terminals to GND then the speaker is constantly consuming 0.8 watts of dc power. It’s a waste of power and could possibly overheat the speaker’s voicecoil and cause permanent damage.

1 Like

My use case was with high-ohmic headphones, so it sounds like I got super lucky. Thanks to you and @Bob_in_NJ for giving it a try and sharing your results. Hopefully it saves others some pain.

Hello, Thanks for the good tips. Can you explain what your playTrack() function does, because all it does for me is play 200ms of the track in an endless loop. Thanks.

It just plays the supplied track number once. I found that:

MP3Player.play(track);

Wouldn’t always set the correct track number returned by:

int file = MP3Player.readCurrentFileNumber();

The loop at the end of the playTrack method ensures that the call to play was correctly setting the track number stored within MP3Player. You could try removing that loop, but I found that perhaps about 4% of the time, MP3Player would lock up and not play the correct track without it.

From memory, I think the MP3Player library from DFRobot had some methods you could call to set looping functionality. Double check that is all set to false as well?

Ok, thanks, I could not really get it to work.

The problem I’m having is that the DFPlayer is completely ignoring the file name indexing, and ONLY uses the file creation timestamp to index the tracks. Doesn’t matter what I name them, Track 1 always is the first track copied to the SD card, Track 2 is the second, and so on… I spent TWO DAYS trying to figure out why the wrong tracks were playing until I saw your note about the timestamp, and that works. I’ve tried all the file name conventions mentioned across the web: One, two, and three leading zeros; putting the files in an /mp3 subdirectory, in root, adding extra characters after the number (i.e. 0001_track_1.mp3), only having a file number (i.e. 0001.mp3), etc. Nothing works! ONLY the file creation timestamp determines the index/track order. Any ideas?

Thanks.

I found the answer here: [http://markus-wobisch.blogspot.com/2016/09/arduino-sounds-dfplayer.html]

See the “## Modes of Operation” section of the above link.

There are three different play modes… this isn’t documented anywhere else online, and I’ve been looking for a week to solve this nagging problem.

So the bottom line is:
Mode 1: Files in root directory: Played in create date order, file names do not matter
Mode 2: Files in /01…/99 directories: Uses THREE digit file names (001.mp3)
Mode 3: Files in /mp3 directory: Uses FOUR digit files (0001.mp3) names played in that order (this is what I needed)

1 Like

I was using four digit file names, but the little bash script I was using to copy mp3 files over to the micro sd card would also ensure that the creation timestamps matched the sequential file names.

That sounds pretty kludgy to require a script to copy files in an exact particular order for it to work. Not everyone has access to linux or knows how to write a script to do that. The hardware should just work as specified.

For Mode #1, (files in the root directory) it’s the order in which the files were created. A pretty useless mode if you ask me.
For Mode #2, if you put the files in /01…/09 directories, the DFPlayer will use the track file name numbers (i.e. 001.mp3) to play a specific track, and then no extra function/procedure is necessary to play a specific numbered track.
For Mode #3, the mode I’m using, with all the files in an /mp3 directory has its own quirk. It ALSO does not play the tracks by track number (i.e. 0001.m3)… it indexes them in filename order… the actual file name is irrelevant, it’s the sort order that counts… if you have files:
0001.mp3
0002.mp3
0004.mp3
0009.mp3

You need to request Track 3 to play 0004.mp3 and request Track 4 to play 0009.mp3

So the 0001…000x naming scheme is just to sort the files in ascending order, but the file names are not used for playback— it’s their physical sorted order.

I would suspect if you used Mode 2 and moved your files into a /01 folder and used the native playFolder(dir, track) function, you wouldn’t need the PlayTrack function. I have yet to have a track not play or the player hang. Also, in many sketches that have serial devices sending data via interrupts (GPS, accelerometers, etc), you can’t have any delay() functions because that will cause data to be lost.

1 Like