SPE035 MP3 PLAYER

[B4Lamb]

I'm in the development phase using the spe035 module and started with the example code in the editor for the kit.
After a short while I realised that the busy loop that tests if a song or audio file has completed was not actually detecting the end of the file and it was jumping out of the do while loop too early. On examination I see that the SPE035 or more precisely the dfplayer mini busy signal goes high and then back low during playback so I had to introduce a pause a another do while loop to find the true end of the playback file. I would have thought that the example code in the editor would have been fully tested but clearly it is not. I wonder if anyone else has come across this problem?

 

[hippy]

On examination I see that the SPE035 or more precisely the dfplayer mini busy signal goes high and then back low during playback so I had to introduce a pause a another do while loop to find the true end of the playback file. I would have thought that the example code in the editor would have been fully tested but clearly it is not. I wonder if anyone else has come across this problem?

Nothing is ever 'fully tested' under every possible circumstance.

The DFPlayer Mini datasheet describes the Busy as low while playing and high when not; that appeared to be the case when we tested things and that is what our software examples reflect.

If the DFPlayer Mini is appearing to do something different then it would need to be investigated as to why that was.

If the Busy signal is spiking high during playback, the best option may be to check that the high is of a certain length before considering it to be an end of playback signal. The original code is most likely -

Do While BUSY_PIN = 0 ; Playing
  Pause some time period
Loop
; Finished playing, at end of track

This should ignore false end of playback spikes -

Do
  Do
    Pause some time period
  Loop While BUSY_PIN = 0  
  Pause length of false spike
Loop While BUSY_PIN = 0

I am guessing that's something like the fix you have.

We could have added that into our example code but there did not seem to be any necessity to do so.

 

[B4Lamb]

Yes that is basically what I had to do to fix the problem. I didn't measure the false spike of the busy signal with a scope but maybe I should do to make sure the pause covers worse case. In my application I need to have the minimum delay between playing one file and the next and I was finding the next file was being stated erroneously before the last was finished. I have developed an algorithm that converts a variable number between 0 and 255 or 0 and 25.5 into spoken words where these are only saved as files such as 'zero' 'one' 'two' .... nineteen then twenty thirty etc to one hundred, then two hundred
Plus a joining words 'point' plus 'and' are the only recorded phrases. So to read out a value of two hundred and thirty nine is 4 files to play back with minimal time gaps. Anyway the fix works so others may benefit from this knowledge. The example code in the editor is sprinkled with pauses that are unecessary if busy is detected and deglitched properly.