DF player mini trigger input (IO) pin problems

Other Hardware Audio
1

Hello,
Recently I created a board with multiple DF players to output separate audio sources to designated speakers. Unfortunately, I'm running into a problem with playback on these boards. I have wired the boards as shown in the pictures. I am making use of the IO pin, which is supposed to trigger either the previous audio file or the next audio file. However, the DF player seems to be completely ignoring this, and instead plays the smallest or largest audio file first, and ignores the order of the files on the SD card. I have them labeled as follows: 00x.mp3, and have tried changing the format several times to include numbered folders, more leading zeros, and anything else I could find on existing tutorials for the DF player. Changing the format made no difference.

20221029_000105
20221029_0001051920×1080 174 KB

20221029_000016
20221029_0000161920×3413 410 KB

Has anyone else run into this problem? I am unable to make my DF player play the audio files in order of their file names, even though I am using the IO pin, and not the ADKEY pin.

Here is where my issue gets even weirder, though. I originally had the negative side of my 5v power supply connected to the ground on my Arduino board, and the largest audio file would play first. When I removed the connection to ground from my board, the trigger would still activate, but it would instead play the smallest audio file first. Apart from this odd flip-flop, I was very surprised that the digital OUT from my Arduino board was still able to activate the transistor, given that there was no completion of the circuit via ground to the Arduino board. This entire situation has completely confused me, and I'm hoping someone with more experience can identify the problem, as well as provide some insight on how my digital OUT pins are still able to saturate the transistor despite the absence of a pathway to ground on the Arduino.

To further help with the troubleshooting process, here is a description of the DF player breadboards:
-Positive 5v on the far left side, with negative 5v on the far right
-Transistor wired to close connection to negative 5v when saturated. Base connected to Arduino digital OUT with 10kohm resistor, collector connected to IO2, emitter connected to 5v negative.
-DF player mini connected directly to 5v negative
-DF player mini connected to 5v positive with 20ohm resistor
-3.5mm audio jack wired to DAC_R & L pins, also connected to 5v negative

-All DF player breadboards are connected to the large breadboard at the bottom for power distribution. The 5v power supply cables are the orange and yellow jumper cables connected on the far right.

If you have read up to this point, I really appreciate your help, thanks!

2

There's a cheat sheet somewhere that i think says files are played in the order they are written to the SD card and not by filename. I could be wrong!

3

Thank you Mark! I can't believe this was the issue the entire time. For some reason, it ignores the filename and plays in the order that it was written to the card. I really wish they had more documentation on this, as I spent a long time trying to troubleshoot it.

While it's great that I fixed it, I'm still wondering how this circuit is able to work without a connection to the ground pin on my Arduino. If anyone can answer this, that would be much appreciated!

Thank you again, Mark.

4

Maybe the ground is common further up the power chain?

5

What do you mean by that? Right now there is nothing connected to the ground pin on my arduino, as you can see in the picture, yet it still works. Everything is tied into the 5v power supply, however I have always been under the impression that for a digital out to work, it must be a full circuit back to ground on the arduino.

6

Your Arduino ground pin is connected to the 0V of the USB connector which is connected to the 0V of your PC.

Where do the 5V supply orange and yellow cables go to from your breadboard?

8

I've been hoping to experiment with this issue. In the days of MS-DOS (before Windows), there were all sorts of disk utilities kicking around. If I recall correctly, amongst them were tools to rewrite the FAT (File Allocation Table) to change the order of the files. If a tool like that could be used to get the files into the order that the mp3 player used, then it would mean that new files could be inserted into the play order without having to start from scratch.

9

What follows may or may not be of interest:

I've been experimenting with my DFPlayer Mini (probably a clone). I have a 512Mb MicroSD card and 8 test MP3 files (actually TV theme tunes beginning with A, B ,C etc) named 001.MP3 to 008.MP3.

I deliberately dragged the files into the root folder of the blank card one at a time starting with 008.MP3, then 007.MP3 etc.

With a simple sketch and the DFPlayerMini_Fast library, I played track 1, then track 2 etc. The tracks were played in the order they were written to the card. Track 1 = 008.MP3, Track 2 = 007.MP3 etc.

After a quick search, I discovered a potentially useful little PC program called DriveSort. It's a portable program that doesn't need installing. The author says:

DriveSort sorts the directory tables of a volume formatted in FAT12, FAT16 or FAT32. This sort orders the files on the disk according to a customizable order.
Recent operating systems sort the files before showing them to the user, either by name, by size or by whatever the user choose. However, it is not always the case in embedded OSes on small portable devices like MP3 players. On these devices the lack of resources (CPU, memory) can lead their developers to make it display or play the files in the order in which they are on the disk.
This order depends mostly of the order in which they were added to the disk, which is not convenient for the user. DriveSort can change this order to help such devices to play or view their files in the order you want, by putting them on the disk in a customizable order.

I tried it out directly on my SD card, and now track 1 = 001.MP3, track 2 = 002.MP3 etc.

I've not yet tried it with folders (and folder contents), but I don't see why it wouldn't sort them as well.

10

Thanks Mark, I'll have to try that out. I was working with them yesterday and found something interesting. In order for the files to play correctly consistently, I have to re-format the sd card every time I make a change to the files. I'm not sure why this is the case, however so far it has worked without any issue. I'll test out DriveSort and see if it doesn't require me to reformat every time.

As for the grounding issue, there is no jumper cable connected to the ground pin on my arduino at all. The only cables connected are to the digital pins. The 5v power supply (orange and yellow cables connected to breadboard) go directly to a 5v plug in wall adapter. I'm still confused as to how my digital pins are working, as they have no path to the arduino ground.

11

If you take a look here : DFRobotDFPlayerMini/FN-M16P+Embedded+MP3+Audio+Module+Datasheet.pdf at master · DFRobot/DFRobotDFPlayerMini · GitHub you'll see some info on page 3. Basically it says its done by date not by filename - it needs a numeric strucutre to the file name, but ignores the numeric sequence and goes by write date.

12

The page 3 I read makes no reference to "date" and the word "date" does not appear anywhere on that page as far as I could see.

13

Thanks edster, I do see that. That's weird, because all of the other datasheets that I looked at had no mention of anything like that. I'll keep that in mind from now on.

14

image
image1300×131 29.8 KB

If you read the very first line .....

15

Yes, and there's no mention of a date or time. What they are probably referring to is the order in which the FAT is populated with the files. The player probably plays the files by traversing the FAT entries sequentially from the first to the last. The embedded play probably doesn't have the spare RAM to be able to load up the complete file list and then sort them.

16

It doesn't use the words date time, but I don't know how else you would interpret '.. the 1st track you copied from computer..'

17

Perhaps:

18

Well that is different. The document refers to it in terms of the sequence in which you bring things from the source, your option refers to a changed sequence on save at the target. It's possible, I guess, but that's not what the document says.

19

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.