Voice alerts test build

mwm, it's not my intention to take over your voice feature. I just want a quick way to have voice feedback when changing switch positions before your final version becomes available. It's very likely my implementation is not the proper way or best approach. As I said earlier, if you find any of my work useful, use it. If not, just forget about it.

If I understand correctly, the sound ini file contains all standard alerts (pre-programmed) in the system. For me, I want the switches on each model to behave differently. For example, FMODE1 for model1 is to turn on Acro mode and it will speak "Acro Mode" once turned on. For model2, this same switch will speak "Switching to primary FPV camera" when model2 is active. These functions can't be determined in advance and we don't really know how many to pre-program. Of course, you can pre-define a bunch of user mappable alerts in the sound ini file, such as "switch_alert1", "switch_alert2", etc. But it will be hard for users to memorise which one is for which specific voice prompt.

Here is what I did. For each model file, users can optionally provide a switch alert file, such as the one below. These files will not be used by Deviation.

I've another utility on Mac which will process all these model alert files and use text-to-speech to generate a list of speech files. These speech files will be uploaded to the hardware voice module. The same utility will also generate another mapping file for each model. These mapping files contain the details on switch positions & their corresponding speech filename. The mapping files will be uploaded to the transmitter and used by Deviation. When Deviation reads the model file, it will also read in the mapping file for that model. It will then use it to play the corresponding voice prompts when switch position is changed. You can of course still have the standard system voice alerts, just like the ones you did already. BTW, I haven't touched any of the standard alerts.

Loving this idea ! Hope you're successful in quickly coding up some awesome things mwm
We can get sound files off the opentx / taranis people. I like their voice alerts

FDR wrote: Why not simply make a new section in the model.ini file, which could contain the codes or file names of the voice for all the switches you need?

[sounds]
FMOD0=normal_mode.mp3
FMOD1=acro_mode.mp3
RUD_DR1=throttle_hold.mp3

Currently, it's being implemented as a separate file. It's certainly possible to merge the mapping file to the model ini. Once I post my code, mwm can decide how to proceed.

Well, if you don't want to do it, that's fine as well. I just wanted to make it clear that I'm perfectly ok if someone else wants to take this code and run with it! I wrote it, but it belongs to the community.

My idea is to let users edit the "media/sound.ini" file to add new sections. Currently, the telemetry alerts are all called "telem_alarm#" for # from 1 to n. Instead of hardwiring the names in, the telemetry page would list all the sections in that file. So you could then add something like:

Then in the telemetry alarm section, you would select an = alarm on FMODE1 and the "acro mode" alarm. Hmm. As a first hack, the "=" comparison would only beep once, but eventually a "repeat" option needs to be added.

Note that this still has the old "beeps" info in it, so that if your audio player is disabled because you're using PPM (I understand that's not always the case now), it still plays something then.

FDR wrote: Why not simply make a new section in the model.ini file, which could contain the codes or file names of the voice for all the switches you need?

[sounds]
FMOD0=normal_mode.mp3
FMOD1=acro_mode.mp3
RUD_DR1=throttle_hold.mp3

The problem here is that the player interface doesn't use file names, or requires magic coding in them. So you really want a layer of indirection in the interface which lets the user pick a name that is then mapped to the right file. I also expect that most users wont' be soldering to mcu pins, meaning the audio Tx line will be shared with PPM input/output, so there ought to be a way to associate the sounds with a fallback to the buzzer stuff.

mwm, it's obvious that we're using completely different approaches. Yours is more elegant and I don't think there is much of my code that you can reuse. Anyway, I've completed my simple version of switch voice feedback and it's uploaded to Github.

Here is a video of the switch voice feedback in action.


If anyone is interested in testing it out, you can obtained it from github.com/phantom-8/deviation/ under branch extended_audio. There is a utility named genspeech which will automatically generate mp3 speech files for you if you have access to a OSX machine. The utility is under "osx" directory. Here is the usage instructions.

that's some really nice work bud!

FDR wrote: The fallback is reasonable in case of the PPM line, but there was talk about using some other UART or even SPI for the voices.
BTW I like your idea about the sounds.ini, and the extension of the alerts in general, but I would hesitate to use up the PPM line for that...

Well, my last builds uses the PPM line because that's what's available! IIUC, phantom8 is doing this on an ultimate7e build and is comfortable soldering to mcu pins. Some of us aren't comfortable doing that, which makes the PPM line the only real option. AFAIK, there are no unused board contacts on any of the Tx's that are serial lines. I haven't checked, but it's possible that some of the transmitters don't have an unused serial line available even as an mcu pin, but it would surprise me. But if I get back to this, I'll certainly make sure to make the pin part of the hardware configuration.

The other nice feature of using the PPM line is that you can put the audio board, speaker and battery in an external box and just plug it into the trainer port.

Fantastic Guys, this rocks !
Personally I would prefer as short as possible notifications, like armed / disarmed, Horizon, Stabilized, Acro etc
Instead of Acro Mode Activated, but that's all personal details excellent !

mwm wrote: AFAIK, there are no unused board contacts on any of the Tx's that are serial lines. I haven't checked, but it's possible that some of the transmitters don't have an unused serial line available even as an mcu pin, but it would surprise me. But if I get back to this, I'll certainly make sure to make the pin part of the hardware configuration.

The other nice feature of using the PPM line is that you can put the audio board, speaker and battery in an external box and just plug it into the trainer port.

I've checked the MCU pins for Devo 10 & 7e. Devo 10 has no unused MCU pin for UART transmit. Devo 7e only has UART5 transmit after upgrading MCU. The stock 7e MCU doesn't has UART5. I didn't check for other transmitters.

I'm a bit curious about the future of the voice alert function. Do you have any plans to resume your work? It's fine if you still haven't decided.

phantom8 wrote: I'm a bit curious about the future of the voice alert function. Do you have any plans to resume your work? It's fine if you still haven't decided.

Yes, I'm still planning on doing this. But my health hasn't really been up to coding for a while.

Is there any interest in just adding the existing functionality - playing audio files in place of the existing alerts - by itself? That would be mostly dealing just getting the code move into a git repo, and would make a good starting point.

mwm wrote: Yes, I'm still planning on doing this. But my health hasn't really been up to coding for a while.

Get well first before doing any coding. Health is the most important thing. The reason I asked was 'cos I spotted there are some issues with the existing voice alerts, such as wrong alerts are being played, haptic sensor is disabled, etc. I think I'll try to resolve those.

Is there any interest in just adding the existing functionality - playing audio files in place of the existing alerts - by itself? That would be mostly dealing just getting the code move into a git repo, and would make a good starting point.

Not sure what you mean by getting the code move into a git repo. I thought I had already moved your code to a git repo and gave you the link. Sorry if I misunderstood you. English is not my 1st language.

phantom8 wrote: I've checked the MCU pins for Devo 10 & 7e. Devo 10 has no unused MCU pin for UART transmit. Devo 7e only has UART5 transmit after upgrading MCU. The stock 7e MCU doesn't has UART5. I didn't check for other transmitters...

Hi, thanks for all your work so far!

I have a u7e but was planning on making my D10 the one I installed the DFPlayer in when I saw serial comms from it to the MCU was a possibility but now I read this, so you're saying there is no other possibility of using a UART on the devo 10 without using the PPM trainer port?

I only have one module in mine (I removed the stock devo module and installed CC2500), are any of the spi pins used for modules another UART port I could do a custom build for?

Custom build wise, what would I have to give up to save my trainer port (specifically the ppm input) I often use?

Using the PPM port for audio doesn't disable the PPM port. In fact, it's the other way around. If your model uses PPM and you're using the UART used for PPM for it, then the voice alerts will be disabled.

phantom8 wrote: Get well first before doing any coding. Health is the most important thing. The reason I asked was 'cos I spotted there are some issues with the existing voice alerts, such as wrong alerts are being played, haptic sensor is disabled, etc. I think I'll try to resolve those.

Not sure about the haptic sensor, but that's certainly possible. "Wrong alerts" could be the odd way the file system is built. My code used the "Play by number" feature of the audio cards, so if the wrong alert is being played, it's because the file system was returning the wrong file. On at least one of the two audio cards I worked on, that changed if you moved files on the SD card. That's certainly got to change!

Not sure what you mean by getting the code move into a git repo. I thought I had already moved your code to a git repo and gave you the link. Sorry if I misunderstood you. English is not my 1st language.

No, you did. I just haven't checked it out because I'm not up to doing anything with it. If there were some interest in just that functionality, then getting that put together and issuing a pull request for it would be worthwhile. I'm just not sure that level of functionality is worthwhile.

mwm wrote: Not sure about the haptic sensor, but that's certainly possible. "Wrong alerts" could be the odd way the file system is built. My code used the "Play by number" feature of the audio cards, so if the wrong alert is being played, it's because the file system was returning the wrong file. On at least one of the two audio cards I worked on, that changed if you moved files on the SD card. That's certainly got to change!

Hmm, I don't think it's file ordering on the SD card. For instance, if you load a model with V202 protocol with rebind option enabled, it will first say "Your model is running out of power". Followed by "Your model has been bound" a few seconds later. Looks like the out of power message has been misfired. (I thought the "out of power" message is the BATT_ALARM, just realised it's Telemetry Alarm 1. Many of the nrf24l01 protocol, such as V202, CG023, CX10, etc, all playing Telemetry Alarm 1 when doing the Bind init. I think it's a mistake.) Another case is when your transmitter has been left idling for a while, it will keep saying "Goodbye", until you move the stick. I think this is 'cos the system is currently using the same alert for 2 different scenarios. Anyway, that's just my preliminary testing.

No, you did. I just haven't checked it out because I'm not up to doing anything with it. If there were some interest in just that functionality, then getting that put together and issuing a pull request for it would be worthwhile. I'm just not sure that level of functionality is worthwhile.

I can make a pull request on your original code to the main Deviation repo if that's what you want. IMHO, it just seems a bit incomplete atm. Anyway, it's your call. Just say the word & I'll make the pull request.

Cereal_Killer wrote:

phantom8 wrote: I've checked the MCU pins for Devo 10 & 7e. Devo 10 has no unused MCU pin for UART transmit. Devo 7e only has UART5 transmit after upgrading MCU. The stock 7e MCU doesn't has UART5. I didn't check for other transmitters...

Hi, thanks for all your work so far!

I have a u7e but was planning on making my D10 the one I installed the DFPlayer in when I saw serial comms from it to the MCU was a possibility but now I read this, so you're saying there is no other possibility of using a UART on the devo 10 without using the PPM trainer port?

I only have one module in mine (I removed the stock devo module and installed CC2500), are any of the spi pins used for modules another UART port I could do a custom build for?

Custom build wise, what would I have to give up to save my trainer port (specifically the ppm input) I often use?

@Cereal_Killer, I checked against PB's wiki on Devo 10 MCU pin assignments. If there is no mistake in the doc, there are no spare UART transmit pins left. As mwm has already said, your PPM will still work as it will disable voice alerts when active. If you really want both PPM & Voice alerts working together, I guess there is a way if you don't mind doing some hardware & software hacking.

Currently, UART4_TX (PC10) & UART5_TX (PC12) are connected to FMOD0 & MIX2 respectively. If Devo 10 switch connections are like the Devo 7e, that is, the switches are wired via connectors plugged into motherboard (I don't have a Devo 10 to check), you can disconnect the plug and freeing the MCU pin and use it for UART TX. You can then find another unused MCU GPIO Pin & connect it to the switch. Of course, you will also need to customise the software to handle the changes. This is kind of an ugly solution. FDR also mentioned there is talk about using SPI on 1 of those add-on boards, maybe that is a much better approach.