Voice alerts test build

Firmware and Emulators are yet again updated (MP3s and music.map are unchanged)

Changes:

• Timers will now readout time with hours/minutes/seconds
• Stopwatch timers will alert in 1 minute intervals from 1-6 minutes, in 2 minute intervals from 6-10 minutes and in 5 minute intervals above 10 minutes
• Minor cosmetic change in Music menu: if "none" is selected the button function on color screens will disable (as in other menus)

I decided against safety warning alerts, as they were without alarms before and I'd like to keep it at this for now as it is not extended-audio related and there maybe good reasons against doing so.

Excellent improvement !!! That adds a very interesting information during the flight.
But as I am never satisfied why not to have the same messages on the count down until the pre-alert messages ?

You are never satisfied, are you?
I offer a simple solution: the next build will allow you to increase prealert time up to 30 minutes if you have a need for it.

Anything else?

Moeder wrote: You are never satisfied, are you?

No, it's just because you have done a very good work and may be it could be a little improved

Moeder wrote: I offer a simple solution: the next build will allow you to increase prealert time up to 30 minutes if you have a need for it.

It is simple but If it is interesting to have precision (and frequent messages) during a prealert time, the same interval would be boring during all a flight but information would be good . That is why your predefinite count for stopwatch would be in my opinion good for count down, automatically before the prealert count.

That would add quite some announcements, which would probably need a more thorough configuration in general for timer alerts (which actually would be some major gui work especially for color screens. I do not have time for this currently to be honest.
In my opinion the next major revision would include a music menu with submenus for switches, telemetry and timers with each submenu having more options (like choosing between buzzer, mp3 or both, customizable timer alerts and stuff like that). But I feel if we have this running it would actually be preferable to have the current setup, which is IMHO very usable, running smooth and being well documented.

Especially documentation is something needing more improvement, which also people without programming knowledge are able and invited to do (deviation-manual on github and the wiki). For voice alerts we would need to add a chapter to the manual, update the stuff we included in the transmitter menu and the wiki would need a nice entry with instructions to installing an audio player (most likely DFPlayer, as it's cheap). Then some nice MP3 sets in multiple languages, translations of the new menu entries and after that we're ready for the next steps

Moeder I like your work and the way its going. thank you.

I agree with you.
The present status is very satisfying.
Improvements can be left for the future, A not too far future, I hope
You mention translations in multiple languages for the mp3 sets. i agree. A suggestion . Once multiple languages sets will be set up, It will be more difficult to change them. That's why I suggest, it it is possible to leave some free entries in the global alarm set. there are for the moment 2 (10 and 12) but there could be a kind of stock of free message disponible for future development which would not oblige to a change all the numbers of the custom messages if a global message is added.
Can you give the link to the deviation manual and the way to propose a text. I would be interested in participating to this if I can (in a french version because my english is poor !)

Don't get me wrong, I'm not hunting for compliments although they are nevertheless welcome

Leaving some spare room for future preset alerts is a good idea, as this would prevent breaking compatibility in future releases. We have 20 alert messages so adding another 10 (or 20?) should be enough?

Remember, the IDs of custom messages can be anything you want (as long as it is starting at music.map entry 150. This brings me back to the idea of rather adding a group delimiter as in ini files like
to separate the two sets...


Concerning documentation:
The english manual is on github . You need to register at github (free), fork the repository, do changes and make a pull request for merging them. Documentation changes are easy enough to be made on the web interface and the markup language used is pretty self explanatory when looking at existing manual chapters.
There hasn't been a french manual since 2.0, so if you are really serious about doing a good and complete translation, we could extend the github repository to do translated builds as well (FDR, do you hear me ? )

For custom messages 20 free would probably be enough. This would push the first custom message to 171 if I understand correctly. Adding a group delimiter in the music.map would not add more possibilities as global are fixed (not for the message which depends from the mp.file but for the number of the file) and their number too. But why not if is seems clearer. Your first version making the first custom entry ot a 2000 had the advantage of leaving free development of the global ones but caused probably other problems.
As concerns this music.map , why not music.ini and put it in the media files ? just for congruence ?

As concerns translation why not ? I can try. But I need a precise " How to do", step by step.

I'm in the process of moving things to the ini format, as this will also use existing code and should make a smaller rom file. It will have the two sections as mentioned above, basically we can have any number of entries in each section (limited by a maximum allows due to memory reasons in the code, currently 240 by the way). The first 150 entries in global section will currently be used for the hard coded alarms, but could actually have any mp3 id we want. This is what I'm thinking of:


Concerning naming I was thinking of mp3.ini or extended-audio.ini, as it makes more sense than "music". Also, shouldn't we name the menu "MP3 menu" instead?

The "Marketing" voice in my head says we should call it "voice.ini" and "voice menu". I kinda feel like this is a big feature we haven't been able to offer up to now, and this is a pretty big feature. Other names may be technically right, and I am good with whatever works, but I like the sound of "voice"

Of course, voice is the most reasonable, so voice.ini it is! Placed in media folder or root?

Agreed. What about the entry in hardware.ini, do we stay with extended-audio=... Or should it also be voice=...?

Hi could I add an idea

Put an voice.ini in root with content; alerts=voice_EN.ini

in /media put voice_EN.ini; voice_FR.ini; voice_DE.ini ......

and then on the SD card (with plenty of space ) different directories;
/voice_EN
/voice_FR
/voice_DE

this let then a lot of flexibility, not even limited to language, but according to the mood change from a male to a female voice like in a GPS

Hope you get the idea, and that it does not require to much code.

@moeder, thanks for your efforts, improving this addon feature

This is not to add confusion. Voice or voices are a good name but may be confusing when speaking of changing voices in this case its changing speaker which is not the same than changing messages..I have not succeeded to find a 8 letters equivalent of vocal messages or voice messages. voicecom for voice communications maybe.

voice=... and voice.ini seems to be the most consistent to me as well.

While I was thinking about it.....at least on devo7e-256 we could possible use GPIO A4 as DAC out for direct audio output.....on devo10 this pin is used for AUX5 input...didn't look into other transmitters. Maybe voice=internal is realizable....