JQ6500_Serial
JQ6500_Serial copied to clipboard
JQ6500 stalling program
I've been using this library with the JQ6500-16p v2.1 (module with microUSB). I'm finding that when I use the "playFileByIndexNumber" command, my arduino has to wait for the mp3 to finish playing before it continues with it's program. I've tested this by running timers on my sketch, as well as the included jq6500 examples. Is this just how the library is meant to work, or is it a bug? If it is working as intended, is there a way to turn this off?
Most likely a problem in your code.
Here is the simple code I wrote to test the delay, just a modification of one of your examples:
#include <Arduino.h> #include <SoftwareSerial.h> #include <JQ6500_Serial.h>
// Create the mp3 module object, // Arduino Pin 8 is connected to TX of the JQ6500 // Arduino Pin 9 is connected to one end of a 1k resistor, // the other end of the 1k resistor is connected to RX of the JQ6500 // If your Arduino is 3v3 powered, you can omit the 1k series resistor JQ6500_Serial mp3(8,9);
unsigned long timer; unsigned long lengthofdelay;
void setup() { mp3.begin(9600); mp3.reset(); mp3.setVolume(10); //0-30 mp3.setLoopMode(MP3_LOOP_NONE); Serial.begin(9600); }
void loop() { Serial.println("This is a test to find the delay of the JQ6500 when playing files"); delay(1000); Serial.println("Test track 1, length of 792ms"); timer = millis(); mp3.playFileByIndexNumber(1); lengthofdelay = millis() - timer; Serial.println("Test track 1, delay of: "); Serial.println(lengthofdelay);
Serial.println("Test track 2, length of 1764ms"); timer = millis(); mp3.playFileByIndexNumber(2); lengthofdelay = millis() - timer; Serial.println("Test track 2, delay of: "); Serial.println(lengthofdelay);
Serial.println("Test track 3, length of 396ms"); timer = millis(); mp3.playFileByIndexNumber(3); lengthofdelay = millis() - timer; Serial.println("Test track 3, delay of: "); Serial.println(lengthofdelay);
Serial.println("Test track 4, length of 189,000ms (3min,9s)"); timer = millis(); mp3.playFileByIndexNumber(4); lengthofdelay = millis() - timer; Serial.println("Test track 4, delay of: "); Serial.println(lengthofdelay); delay(20000); }
And the Serial output: This is a test to find the delay of the JQ6500 when playing files Test track 1, length of 792ms Test track 1, delay of: 1142 Test track 2, length of 1764ms Test track 2, delay of: 1166 Test track 3, length of 396ms Test track 3, delay of: 676 Test track 4, length of 189,000ms (3min,9s) Test track 4, delay of: 1166
(all these tracks are converted to the lame --preset phone, btw) So it looks like when the song length is >1000ms, I get the max delay of 1166 before I can execute anymore code. I have tested this with both of JQ6500 modules.
Before sending a command, the library waits for up to 10ms to see if there is any left over data from the device...
https://github.com/sleemanj/JQ6500_Serial/blob/master/JQ6500_Serial.cpp#L255
after sending the command the library waits for a response for up to 1000ms
https://github.com/sleemanj/JQ6500_Serial/blob/master/JQ6500_Serial.cpp#L274
and after that it will wait at least 150ms while reading the response
https://github.com/sleemanj/JQ6500_Serial/blob/master/JQ6500_Serial.cpp#L281
since in the case of playFileByIndexNumber you don't need a response at all
https://github.com/sleemanj/JQ6500_Serial/blob/master/JQ6500_Serial.cpp#L255
you could perhaps get away with adding
if(!responseBuffer && !bufferLength) return;
immediately after the last command byte is written (currently line 263 of JQ6500_Serial.cpp)
https://github.com/sleemanj/JQ6500_Serial/blob/master/JQ6500_Serial.cpp#L263
that should reduce the time required to about 10-20ms probably.
NB: Check your wiring, it may be that you have not connected the TX of the device to the appropriate pin you are using for RX on the arduino (Digital Pin 8) and so none of the responses form the device are getting through, only commands sent to it.
Thank you for taking the time to write such a useful and comprehensive response. I have checked my wiring lots and lots, also took my parts out of the breadboard in case I was running into issues there. Since my project is reasonably timing critical, I think I will try and modify your library to not listen for a response from the JQ6500 after sending the playFileByIndexNumber command, like you've suggested.
I am having the same problem.
I am building a prop with several buttons, whenever a user pushes a button a sound is triggered to give feedback. The sound I'm testing it with is around 2 seconds long, and I find people can't push another button until the sound is finished. Well, they can push the button but the arduino doesn't notice.
I've tried adding
if(!responseBuffer && bufferLength) return;
immediately after the last command byte is written but to no effect.
Did any of you find a soluton to this?
I think it must be:
if(!responseBuffer && !bufferLength) return;
This worked for me :)
Seems like I'm in the same boat. I've edited the library to read as follows:
this->write((byte)MP3_CMD_BEGIN); this->write(2+args); this->write(command); if(args>=1) this->write(arg1); if(args==2) this->write(arg2); this->write((byte)MP3_CMD_END); if(!responseBuffer && !bufferLength) return;
but I still get a pause between the files and at the end of a playback loop. I've already condensed the code into its most basic form.
#include <Arduino.h> #include <SoftwareSerial.h> #include <JQ6500_Serial.h> // Arduino Pin 8 is connected to TX of the JQ6500 // Arduino Pin 9 is connected to one end of a 1k resistor, JQ6500_Serial mp3(8, 9);
void setup() { // put your setup code here, to run once: Serial.begin(9600); mp3.begin(9600); mp3.reset();
mp3.setLoopMode(MP3_LOOP_NONE); mp3.playFileByIndexNumber(0); }
void loop() { if (mp3.getStatus() != MP3_STATUS_PLAYING) { mp3.playFileByIndexNumber(1); mp3.setLoopMode(MP3_LOOP_ONE); } return; }
but I still get a pause between the files and at the end of a playback loop.
How long a pause
Guessing, at least a tenth of a second. Enough for a sharp gap to be noticeable. https://drive.google.com/drive/folders/1mf_6EkC3Cux1Qpcko6f3cO5WTrvdhBNd?usp=sharing The above code seems to skip the 1 second startup sound and immediately jumps into the loop file as well.
A 10th of a second just sounds like the normal track start gap. These devices do not, AFAIK, made for "seamless" playing.