DF-Player mini (aka FN-M16P) extended library for STM32

Hello,
as needed for my wooden-mp3-player project, I’ve completely rewritten the original library (now all commands are included!)

You can get this little module for about 4-6USD (search tip: “DF-player mini” and(!) “FN-M16P”)

good: Sound quality, build in amplifier, easy to handle (everything via serial commands, only TX and RX module to microcontroller), all of my micro SD-cards are working (even FAT32 formatted)
bad: filenames are not returned, files and orders must be specific named.

bonus: not in the datasheet: just connect the usb-pins (via 27R) to a USB jack and the player acts like an “removable device”, little bit slow, but useful.

As add-on, I’ve included a complete serial example for beginning. STM32_DF_player_serial_demo

For datasheet, please google “FN-M16P Embedded MP3 Audio Module” and NOT the DF-player one (incomplete and serious(!) errors!)

Matthias

Did you buy on eBay or AliExpress. I can’t seem to find it on eBay Australia

http://www.aliexpress.com/item/Mini-MP3 … 68837.html

Strange how I found it There is no “DF-Player” or FN-M16P in the description, but it is the original DF-Player.

Edit: offtopic: Look at the seller rating, wow. I know that the shipping was incredible fast (13 days to Austria is really a new record).

Thanks Matthias

I can only see it on AliExpress, all the MP3 modules on my eBay seem to be using the wdt020, which i already have, and its generally useless, as it only plays specially encoded files.

I will some from AliExpress.

BTW. i had some record delivery times from eBay chinese suppliers last week. I think 7 or 8 days !! from some suppliers.

Perhaps China Mail is not very busy with express packages at the moment

Hi Matthias,

I am working on an mp3 alarm clock for my daughter for Christmas. I am testing with a Maple R3 and Mini, and the DFPlayer is one from DFRobot. Having a problem getting your STM32_DF_player_serial_demo sketch to play any files – all I get is “Error: Specified track is not found”? The “DFPlayer_sample” sketch works fine – so I know my connections, file naming, and sd card are ok. I have tried quite a few different file/folder names with no luck….

Does your modified library require a different file/folder naming format than the original?

Hi,
did you installed my library from the first post?
Yes, I changed many things, because the original library was really incomplete (not all commands were included plus some minor errors)
Here is my complete project (maybe useful to compare) + library again.

regards
Matthias

Some additional important info:
If you plan to use the player with folders you have to obey following structure, otherwise it wont play in folder mode!
All folders must have the name “01”, “02”, “03”,… to “99”
All mp3’s within the folders must have the name “001.mp3”, “002.mp3” ….
so you have:
01
–001.mp3
–002.mp3
–xxx.mp3
02
–001.mp3
–002.mp3
and so on.

I’m not sure if you can use file names like “001_songxy.mp3”, “002_songyz.mp3” I didn’t try that out.

I got it working – I was using the wrong file/folder naming – changed it and all is good now. I also tried “001_songxy.mp3” file format and it works fine.

thanks again for your help!

cheers,

Brent

Dear Brent,
I’m glad to help you!
Funny part is that I build last summer an mp3 player for my daughter also She loves it and use it every day. So hopefully you’ll get it ready until christmas!
Here is my project link (if you didn’t have seen it already): viewtopic.php?f=19&t=14&start=20

Cheers
Matthias

Matthias,

Is there any chance you can confirm that the mp3_next() command actually steps serially through the files in the correct order when you’ve tested, from 0001.mp3 through whatever maximum number file you’ve assigned, and then recycles to 0001.mp3 and repeats?

On my board I seem to be able to ask for any specific file number foo ( mp3_play(<foo>) ), and it correctly plays that file, however, mp3_next() appears to cycle through the files in a random (but repeatedly consistent) fashion. i.e., if I have 8 files named 0001.mp3 … 0008.mp3, it’ll play 1,8,7,6,4,3,5,2,1… and repeat that cycle over and over. If I name the files 001.mp3 … 008.mp3, it will cycle through them in a different deterministic order. I’m pretty sure that in both cases, mp3_play((i.e.)3), correctly plays 0003/003.mp3, etc.

Since I have an N of 1, I can’t figure out whether I’m doing something wrong, or if this is expected behavior, or ???

Any insight into what you’ve observed in your work, would be really helpful!

Will

Hello, sorry for delayed answer:
At first, I don’t really remember how I managed the file system exactly. As I can remember, there are some problems so I’ve done it manually. (Reading back the error if the next file isn’t available)
Please feel free to examine my code!
https://drive.google.com/folderview?id= … sp=sharing
The latest version should be in “sketches/Vali_mp3_master3”
I’m quiet sure, if you use the folder mode, you must use filenames for mp3 like “001.mp3” and not “0001.mp3” within folders.

Hi Will,

I am using 01,02… folder names and 001,002 for the mp3 files, and I did not noticed any problems with the order of files played when I tested mp3_next command. I ended up not using mp3_next, but I am keeping track of folder/file currently playing, and use mp3_play (track, folder) to play next file. This also enables me to move to the next folder when the last file is played by keeping track of the # of tracks in each folder.

So, does that mean then that you’re relying on knowing the count of folders and tracks in each, to properly move amongst the tracks, or, are you successfully extracting this data from status responses from the mini player hardware?

I started trying to read data back from the player and was getting nowhere, but I think that was a level-conversion problem. Finally dredged a level converter out of the parts box, and I’m getting 8-byte responses now, so next is to try to figure out whether those responses are reasonable. I’m worried about un-playable files (non MP3s, etc) being counted though. Maybe won’t turn out to be a problem in practice?

In the mean time I have a work-around working, using track numbers (and incrementing them to move forward to “next”) and checking the “busy” line to see whether I’ve stepped forward past the end of the existing files. Inelegant, but at least usable for my purposes.

The “previous/next” behavior in the absence of explicit track numbers (even with files named 00# or 0# or 000#) is just plain messed up, at least with the version of the hardware that I have. I noticed a note, somewhere on the interwebs, where someone hypothesized that these devices might be dumb enough about filesystem access that “next” to them doesn’t mean alphanumerically, but rather next in physical device block-address. I haven’t confirmed that, but whatever mine does to implement prev/next, definitely has nothing to do with the alphanumeric sorting of the file names, so block-order is at least a reasonable guess.

madias wrote:
I’m quiet sure, if you use the folder mode, you must use filenames for mp3 like “001.mp3” and not “0001.mp3” within folders.

And, I’ve verified that the module’s knowledge of the filesystem is sufficiently trivialized that the mp3_get_*_sum() routines are more or less useless.

They return the total number of files on the device, rather than the total number of playable files that you’d want them to return. As a result, if your operating system has a habit of leaving “dot” files laying around, or hidden directories with undeleted trash, etc, the get_*_sum() routines can’t be counted on to inform you of the actual number of playable files.

This might be acceptable if you have a tightly controlled environment and can guarantee that the media is always clean of everything other than playable, properly named files, but, it’s too brittle to use where random users can plug in media with potentially unexpected filesystem contents.

It looks like the safest way to implement next/previous is to use the play(#) command with explicit track numbers, and the busy line, and to cycle back to the default play(1) state when play(track++) fails to result in a busy status.

Hello, i use this.
call function for example:
soundnumber(1);

int crcaudio=0;

void init() {
crcaudio=0-(255+6+6+0+0+30);
Audio.print(126,BYTE);
Audio.print(255,BYTE);
Audio.print(06,BYTE);
Audio.print(06,BYTE);
Audio.print(00,BYTE);
Audio.print(00,BYTE);
Audio.print(30,BYTE);
Audio.print(254,BYTE);
Audio.print(crcaudio,BYTE); //// CRC
Audio.print(239,BYTE);

delay(100);

}

///// MP3 NUMBER IN FOLDER NAME=01
void soundnumber(int num) {
crcaudio=0-(255+06+15+00+01+num);
Audio.print(126,BYTE);
Audio.print(255,BYTE);
Audio.print(06,BYTE);
Audio.print(15,BYTE);
Audio.print(00,BYTE);
Audio.print(01,BYTE); //// FOLDER 01
Audio.print(num,BYTE); //// MP3 NUMBER 01.mp3…….02.mp3…
Audio.print(254,BYTE);
Audio.print(crcaudio,BYTE);
Audio.print(239,BYTE);
delay(400);
}