Suggested changes, firmware part 4: alerts

Well, this has taken a while to get to, but these are the last of the changes I'd actively contemplated when considering the fork. And they are the next thing I'm planning on working on.

We have a test build that lets you add an audio playback module. The end goal is to provide voice alerts for both telemetry and channel values, which means it 's going to need a couple of changes.

First change - hardware.ini will have an audio setting. This is already in the test builds. Since the audio code uses the trainer PPM connection to communicate with the audio module, any model that uses PPM in any way - either as an input or the output protocol - won't be able to use the audio module. That having it on the line doesn't interfere with the PPM functionality also needs to be checked.

Second change - the sound.ini file will be enhanced to include an optional file name as well as the current set of notes to play. Editing this needs to look at the files available, which depends on the audio module.

Third change - any setting dealing with playing a sound will be extended to let the user pick a sound from the sound.ini file by section name. Volume setting may move into this as well, ignoring the volume setting in the file. This will give us the current behaviors except with a better ability to select sounds.

Fourth change - we need a merged list of telemetry (and Tx voltage) and channel values. This is so we can make alerts from them. Since we've had a number of requests for the telemetry values to be available in the channel list, adding all of those to the channel sources seems like the right way to do it.

Final change: And now it's simple: the Telemetry page changes it's name to the "Alerts" page, and changes the test setting to include an "=" value so you can get center beeps on dial inputs and the like.

On the voice alerts is there going to be a way to assign voice announcements to switches? Like for example for APM/Pixhawk boards which use multiple flight modes a way to assign to the switch/switches a voice alert to which flight mode is currently in use...So when the mode switch is flipped from one mode to another it announces which mode is currently selected?...Personally i don't use the telemetry on my tx i use the 3DR telemetry radios on my APM boards when flying with the mobile app it announces flight modes ect on my phone but i don't always fly with it, so it would be nice to have the tx announce the modes...

Yup. That's why telemetry values and the sources list are going to be merged. You'll be able to select either a switch input or the output channel that controls the mode, and have a warning play when it goes on. But I do need a "play once" option.

This sound all very nice with the Telemetry to spoken Voice Part.
Thubs up !

Great Idea general alerts page ! buzzer, vibrator or mp3.
Select whatever source you want to trigger an alarm, a flip of a switch, a telemetry value, a Tx bat voltage, or a lowest lipo cell alarm , possibly even a timer ?

However still I wonder if still do not need a telemetry configuration setup ?.
For instance you do have an RPM sensor and want to adjust the nr of poles or blades?
You have Volt and Amps and want to display Watt?
You want to display Mah used ?
Also the keep the min/max telemetry values of each flight and store a counter for alerts, such as RSSI below threshold etc.
Were to display that?

I suspect a lot of the telemetry config stuff is protocol specific, in that some sensors can do this stuff for you or the settings depend on it. The telemetry test page rewrite might be a good place for it if there's anything that's type but not protocol specific.

However, the mechanism for doing arithmetic in deviation is the mixer. This change would merge the telemetry values with sources in the mixer, so you could do arithmetic on them to create virtual channels that have adjusted values, and then display those adjusted values on the main page and use them in the alerts. Watts is easy given volts and amps. The mAH total should also be possible, but range is an interesting issue.