Disclaimer: This topic may require some knowledge about DFPlayer Mini troubleshooting. Feel free to engage, but at your own peril.
I am working with a set of known problematic DFPlayer Mini clones (the notorious MH2024K-24SS) (1). I have done some due diligence and at this point I am well aware of the issues with these clones. (For those who are not I would like to refer to these excellent reviews by Printed Droids and Garry's Blog (2,3).
I confirmed some basic function by using the trick of pulling the I/01 pin to ground, which plays sound and activates the status LED for the duration of an MP3 file's playtime.
I am using the DFPlayerAnalyzer (4) to troubleshoot and analyze how the module behaves through different setups. As expected with these clones, the response time is bad compared to the original and the wake/sleep cycle misbehaves.
My initial question for the forum is if you have encountered ERROR 129 before?
In my log, ERROR 129 appears selectively after playback/sleep operations:
"TestGetCurrentTrack" after playing tracks
GetCurrentTrackSD times out ([26071])
"TestWakeupAfterSleep" after waking from sleep
GetStatus times out repeatedly ([257802], [259415], [261027], [269968], [271581], [273193])
This error is defined in DFMiniMp3 library as a communication error caused by timing conflicts that occurs when the module sends a command and is waiting for a response. But I am suspecting that this might be an issue with the TX line not sending a strong enough signal to the Arduino RX. Has anyone troubleshooted this error before?
Not that I can recall. Do you have a minimal sketch that demonstrates it, which we can try?
I have seen most of the points before that you include in the bulk of your (and AI's) post. Reinforces my largely trial/error approach when working with this module!
The sketch I'm using is the current DFPlayerAnalyzer from ghmartin77. You can find it, and the library DFMiniMP3 listed in the github page below. (1) The last commited date is over seven years ago, so I'm honestly not sure it is maintained. It was recommended by users that I trust (eg. Garry's Blog and Printed Droid) for troubleshooting these modules.
I've gotten some basic functions to work on these modules using serial commands and the official DFPlayerMini library. (2)
Tested commands: using serial commands:
Plays file 01/0001.mp3
Plays file 01/0002.mp3
Stop the file playing in the middle of a track.
Pause the file playing in the middle of a track, then unpause.
Activate/Deactivate repeat mode. Can be done in the middle of a track playing.
A bit of googling and help from AI. Check out the following and see if it helps.
Error 129 = 0x81, and it arises in two distinct contexts depending on which library you’re using:
In the Makuna/DFMiniMp3 library (one of those I understand you use), error 0x81 is an RX timeout — the Arduino sent a command but no valid response packet arrived within the timeout window. This is a library-side error. It appears selectively after playback/sleep operations — for example, GetCurrentTrackSD or GetStatus timing out after waking from sleep.
From the module itself (hardware-side), 0x81 (129) is actually sent by the DFPlayer when it resets after a brownout — if the supply current is too low or volume too high (I rarely use over 20), the module goes into a noise/crash state, becomes unresponsive to serial requests for several seconds, then resets and sends the 0x81 error code.
With clone chips, calling
getTotalFolderCount()
on certain clone variants (e.g. MH2024K-16SS) will run into a communication timeout, resulting in RX error 0x81.
With certain repeat/loop commands, error 129 can appear when using loop-mode commands — for instance, loopGlobalTrack(3) produces Com errors 131 then 129 on some module variants.
So in short, error 129 signals one of three things:
• RX timeout (no reply received in time) — most common with clones and their slow/unreliable response timing
• Post-brownout reset — module crashed due to power supply issues and is reporting its self-reset
• Unsupported command on a particular chip variant — some commands just don’t work on certain clones.
Interesting. Using an external power source (5V, max 700mA) was an important part in getting the module to initialize using the DFPlayerAnalyzer sketch.
This might just be that the library is not compatible with the specifications of the module, as I have managed to operate it with serial commands using Just Baselmans sketch and the DFRobotDFPlayerMini library (v1.0.6).
I've attached a test log as PDF if you want to have a look.
I've noticed that I get much more reliable initialization after adding a 2000 ms delay in voidsetup() after softwareSerial.begin(9600), and immidietly setting the volume to mid through sendCommand(0x06, 0, 10).
This was suggested by Garry's Blog's example sketch, and I thought about it after your comment about brownout/crash.
Garry left a comment that "set volume (otherwise will be full volume)", but I cannot find this in the documentation. But if true, this may explain the troubles some users have had getting this model to initialize.