Feature request: Trim buttons as switches?

Kdean wrote: what about getting the trims on the display to act like bargraphs.

You can achieve this with the actual version too:
Select a free virtual channel, say Virt1.
Select a pair of buttons, say UP and DOWN.
Define a trim for Virt1 and use the buttons UP and DOWN. Set the trim step according to your needs (I had to set it to 5.0 to get the full range).
Define a mixer for Virt1 like this: complex mixer, curve fixed, scale 100%, offset -100%, trim.
Define a new bar with Virt1 as source.
UP and DOWN increase / decrease the value of the bar (with corresponding beeps).

I was hopeing for something easier to setup, actually no setup at all. Lets say i want to display the stick positions with trim like bars, instead of the little bargraphs that are limited to the vertical position. It should be as easy as placeing and selecting the trim in the page setup, and just like you have many options with the bargraphs, the trims should have the option to display other inputs and not just trim 1-6.

rbe2012 wrote:

mwm wrote: I believe that "Right" means the button labeled R+ on the 7E.

Yes.

Your config looks ok an I just tried it with the last emulator and it worked fine when I select UP or DOWN bot not with LEFT or RIGHT. They seem to be used for other things (quickpages) on the main page.
This is the same in emu_devo12-v3.0.0-ddf6350.

PhracturedBlue, should left and right be removed as toggle buttons to avoid confusion?

Thanks for checking. I didn't think this would be the problem, as I use UP and DOWN for quickpages in my configs. However, changing it from RIGHT to UP worked. For that matter. changing it to EXIT also worked.

I tried them all. EXIT/UP/DOWN worked fine, even with long presses on UP and DOWN for quick pages. ENTER/LEFT/RIGHT didn't work. I'm not sure how ENTER could work in any case. Maybe it needs to be a long press from the main page?

I hadn't been looking at the new main page config stuff. However, to use this, I sort of have to have that. Is there some documentation on that available yet? Searching the forums turns up the PBR'S NEW GUI thread, but that seems to mostly be problem reports rather than documentation.

Thanks again.

As far as I have seen yet the docu is indeed hidden between many bug descriptions. But it is mostly self-explanatory / intuitive to use.
The main thing is that you have two modes: one for adding and placing elements and one to change the properties of a class of elements.
Just try the buttons and you will easily see the possibilities.

rbe2012 wrote: As far as I have seen yet the docu is indeed hidden between many bug descriptions. But it is mostly self-explanatory / intuitive to use.
The main thing is that you have two modes: one for adding and placing elements and one to change the properties of a class of elements.
Just try the buttons and you will easily see the possibilities.

Adding a bargraph does nothing. Adding a BigBox does nothing if you're lucky; if not, it'll reboot the Tx. For Toggles and SmallBoxes, it's obvious what's going on - except they always wind up centered over the middle of the vertical trim displays. This doesn't seem self-explanatory to me.

I haven't seen any indication of there being more than one mode, or any way to change it.

Could this be bugs in the 7E UI? If so, would the 10 be any better?

Hiya Gents!

PB -> My hero! Thanks for the info on the D7's limitations, I assumed the limiting factor was their ability to store your magic code, not to process it... obviously no amount of storage will overcome that limitation.

MWM -> Thanks for opening the ticket, I tried responding to it, and cant log in for some reason.. probably not enough coffee in me yet

RBE2012 -> You mentioned that R+ was being used for quickpages on 7E, how is that setup? I originally started wanting the trims as buttons to activate those quickmenus!

I have some feedback from the limited testing I could do with the nightly builds on emu for devo10...

1) "momentary" text overlaps trimLV- and "ary" remains when you change to toggle or anything else
2) small box1 just displays "1" as title in mainpage config (layout)
3) adding a big box crashes, but only when you scroll through mainpage config... After adding the box, when you get to the line where the bigbox would be displayed, it's blank and moving the cursor to the blank line causes the crash.
4) bar graph doesn't do anything, but you can move it around in the preview page if you get bored.

For the trims -> i'm still exploring the current implementation, but as usual I have some ideas...

When in the trim page, IF I choose input press enter then I'm at the non-titled "input select screen"... In that screen IF I were to choose input=none, trim-/+ = the specific trims to be used for the intended function, trim step = toggle and then assign a lable to the newly promoted trim keys by using SWITCH = T1 or T2..ect then wouldnt I just be able to choose T1 from the normal spin boxes like how we do now when we config a complex mixer? Just an idea to help simplify the introduction of this feature, since we wouldn't need virt channels! It probably just makes things harder for the coders, though

Last layout idea for today -> battery meter config page. 3 or 5 points, so people using different batteries/Tx's can set up the correct voltage to represent each point, and each point has an icon? All battery points occupy a total "field", you could use the standard celly batt meter, or pie chart or even crazier?

model menu 6. Datalog -> WTF,OMG!!! Wow. Wow and more WOW! Where've I been? When did that show up? Can it timestamp the "recordings"? Is there a way to break up the file to represent individual flights?

Between the new layout functions, the new trimboxes, dataloging, I'm farking dying for the next full release... at the very least please tell me when its safe to start testing the nightlys on a real TX, the emu swandiving is scaring me off for the moment.

Thanks so much for the efforts invested!

Cheers!
-=S=-

It's a little bit off topic but the answer is important, I am sure:

I think it's time to test on a real tx now, but I recommend to distinguish between "testing for bugs of an untested version" and "fly a potentially harmful bird"!!
PhracturedBlue has told us that he freezes the features and will take the time until the next release to fix bugs, if they exist.
I install a new version on my Devo8 and Devo12 daily and go flying, but the only thing I mention (besides some minor issues) is that it gets better and better. But without testing and reporting errors in "real life" situations issues might stay hidden... but if you find one you will be glad if you only loose a microbird.

Creating virtual switches via trims set as momentary/toggle/on-off is a fantastic idea.

Can I ask that the following suggestions be considered:-

1) That the number of trim switches be configurable for all tx, not hardcoded dependant upon tx model.
I use Devo7e which has the potential for 13 virtual switches. The current nightly limits this tx to just 6 trims.

2) That the toggle setting allows for a default initial value to be configured (when tx switched on / model loaded) rather than always remembering the last value.
For example, if I configure a virtual switch to toggle the LEDs on by Hubsan X4, I would rather they are always on when the model is first turned on.

And lastly, a comment - does it actually make any sense to allow the "Enter" button to be selectable as a virtual switch?
The currently nightly seems to ignore a switch that is configured with this button - and very wisely too

If there is enough positive reaction to these suggestions, I'll try and update the a ticket on bitbucket.

Ian

PhracturedBlue wrote: The reason the Devo7e is limited is because we are right on the edge of the available space of the Tx, and I need to have enough space to enable the code-creep that happens as we fix bugs and add other features.

I know that this may be considered contentious, but . . .

Does Deviation really _need_ to have a standard interface (especially on the Devo7e)? Would removing it, a) save a decent amount of space, and b) be reasonably straight forward?

It seems to add nothing to the overall functionality, and consumes much needed resources (memory and developer time). There is nothing that cannot be achieved using the advanced interface, and any lack of a standard interface can be catered for with good documentation & support for the advanced interface.

I'm guessing that people don't choose Deviation because they want a simple interface, but because they want the maximum capababilty and flexibilty out of their Tx - i.e. advanced users.

Ian

sllewji wrote: I'm guessing that people don't choose Deviation because they want a simple interface, but because they want the maximum capababilty and flexibilty out of their Tx - i.e. advanced users.

It's exactly the other way around. Most people (flying helis) start with the standard interface then move up. But, not all of them, there are a few who don't need/want or are capable/have interest in grasping the advanced mixer.

Yes we thought the same, but nowadays a lot of absolute beginners buy the 7E to replace their toy transmitters to control for example the Blade nQX...

It's exactly the other way around. Most people (flying helis) start with the standard interface then move up. But, not all of them, there are a few who don't need/want or are capable/have interest in grasping the advanced mixer.

I wonder whether the possibility of releasing more capability in their Tx might encourage these new users to spend a little more time up-front to understand the advanced interface - especially if documentation at the appropriate level was there to support them.
The documentation as it stands at the moment is very concise - but there are are number of posts that could be used to expand it and help explain some of the complexity and make it a little less dense, and easier for the new-comer to get to grips with.

Whilst, getting involved in the coding is probably a little out of my reach, expanding the documentation to help explain how to get the most out of the advanced interface is probably something I could help with.

Ian

Maybe the solution is not longer documentation, but beginner-specific templates? We can assume these people are flying 4-channel heli's (if they've got the chops to start with a CP heli, they've probably got the chops to deal with the advanced interface), and just need to get the basic setup right.

For example, all the Blade 4-channel copters (mCX*, CX*, nQX, mQX, presumably the QX350 when it shows up) use the same basic setup. Ditto for the WLToys 4-channel ones - at least on the same transmitter. I normally configure those by grabbing whichever similar copter I was using before as a starting point.

So, have templates for Blade 4 channel, WLToys/FlySky 4 channel, etc. Describe them in the documentation (I'd hope that would be done for all templates), and provide a pointer to a forum thread on customizing the templates for specific copters. I.e. - how you'd enable (or maybe use, if it's enabled all the time) stability/agility switch for the nQX, ditto for the QX350 modes, how to set up the lights and camera/etc. on the WLToys quads, etc.