Feature request: Trim buttons as switches?

This brings me around to a perennial question for open source software: is the goal for the software to attract as many users as possible, or to be the best that it can be?

This would seem to be especially pertinent in this case, where trying to expand the user base on the low end, entry-level receiver is apparently holding back improvements on the more capable receivers.

It's possible to succeed doing it either way. Perl succeeded by adding features (whether to expand the user base or not) because "There's more than one way to do it." Python succeeded in the same space in spite of regularly refusing to add features that might have expanded the user base because they didn't improve the language.

I'm not saying that either choice is wrong, and it's pretty clearly your choice. But I'd be interested to hear where you stand on this question.

What i feel after having used deviation for a while is that the standard gui is a bit to simplified and missing a few features. And that the advanced one is a bit to complex.

The standard gui is also nice in that its much faster to setup a basic fbl model in it then the advanced one. For those that dont like messing around with tx settings. Or have their hands full with learning the ins and outs of their fbl gyro. And dont want to add the complexity of the advanced mode ontop of that.

As a side note, the standard gui is much easier to navigate and setup on the 7E and 10.

Also still not sure why there isn't a trainer menu/option in the standard gui, or at least a template for the advanced one.

Though, what i find even more strange is the fact that im the only one thats even been asking for help with setting up a trainer mode. that should indicate that most of the user base has quite a few flying hours behind them, and don't let others try their cheapo models. Though they might just not care about the cheapos getting a battle scar or two.

+Xermalk, I have little or no trouble handing the 7e over to someone for the cheap things I fly with it (ultramicro copters). But I've always got the 7e and a quad for someone to play with handy. A number of things drive that:

• I only do it indoors, so they aren't likely to get lost.
• Coaxs and quads are so easy to fly that they can't get into a lot of trouble.
• They are so light that "flip this (throttle hold) if you're getting into trouble" will prevent most damage.
• For CP copters, I make it clear that if they break it, they bought it (nobody has been willing to risk that).

I've been doing this for a couple of years now, and the only thing that's been broken at the hands of a beginner is the tail boom on my mCX/S300.

If I were flying planes, I'd probably want a trainer mode - but most of the things on that list don't apply to planes. I'm planning on picking up the QX350 when it comes out, and may feel the same about that. Then again, the "return home" switch on it may make me feel safe without one.

Hi All, thanks for all your input on this thorny issue

Although the 7e is an entry level Tx from an initial cost point of view, with Deviation and a couple of simple hardware mods, it becomes a very capable Tx indeed - and one with a seemingly unique physical form factor for those into smaller models such as the micro quads.

I think mwm made a very good point when he raised the question regarding the point of open source software.

It does seem like there are two audiences that this Tx is attracting, those who want a cheap Tx that supports multiple protocols with a simple and familiar interface, and those who would like to capitalise on the features that Deviation can open up on the device, and are willing to sacrifice the simple interface in order to make use of additional features that the Tx would otherwise not have room for.

Perhaps a compromise could be reached? A quick look at the code seems to indicate that there are already defines in place to allow the standard gui to be exluded from the compilation - in this case to allow a debug build to be made. Perhaps this feature could be formally supported and allow Deviation to be built without the Standard interface.
Then other, more advanced, features that are currently being considered for exclusion from the 7e due to resource limitations could be compiled in based upon enabling similar defines.

Assuming that excluding the standard interface frees up enough resources, might it even be possible to have two 7e builds - a standard one and an advanced one, each being a subset of the complete Deviation supported by the bigger Txs, but focused on a particular user audience?

Ian

You're absolutely right - its easy for someone looking in from outside to make simple sounding suggestions without having a detailed understanding of the full implications. I wish I had the skills to be useful to you in this regard without further draining you resources.

If I was to have a poke around in the MinGW dev environment myself - would it be worthwhile pursuing the NO_STANDARD_GUI makefile and target_defs.h defines?
An initial check gave a compile error in the pages/common/_model_page.c file which appears to refer to ITEM_GUI on line 142 even though NO_STANDARD_GUI is defined.

Ian

I appreciate you getting back to me on this.
A last couple of questions
- does the 7e emu also reflect the low resources of the actual Tx? i.e. If I make changes to the code and they work on the emu, am I likely to suffer issues when I try it on the Tx itself?
- Am I likely to get myself into a situation where I could brick the Tx by flashing my own homegrown dfu? Or will I always be able to just flash a 'proper' build over the top?

Ian

If the 7E is attractive because of the form factor (and I think it is), the 6S would also fit the bill. The 7E and 6S use the same case. I couldn't find dimensions on the 6S, but the 6S ships in the same size package as the 7E, and weighs less - even with a receiver.

The downside is that it costs twice as much or more. However, for that you get the mods you'd want on the 7E already made: two extra (3-position!) switches and higher output power. You also get a color touch-screen, and you don't get the cheap 7E gimbals & sticks or the issues that you run into running Deviation on the 7E.

I've avoided the color touch screen Tx's because - well, the environment just seems wrong (bouncing around in the car going to/from the field, out in bright sunlight). But those don't apply for where I use the 7E. I been thinking about trading the 7E for a 6S for a while, and I think I just made up my mind to do that.

Hi PB

Thanks for the confirmation.

BTW - the Devo7e does seem to behave if the NUM_TRIMS define is increased from 6 to 10.
However, I haven't been able to get the R+ or L- buttons to activate trims

Ian

I just verified that something works (well, in the older build I'm running), and suspect it may be an accident.

If so, I'd like to request that it be supported as a feature.

Basically, I set up two of these nifty new trims on the same button. One is a momentary to ch6, and the other a toggle to Virt1. This works just like I'd expected: hitting thebutton bounces channel6 (so my nQX swaps between agility/stability mode), and toggles Virt1 (which displays an icon indicating which mode my nQX is in).

I was going crazy trying to figure out how to set up a virtual channel to do this tracking. Just using the second trim is simple and works like a charm. It'd be nice if it kept on doing that.

It does not work "by accident" but "by design". As with all other inputs they can be used more than once for different (even the same) channels.
So you don't have to fear that this feature will disappear...