ESP8266 Community Forum

Voice Announcer

Here are 2 different Voice Announcers...

1. The first offers stand-alone selectable pre-recorded voice messaging capability to your ESP_Basic projects - allowing your projects to speak when you wish them to say something. This is a non-network version developed on V3, but it can easily be converted to be V2 compatable by removing the comma's from the web buttons and slider controls.

2. The second implementation offers a V2 version giving EasyNet udp remote-controlled Voice Announcement system capability - allowing remote (or local) event triggers to cause corresponding local alert messages to be spoken. Multiple Voice Announcer nodes might speak different (or identical) audio messages in different multiple locations if wished, allowing common messages to be broadcast around the house, as well as perhaps more targeted messages to be aimed at specific locations.

Both the stand-alone and network versions use the same JQ6500-28P module that was used in the Music Player published here... http://www.esp8266.com/viewtopic.php?f=40&t=9381

The following link offers a good article about using the JQ6500, including how to control it using IR signals or hardware buttons if wished... http://sparks.gogo.co.nz/jq6500/index.html

The 2 projects offered here are based on sending the JQ6500 appropriate serial control codes for instructing it to play the specified audio file in the specified folder, and no attempt is made to receive any info back from the JQ6500. If you wish to take things further, the following article offers a good source of info regarding the serial codes... http://sparks.gogo.co.nz/jq6500/serial.html

According to the article above:

"Play file by folder and name from SD Card needs to use folders named 01 through 99, and files in those folders named 001.mp3 (or .wave) through 999. Note that arguments are a single byte, so effectively you can only access up to file 255 in any folder"

.
In summary, you appear to be limited to 99 folders each holding up to 255 files... which should be ample for most purposes.

For my purposes I need a few dozen 'events' to announce corresponding event messages, thus 'event 1' would play audio file 001, and 'event 9' would play audio file 009, etc.

I don't envisage ever requiring more than 99 different sensor-triggered events, so I have opted for a convention which uses files 001 to 099 to specify 'primary' event messages, and uses files 101 to 199 for any possible 'opposite' type secondary event messages if they are needed... so for instance event 5 could have an associated primary file 005 'Door Open' message, plus a corresponding associated secondary file 105 'Door Closed' message if wished.
I've reserved file 200 for a main 'Welcome" type message, and file numbers from 201 upwards are reserved for specific system-type messages such as "Volume UP" etc.
This convention allows the entire 'message set' to conveniently fit into one folder, allowing use of different folders for alternative 'custom' message sets, or even alternative language sets if wished. So this convention lends itself well to having a bog-standard development 'message set' in folder 01 which announces events by their 'channel' or zone' number, ie: "channel 5 triggered" or "zone 5 alert" or whatever you may prefer, but it then allows subsequent easy switching to a custom message set in folder 02 for announcing tailored messages to events, such as "Shed door opened" or "Mailbox delivery" etc.
This is the convention adopted for the EasyNet version, which basically just sends a file-number to be announced from the currently selected folder (more later).

Another useful convention (perhaps particularly for the stand-alone version) might be to use folder 01 for all primary 'On' event messages, folder 02 for all secondary 'Off' event messages, and folder 03 for all system type messages.

Don't forget that ESP_Basic is capable of reading IR signals, so an advantage of having a folder just for system type messages could be to have up to 254 voice response messages available for a 'voice announced menu' if you wished, which could effectively offer a multi-level menu of options each containing several sub-menus of multiple options which you might navigate through (perhaps with an IR remote controller) using audio feedback - rather than depending on visual feedback, which obviously requires some form of connected display device.
Choose whatever file and folder convention best suits your own purposes and offers you easiest access and control of your recorded audio files.

The JQ6500-28P module I'm using has on-board mini-USB and micro-SD slot, so it is possible to load files to SD remotely, then plug in the card. Or you could load the files directly through the JQ6500-28P USB port which should show up as a Removable Device on your computer if the device drivers load ok.

The stripped-down numerical filing systems used by cheap asian devices are prone to reading files according to the order they were written to disk irrespective of what the files may be called, and although the JQ6500 actually has a separate 'native FAT order' addressing mode, my experiences have shown that it doesn't take much for the Named addressing to get it's nickers in a twist if given a non-existent file to play, or trying to play file 0 even if it does exist.
So don't take liberties, and only send it filenames to play that actually do exist in folders which exist, cos once it gets it's nickers in a twist it might require a JQ6500 power off/on to straighten things out again.

Be aware that when driving an attached speaker the JQ6500 module is prone to bursting into 'motor-boat' oscillation if the volume is above about a third to a half - this is caused by excessive power consumption of the onboard amp, which keeps causing the module to rapidly reset and reboot over and over. If using an external amplifier instead of a speaker, the modules onboard amp is less loaded so the module volume should be less of an issue, but bear in mind that a breadboard rats-nest acts like a bunch of aerials likely to introduce a lot of 'noise' to the relatively low-level audio signal output.

Record your audio messages however you prefer... you could record someone speaking messages into a mic, or you could use an audio utility like audacity to record text-to-speech messages from your computer (perhaps using Google Translate), or you could use one of the online TTS sites which allow you to type in text then create a resulting audio file using whatever voice you selected.
I am using .wav files, but the voice module should be able to play .mp3 if you prefer (it played MP3s in the Music Player project).

Message Tips - Name your original recordings with something meaningful indicating the message contents, and keep them as an un-touched source to return to if/when needed.
Create a list of file numbers and their corresponding spoken messages to refer to, then rename a copy of the relevent files in another folder according to your list.
First create your folder structure containing the required files on your computer, then copy to SD when done, so that all files and folders get written to SD media in their correct numerical name order.
Create a list of your required message set folders with an appropriate corresponding description, ie:
01 - default english
02 - custom english - Electroguard system
03 - custom english 2 - Joe Bloggs system
04 - default french
05 - custom french
10 - default chinese
99 - klingon


I have no public online storage for posting up accompanying pictures or attachments, so please refer to the previous links for pinouts and connection details.
Essentially you just need to connect up the 3,3v and 0v, an RX serial connection from your designated ESP TX pin, plus either the speaker pair, or left and/or right audio output to an external amp. The JQ6500 can be quite 'juicy' in operation, so ensure it is operating from an adequate 3.3v power supply, and make sure to link the JQ6500 and ESP 0v together.

The ESP_Basic script uses serial2 for communicating to the JQ6500, so you can assign alternative serial pin(s) if you wish... the script is not looking for any responses, so a 9600 connection from the assigned ESP TX pin to the JQ6500s RX is all that's required for our purposes.

It is useful to connect an LED with limiting resistor from the JQ6500 'Busy' pin to 3.3v. The normally low 'active high' Busy signal will cause the led to remain lit except during the time it is pulled high when playing an audio file, so it gives a good idea of what's happening and when.

The Busy pin could also be fed back to one of the ESPs digi-inputs to prevent it from sending any new announcements until the previous announcement is finished, but I haven't included any software facility for that yet because it would require some form of FIFO buffer, which will probably involve using arrays, which is something I haven't tried in ESP_Basics yet.


Stand-Alone version - How To Use
To announce (ie: play) the specified 'vfile' from the specified 'vdir' folder, the following command is used...

serial2println chr(vstart) & chr(4) & chr(vfiledir) & chr(vdir) & chr(vfile) & chr(vend)

The script already initialises vdir to the '01' folder, so if that's where your specified audio files are located it is not necessary to keep redefining 'vdir' before each use, therefore its only necessary to change 'vfile' to specify the file number of the required audio file.

Eg: assuming you have a folder on the SD card called 01 which has 001.wav, 002.wave, 003.wav and you wish to play 002.wav, you would use...


So each of your trigger event subroutines might look something like...


(ESP_Basic will ignore leading zero's from numbers, therefore it doesn't hurt to include them if it helps be consistent when specifying the appropriate 3 digit filename numbers)


StandAlone Code



EasyNet UDP version - How To Use

* Assume your Voice Announce node is called "Voice1" and has a folder on its SD card called 01 which contains files 001.wav, 002.wav, 003.wav.
Let's say you wish a networked nodes triggered event to cause event message 002.wav to be played, the udp command for your event-triggered node to issue would be...
Voice1 ANNOUNCE 002

* Assuming you may have several EasyNet Voice Announcer nodes - all members of the default "ALL" group - you could cause all to play the same message using...
ALL ANNOUNCE 002
(other non-Announcer "ALL" group members would ignore the unrecognised command)

* If you wish to test the node locally (from the Broadcast message window) you could use... "LOCAL ANNOUNCE 002", similarly for any of the nodes recognised udp commands, such as "LOCAL SETVOL 20".

* If you wish to use a different message set in a different folder you can effectively specify the required folder by sending a "VDIR (number)" udp command - eg:
"Voice1 VDIR 02" which would set Node1's message folder variable 'vdir' to "02" for all subsequent ANNOUNCE messages. The event message numbers still need to correspond of course - so event 005 would still play a relevent message 005 - but it might now be a customised message, or perhaps even in a different language if wished.

* Alternatively you could change folder by using the "DIR>" and "DIR<" network commands, but be aware it's an easy way to cause problems by pointing to non-existing folders and files.

* If you do get things wrong you can try sending the "VOICERESET" command - eg: sending "Voice1 VOICERESET" would cause Voice1 node to reset it's file, folder, and volume variables back to defaults (vdir=1, vfile=1, vol=15).

* You can remotely change the volume by issuing the "VOL>" and "VOL<" commands, or alternatively use "SETVOL (number)", where number is between 0 and 30 (midvol=15).

* For completeness, I've created a 'VFILE' udp command (to accompany the VDIR command) for allowing remote setting of the 'vfile' filename variable - but I doubt it'll prove useful because the required vfile parameter would invariable be passed along with the 'ANNOUNCE (vfile)' command anyway.

All such new 'Voice Announce' commands mentioned above have been added into [LOCAL_COMMANDS] along with an appropriate subroutine [BRANCH] for the command to jump to when recognised, so adding/removing/modifying any recognised udp commands is a simple matter for others to do likewise if wished.

And finally - the Voice Announcer functionality does not impede the Relay functionality. Therefore I have included a 'goto [CYCLEON]' relay command in the [ANNOUNCE] subroutine to cause announcements to CycleOn the Relay for a few seconds then Off again (according to the CycleOn defaults). This offers a visual indicator of announced messages if wished, but is easily commented out if not required and you prefer to retain independent Relay control.

Network version code

Interesting project a lot of careful thought put into this.

It would be excellent to experience this audio visually as some may not have the same minds eye not to mention it would be the same as putting a name to a face. To see a video of this rolled out would be most excellent.

To sum it up the Voice Announcer is based off of events that happen to trigger specific audio files to be played to voice announce what has or is about to happen depending on the users integration and positioning of the said audio trigger vs the triggered event if I am understanding this correctly.

Some things that come to mind as possibilities:

- Bluetooth Module Interfacing
Interconnecting this with a bluetooth audio module that would allow play to other bluetooth based devices such as speakers or phones a local solution.

- FM transmitter Interfacing
Simply hook up a whole home FM transmitter to the output and use cheap small simple FM radios to play what is happening locally to limit the number of wires and difficult setup of whole home audio wiring.

- Internet Broadcasting
Audio output of the MP3 player to audio input of a small low power computer such as a pi based computer and the ability to host a radio station. From this what is happening could be heard via audio on the broadcasted network from wherever you are via any internet connected device. This could be both local and remote for those looking for a remote solution.

Other thoughts couldn't there be a handler to solve some of issues or a newly developed board? For instance are we sure there is not a board made with an amplifier that is integrated for the hardware issue of level of sound and could the sound not be limited by software control? Finally seeing as how the sounds are triggered by software would it not be safe to say unless we make a mistake in selection of audio file we really should not be selecting something that does not exist but for good measure could not one create an array of accepted requests manually seeing as how there is no rx capabilities before sending the request to ensure no miscommunications occur causing the unit to have a need of power on/off?

Yeah, you grasp the idea ok, forlotto, and thanks for showing an interest.

It could be used wherever you might like audio notifications - whether for home automation, a security system, verbal compass or weather alerts etc, or perhaps just a personalised speaking clock, or an unusual talking gizmo.

As you said, the user could additionally interface to it however they wish, which is entirely up to them. Or they might just announce local status... perhaps the changing of a roomstat setpoint temperature, or warn of an overheating situation.

The possibilities are limited only by imagination - I'm converting an ex-ambulance into a camper, and much of the internal lighting and other systems will be controlled by a gaggle of ESP-Basic devices, including some outside PIRs which will cause internal verbal alerts if anyone approaches the vehicle too close for too long (we were gassed and robbed in our sleep in Spain a few years ago and I don't intend to let that happen again).

I included the udp version because I'm working towards creating a distributed ESP_Basic automation system over wifi to replace my existing security/automation system - which currently uses half a dozen mixed PIRs beam-breaks and magnetic door contacts to trigger appropriate alert announcements in the places where we are likely to be (lounge, kitchen, bedroom, office, workshop, garden). So we hear announcements of approaching visitors or trespassers or other notifications wherever we are.

That's why I've been developing the 'EasyNet' common framework configuration for UDP networking, it's over-kill for 2 node interaction, but it will be very useful for a dynamic fault-tolerant multi-node interactive system. It may not be of interest to anyone else at the moment, but I keep publishing things anyway on the off-chance that maybe some day someone on the same wavelength might be glad of not having to invent the same wheel for themselves.

As I said, I don't have any publicly hosted storage for uploading to, cos I'm very old-school and have nothing cloud-based for hackers to target, nor any social-media pipelines tapped into my jugular. But if someone with online storage was to PM me their email address I'd be happy to email some sample audio files and pics (and perhaps even a video) to link to from the article.

The JQ6500 is actually one of the better audio modules I've tried, and like anything with lots of options it is basically a matter of if it is used properly, so any mentioned issues pretty much come down to a GIGO situation (if you put garbage in you can expect garbage out). But it's very good when driven properly, which is quite easy to do when given the benefit of someone elses hindsight pointing out a few tips and gotcha's.

I'll tell you what upload a zip with all the information without registration here http://www.filedropper.com/ and share with me the link. I will see to it that you get the links to post to your project page. Upload audio, video, and pictures and I will post them in the appropriate spots and give you the live links.