Preliminary survey results

Ok, the survey is now closed. I've not done a deep dive yet, but wanted to thank everyone and give my initial reactions. These are preliminary conclusions based on the summary. I really need to look at correlations between various things, and these may prove to be spurious after we do that. Links to the survey and results at the end.

First, and most importantly, there are a lot of good ideas, and no really bad ones. Some I don't think we should do for one reason or another. However, since this is a volunteer project, not a commercial one, nothing will get done unless someone steps up and DOES it. If something on this thread strikes your fancy, do it . If you need help getting started, ask! If you need help getting it back to us, ask for help with that as well.

The most popular contribution people were willing to make was donating money. Since PB doesn't accept donations, we need someone/thing else to do that, like a real non-profit. A number of people indicated they were willing to help with such. If you're such a person, please PM me about doing just that!

I did at least one thing wrong. I didn't explain the terminology. For instance, I suspect that "Transmitter ready" would have had more users if I had explained that it meant "an RTF package that doesn't include the transmitter, also called Bind-N-Fly or BNF". Can be fixed next time.

Most importantly, we have a serious problem with discovery of anything not on the main web site. There were suggestions for things that have been done, or discussed, or that we have, or etc, and lots of "I don't know about/how/etc." answers. Fixing that requires fixes to the main web site.

RTF aircraft dominate our user base, with BNF being second. No other forms get enough usage to really notice, though scratch builds do suprisingly well. Similarly, drones dominate, with helicopters a distant second. This aligns my feeling that most of the 7E users fly RTF drones, but an analysis of those numbers correlated with transmitter needs to be done.

This correlates with software changes people would like to see, with more RTF models and the universal module being clear favorites, and more receiver models looking like it's the first among the rest, though that's not clear. Outside of the firmware, the most popular option was a desktop/web model configuration tool, followed closely by a file manager. We already have a greenfly's file manager. So it needs to grow model file configuration tools. That people haven't found the latter illustrates the discovery problem, and why providing this won't help a lot of people until that gets fixed.

I'm posting a discussion of all the longer responses, just to thank those who took the time to do that. Since this was done via cut-n-paste, I may have missed yours, in which case I apologize and recommend that you post it here yourself.

Results:

Summary of responses:
docs.google.com/forms/d/10yCwkXLnQUufACc...hU5J9c/viewanalytics

Spreadsheet of all the results:
docs.google.com/spreadsheets/d/19iSEYjXl...BVw/edit?usp=sharing

A list of models currently supported in Deviation nightly builds should be part of the nightly build documentation.

Not really possible. The firmware does protocols, not models. Which models use which protocols depends on the manufacturer. We probably can't find out which models are supported by the DSM protocols, much less for protocols from manufacturers that change protocols between models willy-nilly.

A contributed library of model ini's is badly needed

Model file library management, starting with all the models posted at deviationtx.com.

Easy to find model files that are categorized by each radio model i.e 6S, 7E, 10.

This shouldn't be difficult, just time-consuming. Simply adding a column to the existing models spreadsheet with a link to the model.ini forum in the thread would do it. Unfortunately, it won't help people find the model files unless it goes in the existing database and not a copy, or we fix the discovery issue.

readme type file summarizing what each of the assigned switches does for a particular model.ini

Model files are donated by users, so they'd have to add those to the contribution. I try and do that in the post with my model files. Checking that and providing links to it could be part of the curators job for a library.

Icon depository, some way to file icons for easy lookup. If the was a way to look at all icon images in a folder. This way I don't need to know the exact model name, I can choose by the image.

Some avatar or icons for the models (boat, multihull etc...)

Same issue as the model files. Given that people often include icons with model files, this would be a nice thing to have in the library.

A simple to use icon editor. All that Gimp stuff is too involved just to make a model image.

Nothing special about the icon images, they're just images, so you really need an image editor like GIMP to work on them. But there are probably simpler image editors that can do the job - they just need someone to document how to use them. Alternatively, I believe it's possible to add scripts to the GIMP, so a script for taking an image and converting it to an icon image would be possible. That would be simpler to use but harder to install.

An updated Deviation User manual is badly needed

We have a PDF for the 4.0.1 manual (the last release), and the online manuals linked in the Main Menu are for the nightly build, and were updated last summer. I don't think there've been any major changes since then. There's lots of room for improvement, but updating doesn't seem to be required. Care to expand on this?

A Devo Controller Theory of Operation with examples is badly needed

Good idea. Possibly the "Overview of mixes" from the introductory tutorial would be a good starting point?

In-depth help and examples when using the .ini files for configuration.

Proper tutorials with exercises to follow that break down everything for a new user, never used deviation before. I use it everyday but can't use advanced mixer at all.

Have you looked at docs.google.com/document/d/14NhJCKgtMoy9...z3w/edit?usp=sharing ? If so, what's it missing?

More tutorials on writing model files that are maybe more specific to each radio. Writing a model file for the 7e is different than for say a 6s or 8s. Also if the manual went into some of the finer points about mixers and creating a model file that would be very helpful.

I don't think the manual is the right place for this stuff, but we could use more tutorials.

I'm not sure I agree about writing a model file being different for the 7E, as all that changes are the switch names. Well, and availability, which means you need to use buttons where sometimes you'd like to use switches. But hey, if you can write a document about the differences, that'd be great!

There are some "known" issues or bugs or enhancements that are in the nightly builds but are not documented in the user manual. Those should be documented -- perhaps not in the user manual (since nightly builds aren't "released versions"), but at least in a single, easy to find place on the Deviation website for now.

These aren't known to me. Could someone who knows them please submit pull requests for them, or open a thread listing them?

If above issues are addressed for newbies that would really help! Newbies have no direction of how to start, proceed, and/or trouble shoot with the cryptic documentation as it now is. This holds back popularity for the masses and helps only experienced Deviation advanced users.

I think this may be addressed by the discovery issue I mentioned in the first post. Hopefully, we'll have a curated set of links to documentation, tutorials, etc to help with that.

patience with newbies and those who dont learn fast due to age or other reasons. Dont write as though you are discussing with a person of equal knowledge - we struggle with acronyms and tech speak. You are asking about the 7E below... I dont know anything about it... but you will make me enter a a value! Not really helping you is it!

"You can't teach a rock." When writing documentation, you have to assume some level of expertise. As you note, if you start to high, you'll lose people. But if you start to high, you'll insult people. There's no good choice.

As for having to enter values for the 7E - I want to know what everyone thinks. I also want to make people think about it. I will filter out the responses from people who don't own a 7E as well, because that's also of interest. So yes, it is helping!

Some of these are in the nightly builds and not the release. Again, this looks like a discovery issue. It may be people who aren't willing to run nightly builds, though those are more popular than any of the releases.

Ability to hold down key to be taken to bind menu. Or decision to preassign the bind/model setup menu so everybody's radio is the same.

We have this - or at least as close as we're likely to get. Just add the model setup page to the quick menu's in the layout editor. That's the page with the bind button on it. Since the 7E doesn't have a layout editor, you'll have to edit the model file. It isn't on by default, and I'm not sure enough models need to be bound more than once to justify doing that. Of course, I'm pretty sure few enough have telemetry to justify putting that on by default either.

Fr-sky telemetry

It's in the nightly builds. I've also been extending it and provided test builds with a variety of fixes, but haven't gotten any feedback on it.

Compatibility with Devo "F" range transmitters

In the nightly builds, but needs testing and more work.

More virtual channels.

Adding more virtual channels should be easy, and the only reason not to do so is the extra display space they take up.

It's a little-known feature, but you can use standard channels as virtual channels. Raise the number of channels so you an edit them in the mixer, and then lower the number of channels after you've set them up so they aren't transmitted.

Make a "Lite" version for those tx with limiting characteristics and "Enhanced" version for the rest. A tx may have to drop into the "Lite" category if it becomes a limitation for deviation-features of other tx's.

We already have a "Lite" version for the 7e. But if it's deviation, it ought to share model files with the "Full" version. We've not added features that would be nice to have because of this.

Someone please implement these! Or at least open an issue in the bug tracker for them.

More switch icons

Yes, yes, and a thousand times yes! I'd love this, but lack the artistic skills. I'll, approve a pull request for it, or build one. I've asked a number of people to donate them, or if their contributions could be used in the build, but never gotten a response. This one doesn't need the discovery issue to be fixed, it just needs to go into the source.

Assign extra channels in Easy GUI and some sort of easy mixer for setting a preset value on a channel output, for bank switching and rescue in FBL. Spirit FBL have rescue on negative tailgain and I have it setup in Advanced GUI but prefer the Easy GUI for field change of expo and trottle curvs. Brain/Ikon have self level one of three banks and I have to use Advaced GUI to use one extra channel.

More features in the Standard GUI. Mostly for Quad features like headless mode and return to home channel assignments. Also icons for these features would be nice.

The standard GUI is meant for collective pitch helicopters. If you're using it for multirotors, you're introducing latency and setup issues that don't exist for multirotors. We have added a "multi" model type, so tweaking the standard gui to support multirotors and add those should be possible.

When I used OpenTX on my Turnigy 9X, I liked using the Companion software for creating & configuring models, updating the firmware and emulating the behavior of a model setup. The Emulator for Deviation only runs on Windows (I believe) and I don't have Windows. If it wasn't for the superior Devo hardware, I'd go back to OpenTX, just for that.

some setup wizzards for known mixers, like delta V etc

The emulator will build and run on Linux and FreeBSD. Could probably be built on the Mac as well. However, we only distribute the Windows version. Have you thought about running OpenTx on a Taranis? In particular, is the Devo hardware better than the Taranis?

Not sure if the person wanted wizards on the desktop or not, but I think that's the place to put them. Partly because a desktop/web configuration tool was the most popular choice for the software. This also has implications for dealing with the 7E.

Ability to use telemetry as an input (like virt1 etc) so i can transmit RSSI over PPM to my flight controller

Telemetry values accessible in the advanced mixers

Interesting idea. Since the channel values are -100 to 100 %, it's not clear how telemetry values would show up in the channel mixers. Someone want to start a thread in the forums discussing this?

Being able to transfer files to/from a USB stick (via adapter).

Well, we can already do that - except your adapter has to be a computer of some kind. Best case, use an OTG-capable smart phone and copy the files to it, and then to a stick. But being able to do it directly would be nice.

Our own radio line (one small sized and one large sized radios similar to devo 6s and devo 8s).

an open diy board

I think the open diy board would be a great "deviation" radio line. Especially if we had an easy-to-use build system with a GUI that lets you pick features and specify the hardware configuration then click "build & install".

Deviation brand multirotor frames, helis, etc.

New popular protocols,Frsky Flysky

wireless trainer function

More than 27 main screen items, ability to move/remove model name.

Change the displayed timestamp on the Forum posts to DATES. I hate the "3 months 2 weeks ago in a Universe far far away" format when I'm trying to match conversations between Deviation and conversations in other RC sites.

A sub-forum specific for test builds that people post with detailed information about the changes they've made. This is how I best learn how to do my own builds.

100% stable Spektrum telemetry support - I like flying sailplanes, and having at least a vario is vitally important once you look for thermal flying

Improvements to exiting protocols, for example better range for DSMX/DSM2.

All good ideas if someone wants to work on them.

Someone please implement these!

Making a basic model into advanced or back wipes the model making transition impossible. Not user friendly unless your a coder and little help online

Only half right. Going from the standard gui to the advanced gui doesn't wipe your model. Going the other way does. Not really much we can do about that, as the advanced gui may be using things the standard gui doesn't understand. It might be possible to check it and only do the "I have to wipe" if they exist, or some such.

More than 12 channels.

This depends on the protocol. I don't know that any of the protocols we currently support support more than 12 channels. Possibly DSMX, but it's not clear that just adding channels will do it.

Convince walkera to lower devo 6s value to devo 7e prices.

Convincing them to keep selling the 6s was hard enough, and may not have been successful.

after hacking the protocols, was there ever an attempt to reflash an RX, e.g. to convert a DSM2 RX to DSMX?

Not that I know of. I don't think I've seen an Rx that was user-upgradable, which would be a major boost for this.

More frequent version releases.

Official releases require PB's help, and he's tied up elsewhere. It's not clear we can do anthing better than nightly builds without his help.

The survey shows that only a few people insist on running a release. I think we might want to go to a "stable" branch, which is updated less frequently than the nightly. Say after it's been running for a month or more with no problems. Between those builds, it would get nothing but bug fixes and new protocols.

Showing interest in suggested features by commenting on them in the threads, especially if you answer questions from the developers, will make it more likely that they get implemented.

I don't know if it is already possible. I'm flying arducopter on one of my drones. It would be really nice if when in Loiter mode i could flick a switch and then my right stick (Roll/Pitch) became Pan/Tilt on the camera gimbal.

See deviationtx.com/forum/how-to/5030-using-...-for-multiple-things

Better use of sound in general

Independent beeper/haptic feed-back alarms settings for all Devo TX's

More beep/alert functions.

See the channel beep facility thread ( deviationtx.com/forum/builds/4953-channel-beep-facility ) for the first part. More coming soon. But not to the 7e.

Universal module.

See the universal module thread: deviationtx.com/forum/7-development/3154...iversal-module#38434

Script programming like OpenTX

See the proposal: deviationtx.com/forum/7-development/4939-scripting-deviaitontx .

Add text to screen

See deviationtx.com/forum/7-development/4495...ii-display-box#34582

Better toggle icons, like MWM's test build.

This is now old code. Since it changes the config file layout, it has to run on the 7E, and it doesn't fit as things stand: deviationtx.com/forum/builds/4287-new-toggles-code-test-builds

I haven't been following things in a while, and I am not sure if "mobile devices" option covers it, but I would take a page from Spektrum and do the configuration on a computer, then push it to the TX. I guess you could have profiles loaded up on a USB or mobile device, but I don't want the phone to cost more than the RC equipment. I already have a FitBit that won't sync with my 3 year old smartphone because it doesn't support Bluetooth LE profiles.

Well, since hardware mods don't solve the problem, doing this by modifying the file system on the device is about the only option. A desktop/web configuration tool was the most popular new feature option, and that's basically what this is. A version that ran on a mobile device would allow you to do it if the device supported OTG, but the desktop/web option means such a device wouldn't be required. So this looks like the best option going forward.

I like the idea of customized builds or at least builds with different subsets of features to choose from.

Modular is fine, user chooses what option they want for their memory allocations.

Allow users to pick only functions they need example:Protocols via PC.

Certainly possible if nothing else works. It'd at least allow people to get options they want that are being left out to make room for other things, like the standard GUI.

Freeze development on the Devo7e this would come even before the incompatible fork.

If someone only has the 7e, it will be important to continue support for this Tx. But, like some of us, we start with the 7e, then realize the other Devo Tx are "better," so limiting other Tx functionality because of the 7e's issues isn't the best solution. I suggest a separate "version" that isn't compatible with other Devo Tx.

Let the 7e become a simple, entry level tx without all the bells and whistles, that would make you want more (D8/D10/D12 etc).

This isn't really an "other" option, because it was offered in the multi-choice set. While this is a great choice from the software view, I think the community is small enough that splitting it in half is a bad idea. But it may get more discussion anyway.

The 7E is what it is, a basic, $50 transmitter. Trying to get it to function like a Devo 10 or an 8 even is kind of "belittling" for these latter. Some more advanced features aren't really needed on it, as most people that use it are controlling more basic or smaller models, especially RTF. The number of protocols is nice, because this radio is probably most used with the assortment available, but some things like telemetry for every protocol I don't think is needed. If you want full telemetry, then get a higher end model, or get a Devo receiver. A Smart car can only do so much, and if you make it bigger and more powerful, it's no longer a Smart car, so you might as well have gotten the SUV in the first place!!

Unfortunately, not a solution. There's also some debate about whether or not it's mostly use for small, basic RTF models, though the survey seems to indicate that is the case.

The problem with the 7E is that we have a very popular model with fewer resources than other models. Hardware mods don't make that model stop existing, they just provide another model with higher limits. We can no more require people to mod a 7E than we can require them to buy a 10 or 6S instead. So while we may well do some of these things, they don't really answer the question of what to do about the 7E.

Bluetooth phone/tablet gui.

Put the 12S type standard touch screen GUI on Android mobile devices and limit the 7e internal software to Advanced gui + download from Android. The same download feature could be used on all models of TX and allow for "off-line" programming using the same layout as a 12S on Android.

Turn 7e into slave terminal. Add serial interface. Make a daughter board with mcu with breakouts for RF modules and with any combo sw/pot you could ever need! And or header pins for other things. No black art soldering

Figure out how to hardware mod the 7e for parity. Rank 10 for me. Or get the 6s priced at $80, lol.

Create a fork for support and promotion of 7e MCU chip upgrades. With the intent of making an upgrade as easy as the other popular hardware mods.

Extended memory ?

For the hardcore 7E users, the single PCB Universal Module paired with a dedicated processor for protocol related stuff could free up some memory on the 7E itself. I would like to see the universal module finished or at least some development progress on it. I'd happily design my own JR style 'motherboard' with an STM mcu for protocol handling which could also work in the 7E. I do lack the programming skill to port a slimmed down version of deviation to it though.

Possibly use the small flash storage as some sort of ram overflow but i don't really know here. Another solution would be to have two versions of the firmware, one with the advanced gui removed and another with the simple GUI removed. This would save memory either way and the user gets to chose which to have.

MCU/memory upgrade guide with supported builds.

Or, to upgrade the devo 7e. Find a way to increase memory (memory mod?)

Since the survey showed a lot of people didn't know they could buy one, I'm relaunching this campaign. Estimates on shipping dates have them arriving by christmas eve.

teespring.com/deviationtx-support