Dfplayer Mini

Does anyone know whether a DFPlayer Mini's LED should light immediately on connection to ground and 5v/3.3v? I have it wired up but there is no life in it. Two of them in fact. I'm wondering under what circumstances the LED should turn on. Is the device off until told to do something in software? Or should the LED always be on? Thanks

The LED is on only while a track is playing.

Yes, the led is only on when playing with mine also. At other times the unit is on standby. Have you inserted a card with some files yet? Have you accidentally grounded one of the pins that will cause the unit to play?

One of my units was faulty on arrival. There was a solder bridge underneith, in a poorly laid out corner of the PCB. I managed to repair it without too much problem. Perhaps you could post well lit, well focussed pictures of the top & underside. I will have a look.

uxomm: The LED is on only while a track is playing.

^ this. LOL

I have received 2 separate batches.. one had red leds...others had blue leds.

Blue LED versions will work with the latest DFRobot library out there...

Red LED versions will not. (ie: no readState()...etc functions are supported?)

My guess is some old versions with old firmware... (anyone ever update their firmware or know if its possible?)

@PaulRB - Do you get a loud 'POP' from the speaker upon power on/down of the project?

I have read an article (thanks to uxomm for sharing/pointing it out).. http://work-now-dammit.blogspot.co.at/2016/08/dfplayer-mp3-module-high-quiescent.html

That talks about a 'hardware' fix (still havent found time to try it unfortunately) where they move a 0R resistor from one side of the amp to other available pads there..

Another link shared by uxomm was a German post that it eliminated the 'pop'.. but introduced even MORE noise to the lines? https://translate.google.com/translate?sl=auto&tl=en&js=y&prev=_t&hl=en&ie=UTF-8&u=http%3A%2F%2Fforum.arduino.cc%2Findex.php%3Ftopic%3D529514.msg3632548%23msg3632548&edit-text=&act=url

  • I already have 1k resistors on both RX & TX lines.. (I had noise too without them... but if introduces more noise.. how can we fix that after resistors already in place?)


There is a big open source project here for an Arduino based Lightsaber board (hes had several revisions already, called DIYino or Prime something 'er other)... and while open source.. and many others have helped him.. he hasnt responded to any questions so far.

So I reached out to member JakeSoft who helped with the open source project.. and asked how they dealt with the 'pop' issue.

He replied that its been a while, and the main guy (member Protonerd) would be better to ask.. since he maintains it still.... but he seemed to recall there was an extra reset() call somewhere in the library.. that they commented out.. (and all was well!)..

However.. I'm not really that advanced to be digging into libraries (and there are a lot of files there!!) and fully understand what is going on.. (although I tried...just wasnt really sure if I needed to be in the .h files.. or the .cpp files.)

Or if that meant the default DFRobot library? Or their 'versions' of it?

They have several open source libs for their project on GitHub

USaber LSOS (LightSaber OS) DIYino

Here is a link to one: https://github.com/neskweek/LightSaberOS/tree/master/Libraries/DFPlayer

The last two seem to have 3 files for the DFPlayer? (no real documentation for it.. since its supposed to be used in conjunction with all the other stuff going on)

Anyone see this 'extra' reset() call that was commented out?

There is a distinct and noticeable "pop", yes. You would not describe it as as a quiet pop. But compared to the volume of sound when a file is played at full volume, the pop is not all that loud.

I agree... compared to file playback at full (or even more than 17 volume level.. it NOT that loud)..

However.. there is NO audio playing on power on/off.. which make it quite noticeable.

I'll try the resistor hack/mod this weekend.... and report back..

I'm still REALLY curious about those other libraries... and where this extra 'reset()' call stems from...

It would be MUCH nicer to just fix this with a software update instead of a hardware fix! LOL


So I performed the 'resistor' mod/hack...

Let me say... DO NOT DO THIS.

It does -not- work..

I removed the 0R resistor just fine with a little flux, and bridged the other two pads on the opposite side.

I replaced my currently working DFPlayer for this recently mod'd one..

Boot up.. the audio was a bit... off.. (louder? volume and pitch a bit? maybe in my head)..

however the same sketch, did not run the same.. loops were clicky and not seamless anymore...

So that is a bust.

Last hope that I know of (rumor) if this extra 'reset' call somewhere in the libraries.

Another update.

So the resistor hack/mod was a complete FAIL.

I then looked at some of the library files.. (not my strongest skill to be clear!) LOL.. but not that many references to a 'reset()'

But I found this in the .h file

bool begin(Stream& stream, bool isACK = true, bool doReset = true);

so I removed the doReset boolean..

closed the IDE... re-opened.. and still got the same 'pop'..

At this point.... I have no clue how to handle this? (can I some how use a transistor to toggle one of the speaker lines.. or something?.. after power is on/after a second or two?)


Leaving the above for truth/others..

So I went back and and instead of the boolean on the arguments being removed..


I actually commented out this line:

file: DFRobotDFPlayerMini.cpp

line#: 103 (I believe)

part of this method/function: bool DFRobotDFPlayerMini::begin(Stream &stream, bool isACK, bool doReset){

this line: (comment it out) //reset();

I have reset a few times, and do -not- hear the pop any more.

I have lowered the volume previously.. but will do more tests, and raise the volume, can anyone confirm the same results?

If this does indeed work, then thanks to member @JakeSoft for giving me the tip!... hes the hero! :)

It helps make these little $1.50 boards more usable!