MultiWii

While adding new gadgets to my copter, I noticed the way AUX switches (and the associated subsystems) are handled is quite inflexible.
When adding a new gadget you want to be able to trigger using your TX, you have to add the necessary code to both the copter firmware as well as the GUI - as well as any other GUI in existence (Android, WinGUI etc.).
The other alternative encountered here is hardcoding the function in the code, which is awkward in its own way.

In my opinion, the fixed number of aux switches and subsystem ("boxitems") should be replaced:

The GUI should have no knowledge whether there the copters do have systems called "LEVEL", "ARM", "CAMTRIG" etc., or how many AUX channels are present. Instead, the GUI should request this information from the copter itself.


The GUI can then be built from the copter responses as needed by the vehicle. For adding a new gadget, it would be sufficient to add the necessary firmware code without touching any GUI sources.
Configuration data can be exchanged using either the literal name of the subsystem or by using its index. Since the above dialoug will only occur when connecting the the copter, the overhead should be minimal.

Any ideas about that?

Decorrelating the GUI from the function is a nice purpose for future evolutions, but your idea seems to be quite complicated.
You will still have to associate a string name to an id somewhere. And id it's inside the sketch, I predict a non neglectable code size impact.
We have also to match reality: how many rc systems do you know that can already have 4x3 way switchs and could do more ?
If you must add a special module on the radio to be able to transmit 10 or 15 states via a channel, it's a very specific need.

For specific needs.
A opton could be a SwitchBox with a zigbee or some other serial wireless inteface who can send commands to MWii.

Alexinparis wrote:Decorrelating the GUI from the function is a nice purpose for future evolutions, but your idea seems to be quite complicated.
You will still have to associate a string name to an id somewhere. And id it's inside the sketch, I predict a non neglectable code size impact.

It would require 76 bytes in pogram space if the copter uses the entire array of systems that is now present in the GUI. I wouldn't consider that a big impact.

We have also to match reality: how many rc systems do you know that can already have 4x3 way switchs and could do more ?
If you must add a special module on the radio to be able to transmit 10 or 15 states via a channel, it's a very specific need.

The better question is: would the system benefit from the possibility of easily adding new systems and aux channels? I think that is the case. I'd love to have a switch for toggling my LED flasher, but I refrained from it because it would require me to change the GUI code as well - and since I am using the android configurator as well, I wouldn't benefit from it there. A generic pproach would offer much better possibilities for further developments.

some time ago we had someone suggest getting rid of the using 3 fixed ranges for each aux channel only and turning it into an 8 bit aggregated data like this:
use range 0-2000: so
+1000 - bit 0
+500 - bit 1
+250 - bit 2
... you get the idea.
With current TX/RX resolution this might be limited for only 6 or 7 bits, but it sounds like fun.
My dx6i could not handle it, but with the freely programmable t9x it would be a treat.