The DFPlayer Mini is a module that allows easy playing of Mp3 files. I'm designing a system that will use this module to play audio books.
The DFPlayer mini is great for playing short MP3 files. However, it doesn't have a way to move forwards or backwards on a track which makes it bad for audio books that are usually very long.
My solution to this is to have a script that would cut up the audiobook into smaller chunks so that the DFPlayer can jump to each one as if it's moving forwards and backwards. The script needs to be smart enough to cut only on places where there is silence. This way the transitions between chunk/tracks would not be noticeable.
It's a simple solution that is not for everyone but exactly suits my needs.
The lithium ion polymer battery that I used for this project does not properly hold a charge anymore.
I figured an 18650 is a good substitute since I have lots lying around. The only problem is that it's way way bigger than a polymer battery. I could not fit it inside the case so the solution I came up with is to put the battery outside.
It's now uglier than ever. And I love it.
Also, I learned form the ESPBoy project that you could change the resistor on the TP4056 charging module to change the charging current used for the battery.
This meant that if I wanted to ensure a longer battery life I need to make sure that I choose the correct resistor value. It is recommended that the charging current is half or less of the battery capacity.
So I used a 2.2k resistor since my 18650 battery has a 1200 mAH capacity. Not sure if I did it correctly but it seems to be working. We will see just how well soon.
I have been using the device for a full week and everything has been great. The only concern I had is the power consumption. Don't get me wrong, the device can play an audiobook for 4 hours straight. In low power mode it can go as long as 12 hours.
I knew I can improve this so I don't have to charge every day. What I did was I added a power switch so I could turn the device off if I know I won't be using it for a long period.
I needed to make sure that the last track is saved first before turning the power off. So I made use of EEPROM saving. I was initially hesitant to do this because there is a limit to the number of EEPROM writes but after doing calculations I don't think I'll reach that for years.
Things have been great after this upgrade as I only need to charge sparingly.
The project is pretty much done and is working great. Watch the video below to see it's latest incarnation.
One thing that I had to add during assembly was a reset button to reset the ATTiny. This is needed because the battery needs to be connected first before the display. Because the system is already running before the display is added, a reset is needed to restart the sequence so that the display can properly show it's contents.
I also used cut up Sintra boards to hold the components in place. It's ugly but it does the job. The screw on the lower right acts as an anchor plus a way to keep the cover closed.
Overall I'm pretty happy with how the project turned out. The battery capacity needs to be upgraded though to allow longer usage. Thankfully I made disassembly and reassembly easy.
I spent the past few days finalizing both the hardware and software side of the project. Feeling confident that I've covered all my bases I decided to start planning the switch to perfboard.
The circuit is simple enough that it didn't take me long to finish a connection diagram that I was happy with.
It's a little cramped and that's because I wanted to use small this container.
I can't remember what the container was for but the plastic feels really solid so I went with it. My other reason for picking this is that it is slightly transparent. I like transparent containers to show off the insides of my projects.
Before committing fully, I wanted to give myself some practice with soldering so I decided to work on the part with the buttons. Thankfully, I didn't mess up anything but the connections are a bit messy.
Up next I'll work on soldering the other components. There's the challenge of keeping them in place, a problem I plan to solve with my favorite method: Sintra boards.
The project already has a working resistor ladder that allows multiple switches to work on one pin. My implementation is a bit unreliable though as I had limited understanding of it when I first implemented it.
This is why when I came across this post that offers a different resistor ladder I implemented it to see if it is better. To my disappointment, it didn't work. The values I was getting were wildly different from the supposed computations found in the post.
I later found out that it actually did work and turned out to be more reliable. Turns out that there was this buggy behavior in my code that made only my version worked. What happened was I designated one pin both as an input and output. There were no errors but the outcome was not correct.
I have since fixed this and applied the new resistor ladder to the circuit. It's now reliable and working great. The changes are now reflected on the github page.
I wanted to make a script that would cut an audio book into smaller files so that my player can play one file after another but also allow going forwards and backwards.
My idea was that the script would cut every 5 minutes but at a point of silence. Audio books have lots of silent moments in between speeches so the script would just move forward in time until it reaches silence.
I searched online to get ideas on how to go about in doing this until I chanced upon this solution. It' different from what i wanted as it cuts at silences that matches a specific duration like 2 seconds.
I tested this script out and found that it actually works just as good. The length of each file differs wildly but I think it doesn't really matter. As long as my player can move forwards and backwards it doesn't matter how much as long as I get to the point that I want.
I experimented a bit more with the above solution and found that a silence duration of 10.0 seconds is best for my needs.
With the above command, a 13 hour audiobook has been split to 1014 files.
13 hours is 46,800 seconds. Divide that by 1014 files means that each file should have around an average 45 seconds each. This means pressing the next and previous buttons should jump more or less 45 seconds. Not bad.
I'm going to be sticking with this setup for now. We'll see if the places where the audio is cut makes sense. If not, then I could just run the script again and just change the silence duration.