Er9x future development

[andrewju]

Mike,

Do you think it may be worth adding "S.Port device updating" feature to er9x? Of course, one will have to have bi-directional S.Port connection in order to use the feature. But it may be useful for some people living in EU.

[MikeB]

Clearly, not on the M64, not enough flash.
Quite complicated to do as we need access to the SD card for the file to update with, as well as needing inverted serial data with output control (which may be a diode!) at logic levels.

Mike.

[andrewju]

Quite complicated to do as we need access to the SD card for the file to update with,

This we can already do, as we're able to read models settings from SD, right?

as well as needing inverted serial data with output control (which may be a diode!) at logic levels.

And this should be pretty simple to do (instead of inverting only the RX line, we shall invert TX line as well and connect them together using a diode).

Clearly, not on the M64, not enough flash.

Ugh, I didn't think about the m64 issue (flash size). Yeah, perhaps it's not worth it... Those of us able to replace the Atmega chip will certainly find a way to update FrSky firmware, if needed.

[MikeB]

Just thinking about the "global voice alarm" idea I had, and this might just apply to some other things.
The general idea is to have some things that are in the general settings, rather than in every model. Why? Because there is only one general settings EPROM file, but an EEPROM file for every model. So, slightly extending the idea, we could add a small number of "global voice alarm" settings, so common to all models, but in each model have a setting that enables them, quite possibly individually.

So, suppose we have 10 voice alarms in each model, and an extra 4 common ones. You could use all 10 in one model, and enable the 4 common ones in the same model, while never using the common ones in any other model. Or you could use all 10 in each of 2 models, and 2 of the common ones in one of them and the other 2 common ones in another.
However, as soon as you find you need the same settings for a voice alarm in two models, you could put it in a common one and use it in both. This would save a bit on EEPROM usage.

Mike.

[jhsa]

Hmm, I think this will add confusion. It's the kind of thing that drives people away from the open source firmware. Voice alarms should be together with voice alarms. safety switches should be kept together, logical switches should be kept together, hardware configuration items should be kept together. it's called organization
For that it would be better to leave some voice switches in then, if you could move them to the end of the voice alarms of course.. At least all would be kept together..

But that is the way I would do it if I knew how

João

[andrewju]

Well, I think Mike could physically keep these parameters in the same section, so that voice alarms will stay with voice alarms. But 10 of them will be called just voice alarms, and another 4 will be called global voice alarms. Any change to the last 4 will affect all the models, except for an extra switch to enable/disable each of these 4 alarms for a specific model.

This may only seem complicated at the very beginning. Once that is understood, it will become another great feature of the firmware!

[jhsa]

Not possible to keep them in the same section as the voice alarms are set per model. That means the same settings would have to show on every model..
I think it is a step backwards. And another feature to be removed in the future.
The tendency has been since the beginning to have the settings available on a per model basis. Example, the new excellent idea from Mike of having custom stick names per model. This is the reason why the open source firmware is so flexible. You use a switch for a global setting like the backlight for example, and you can forget that switch for using it on a model unless you don't mind the backlight coming on when you retract the gear on your model.
The same with global voice alarms. Apart from global system alarms ( which are harcoded anyway) I don't see any good use for them. Once you use a switch on one of them that switch is locked to that function on all your models. GLOBAL is not good and it has been like that since the beginning. Even the known brands are drifting away from global settings.
As I said above, in my opinion keeping some voice switches (with just switch capabilities without the logical part) mapped to the end of the voice alarms menu would be a better idea, keeping everything tidy and keeping the flexibility. Change their name to "Simple Voice Alrams" for example. .
By the way, could the backlight control be made available on a per model basis as in ersky9x;)

Thanks

João

[MikeB]

Yes, I could show them, and allow them to be edited, on every model, I've done this with other things before.
If such global voice alarms each have an enable on each model, then you aren't dedicating a switch for all models. If the voice alarm isn't enabled for the model then the switch isn't allocated to that function.
If we had plenty of EEPROM I wouldn't be suggesting this, I'm trying to make the best use of what we have available.

If we have some (optional) common settings, it could make setting up a model quicker, you just enable a common setting rather than having to configure it in every model.

Keep an eye on the first post, I'm updating it with where I've got to as well as possibilities. I have currently got 10 voice alarms and 8 voice switches (ON/OFF/BOTH/ALL/ONCE), all in the voice menu.

I'll think about a backlight switch on the model. One of the biggest usages of flash is adding the ability to edit something! I keep looking for ways to improve this!

Mike.

[jhsa]

Mike, you're the one programming and obviously the last word is yours. I can only make suggestions and give ideas

Keep an eye on the first post, I'm updating it with where I've got to as well as possibilities. I have currently got 10 voice alarms and 8 voice switches (ON/OFF/BOTH/ALL/ONCE), all in the voice menu.

Oh, didn't know about that, that is great thanks. That should be more than enough. Use the voice alarms for alarms and speak telemetry values, and the voice switches for speaking the switches functions..

I'll think about a backlight switch on the model. One of the biggest usages of flash is adding the ability to edit something! I keep looking for ways to improve this!

Mike.

Thanks, as we know, using a switch for the backlight we lose a switch for all the models unless we don't mind the backlight switching ON of course
Thanks
João

[MikeB]

Regarding the backlight switch, you could assign a logical switch to it, then, in any model set the logical switch to be a physical switch (e.g. AND AIL AIL). Now you lose a logical switch (of which we now have 18) in each model rather than a physical switch.

Mike.

[jhsa]

It works, and it is a very clever way of doing it, but.... Workaround
Unless you keep teaching people how to do it over and over again, no one will ever know that they can do it

It would be nice if you did implement it, but in case you don't this example is on the list of additions to the next revision of the manual..

Thanks

João

[MikeB]

Gvar adjusters look like they need a LOT of flash, around 1500 bytes. They can be added for the '128 and '2561, but almost certainly not on the '64.

Mike.

[jhsa]

Thanks for adding them. Well for some reason some of us changed the CPU, right??
What about RAM?
João

[MikeB]

I thought 1500 bytes was a lot, I'd copied the code from ersky9x and left several values as 32-bit (fine on a 32-bit processor) when they should now be 8-bit. The added code is now only 938 bytes!

Mike.

[jhsa]

I'm looking forward what surprises the new test version (or should I say the first mbTX test version? ) brings..

João

[MikeB]

RSSI alarms. Currently the RSSI alarms are implemented to use the "beeps" in a FrSky DJT module. This was OK, but with the XJT module and the use of other modules, this is now out of date.

Proposal:
1. Remove all use of the DJT RSSI alarms. eepe has a facility to set or disable DJT RSSI alarms using the serial connection on the rear of the module.
2. Add two configurable Rx RSSI values "low" and "critical". If voice is not configured then you get some beeps, if voice is configured then the appropriate voice file is played.

Mike.

[jhsa]

That's wonderful.. thanks..
There are voice files already in the voice pack for these settings I think..
Mike, one thing I never understood. Why configuring the module's alarms if we can have the radio triggering the alarms in a much better way? If the telemetry mod wasn't necessary to configure the module's parameters I would understand. But it is necessary, correct? So those settings never made sense to me.
We currently have a setting to trigger the beeper in the module when RSSI is low but not an alarm on the radio? Never understood this
One of the reasons I kept asking for a hardcoded setting. I did think that the rssi setting worked like this but in fact it doesn't

João

[MikeB]

Historical!
When the code was done originally we didn't have voice (or audio I think), so we couldn't do any better than beeps. It seemed a good idea therefore to be able to set the options on the module. Things have clearly moved on from there.

Mike.

[jhsa]

In other words, since the radio is able was to produce audio alarms that this setting along with the A1/2 Red, Orange and yellow alarms is a waste of space in the firmware
Funny that I don't remember ever using it, and I'm pretty sure that I started using er9x when the telemetry was implemented, or even a little before. Actually well before. I still have all the first binaries on my HD.
My first er9x binary - er9x_r153.hex Was this just before you started working on the project?
My first er9x Frsky - er9x-frsky_r537.hex

Good times.. Every single day was just like Xmas. new features, sometimes a couple times a day..

João