I recently purchased this module (DFROBOT DFR0760 Gravity Speech). There is little technical data about it but based on the commands the module accepts it is fairly certain that it is based on the XFS5152 chip.
I am having some issues with that module: It frequently fails to work.
When that happens, I noticed that the module return a code of "0xEF" instead of the "0x4F" to indicate that it is ready for the next command.
When the module works the returns are:
"0x41" (last command received and understood)
then
"0x4E" (module busy-during speech generation)
then
"0x4F" (module idle)
However I quite often get "0xEF" as a return and when this happens the module stops talking. All subsequent status request return "0xEF".
I cannot find any documentation about what the code "0XEF" means and how to get the module out of that mode.
Even un-plugging from power and re-starting does not always cure this (frequenlty not ).
If this helps, I am using the I2C protocol to communicate with the module.
I also noticed that the DFRobot library has small difference in their "begin" function for the module between the I2C and the UART modes.
In the I2C begin it send a "0xAA" command as a single byte (not the usual 0xFD | 0x00 | 0x01 | <>) but not in the UART version.
However, commenting this "0xAA" out or not does not appear to make any difference and I cannot find any information either about what this 1 byte command could be for.
I did but only after I started having troubles with the I2C link.
I did not get any success with the UART/Serial coms either.
The status I get are 0 which means "no serial message available".
I am powering the module straight form my UNO (tried 5V and 3,3v as the module supports both). This is as per the DFRobot diagrams.
I have seen videos where people power the XFS5152 from their board or from an external power supply. The board is rated 160mA so I dont believe it is an electrical problem (like lack of power or unstable power supply).
The cables are 40cm long so not short but still well within the tolerance of I2C running at 100Hz.
The code is not in a state I am proud off. I need to spruce it off a bit before imposing it on the community in a shorter format & with comments.
I spent more time on this last night. I did some tests with an external power supply to validate the theory that this was not power supply related. The external power supply did not help.
So I carried out more tests and the conclusion are:
When the Arduino & the module are working well together, things remain well.
It is only when I upload a sketch or reset the Arduino that the communication between the 2 is lost.
From that point on the module will have to be "reset" by disconnecting it from power (I have not found any other way to reset it - no button, no code sequence that I am aware of).
On the this has been done, if I send a succession of 1 byte codes (I thought of this based on my observation of the original "begin" sending the code 0xAA) then the module will spring to life again (I am sure that I don't need to send all the bytes from 0 to 255 but I have not had time to narrow this to the one that work). More precisely, after I have sent the code from 0 to 255 and gotten the dreaded "0xEF" answer each time I asked for status, the next full simple 5 byte command (like "set volume") makes the module emit a sound and from that point on, all is well.
That is....until I need to load a new sketch or reboot the Arduino.
So it feels an issue with the starting sequence
Regards...
H
that sounds like the UNO reset after upload does not trigger a DFROBOT DFR0760 Gravity Speech reset. May be you could try to call the reset() function from the library in setup()? (not sure what it does though as it seems to require a working connection to the module)
another option could be to try to add a transistor to control the power supply of the Gravity Speech and turn power off and on in setup to trigger a full reset. May be that would help
I tried the reset() function from the library. It does not reset the module, just resets the settings of the voice generation (tone, volume, voice,...) and as you rightly said, it requires to have established communication with the module.
YES, using a transistor to switch the module on/off was/is one of the routes I am considering....probably an activity for the week-end
Thinking about it, the speech module should not be affected by the Arduino reset. The module is powered up and listening to the I2C bus.
The arduino reset does not affects the module power supply, so the module remains "on" and still listening to the I2C bus for its next command.
As the Arduino re-starts it will execute a "Wire.Begin()" but I dont think that this affects the slaves devices on the bus.
So I still dont understand why rebooting the Arduino would impact the communication between the 2.
After many hours spent experimenting with the 1 DFRobot version of the DFR0760 library and getting nowhere, in desperation, I swapped Arduino.
I had been using my old and trusted UNO from 2011:
And I very often got I2C communication issues with the Gravity sound module.
But when i swapped to a newer mode:
Everything started to work as expected.
I am not sure why.
I can control other I2C devices (such as the BME280 or BME680) without any issues.
).
