.volume() doesn’t send data on first call unless debug interface is turned on

[timdmackey]

This is a really strange bug I'm experiencing. I have my code set up to read a potentiometer value for the volume. It checks the volume every x milliseconds in the loop() function, as well as one time immediately after the DFPlayer is initialized in the setup() function.

For some reason, the initial volume setting doesn't occur unless I have the debug interface set to true when I initialize the DFPlayer. If it set it to false, it stops working. Subsequent calls to the volume() command do work.

Because I'm keeping track of the current volume and only sending volume() commands when the volume changes, the result is that the volume will be incorrect until I turn the potentiometer, at which point the player volume jumps to the correct setting. I confirmed that the code is being reached, because there I print a message to the Serial buffer in the lines immediately before and after the volume() call.

[timdmackey]

Actually, I can't even get the player to start playing if i have the debug parameter set to false. I must be doing something wrong?

If I set debug to true and start up the arduino, the files will play. If I then set it to false and upload the sketch to the arduino while it is running, the file continues to play and i can adjust the volume and change the track number with my programmed buttons. However if I unplug the arduino and DFPlayer and restart them while the debug parameter is set to false, the file won't start playing.

I tested this with the example sketch and I'm running into the same problem. Simply changing the debug values to false prevents the files from staring to play.

[timdmackey]

Is it possible that I'm sending too many commands too quickly, and the debug information is slowing the Arduino down enough that the DFPlayer doesn't choke? I remember reading an older discussion here about the original library having delays to prevent the DFPlayer from getting overwhelmed.

On a hunch, I decided to experiment with adding delays, and I was able to solve the problem with just one delay:

myMP3.volume(20);
delay(500); // ← added this
myMP3.playFolder(1,5);

Those two functions are being called right after each other in the setup function.

Does this sound plausible, and if so what is the best way to handle this issue?

[agfaps]

Hi @timdmackey , What DFPlayer chip are you using? There's a lot of different chip out there and many of them didn't have the same performance/command set as the original one (from dfrobot, chip YX-5200). In my experience to have a consistent output from many different chips are:

1. Add delay about 1 second after dfplayer.begin()
2. Add delay about 500ms after each command
3. Some chip only support command without checksum, so comment the checksum part in senddata()
4. Some chip need more time in query mode. 500ms instead default 100ms helps.
5. Regarding point 4, if query return is -1, you can't use isPlaying(). If this happens, just check busypin state. Maybe you can also encounter a chip where there is no isFinished event sent from dfplayer or the busypin always busy(led also always on) after playing even after reaching the end of audio file.

Hope it helps.

Regards.

[terrypin999]

Hi @timdmackey,

Did you ever get a solution please? I've just started working with this library and cannot get the example.ino sketch working. One of the puzzles is that it does not respond to the reduction from 30 to 5 in the volume.

Also, where is the 'debug' setting you mention?