DFR Mini MP3 Player: monitor displays incorrect messages

[Terrypin]

Working with the DFRobotDFPlayerMini library I've been trying to add an additional facility to my jukebox. That may be the subject of later posts. But meanwhile in an attempt to gain insights I've resorted to switching to 'debug mode'. That delivers Send and Receive hex messages in the monitor (in addition to the plain english ones). Here's a much simplified example:

CODE

// Earlier preparation code
 // The following is in setup()
 Serial.println(F("DFPlayer Mini online."));
 myDFPlayer.volume(15);
 delay(1000);
 Serial.println("I have just used 'myDFPlayer.volume(15);' ");
 while (1 == 1); // Stops program from proceeding

SERIAL PRINT OUTPUT

12:36:23.511 -> BASIC-DFR—Test_PlayFinished
12:36:23.511 -> 
12:36:23.511 -> Initializing DFPlayer ... (May take 3~5 seconds)
12:36:23.511 -> DFPlayer Mini online.
12:36:23.511 -> 
12:36:23.511 -> sending:7E FF 6 6 1 0 F FE E5 EF 
12:36:24.531 -> I have just used 'myDFPlayer.volume(15);' 

Extra debug lines, like that one, are meaningless to me as they stand. So I intend to search for them (automatically) in the PDF files I've downloaded to get clues.

However, an immediate snag is that the IDE seems to change the specified hex strings. For example, according to the specs the command setting volume should be:

7E FF 06 06 01 00 0F FE E5 EF
But as you see it gets printed so that SINGLE character elements (3 to 7) are not padded with '0':
7E FF 6 6 1 0 F FE E5 EF

That requires an extra editing step by me before I can search.

Q: Is there any way to fix that?

[blh64]

You will have to modify your version of the library. If you look in your Documents folder (Windows) there is arduino\libraries\DFRobotDFPlayerMini which contains DFRobotDFPlayerMini.cpp

That file contains this at line 41

#ifdef _DEBUG
  Serial.println();
  Serial.print(F("sending:"));
  for (int i=0; i<DFPLAYER_SEND_LENGTH; i++) {
    Serial.print(_sending[i],HEX);
    Serial.print(F(" "));
  }
  Serial.println();
#endif

you need to add one line to print a leading '0' if the value is less than 0x10

#ifdef _DEBUG
  Serial.println();
  Serial.print(F("sending:"));
  for (int i=0; i<DFPLAYER_SEND_LENGTH; i++) {
    if ( _sending[i] < 0x10 ) Serial.print('0');
    Serial.print(_sending[i],HEX);
    Serial.print(F(" "));
  }
  Serial.println();
#endif

Ideally, you could file a defect against the library and propose this change

[Terrypin]

Brilliant, thanks so much, I'd never have fixed that myself!

The 'received' strings remain unpadded:

16:15:44.595 -> sending:7E FF 06 4C 01 00 00 FE AE EF 
16:15:44.595 -> received:7E FF 6 41 0 0 1 FE B9 EF 
16:15:44.641 -> received:7E FF 6 4C 0 0 1 FE AE EF 

There appears to be a similar section at line 234. But not close enough for me to risk an attempt at copying your hack!

#ifdef _DEBUG
      Serial.print(F("received:"));
      Serial.print(_received[_receivedIndex],HEX);
      Serial.print(F(" "));
#endif

[blh64]

Really? The fix of the received string would be identical to the other fix, except for which variable is being used.

"Risking an attempt" is exactly what you should be doing. Try it. Figure it out.

[Terrypin]

Well, I'm keen to learn so welcome your encouragement, but I didn't give up without some thought!

My hesitation was because I saw no equivalent for 'received'. I realise it must be trivial for a C/C++ programmer, but I'm wary about coding access to each of the ten individual elements of '_received'.

// In line 41 it was clearer:
#ifdef _DEBUG
  Serial.println();
  Serial.print(F("sending:"));
  for (int i=0; i<DFPLAYER_SEND_LENGTH; i++) {
  if ( _sending[i] < 0x10 ) Serial.print('0'); // NEW
    Serial.print(_sending[i],HEX);
    Serial.print(F(" "));
  }
  Serial.println();

But not so IMO in the two sections for 'received':

// Line 234
#ifdef _DEBUG
      Serial.print(F("received:"));
      Serial.print(_received[_receivedIndex],HEX);
      Serial.print(F(" "));

// Line 245      
#ifdef _DEBUG
      Serial.print(_received[_receivedIndex],HEX);
      Serial.print(F(" "));

I realise that I have yet to study Arduino's serial processing in sufficient depth.

By temperament I'm always loathe to abandon puzzles. But for my immediate tasks I'm going to return to my library method. At this stage, for me it's counter-intuitive and tedious to work with strings of hex. I was hoping to find it allowed me to more easily implement operations that have eluded me with the two libraries up until now. Such as randomly playing a chosen folder (not successively playing a randomly chosen folder, which I already do). Or printing the track number within a folder (not the 'indexed' track number within the micro-SD card). But in my admittedly brief study so far I've found no such advantages. Or unique commands.

But more important, I think I'm now close to sorting my remaining targets (like those two above) with library-based code!