Voice alerts test build

yes it helps thanks...I will see about finding a text to voice generator and save the files as mp3s ..basically i just want the flight modes for APM as well as the current timer alerts ect..

I've been thinking about the SPI approach, and I don't think it would be all that bad. After all, we're not transferring data over the lines, just the "start playing file #" instruction. Or has the focus shifted away from the DF Player while I wasn't looking, in which case what are you using? You could even use the digital IO pin used by the existing buzzer as a chip select line for it, and have audio files of beeps if you really wanted that.

But the point is moot unless we can find an audio module with an SPI interface. Anyone got one?

Personally i think the DF player is the best choice currently as it is small and cheap ..

Yes don't change it, I just bought five of them to put on three devo TX (always have spares, you never know, waiting for the snail mail sucks )

Technical Specifications:
1, supports sampling rates (KHz): 8 / 11.025 / 12/16 / 22.05 / 24/32 / 44.1 / 48
2, 24-bit DAC output, support dynamic range: 90dB, SNR support: 85dB
3, fully supports FAT16, FAT32 file system, maximum support 32G TF card, support U disk to 32G, 64M bytes NORFLASH
4, a variety of control modes are available. IO control, serial port, AD button control mode
5, radio spots language function, you can pause the background music being played. Advertising finished playing background sound continues to play back
6, the audio data is sorted by folder, supports up to 100 folders, folders can be assigned to every 255 Tracks
7, 30 level adjustable volume, six adjustable EQ

See point 4, is it not allready possible?

Here is a crazy idea to throw out here...What if we could add a mic to the tx and simple record our own voice alerts by simple selecting what option we want on the screen and holding a certain button or buttons and speaking the voice alert to assign to that function..example> setting up a gear switch for flaps in the mixer select voice alert hold trainer switch ect and speak what you want to be announced when gear switch is flipped...

We already have support for multiple player types - the first version used the adafruit audioFX board. Adding another one wouldn't make the dfplayer support go away, it would just make it possible to use both audio alerts & PPM at the same time without doing an mcu upgrade.

We're currently using serial mode. It needing a serial IO pin is the issue we're trying to work around.

AD Key mode uses the voltage levels on two analog inputs to simulate 10 different keys on each pin. That lets you play 14 tracks, but requires both pins to do so. It needs two DAC output pins rather than one serial pin. This makes things worse, not better.

IO mode is just two pins that play the next track and the previous track, respectively. You could make this work with one digital IO pin, but implementing soft serial seems like a better idea.

The eemart board - similar to the dfplayer, but using a different player chip - has a "two-line serial" mode that uses a clock and data pin. It's close to I²C, but apparently not close enough to use the I²C pins - meaning you have to bit-bang the values out. Looks like it needs two or three pins as well.

The bit-banging approaches seem like a worse option than SPI, as they are slower protocols and hence you wind up spending more time sending the message.

Ok, these ( www.ebay.com/sch/i.html?_from=R40&_trksi..._nkw=WT588D&_sacat=0 ) look interesting. It's got an SPI interface that I was looking for. IIUC, it's also got 4MB of SPI flash on board for storage of WAV files.

You'll notice four different modules listed. There's a 16P version about the size of the dfplayer. There's a U version about twice that size with a USB connector. Far down the page you'll find a 28P version that's just a bit smaller than the U version, but no USB connector. Finally, there's a programmer module. The 28P version just exposes more IO pins for more flexible operation, and isn't really of interest to us. The programmer has a socket for the 28P or 16P version and a USB connector, giving them the same interface as the USB version. Downside is that the USB interface doesn't seem to be a flash drive, but some magic interface that they expect you to use their software with. Upside is that the interface has been hacked, so we can potentially run it on the Tx, meaning you won't need to access the module to upload voice data into it. You will probably need their program to prepare the data, though.

Timing issues: The existing buzzer audio already does a lot more SPI IO than this would do. When it plays a sound, it opens the sound.ini file and reads it from the SPI flash card to get the beep sequence to play. My code avoids that, just telling the audio module "Play file #". Data logging also happens to the SPI flash drive. However, this uses a different SPI interface than the RF modules. I'm not sure how much difference this makes. One possibility is that we might be able to use the flash SPI lines for this instead of the RF module one, but that might create problems for data logging instead of the RF modules.

I'll probably order the USB version (since it can also use the flash interface) later this week to play with.

It seems the largest flash for the WT588D module is 32Mbit (4MB). That is kind of small considering it only supports wave format. If we use 16bit 22KHz sampling rate, that's less than 100 seconds recording. Is there a version that uses SD Card?

BTW, I think we may have an unused serial TX pin on the Devo 10. PB's Devo 10 Wiki says GPIOD Pin 8 (PD8) is used for LCD, but I couldn't find any reference in the code. Can this be a typo on the doc? If it's available, PD8 can be used as USART3_TX.

AFAIK, there's no SD card version. I believe the USB version can play sound from a usb mass storage device, but didn't really check as that's the biggest module and would need even more stuff to use it. On the other hand, why are you using a 22KHz sample rate for voice? Half that is more than adequate, and the low end of the chip (6KHz) isn't unreasonable, being about what you got with a POTS line. And seems like you're assuming stereo, as they claim 1000 seconds at 6KHz, which would make everything the numbers line up. But this is why I set things up for more than one audio device type - you can pick the one that best meets your needs.

PD8 is a data line in the STM32's external memory controller, which is used to talk the LCD controller/memory. So it wouldn't be mentioned explicitly, but instead via references to the FSMC hardware.

The example I quoted is mono with assumption of lpcm format. Going to a-law or u-law encoding, the size can be cut into half, recording duration will increase to 200 seconds. With 22KHz sampling rate, you will get good quality audio. If you lower it to 11KHz, you will notice voice quality degradation even on a crappy speaker. With 8KHz, that is telephone line quality and voice will sound muddy. Anyway, it's good to have choice and people can pick whichever audio module they prefer.

Thanks for clarifying the PD8 pin on the Devo 10.

I'll repeat it here, as it is the main thread discussing adding sound alerts.

The problem with WT588 - SPI enabled sound module - is its implementation of SPI.

We started using SPI sharing for RF modules and SPI flash memory for devices without its own memory or small memory - Radiolink AT9 and Devo F series. This works because memory uses high speed clock and short packets - in microsecond range. We use simple strategy - disable interrupts for memory access while CS is low. RF modules use timer interrupts for their workload, so they can't be interrupted, while delay because of memory operations is negligible.

While it's true that WT588 does not require long transfers - one byte only - this byte can be very long. Recommended timing is a 2ms delay after CS goes low and then 60us per bit clock rate. If we use the same interrupt disabling strategy, it requires us to hold the radio packets for up to 2.5ms, which can be problematic - there are protocols with packet period of 4ms.

So, I'm aware of the need to extend TXs I/O but need to think about it a bit more. This timing is quite surprising, I only looked at the WT588 specs yesterday.

Thanks for bringing that up here. I'm not really up to speed on the STM SPI architecture, so forgive me for possibly obvious questions.

There are two different goals here. One is to have an alternative extra module that will work even if PPM is in use. The other is for adding something to the 4-in-1 deviation module. I haven't been able to find a description of that, but I'm wondering if it's going to include an mcu on it? And if so, which one? In particular, does it have a spare usart so we could use one of chips with a serial port connection, and there are a number of interesting choices. Beyond that, is it really feasible? The dfplayer (probably the best stand-alone module option so far) will drive a small speaker. Can that kind of functionality be integrated into your board? If not, then is there any point in trying to do this. V

The only good option for getting away from the trainer port seems to be SPI. We could use a digital IO pin and bit-bang seriat out on it, but that seems like it would have worse problems than a proper SPI implementation.

The only other audio chip I've found that could do SPI is the VS1000. Pluses: Plays ogg vorbis & mp3s, so even a couple of MB's should be fine: my original alerts used less than half a meg as .ogg files. I've already got one, as it's what the adafruit audiofx board uses. MInuses: some of the formats are licensed, which drives the cost up, so there aren't any small, cheap modules for it. Getting SPI out of it will require custom firmware on the module. I'm not sure this is worth the effort just to save the trainer port.

And a final question: if we can hook the WT588 up into the SPI bus used by the flash disk, could we drop the requirement that it disable interrupts for that 2ms interval? Would it be worthwhile to turn on CS for the WT588 and then set a timer interrupt and do the write when that interrupt happens? The only other thing on that bus is the SPI flash, which means it could interfere with data logging.

The DFPlayer, as well as a few similar boards, are based on the YX5200 24-pin chip which is part of a larger family of similar chips. The chip specs I can find show the SPI pins, but most of the detailed material is in Chinese (I think). Perhaps someone could examine this and the YX6100, YX9100/9200 chips. If anyone has the specs in English I'd be happy to do the research. From what I can tell, the chips are very self contained and with the addition of just the SPI flash, USB or SD chip reader you're good to go.

The finished boards (e.g. DFPlayer) use these lines for Flash memory but they don't expose them to the connectors. If they are too slow for our purposes that would be unfortunate.

These are not details of STM, but of physical limitations and corresponding implementation of the SPI bus sharing between low priority (but fast) memory acces and real time interrupt driven RF module.

Currently design of the add-on board verified in AT9 and worked on by Phractuedblue for Devo F is based on discrete logic.

I thought of using an MCU, but this complicates it a lot, so we first implemented the simple one. I'll publish it soon.

So far adding a slow SPI or serial or any other device seems to require an MCU.

I haven't found the XY5200 docs either, but the WTV020 chips are very similar, and have english docs. The chip themselves only use SPI for flash access, and can't use it for commands.

The VS1000 lets you rewrite the chip firmware, so we could fix that on those.

How about an I2C to UART bridge if we have I2C pins available? NXP have several available. It could probably be done with a small microcontroller too, like the old multimodule if that would be preferred. If a board for the bridge + dfplayer is needed, I would be happy to do the layout and prototyping.

I was looking at the pin assignments of the various TXs. PC10/11 is UART4 TX/RX. These are currently used by switches on the transmitters. Assuming that the are other available pins, couldn't those switches be relocated, thus freeing up UART4 for the voice mod with dfplayer?

On the u7e, I'll stick to the MCU pin solution that phantom8 has provided as PC10/11 is now part of the switch matrix, but for the other devos, relocating switches could be easier than looking for i2c/spi or even bit banging solutions. Just my 2 cents.

Also, I was wondering, does dfplayer need both tx/rx? What functions do we loose using only tx? Thanks!

First, the dfplayer just uses it's Tx line to send back a response to a command. My code ignored it; if your sound didn't play, your sound didn't play, no big deal. For an external voice box, this is required, since the trainer plug shorts the Tx & Rx lines together when you put in a plug, and we don't want to insist on a hardware mod in that case.

I looked for and didn't find any free I²C pins. That actually takes more pins than the serial or the SPI options, because we don't have any I²C going on, so have to find all the pins for it. Well, except for the F12E, which uses i2c to talk to it's lcd. Rather than trying to do a bridge, I there are chips/modules that have an I²C command interface.

As for relocating switches - yeah, we could do that. But we'd have to support both versions, and - well, it gets ugly. Sufficiently so that just living with not being able to use voice alerts if you're using PPM input or output is probably the better alternative. I do have a plan (I have to many plans, so many will probably never happen) to try moving switch config info into hardware.ini. If we did that, then relocating a switch would be a matter of editing hardware.ini instead of a custom build. That would make it possible to relocate the switch if you wanted to, with no software support needed. Ditto for adding switches, buttons, and all the stuff going on for the u7e build.

Yeah, you do have many projects running... lol.

I want to look at the hardware.ini stuff too, first block for me was the sequence that it gets loaded, which you already know about. Gotta find some time to look at that, then it might be easier configuring pins from there.

Thanks for the info about the tx/rx in the voice mod! Now waiting for a dfplayer in the mail.