DFR0760 Gravity Speech Module I2C challenge
Hi. My Gravity Speech module frequently fails to work.
I am connecting via I2C.
I found the problem to be in the “begin” and the “wait” functions.
void DFRobot_SpeechSynthesis_I2C::begin()
{
_pWire->begin(); //_pWire->setClock(100000);
uint8_t init = 0xAA;
sendCommand(&init,1);
delay(50);
speakElish("[n1]"); // This should probably be replaced by “setDigitalPron(eNumber);"
setVolume(5);
setSpeed(5);
setTone(5);
setSoundType(eFemale1);
setEnglishPron(eWord);
}
All these “setXXX” functions call “speakElish” which in turn calls “wait”
void DFRobot_SpeechSynthesis::wait()
{
delay(20);
#if defined(NRF5) || defined(ARDUINO_SAM_ZERO)
while(readACK()!=0x4F) {}
#else
while(readACK()!=0x41) {}
while(readACK()!=0x4F) {}
#endif
/* readACK(); readACK(); readACK(); readACK(); */
}
This is where my module get stuck.
very often the return code from “readACK” are 0xEF
When this happens, there is no coming back. All future calls to “readACK” will always return 0XEF
The only way to stop this is to power down the module and re-start again.
If I am lucky the module starts to behave and the returns are as expected:
0x41 ==> Last command accepted
0x4F ==> module idle
I dont know what 0xEF means as a code but it is bad news. Any clue how to recover from this?
I see that the “begin” function sends a simpla “0xAA” code:
uint8_t init = 0xAA;
sendCommand(&init,1);
delay(50);
What does “0xAA” do? Are here any other code that could “reset” the module when it is stuck in an endless “0xEF” loop?
Thanks for your help.
H
I am trying to interface DFRobot Speech module with USBSTK5515 through I2C
What is the protocol to send ASCII characters? I have tried using rhe voice synthesize control commands starting with 0xFD but not successful. Please help
elwincmGood Evening,
I just wanted to share an update with you.
After many more hours of tests, i swapped the Arduino.
I had been using a UNI R3 original from 2011:
And I was getting all the communication issues with the Gravity Module.
When I swapped for this newer model:
Things started to work as expect.
I am not sure why as the “old arduino” has no issues communicating with other I2C components such as BME280 or BME680, but clearly it is not happy with the Gravity Module.
but at least for now, I have a solution.
Thanks for your assistance.
Regards.
H
Hugues.LecoeucheHi Jenna,
Thanks for the input.
I downloaded the new library and tried to run the “i2c.ino” example.
But I did not get much success.
Most of the time nothing happens.
if I unplug/replug the arduino to force a reboot with complete power down, then I may get the first syllab of the first sentence “She….” but this is it.
I dived into the code of the new library to try to understand what was happening.
I amended the setup to add a few traces:
#include "DFRobot_SpeechSynthesis_V2.h"DFRobot_SpeechSynthesis_I2C ss;void setup(){Serial.begin (9600);Serial.println("\n\n==========STARTED==========");Serial.println("Calling begin"); ss.begin(); //Init speech synthesis sensorSerial.println("After begin"); //Set voice volume to 5
And I could notice that very often the program was stuck in the “ss:begin();” function.
I looked into begin and did notice that the function was now sensing the mysterious byte “0xAA” up to up times followed by the request for status ({0xFD,0x00,0x01,0x21})
The former version of the library was sending this command only once.
I also noticed that the settings had been cut down and that now only the volume was being set:
void DFRobot_SpeechSynthesis_I2C::begin(){uint8_t ack = 0;
_pWire->begin();
uint8_t init = 0xAA; for(uint8_t i = 0;i<40 ;i++) // Sending up to 40 times the “0xAA” command
{ sendCommand(&init,1); delay(50); uint8_t check[4]={0xFD,0x00,0x01,0x21}; // Requesting status sendCommand(check,4); if(readACK() == 0x4f) break; // hoping to get a "module idle answer }
//delay(5000); // Possibly some former attempts to give time to the module to reset? //delay(50); // //speakElish("[n1]"); setVolume(1); // Only set-volume remains from the former version of begin //setSpeed(5); // setTone(5);
// setEnglishPron(WORD);}
To understand what was happening I added a few traces in the function:
void DFRobot_SpeechSynthesis_I2C::begin(){Serial.println("DFRobot_SpeechSynthesis_I2C::begin"); // So I know begin has starteduint8_t ack = 0;
_pWire->begin();
uint8_t init = 0xAA; for(uint8_t i = 0;i<40 ;i++) { sendCommand(&init,1); delay(50); uint8_t check[4]={0xFD,0x00,0x01,0x21}; sendCommand(check,4); ack=readACK(); Serial.print(ack,HEX); Serial.print(" "); if(ack== 0x4f) break; // To replace the former “if(readACK() == 0x4f) break;” }Serial.println("loop done"); // So I know if the loop is over
Serial.println("Calling setVolune"); setVolume(1);Serial.println("Volume set");}
Quite often I get the following trace:
==========STARTED==========Calling beginDFRobot_SpeechSynthesis_I2C::beginEF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF loop doneCalling setVolume
This indicates that the module did NOT start well and was only responding with “EF”
Once or twice after a powerdown/reset, I got:
==========STARTED==========Calling beginDFRobot_SpeechSynthesis_I2C::beginEF 4F loop doneCalling setVolume
The first response is still “EF” but eventually the module gets back to normal and responde “4F”
Still it was not working to I looked into “setVolume()”.
Nothing had changed: DFRobot_SpeechSynthesis::setVolume
calls DFRobot_SpeechSynthesis::speakElish
that eventually calls DFRobot_SpeechSynthesis::wait
I remembered getting stuck in DFRobot_SpeechSynthesis::wait
So I looked into it. the function start by waiting for ever to get a “0x41” code (i.e. “last command received and understood”)
void DFRobot_SpeechSynthesis::wait()
{while(readACK()!=0x41)//等待语音合成完成 { //if(readACK() == 0) break;#if (defined ESP8266)yield(); #endif } //DBG("NEXT--------------------------------0X41") delay(100);
……..
And I was suspicious that this is where the module get stuck.
So I added some traces:
void DFRobot_SpeechSynthesis::wait(){Serial.println("DFRobot_SpeechSynthesis::wait"); // So I know we are hereuint8_t ack; do // instead of “while(readACK()!=0x41)”//等待语音合成完成 { ack=readACK(); Serial.print(ack,HEX); Serial.print(" "); // So I can see the value returned } while(ack!=0x41);//等待语音合成完成 //DBG("NEXT--------------------------------0X41") delay(100);
And the trace I got confirmed my fears:
==========STARTED==========Calling beginDFRobot_SpeechSynthesis_I2C::beginEF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF loop doneCalling setVolumeDFRobot_SpeechSynthesis::setVolumeDFRobot_SpeechSynthesis::waitEF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF
……..
We never get over the waiting for ever to get a “0x41” code. We are endlessly stuck with “0XEF”
Can somemeone explains what “0XEF” means as a resturn code?
Also, what is the purpose of the “0xAA” byte sent at the start of begin up to 40 times?
Is this supposed to trigger some form of reset?
Regards
H
Hugues.Lecoeuche
1. Please check the version silkscreen of the module, and use the code and library of the corresponding version.
2. It is recommended to use the code provided in the wiki directly.
Gravity: Speech Synthesis Module V2 English/Chinese CSK4002 Wiki - DFRobot
jenna