Observations from a green user

Aloha, and thanks so much for putting together such wonderful stuff for R/C deviates!

I've just barely gotten my Devo 7e working with an nRF24L01 add-on. Managed to get one of my quads flying with it. Impressed and looking forward to learning and doing more!

I have lots of soldering and programming experience, and interested in maybe creating more cool stuff. But feeling the need to note some early observations -- before I know enough to 'know better'. So here are a few observations that may interest, enliven or infuriate ... provided in hopes of adding (hopefully good) ideas to the fray.

1. Model file names with numbers are counter-productive. And a recipe for lost information. (Overwriting one with another.) Names of models are probably worth the extra code and space. And a folder/directory on the web site chock-full of such files would be way better than spreading them all around the discussion lists.

2. Use the display. When you try out a new model.ini you could display what's supposed to be happening: Lights: on, Flip-mode: off, Rate: 100%, Headless-mode: off, etc. This isn't just for new stuff. Perhaps the switches aren't implemented yet, that would be good to display too. If you have a few models you'll probably be using this often to remind you what's possible. Switch names could be included in those legends, too.

Comments in model.ini files should be fostered too. Dates of creation and last change. What they're meant to do. What remains to be done, etc.

3. If you need more space perhaps a cheap SD card implant will do. Store whatever you're not using at the moment in there. The tiny Devo 7e is so cool, I really don't WANT one of the bigger monsters. They remind me of today's (mostly empty) desktop computers. Wasted space. (Apologies to owners of other Devo models.)

4. Far out, but cool: Add a $5 Bluetooth board and put chunks of the user-interface on your phone or tablet. Easy to use. Cheap. Nice, easy-to-see graphics. More computing power and space. (Not necessarily connected during flight, but arguments go both ways.) Okay, this one will require a lot of work. But it will likely attract more developers too. Just too cool.

5. Absurdly impossible: Load up with all the model definitions you can find, set a new plane/quad/helicopter down and turn it on ... and have the transmitter try binding with each one (or your list of likely suspects.) Not completely automatic, but it might save some time, and cause more folks to create more usable definitions.

More to come ...

Richard

1. You can name a model file anything you want, but has to be 8 characters or less, and I think perhaps some characters are not usable. The Windows format of xxxxxxxx.yyy applies here.
Taken directly from the deviation manual:
Deviation only supports 8.3 style file names. That means file names should be no larger than xxxxxxxx.yyy

2. They are called toggles. You can make custom toggle icons, and assign them to switches.
Taken directly from the deviation manual:
Toggle: Show an icon indicating the state of a toggle switch. There can be 1, 2, or 3 icons defined for a given toggle indicating different states depending on the switch position. Two-state switches can have up to 2 icons. Three-state switches can have up to 3 icons.

3. I don't have enough tech knowledge to comment.

4. I don't have enough tech knowledge to comment.

5. If you even could allow the Tx to select a model .ini file from a giant folder of different ones at random and automatically bind to a model, how are you going to know exactly how it is configured to be able to fly it? Especially if you have not vetted it yourself.

Richard96816 wrote: 1. Model file names with numbers are counter-productive. And a recipe for lost information. (Overwriting one with another.) Names of models are probably worth the extra code and space. And a folder/directory on the web site chock-full of such files would be way better than spreading them all around the discussion lists.

The 7E is already missing features because it's running out of memory. And you can't run the latest release of the build chain, because the resulting code doesn't fit on the 7E. We be a bit cramped.

Richard96816 wrote: 2. Use the display. When you try out a new model.ini you could display what's supposed to be happening: Lights: on, Flip-mode: off, Rate: 100%, Headless-mode: off, etc. This isn't just for new stuff. Perhaps the switches aren't implemented yet, that would be good to display too. If you have a few models you'll probably be using this often to remind you what's possible. Switch names could be included in those legends, too.

I don't think this is possible. Each model has different features, that are activated by different sets of channels. So you can't display the names until after you've set up the model file. it's already possible to use the toggle icon feature to display things like this. I don't normally do an LED display, as it's sort of obvious, but my models all change the display for flip mode (or, if it's a hobby-grade aircraft, flight mode), whether or not it's filming video, etc. I don't use headless mode - it doesn't work reliably on the toys, and it's more annoying than useful on drones where it works.

What's really needed are new icons for all these new flight modes. If you want to create them, I'll set up a pull request to get them added. But my artistic skills are pretty much non-existent.

As for adding names instead of boxes - I've started on that. The first step is code that lets you use more toggle icons than any single switch has states. This is a precursor to displaying the names in a box. This code is written, and working, and I loved it on my 10 and 6S, and there's a pull request for it. But it probably won't be in the next release, because it doesn't fit on the 7E.

The alternative I'm looking at now is "flight modes". Same general idea, but I'd yank out the toggle icon code to make room for it, and instead you'd get to create a set of named flight modes that depended on multiple channels, and could then display the name in a box. But for me getting a release has priority over any new features.

Richard96816 wrote: Comments in model.ini files should be fostered too. Dates of creation and last change. What they're meant to do. What remains to be done, etc.

Comments work just fine. They just aren't preserved if the Tx writes the model.ini file out. Preserving them is certainly possible.

Richard96816 wrote: 3. If you need more space perhaps a cheap SD card implant will do. Store whatever you're not using at the moment in there. The tiny Devo 7e is so cool, I really don't WANT one of the bigger monsters. They remind me of today's (mostly empty) desktop computers. Wasted space. (Apologies to owners of other Devo models.)

Adding an SD card doesn't help. That just gives you more file system space, which isn't where the problem is. We are running out of memory to run code in - both flash and RAM. You have to wire more memory in as addressable memory, not a peripheral.

Richard96816 wrote: 4. Far out, but cool: Add a $5 Bluetooth board and put chunks of the user-interface on your phone or tablet. Easy to use. Cheap. Nice, easy-to-see graphics. More computing power and space. (Not necessarily connected during flight, but arguments go both ways.) Okay, this one will require a lot of work. But it will likely attract more developers too. Just too cool.

That's in the works. IIRC, it was part of the universal module project. Said module will plug directly into the 6, 8, 10 and 12, and can be jury-rigged into the 7E. There was a web-based version of the external config code available, as the tool chain could generate both web apps and ios/android apps. Don't know if it's still there.

Richard96816 wrote: 5. Absurdly impossible: Load up with all the model definitions you can find, set a new plane/quad/helicopter down and turn it on ... and have the transmitter try binding with each one (or your list of likely suspects.) Not completely automatic, but it might save some time, and cause more folks to create more usable definitions.

Could also kill someone. You really only need to try the protocols to see if one works, because you can't tell beyond that which model you have. Well, maybe some protocol has enough telemetry info to tell you more, but none of the ones I'm familiar with do. And you really, really want to be prepared for the thing to take off because it bound to a protocol that set things to half or full throttle because they aren't "the same" protocol, but similar. As an example, the V9x9 protocols work with my V915, but most of the video & flip options just kick it to full throttle, even if the throttle hold is on.

Basically, this is something you should only be doing if you really know what you are doing. I could see a special build that just did this. You'd have to flash it to your Tx, then try it, and then for each protocol for the rf modules you have installed, flash the name of the protocol and a "hit enter to bind" dialog, and let you try it. That shouldn't be to bad, but I'd be surprised if that functionality fit on the 7E with the existing firmware.

Richard96816 wrote: I have lots of soldering and programming experience, and interested in maybe creating more cool stuff.

I'd love to be proved wrong about any or all of these. I've written a tutorial on creating pull requests, and once you have the sources the README has instructions on setting up a build environment. At one point, there was even a virtualbox image with the build tools pre-installed. If asked nicely, I might create another one. So if you think you can get any of these ideas working on the 7E, please do it!

Richard96816 wrote: 1. Model file names with numbers are counter-productive. And a recipe for lost information. (Overwriting one with another.) Names of models are probably worth the extra code and space. And a folder/directory on the web site chock-full of such files would be way better than spreading them all around the discussion lists.

I disagree. It is an efficient system that supports more models than most will ever use. Remember, the primary way of managing models is through the GUI. If you lost model configs by using the GUI then yes we have a problem/bug... but if you lose something because you were hacking the backend storage well... I have less sympathy. I think to change it would be a terrible waste of effort and resources.

You've inspired me to rethink the path to getting proper flight mode support. In particular, adding the ability to have a display box that displayed user-selected ASCII strings seems like it shouldn't be hard, and shouldn't take much room.

I've started a thread to discuss just that idea . Including a short description of the flight modes stuff, and a full description of how this would work.

Ah-hah!
It seems that I totally misinterpreted the intent of OP's initial topics. D'oh! Makes more sense to me now.

BTW, mwm, the thread you linked to shows "The administrator has disabled public write access." I would assume that this is a temporary thing?

RedSleds wrote: BTW, mwm, the thread you linked to shows "The administrator has disabled public write access." I would assume that this is a temporary thing?

Yup. It'll go away as soon as you log in.

I am logged in already and clicked the link, new tab opened and I am a guest. Need to re-log in for this specific thread???

Try reloading the page after you're logged in. Or flushing your browser cache.

Richard96816 wrote: And a folder/directory on the web site chock-full of such files would be way better than spreading them all around the discussion lists.

I meant to comment on this before, but it slipped my mind. I've thought about it as well, and decided that the problem isn't stuff spread all over the discussion lists. After all, if we set up a folder and let anyone drop whatever model/icon/etc files they wanted to into it, would searching it really be any better than searching the model configs/model icons/model templates forums for what you want? Actually, since the search function lets you sort the results by a number of options in both ascending and descending order, limit the time period you're searching, and search either full text or just the title, the directory may not be as good.

That's probably not the directory you were thinking about, though. You were picturing a nicely organized directory, possibly categorized by manufacturer, with updates replacing older ones, etc. And I agree - that would certainly be better than the forums. The difference between what I described and what you're envisioning is curation. And a curated collection is generally always better than one that's not curated. Unfortunately, a curated collection needs a curator - and we don't have one.

If we did, it wouldn't matter whether or not the files were in a folder, or you just had a document - a spreadsheet or some such - that had links to the post with the file in them. It's the curation that makes things useful, not the storage.

This would make a great project for someone who wanted to give back to the community but didn't want to get involved in programming for some reason. Set up a public google drive (dropbox, whatever) folder and start copying model files from the forums to it. Organize it however you'd like. Or set up a google docs (whatever) online document with links to the appropriate forum posts or files. Nuts, I bet no one would be upset if you added columns to the supported models spreadsheet for various Tx configs, and started adding the links to it.

A curated collection sounds good. It would help newcomers get started more quickly and easily. And get new Deviation habits off to faster more positive starts. It might also help the more resourceful among us to more easily see what models could use embellishing or polish. A synopsis of each model and it's features could lead some to want those features for their favorite model. More cool Deviation features on more models would likely lead to more innovation and even better ways to organize the user interface.

So, who's going to be a curator? I can't think of anyone ongoing contributions that I think are worth giving up, and I'm loath to ask someone who's already contributing to donate more time to a volunteer activity.

So unless you know someone who's willing to take this on - I'm going to ask a retired librarian friend of mine about it, but don't expect much - it isn't going to happen.

Eventually including a photo or two of the physical model in the collection might be nice too. If I'm contemplating an addition to my model collection I'd probably prefer to look at Deviation compatible ones first. Having photos and all the other Deviation data together would create a great place to come and daydream.

Who knows, maybe manufacturers would begin to see the value in making their offerings Deviation compatible.