[PATCH] Increase number of AUX channels

Tommie · Post by **Tommie** » Tue Jun 26, 2012 4:22 pm

Having a copter with a lot of gadgets and sensors attached, I consider the limit of 4 AUX channels an issue; it's simply not enough to allow smooth control of the various features.

Since CHECKBOXITEMS (and PIDITEMS partially) are already configured dynamically, changing the number of AUX channels should be easy as well.

I made this patch for the firmware portion of multiwii: https://github.com/wertarbyte/multiwii- ... x_channels

//edit [I'm still modifying the conf gui to process the new message for further testing, but strangely enough, the patch even slightly shrinks my firmware image from 26982 down to 26872 byte.]

Tommie · Post by **Tommie** » Tue Jun 26, 2012 11:53 pm

I also modified the MultiwiiConf GUI to accept the new commands and AUX matrix:

https://github.com/wertarbyte/multiwii- ... x_channels

So far it's working great (apart from the fact that the additional checkboxes are drawn above the GUI); while the firmware patch increases the number of aux channels to 8, the gui part is completely agnostic of it; the number can be changed to an arbitrary number, so feel free to give it a spin.

EOSBandi · Post by **EOSBandi** » Wed Jun 27, 2012 12:07 am

Tommie,
It's great, but currently only the SBUS RX supports more than 8 channels in the MW code, but for SBUS you need a second serial port... (not quoting the enormous prices of a 8+ channel SBUS system).
If we really want more options, then should try to increase the states of the AUX channels (LOW MID1 MID2 MID3 HIGH) but programming TX for it could be tricky....

Tommie · Post by **Tommie** » Wed Jun 27, 2012 5:07 am

Increasing the states for each channel ould be trivial as well. Just replace the constant 3 with another number and set the thresholds accordingly. My homebrew TX _does_ support more than 4 AUX channels (through serial data encoding), and I'd really like to use them; in my opinion AUX "switchables" should be considered detached from any physical radio channel, it is just a flag for controlling checkboxitems.

Those hesitating or without appropiate can still set AUX_CHANNELS to 4 and be done with it; as one with more flexible hardware, I'd love to see a more flexible solution introduced to the MWC codebase. It doesn't hurt smaller TX/RX combos and helps those with more channels.

palton · Post by **palton** » Wed Jun 27, 2012 5:30 am

I use a 6 pos switch (one potentiometer replaced with 6 pos switch) on my transmitter for AC2 flightmodes. That works good, at least 6 of 10 possible flight modes in AC2 can be configured from one single knob.

I think the same type of setups would be pretty nice for MW as well, as MW also starts to get a lot of different flightmodes available. I also feel its a bit limiting as is when you need to choose whats most important to control with aux. Recently I had to remove some functionality to be able to use passthrough, which I was trying for the in flight calibration. I really felt it was limiting with the aux.

Would be nice to be able to set threshold for each (position on the switch) mode within the MW code, so it's easier to match the values the potentiometer actually creates with the different values for each state (programmed function)a channel might have.

I would also like to see more flexibility of the aux part. I think it is limiting as today.

fiendie · Post by **fiendie** » Wed Jun 27, 2012 7:47 am

EOSBandi wrote:Tommie,
It's great, but currently only the SBUS RX supports more than 8 channels in the MW code, but for SBUS you need a second serial port... (not quoting the enormous prices of a 8+ channel SBUS system).
If we really want more options, then should try to increase the states of the AUX channels (LOW MID1 MID2 MID3 HIGH) but programming TX for it could be tricky....

If I ever get around to porting Tommie's Datenschlag code to th9x/er9x/open9x it suddenly becomes viable for a lot of people here

Unfortunately I don't have much time at the moment. So if anybody has ever done some mods to the firmware of his 9x, I'm glad for any help I can get.

Pyrofer · Post by **Pyrofer** » Wed Jun 27, 2012 12:23 pm

I have a cheap 6ch TX and it sucks. Tommies Funkenschlag code for the AVR replaces the chip inside with a better solution and includes the data transfer mechanism.
Currently I am building a from scratch TX using a PS2 pad and would love to see more support for features.
What would be perfect is a dropdown list for each feature to choose channel and 2 range boxes min/max for activating.
Maybe even a way to toggle them on and off, so moving aux1 high then mid turns ON a feature and leaves it on while going low then mid turns the feature off. You could then have aux 2 with 4 positions, one for each feature and use aux 1 to turn them on and off.

There are many ways of doing this, we don't want to feel limited by legacy solutions from the RC world.

The more simple and flexible the solution the better.

ronco · Post by **ronco** » Wed Jun 27, 2012 12:33 pm

Pyrofer wrote:The more simple and flexible the solution the better.

and you think that building a TX yourself or eaven solder avr's into a existing ones make thing simpler?

sorry to say but i really think such mods are good to be there for the small amount of "freaks" the like to tinker more then fly

... i dont think that this should be in the main software. 4 aux channels are enough to fly and have fun

this would make the gui eaven more complex and increase the code size..

regards Felix

Pyrofer · Post by **Pyrofer** » Wed Jun 27, 2012 12:41 pm

I meant simple and flexible IN SOFTWARE.

Ie, able to support as wide range of hardware as possible with as little configuration or manipulation of the code.

My TX, Tommies TX, a bog standard TX should all work and be usable with little work on software.

A well built framework for turning on and off 'features' will allow this.

Tommie · Post by **Tommie** » Wed Jun 27, 2012 3:45 pm

ronco wrote:and you think that building a TX yourself or eaven solder avr's into a existing ones make thing simpler?

No, but do you think artificially limiting the software to 4 AUX channels makes things simpler? There actually are receivers that support mre AUX channels - the only limiting factor is the handling in the Multiwii software. If you want to keep it simple, just #define AUX_CHANNELS 4. Leave those who need or want additional channels the choice of using them.

... i dont think that this should be in the main software. 4 aux channels are enough to fly and have fun

That's why there are a dozen custom receiver types in RX.ino, right?

this would make the gui eaven more complex and increase the code size..

Yeah, sure. Why not remove CAMSTAB/CAMTRIG/GPS/MAG/HEADFREE as well? That would reduce code size even more. The code is there. It's not significantly more complex than the previous code.

Tommie · Post by **Tommie** » Wed Jun 27, 2012 5:56 pm

palton wrote:I would also like to see more flexibility of the aux part. I think it is limiting as today.

You might be interested in this additional patch then:
https://github.com/wertarbyte/multiwii- ... x_channels

By defining AUX_THRESHOLDS, you can set an arbitrary numer of steps for each AUX channel.

palton · Post by **palton** » Wed Jun 27, 2012 8:55 pm

THX Tommie. Yes I'm interessted in that fix. Would be nice to be able to use the 6 pos switch i got installed. I will get free aux channels then for flightmode independent options :=)

When switching between MW and AC2 plattform I got the AC2 flightmodes at the 6 position switch and MW all over the place. I mix them up all the time. Would be great to have one knob for flightmodes, regardless of MW or AC2.

This would be a real improvement for me.

palton · Post by **palton** » Wed Jun 27, 2012 9:09 pm

btw, just saw there is a 6 pos switch announced at Diydrones atm (for sale at ebay), if somebody else is interested in reading about how to mod tx or buying one as DIY kit. Might be interesting for someone so I thought I put the link here as well.

http://diydrones.com/profiles/blogs/universal-6-position-mode-switch-for-any-tx

Pyrofer · Post by **Pyrofer** » Wed Jun 27, 2012 9:34 pm

Wow, I had one of those switches years ago ripped out of something random.
Good idea to put the trimpots on and use it for a 6 pos switch though.

I am just looking forward to playing with 4 aux channels!
Thanks to Tommie for the Datenschlag making my 6channel receiver capable of having 4 aux channels

Tommie · Post by **Tommie** » Fri Jun 29, 2012 12:16 pm

OK, I did some flying and experimenting with the patches, MWC works great with 8 AUX channels. Please consider merging it into the main code tree - maybe in some development branch for the next 2.2?

Tommie · Post by **Tommie** » Mon Jul 02, 2012 5:46 pm

Just one example what AUX channels might be used for:

AUX1: (none) / MAG+ACC / MAG+ACC+BARO
AUX2: (none) / HEADFREE+CAMSTAB / HEADADJ+CAMSTAB (so I can change headfree orientiation midflight)
AUX3: (none) / GPS HP / GPS RTH
AUX4: (none) / LEDMAX / LLIGHTS (to switch on illumination for flying in darker areas or at night)

You notive how I already combined CAMSTAB and HEADFREE, I'd also like to use CAMTRIG, but without additional AUX channels, this is requiring compromising - although there is clearly no technical need for it.

Tommie · Post by **Tommie** » Mon Jul 02, 2012 11:28 pm

Just rebased the diff: https://github.com/wertarbyte/multiwii- ... x_channels

Federico · Post by **Federico** » Tue Jul 03, 2012 11:35 am

EOSBandi wrote:If we really want more options, then should try to increase the states of the AUX channels (LOW MID1 MID2 MID3 HIGH) but programming TX for it could be tricky....

I think that this would be amazing.
For example I have programmed my turnigy for having 6 states on my aux channel then I discovered I could use just 3...

Tommie · Post by **Tommie** » Tue Jul 03, 2012 11:40 am

Federico wrote:
EOSBandi wrote:If we really want more options, then should try to increase the states of the AUX channels (LOW MID1 MID2 MID3 HIGH) but programming TX for it could be tricky....

I think that this would be amazing.
For example I have programmed my turnigy for having 6 states on my aux channel then I discovered I could use just 3...

As I said, my patchset allows both - increasing the number of AUX channels as well as increasing the number of steps. If you are interested in giving it a try, feel free to join our IRC channel #multiwii on Freenode, we're happy to help you with that.

Tommie · Post by **Tommie** » Wed Jul 04, 2012 1:40 pm

Just pushed a commit to make the new AUX channel system backward compatible: As long as you are sticking to 4 AUX channels with 3 steps each, you should be able to use old GUIs:

https://github.com/wertarbyte/multiwii- ... x_channels

Please feel free to comment.

jevermeister · Post by **jevermeister** » Thu Jul 05, 2012 12:39 am

If I may give my two sent here:

I use my Android phone to switch my modes.

I only have Aux1 and Aux2 I already coded a patch to use more states by applying the values for Aux3 and Aux4 to state 4 5 6 of aux1 and 2.

I noticed something while flying : This is very impractical even I I use my selfmade 6 State switch instead of Poti.

So I made myself some parametersets in Android Multiwii Configurator. Now I can switch between Switching setittings in a blink of an eye.
It is pretty versatile.

Set1
Aux1 OFF / ARMED / ARMED+Hover
Aux2 Mag/NONE/Baro+Mag+Hover

Set2
Aux2 RTH/None/PH

Set3
Aux3 Camstab/None/Camstab+PH+Baro+Hover

Nils

Tommie · Post by **Tommie** » Thu Jul 05, 2012 9:01 am

So your juggling with the TX and your phone while flying the copter? Doesn't sound very practical to me.

Why not give my changeset a try? If you already have a 6 position switch, it should be a breeze:-)

jevermeister · Post by **jevermeister** » Thu Jul 05, 2012 10:03 am

Hi,

I am landing to do that. It is not a big deal for me. I usually have to land anayway to equip the fpv cam and bigger props etc.

What I was trying to say is, that I was overwhelmed with all the controls on the switches. a 6 Position switch isn't the solution. I need distingt switches per funtion If you have 6 functions on one switch you will never now what are you activating or not. I did this with a poti a while ago - that was the reason I implemented the togglebeep ;-)

.

I am not into RX code - so it is not for me to decide wheter or not to implement your idea.

Nils

Pyrofer · Post by **Pyrofer** » Thu Jul 05, 2012 10:09 am

Sounds like you need something like my solution. I have reduced each Aux to a single on/off (mid/high) and have only one function per aux.
Thanks to Tommies code I can get 4 aux channels, so I have 4 switchable features.
This is not too hard to keep track of and gives a fair bit of flexibility.

I never liked the idea of 3 position pot/toggle with sets of config on it.

fiendie · Post by **fiendie** » Thu Jul 05, 2012 10:26 am

jevermeister wrote:Hi,

I am landing to do that. It is not a big deal for me. I usually have to land anayway to equip the fpv cam and bigger props etc.

What I was trying to say is, that I was overwhelmed with all the controls on the switches. a 6 Position switch isn't the solution. I need distingt switches per funtion If you have 6 functions on one switch you will never now what are you activating or not. I did this with a poti a while ago - that was the reason I implemented the togglebeep .

Nils

Some functions work well in a "cascade".
E.g. the MAG doesn't make much sense without ACC. So use a 3-way toggle switch with OFF => ACC => ACC + MAG.
6-position switches would be nice for stuff like blinking patterns for LED_FLASHER or things that are not "mission-critical"

Tommie · Post by **Tommie** » Sun Jul 15, 2012 7:53 pm

How about giving this a test spin now that 2.1 is released?
I've been using it for several weeks now (8 AUX channels), works fine for me; only the GUI needs some makeover to to the number of checkboxes.

Tommie · Post by **Tommie** » Sat Jul 21, 2012 1:15 pm

Just rebased the entire patch set to the latest code:
https://github.com/wertarbyte/multiwii- ... x_channels
https://github.com/wertarbyte/multiwii- ... x_channels
I'd appreciate any type of feedback. Having working patches lying around for weeks without any actual reaction feels quite uncomfortable.

msev · Post by **msev** » Sun Jul 22, 2012 1:25 am

I haven't got the hardware to test it yet, but I very much like the idea! Nice work!

Alexinparis · Post by **Alexinparis** » Sun Jul 22, 2012 3:09 pm

Tommie wrote:Just rebased the entire patch set to the latest code:
https://github.com/wertarbyte/multiwii- ... x_channels
https://github.com/wertarbyte/multiwii- ... x_channels
I'd appreciate any type of feedback. Having working patches lying around for weeks without any actual reaction feels quite uncomfortable.

Hi,
I hope this is constructive enough for you.

In the current implementation,
There is a 2x8 bit variable for each item, and 4 bits are unused per item.
First 8 bits: AUX1L AUX1M AUX1H AUX2L AUX2M AUX2H AUX3L AUX3M
second 8 bits: AUX3H AUX4L AUX4M AUX4H

In your implementation, you select the right number of 8 bit variable for the need.
But an item can share the same 8 bit variable.
It is efficient, but it is not very good to keep the compatibility with current implementation and you need to make a switch like:
if (4AUX and 3 states) then {complicated code to keep compatibility using MSP BOX} else {new code with new message using MSP AUX}
resulting in an unneeded flash consumption for legacy case + the need to differentiate 2 MSP messages type.

If you want to make a code really compatible, I think you must first:
1)assign the right number of 8 bit variables per item, even if it implies some bit loss at the tail.
2)fill those variables right so that the peculiar case of 4AUX+3STATE matches the current implementation
This way, you shouldn't need to differentiate 2 MSP messages type.

If you code this in an efficient way (need to evaluate: flash size difference and loop time difference), I promise I will merge it

Tommie · Post by **Tommie** » Sun Jul 22, 2012 3:20 pm

Alexinparis wrote:In the current implementation,
There is a 2x8 bit variable for each item, and 4 bits are unused per item.
First 8 bits: AUX1L AUX1M AUX1H AUX2L AUX2M AUX2H AUX3L AUX3M
second 8 bits: AUX3H AUX4L AUX4M AUX4H

I am aware f the current implementation.

In your implementation, you select the right number of 8 bit variable for the need.
But an item can share the same 8 bit variable.

Yes, I am saving the antire matrix as compact as possible.

It is efficient, but it is not very good to keep the compatibility with current implementation and you need to make a switch like:
if (4AUX and 3 states) then {complicated code to keep compatibility using MSP BOX} else {new code with new message using MSP AUX}
resulting in an unneeded flash consumption for legacy case + the need to differentiate 2 MSP messages type.

No. The compatibility is entirely optional and enclosed in one single commit; if you don't need it, don't use it. It is just a gateway solution to allow traditional GUIs that expect a maximum of 4*3 states to work, even though the backend has changed (of course only if you are actually limiting yourself to that number of states). Once GUIs have made the transition to the new message type (which is able to handle any number of channels and states), the compatibility commit can be reverted and the code can be removed.

If you want to make a code really compatible, I think you must first:
1)assign the right number of 8 bit variables per item, even if it implies some bit loss at the tail.

Why? What is the advantage of that?

2)fill those variables right so that the peculiar case of 4AUX+3STATE matches the current implementation
This way, you shouldn't need to differentiate 2 MSP messages type.

In the long run, MSP_BOX should be superseeded by MSP_AUX since MSP_BOX cannot handle any configuration other than 4*3 at all. Having both messages is a gateway, not a permanent solution.

Hamburger · Post by **Hamburger** » Sun Jul 22, 2012 4:51 pm

How many TX can send more than 4 3.way switches/states?

Tommie · Post by **Tommie** » Sun Jul 22, 2012 4:55 pm

The AUX channels in my ultra-cheap TX were analog pots. Replacing them with a 6pos switch should pose no trouble, probably even more steps are well possible.

Hamburger · Post by **Hamburger** » Sun Jul 22, 2012 9:38 pm

I understand your homebrew TX could do that, that's why you implemented that special code. Question is, how common is this with regular TX out there? As your code adds some complexity it is a question whether enough people would benefit to justify doing it.
The few regular TX I know have 3-way switches at most - I personally cannot imagine fiddling with a 6-way switch while flying - how was I ever to know or feel its current position?

Tommie · Post by **Tommie** » Sun Jul 22, 2012 9:52 pm

I'm only using 3 pos switches. But if you've read this thread, you might have notice that other people are actually using 6 pos switches. If you don't like using a 6 pos switch, don't use it. Stick to 3 states per channel, nothing is taken away from you. But if anyone else wants to use 4, 5, 6 or 20 states per channel, so be it. And the code isn't even more complex than the code that was present in the code base just a few weeks ago.

There are actually quite some people that enjoy using their 6pos switches: http://diydrones.com/profiles/blogs/6-pos-mode-switch

Hamburger · Post by **Hamburger** » Sun Jul 22, 2012 10:42 pm

Which tx ofcers 6way zwitching?
Your patch does not look simple. It does add complexity.
6 members like it?

treym · Post by **treym** » Sun Jul 22, 2012 10:45 pm

and ? do it alienate your personality to know that 6 members like it ? let them be

peace and harmony for all

Tommie · Post by **Tommie** » Sun Jul 22, 2012 10:50 pm

Any TX that has an analog pot connected to an AUX channel offers 6way switching.

And as I already said, no one is taking anything away from you. If you are completely satisfied with 4*3 AUX states, just keep using that.
Other people might want to have more options, and I'd be glad if Multiwii would offered them the possibility to use them.

palton · Post by **palton** » Sun Jul 22, 2012 10:54 pm

I use 6 pos switch, when flying my AC2. AC2 People either go with a 3 mode switch, when they have limited TX, otherwise they combine two switches and mix those for 6 pos (can be done by T9X with er9x sw which is kind of common radio nowdays, it can aslo be done on Futaba radios (not only high end). Prolly other radios can do it as well), or replace a pot with fixed positions, like a 6 position switch. It can be done on any radio, for the DIY interessted. So it's sure doable even with a simple radio.

AC2 got like 10 availble flightmodes (where 6 can be configured and controlled via one channel). I thinki MW is getting in that direction as well, getting a lot of different "flightmodes", as it looks like.

I would like even more flexibility in MW.

Alexinparis · Post by **Alexinparis** » Sun Jul 22, 2012 11:22 pm

Tommie wrote:Why? What is the advantage of that?

I wrote it: no need to consider 2 types of MSP messages

In the long run, MSP_BOX should be superseeded by MSP_AUX since MSP_BOX cannot handle any configuration other than 4*3 at all. Having both messages is a gateway, not a permanent solution.

This is not what I call "compatible"

Tommie · Post by **Tommie** » Sun Jul 22, 2012 11:34 pm

Alexinparis wrote:
Tommie wrote:Why? What is the advantage of that?

I wrote it: no need to consider 2 types of MSP messages

In the long run, MSP_BOX should be superseeded by MSP_AUX since MSP_BOX cannot handle any configuration other than 4*3 at all. Having both messages is a gateway, not a permanent solution.

This is not what I call "compatible"

You can't have your cake and eat it too.
Instead of artificially limiting yourself to 4*3 states with MSP_BOX, MSP_AUX allows an arbitrary number of channels and states. Why stick to MSP_BOX if there is a superior alternative? Somehow the message will have to change to transport the additional data, so one can either modify MSP_BOX, breaking every GUI in existence, or provide a new message type, allowing both systems to coexist for some time until the dust has settled and the GUIs have caught up.

Hamburger · Post by **Hamburger** » Sun Jul 22, 2012 11:41 pm

I stand by what I said:
Which TX offers 6way zwitching? - a pot does not provide 6 distinguishable states.
Your patch does not look simple. It does add complexity.
6 members like it? does not sound like your quote 'quite some people' to me.

Up until now it is project policy to not include every possible feature only because someone built singular hardware & software to support it. This patch does not seem to fulfill relevance criteria, so I says 'do not include'.

Tommie · Post by **Tommie** » Sun Jul 22, 2012 11:53 pm

Hamburger wrote:I stand by what I said:
Which TX offers 6way zwitching? - a pot does not provide 6 distinguishable states.

I could be pedantic and either state that due to the use of an ADC, most pots provide up to 2^10 distinguishable states, or that even a non-discrete space provides an infinite number of distinguishable states; but I won't go there.

When I received my TX, it had two pots connected to the AUX channels. Using the pots, I was able to "dial" through the three states provided by MW. After a while, I replaced the pots with switches and resistors, turning the scale into a discrete one. Judging from a quick internet search, this seems to be common procedure. There is no reason why this replacement is limited to a 3 state switch.

6 members like it? does not sound like your quote 'quite some people' to me.

I like it as well, so do others I have talked to, neither of us have clicked that LIKE button.

Up until now it is project policy to not include every possible feature only because someone built singular hardware & software to support it. This patch does not seem to fulfill relevance criteria, so I says 'do not include'.

Relevance criteria? Policing de.wikipedia.org lately? Sorry, browsing through the source code of the project, looking at the obscure hardware supported by it, I cannot take that statement seriously.

Alexinparis · Post by **Alexinparis** » Sun Jul 22, 2012 11:55 pm

Tommie wrote:Somehow the message will have to change to transport the additional data, so one can either modify MSP_BOX, breaking every GUI in existence, or provide a new message type, allowing both systems to coexist for some time until the dust has settled and the GUIs have caught up.

The message generation can become more generic and still use MSP_BOX to be compatible with unaware GUIs.
For each item, you just have to select the right number of 8bit var needed and order bits in this order (n AUX, m states): AUX1.1 AUX1.2 ... AUX1.m AUX2.1 ... AUX2.m ... AUXn.m.
With the message AUX_COUNT, the aware GUIs will know what to interpret, and the unaware GUIs won't see the difference.

Hamburger · Post by **Hamburger** » Mon Jul 23, 2012 12:07 am

So you showed no TX offering a 6way switch. aprt from your homebrew hardware.
For relevance you quoted an article with 6 followers - how convincing.
Obscure hardware as in led.flasher? I agree - it is not documented at all, requires unknown hardware; did not even compile for long time, re-invents some functionality of buzzer and led instead of extending existing code and functionality.

You have made it clear in the past you follow your own agenda, you do not give 2 cent about the general usability or usefulness of whatever you do to the project. Nothing you have said has convinced me of the usefulness of this patch, so I stand by the reasons; I am against incorporating this patch.
EOF

copterrichie · Post by **copterrichie** » Mon Jul 23, 2012 12:11 am

Why not offer an er9x patch for the WiiCopter? Many people have these transmitters and have upgraded to er9x.

Tommie · Post by **Tommie** » Mon Jul 23, 2012 12:12 am

Alexinparis wrote:For each item, you just have to select the right number of 8bit var needed and order bits in this order (n AUX, m states): AUX1.1 AUX1.2 ... AUX1.m AUX2.1 ... AUX2.m ... AUXn.m.
With the message AUX_COUNT, the aware GUIs will know what to interpret, and the unaware GUIs won't see the difference.

Actually, they will. I thought about such a layout, but it fails once have a different number of states:

Code: Select all

[AUX.STATE]
4*3 states:
[0.0] [0.1] [0.2] [1.0] [1.1] [1.2] [2.0] [2.1]...

4*4 states:
[0.0] [0.1] [0.2] [0.3] [1.0] [1.1] [1.2] [1.3]...

Without knowing the proper number of state and channels, the unaware GUI has no chance to notice the misalignment. The existing code resorts to ignoring requests of unaware GUIs if they cannot be fullfilled (channels != 4, states != 3); if both type of GUIs use the same request, the firmware cannot distinguish the two and can just hope for the best.

palton · Post by **palton** » Mon Jul 23, 2012 12:14 am

Here is a list how to accomplish 6 modes for different tx (mixing setups). It's doable for many TX. It's from Ardupilots manual. It's write ups from people who have contributed.

http://code.google.com/p/ardupilot-mega/wiki/Sixmodes

If one channel would use multiple threasholds for selection of flightmodes, it will free up for other aux, to be used for features that would be run independantly.

Tommie · Post by **Tommie** » Mon Jul 23, 2012 12:16 am

Hamburger wrote:So you showed no TX offering a 6way switch. aprt from your homebrew hardware.

Didn't I just post a picture of a TX with an 6way switch? Didn't some other people in this thread tell hat they are actually using such a device?

Obscure hardware as in led.flasher?

Very obscure. It's called an "LED".

You have made it clear in the past you follow your own agenda,

So we have something in common I guess?

you do not give 2 cent about the general usability or usefulness of whatever you do to the project. Nothing you have said has convinced me of the usefulness of this patch, so I stand by the reasons; I am against incorporating this patch.

I like your completely unbiased and technically funded review of the situation.

Hamburger · Post by **Hamburger** » Mon Jul 23, 2012 12:24 am

Tommie wrote:I like your completely unbiased and technically funded review of the situation.

'So there's something for everyone to enjoy.'

treym · Post by **treym** » Mon Jul 23, 2012 12:29 am

at least you both agree that this is a weird situation ..