TonUINO Aio_plus (Chip JL...): all commands send 3 times to the DFPlayer

[boerge1]

In the TonUINO software we are using this library (version 1.1.0) without an error so far.
Now we tried the version 1.2.1

With most chips it works fine but with the chip JL AB21BPOE481-82A2 on the AiOplus board we have problems. All commands seem to be sent 3 times. So, if starting a Track from the mp3 folder, it starts 3 times (0.5 seconds in between).

The AiOplus has following configuration:
platform = atmelmegaavr
board = ATmega4809
We use HardwareSerial (Serial3) for communication.

Here is the log. You can see calls into the library and the corresponding serial debug logs.

mp3.setvol()
OUT 7e ff 06 43 00 00 00 fe b8 ef
IN 7e ff 06 43 00 00 02 fe b6 ef

mp3.seteq()
OUT 7e ff 06 07 01 00 00 fe f3 ef
OUT 7e ff 06 07 01 00 00 fe f3 ef
OUT 7e ff 06 07 01 00 00 fe f3 ef

mp3.playMp3FolderTrack(262)
OUT 7e ff 06 12 01 01 06 fe e1 ef
OUT 7e ff 06 12 01 01 06 fe e1 ef
IN 7e ff 06 3d 00 01 56 fe 67 ef
OUT 7e ff 06 12 01 01 06 fe e1 ef
IN 7e ff 06 3d 00 01 56 fe 67 ef
OnPlayFinished: 342
OnPlayFinished: 342

mp3.playMp3FolderTrack(262)
OUT 7e ff 06 12 01 01 06 fe e1 ef
IN 7e ff 06 3d 00 01 56 fe 67 ef
OUT 7e ff 06 12 01 01 06 fe e1 ef
IN 7e ff 06 3d 00 01 56 fe 67 ef
OUT 7e ff 06 12 01 01 06 fe e1 ef
IN 7e ff 06 3d 00 01 56 fe 67 ef
OnPlayFinished: 342
OnPlayFinished: 342
OnPlayFinished: 342

mp3.getFolderTrackCount(1)
OUT 7e ff 06 4e 00 00 01 fe ac ef
IN 7e ff 06 4e 00 00 0e fe 9f ef
mp3.getFolderTrackCount return: 14

mp3.playFolderTrack(1, 14)
OUT 7e ff 06 0f 01 01 01 fe e9 ef
OUT 7e ff 06 0f 01 01 01 fe e9 ef
OUT 7e ff 06 0f 01 01 01 fe e9 ef

mp3.pause()
OUT 7e ff 06 0e 01 00 00 fe ec ef
OUT 7e ff 06 0e 01 00 00 fe ec ef
OUT 7e ff 06 0e 01 00 00 fe ec ef

mp3.play()
OUT 7e ff 06 0d 01 00 00 fe ed ef
OUT 7e ff 06 0d 01 00 00 fe ed ef
OUT 7e ff 06 0d 01 00 00 fe ed ef

[Makuna]

(moved to discussions)
This library is expecting the chip to reply to all commands either with an ACK or ERROR responce. If it doesn't get one, it will retry three times before giving up. This is to make the communications more robust, especially useful for bench prototyping.

Your specific chip doesn't seem to follow the standard in this respect.

Use the third template argument to select the no ack, like the following.

DFMiniMp3<HardwareSerial, Mp3Notify, Mp3ChipIncongruousNoAck> mp3; 

[boerge1]

Ok, but why it was working without any problems with the version 1.1.0?

And if you see the log above after playMp3FolderTrack(), there is an answer from the chip but the command is repeated anyway.

[Makuna]

v1.2.0 the ack checking with retry was added along with a de-asynchronism queue for notifications.
v1.2.1 the NO ACK chip variant was added.

The reply from the chip is not related to the request. Remember that responses can come asynchronous, especially the type that was sent (a song had completed playing).

Here is the snippet you are referencing. I annotated the data.

OUT 7e ff 06 12 01 01 06 fe e1 ef  // request to play MP3 Folder Track, Please ACK,  track 262
IN 7e ff 06 3d 00 01 56 fe 67 ef  // track finished playing, from SD, track 342 (async notification, added to queue to make a callback to user's code outside their call, a de-asynchronism to help sketch writers)
OUT 7e ff 06 12 01 01 06 fe e1 ef // no ack nor error, try again
IN 7e ff 06 3d 00 01 56 fe 67 ef // track finished playing again, why?  is it a short track with repeat on? (queued)
OUT 7e ff 06 12 01 01 06 fe e1 ef // STILL no ack nor error, try again
IN 7e ff 06 3d 00 01 56 fe 67 ef // track finished playing again, why?  is it a short track with repeat on? (queued)
OnPlayFinished: 342   // now outside the call to request track playing, pop any notification on the queue notify user through callback
OnPlayFinished: 342 // another queue pop/callback
OnPlayFinished: 342 // last item in the queue popped and callbacked

IS the finished playing track (GLOBAL # 342) the track requested to play MP3 Track#262?

A command error would look like....

IN 7e ff 06 40 00 00 ## cc cc ef // ## would be the error number, cc cc would be checksum for it.

A command ack would look like....

IN 7e ff 06 41 00 00 00 cc cc ef //  cc cc would be checksum for it.

[boerge1]

Many thanks for clarification!
So I will try to add the 3rd template parameter.

[xfjx]

Hi Makuna,

we had developed a custom firmware for our MP3 chip as it was not possible to get any while we developed our PCB. The firmware is optimized for the TonUINO project and was kept as simple as possible.

Thank you for providing out the workaround for the missing ACK!

[boerge1]

@Makuna Additional question:
Now we upgraded to new version and use the parameter Mp3ChipIncongruousNoAck. All works fine.
But now commands that have no reply (e.g. setVolume) take about 1 second until return.
I can't remember that this was the same with the old version.

[Makuna]

I don't have a module that doesn't support ACK, so I have to rely on others to test. So, it could be a bug.

I think I spot the issue though. Even though the module won't send an ACK, it could reply with an error (checksum/bad command/etc). In the case the command doesn't support ACK, it still has to check for a return of an error, and it uses the timeout of serial driver, which is set in the Begin() to 900ms, to let the device decide if the command had an error.

How long will the device take to return an error code?
Will it ever send an error code if it doesn't support ACK?

[Makuna]

@boerge1
If you could setup a test that forces an error with one of your devices and get the time for how many ms it takes to return an error; I can then provide fixes that will correctly accommodate this case.

[boerge1]

Yes, will do so.
But, what I do not understand: the setVolume function doesn't have any return value. So, the function could return without waiting for an error reply. And the error reply could handled in the next loop function call.

[Makuna]

In the library file Mp3ChipIncongruousNoAck.h, in the method generatePacket, modify it to add this snippet just before the return like

        if (command == Mp3_Commands_SetVolume)
        {
            // modify checksum to force an error
            packet.loByteCheckSum = 0x01;
        }

        return packet;

This should have the device return an error, with the error being DfMp3_Error_CheckSumNotMatch.
Also, turn on the debug output for packets by defining DfMiniMp3Debug in your sketch, and lastly, in Arduino serial monitor, turn on time output so it will include the time for each serial send so we can easily see time between send and recieve.

[boerge1]

My serial monitor only gives seconds, so I added the output of millis() before and after the call.

09:35:03: setVolume: 3
09:35:03: before setVolume: 67632
09:35:03: OUT  7e ff 06 06 01 00 1f fe 01 ef
09:35:03: IN  7e ff 06 40 00 00 04 fe b7 ef
09:35:03: DfPlayer Error: 4
09:35:03: after setVolume: 67662

09:35:53: setVolume: 3
09:35:53: before setVolume: 117557
09:35:53: OUT  7e ff 06 06 01 00 1f fe 01 ef
09:35:53: IN  7e ff 06 40 00 00 04 fe b7 ef
09:35:53: DfPlayer Error: 4
09:35:53: after setVolume: 117588

So, normally the error reply comes after about 30 ms.

[Makuna]

I published the branch AckNoAck with the changes.

If you could pick it up and give it a try and let me know. The timeout was reduced to 50ms giving a little overhead from your observed values.

[boerge1]

@Makuna The branch works for our chip very well. Now the commands take only 50ms. Many thanks!
Do you have already an idea, when you create a new release with this changes?

[Makuna]

Either today or tomorrow most likely.

[Makuna]

@boerge1 What is the actual chip model? JL AB21BPOE481-82A2? I wanted to alias the Mp3ChipIncongruousNoAck to a more specific name like, Mp3ChipJLAB21BPOE481, but I wanted to get a more accurate name for it.

[boerge1]

Yes, it is. But here the chip has a special self made firmware on it that has the problem. So maybe there exist other players with this chip with another firmware that sends ACK.
Maybe @xfjx can clarify this in more detail.

[Makuna]

ok I will leave the name alone for now.

[Makuna]

https://github.com/Makuna/DFMiniMp3/releases/tag/1.2.2

[boerge1]

@Makuna: does it make sense that we send you our player for testing?