Making AUX switches more flexible

This forum is dedicated to software development related to MultiWii.
It is not the right place to submit a setup problem.
Software download
Post Reply
Tommie
Posts: 438
Joined: Sun Apr 08, 2012 9:50 am

Making AUX switches more flexible

Post by Tommie »

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.

Code: Select all

(this is a pseudo protocol)
# Request number of AUX/switch channels
GUI: AUX?
MWC: AUX! 4
# Request available subsystems
GUI: SUBSYSTEMS?
MWC: SUBSYSTEMS! (LEVEL, BARO, MAG, CAMSTAB, CAMTRIG, HELLFIRE,  AUTODESTRUCT)
# Get switch configuration with bitmask for each AUX switch
GUI: SUBSYSTEM LEVEL?
MWC: SUBSYSTEM LEVEL! (3,0,0,0)
GUI: SUBSYSTEM BARO?
MWC: SUBSYSTEM BARO! (0,4,0,0)


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?

Alexinparis
Posts: 1630
Joined: Wed Jan 19, 2011 9:07 pm

Re: Making AUX switches more flexible

Post by Alexinparis »

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.

PatrikE
Posts: 1965
Joined: Tue Apr 12, 2011 6:35 pm
Location: Sweden
Contact:

Re: Making AUX switches more flexible

Post by PatrikE »

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

User avatar
kos
Posts: 286
Joined: Thu Feb 16, 2012 4:51 am
Location: Fr

Re: Making AUX switches more flexible

Post by kos »


Tommie
Posts: 438
Joined: Sun Apr 08, 2012 9:50 am

Re: Making AUX switches more flexible

Post by Tommie »

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.

User avatar
Hamburger
Posts: 2562
Joined: Tue Mar 01, 2011 2:14 pm
Location: air
Contact:

Re: Making AUX switches more flexible

Post by Hamburger »

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.

Post Reply