Preparing for the next Deviation release

There should be no changes to the firmware. dfu.py is the tool that turns the binary built by the compiler into a dfu. I was looking at it for the bootloader changes, and noticed that it had a truly awful bit of python code in it - probably written by a Perl programmer who didn't know the proper Python idiom. So I fixed it.

As noted, all it does is improve the algorithm that does the encryption, changing it from the O(n²) algorithm resulting from string concatenation to an O(N) one you get with idiomatic python.

Just figure out a better way to do the merge, that is to make use of "compare" function in bit bucket then followed by merge.

Was going to post this in a different thread (where blackmoon's quote is from) but I think it fits here better...

blackmoon wrote: That we want it or not, sometime in the future the Devo7E code needs to be froze and no more should be added to it (it is already a very capable TX), those who want more should be directed to the Ultimate mod. Granted you need to have a "little" soldering skills to replace the mcu, but a lot of people have done the transceiver diode mod and succeeded.

Tho I hate to see development on ANY product I use (especially something I'm as invested in as the 7E) but I believe this is the route to take.

The custom botloader mod is going well, the rest of the code works great, IMO it's time to do this. Lock the 7E code where it is and use the "4-6k" worth of space gained by removing the BL to be used for protocol expansion on the 7E only.

I've been pushing the 7E to my club buddies, also this past flying season I've personally build several of them for my friends, they work OK with whatever nightly is out at the time but at the end of the day I would prefer a stable "final" release on the ones I build for others.


I definitely agree that no new features, especially something as processor intensve as lua's should be heald back cause they're not suitable to the 7E, this would be a shame to the rest of the Devo7E line to limit them based on the weakest link. I know it's always been PB's philosophy to keep deviationtx compatible across the line but hey, I know most people are happy with the 7E code as it sits, wouldn't be disappointed if the others are developed further but we already don't support the 7 at all so we're eons ahead for that. Would anyone actually be sad stopping development on the 7E?

Obviously I'm a user, not a developer (and specofocally im a 7E user) but in my opinion I'd hate to see anyone not pursue an idea cause it's not feasible on the 7E. The direction devo has been going (and the amount of development in the last 6 months) is amazing, I 100% concur it's time to leave the 7E behind. It's not like it'll suck when that happens, the 7E is a great tx as it sits now...

Cereal_Killer wrote: The custom botloader mod is going well, the rest of the code works great, IMO it's time to do this. Lock the 7E code where it is and use the "4-6k" worth of space gained by removing the BL to be used for protocol expansion on the 7E only.

Those are different types of memory. There are three types of memory in the Devo transmitters:

SPI Flash is what shows up as the USB disk. It's where model files, transmitter settings, images, etc. are stored. And on the 7E, it's where the protocols are stored.

CPU Flash, or ROM, is what you install via the DFuse program. It's where the deviation program lives, and what the bootloader replacement will free up.

RAM is used for running program data, and the 7E loads protocols into it to run them. Those are loaded as needed, and adding more uses SPI Flash, not RAM. But some of the larger protocols are running into problems with this.

I've been thinking about a fork of deviation as well, and think that the one suggested here is the wrong one.

The question is - what do you want your 7E for? I see two draws for deviationTx: one is for people coming from hobby-grade RC gear who want a really powerful computerized Tx. I think those people should be looking at moving on to a more expensive Tx. Either one of the full-size ones, or a 6 if they like the small form factor. But another group is drawn to the 7E because it can fly all their RTF aircraft, mostly quads. I think we need something with a completely different user interface for them. Throw out the advanced gui and most of the features that come with it, and give them something like the standard GUI, designed for those RTF quads: no pitch settings, add functions for flipping, camera control, and calibration, and extend the protocol channel ordering stuff to include those functions.

I respectfully disagree, people coming from RTF quads , a model file for a toy quad or even Hex is quite easy. For the others, I think like many, I do wish the power of the 10/8 in the 7E.

Why ?

- sun readable display, I didn't go the 8s or even 6s for that reason alone, it's why I have a 10 and 7E.
- form factor, unbeatable one, I have a friend that flies Multis for living (uses Futaba), I made him buy a 7E and did the mods for him, now he wish he could only use the 7E even for work. That will never happen of course to much at stake if something happens, and it happens even with the Futaba and the likes.
- lets not forget the fun one have modifying his 7E

For all these factors the Ultimate7E is the answer, PB only did it, I presume, because he said a few time how not fun it was to code for the 7E with the TX limitations, I'll be happy if he pursues it.

mwm wrote: Correct, the disabled telemetry is only disabled on the 7E.

For now, this is only available in my FrSky test build. Be warned that I changed the order of elements in the DSM version, so code that processes datalog files may need to be changed as well.

I am running the latest nightly build on my 6s and it appears the DSM telemetry is turned off on the 6s too.

blackmoon wrote: I respectfully disagree, people coming from RTF quads , a model file for a toy quad or even Hex is quite easy.

I suspect all of people asking for model files and/or help in modifying them would disagree with that. I certainly do.

For the others, I think like many, I do wish the power of the 10/8 in the 7E.

I'd be surprised if it were many, at least once you discount those put off by the cost. By the time you've done everything to get there - replacing the MCU so all the features fit, adding more switches (which is harder than on the 6S, and requires a new MCU to get to the 8/10 set), and replaced the sub-6/8/10 gimbals, the price difference has started to look a lot smaller. Of course, your transmitter is the only thing you actually touch when flying models, so it's clearly not the place to economize.

I'm sort of surprised that you like the idea of having to use an OTG cable to change even stuff as straightforward as the model. I mean - why bother with something as big/bulky/expensive as a 7E? Why not go for a really small form factor and even easier to read display, and use the Proto X RTF Tx?

I have a friend that flies Multis for living (uses Futaba), I made him buy a 7E and did the mods for him, now he wish he could only use the 7E even for work. That will never happen of course to much at stake if something happens, and it happens even with the Futaba and the likes.

Well, it's expected that any simplistic description of the user base will miss quite a few people. And yes, I'll acknowledge that my division is simplistic. The question is whether or not there's a more accurate one, and once you have an accurate description, whether any single contingent is a majority that might be targeted by a fork for the 7E.

lets not forget the fun one have modifying his 7E

That's the best reason in the world to buy a more capable Tx.

djarchow wrote:

mwm wrote: Correct, the disabled telemetry is only disabled on the 7E.

For now, this is only available in my FrSky test build. Be warned that I changed the order of elements in the DSM version, so code that processes datalog files may need to be changed as well.

I am running the latest nightly build on my 6s and it appears the DSM telemetry is turned off on the 6s too.

You seem to have grabbed the tail end of an unrelated conversation. We are talking about my having disabled some FrSky telemetry features on the 7E, but only ones I had added in my test build. So if you're using the latest nightly, you won't have those features on any transmitter, And they weren't in the DSM telemetry at all.

If you're just having issues with DSM telemetry on the 6S and the latest nightly build, have you turned it on in the model in question? Because while it's off by default, the switch to turn it on is certainly on my 6S running the latest nightly.

mwm wrote: I'd be surprised if it were many, at least once you discount those put off by the cost. By the time you've done everything to get there - replacing the MCU so all the features fit, adding more switches (which is harder than on the 6S, and requires a new MCU to get to the 8/10 set), and replaced the sub-6/8/10 gimbals, the price difference has started to look a lot smaller. Of course, your transmitter is the only thing you actually touch when flying models, so it's clearly not the place to economize.
...
That's the best reason in the world to buy a more capable Tx.

I do have/had "better capable" transmitters, and ( care to explain what's the definition of better capable tX ?) in fact I owned a JR one, that was sold, for lack of use and the DEVO 10. I never thought of buying any of the devo line even with deviation, until sunsuv forked the Devo8 code to the Devo10, color screen transmitter and lack of readability in the sun, not for me Sir. Is that your definition of a better capable TX, one you can't even tweak your model in daylight ?

I'm sort of surprised that you like the idea of having to use an OTG cable to change even stuff as straightforward as the model. I mean - why bother with something as big/bulky/expensive as a 7E? Why not go for a really small form factor and even easier to read display, and use the Proto X RTF Tx?

You should be because I never talk about using a OTG to do that, in the thread you think you read that, you were the first talking about and OTG cable to plug your TX to phone (or tablet), then another poster talked about having one model alone in the TX to gain space.

I merely said if (read big if, English is not my first language, sometimes I take short cuts ), you have to take that way, I would prefer (not that I like that) to have ten model kept in the transmitter and not one. I wasn't enough technical to think about bluethoot or wifi even. But, Ho no! You had to mod your devo to do that, certainly not on par with your "better capable TX" definition...isn't it.

I suspect all of people asking for model files and/or help in modifying them would disagree with that. I certainly do.

I'm sorry if this sounds arsh, but people that are to lazy to read the manual, and/or your very well written guide on model file .ini, should be using the Proto X RTF Tx, they don't deserve to be using deviation, period!

I really dislike when people make assumptions on others writing, or maybe I should put that on the back of my lack of the English language subtilities, and set it aside.

For now on I'll refrain myself of posting anything related to these matters, God forbid I steal someone's candy...

Doing things by the least common denominator, is not the way to go forward, never forget that.

Over and out, already way to much of topic!

(sorry for the noise, guys)

blackmoon wrote:

mwm wrote: I'd be surprised if it were many, at least once you discount those put off by the cost. By the time you've done everything to get there - replacing the MCU so all the features fit, adding more switches (which is harder than on the 6S, and requires a new MCU to get to the 8/10 set), and replaced the sub-6/8/10 gimbals, the price difference has started to look a lot smaller. Of course, your transmitter is the only thing you actually touch when flying models, so it's clearly not the place to economize.
...
That's the best reason in the world to buy a more capable Tx.

I do have/had "better capable" transmitters, and ( care to explain what's the definition of better capable tX ?)

In this case, I mean one with a µ-controller with more flash and ram, so we don't keep running into issues with lack of space on the damn thing.

I'm sort of surprised that you like the idea of having to use an OTG cable to change even stuff as straightforward as the model. I mean - why bother with something as big/bulky/expensive as a 7E? Why not go for a really small form factor and even easier to read display, and use the Proto X RTF Tx?

You should be because I never talk about using a OTG to do that,

My apologies - I could have sworn I saw your name on the post when I went back and checked, but looking at it now, it's not.

Which leads to the other question: we have two suggestions for how to deal with the 7E's poor hardware beyond the ongoing scrabbling for space & taking out features:

1. Move the setup to your smart phone, and talk to it via OTG (no hardware mod) or some form of RF (with a hardware mod)
2. Change the UI to target the majority of users.

Care to pick one? Or contribute a third?

I suspect all of people asking for model files and/or help in modifying them would disagree with that. I certainly do.

I'm sorry if this sounds arsh, but people that are to lazy to read the manual, and/or your very well written guide on model file .ini, should be using the Proto X RTF Tx, they don't deserve to be using deviation, period!

Well, I don't think setting up a build environment and compiling your own version of deviation is any harder than creating model files and the like. After all, the instructions are right there in the source.

So that opens a third possibility I missed: quit distributing binaries for the 7E and make more features use conditional compilation, then let people build their own binaries. If they can't do that, do they deserve to be using deviaiton?

Doing things by the least common denominator, is not the way to go forward, never forget that.

If it's not clear, I was being sarcastic above. Well, partly. If we could provide a downloadable GUI that lets you pick features and then "install" to build a custom version, that would work. But otherwise, no.

In spite of the activity here, deviationTx isn't all that popular. Discouraging people because they feel lost isn't going to help that. Helping them over the hump - pointing them to the manual and the downloads section and so on - will keep them using deviation, and hopefully turn them into members of the community who can also contribute. That's why I wrote that "well written guide on model file .ini".

Growing the community is also why PB has resisted putting in anything that would make the 7E code even less compatible with the rest of the code. Encouraging newcomers is why he rejected my suggestion to take the standard GUI out of the 7E build to get more space when I suggested it to make room for the new toggle code (sigh).

Over and out, already way to much of topic!

I think this is a vitally important topic. Maybe it deserves it's own thread.

Yes... own topic.
Actually, seeing THIS topic having lot of new comments, I started to think there was hope again for a new full release...
Now I am heartbroken again.
(btw. back to topic: how are we doing with prepping the next release?)
Cheers,
bm

Next release is on hold until PB re-appears.

Which leads to the other question: we have two suggestions for how to deal with the 7E's poor hardware beyond the ongoing scrabbling for space & taking out features:

Move the setup to your smart phone, and talk to it via OTG (no hardware mod) or some form of RF (with a hardware mod)
Change the UI to target the majority of users

Care to pick one? Or contribute a third?

No, but we really do need a thread on this matter, I'd be happy to read about those suggestions, as I don't understand quite well how they be useful or implemented.

Well, I don't think setting up a build environment and compiling your own version of deviation is any harder than creating model files and the like. After all, the instructions are right there in the source.

So that opens a third possibility I missed: quit distributing binaries for the 7E and make more features use conditional compilation, then let people build their own binaries. If they can't do that, do they deserve to be using deviaiton?

I did in the beginning and yes it isn't that complicated, and I was being rude when I wrote the comment about new users. So, I do apologize to all for that, after all I also was new to deviation one day, I tend to forget that.

Growing the community is also why PB has resisted putting in anything that would make the 7E code even less compatible with the rest of the code. Encouraging newcomers is why he rejected my suggestion to take the standard GUI out of the 7E build to get more space when I suggested it to make room for the new toggle code (sigh).

I think this is a vitally important topic. Maybe it deserves it's own thread.

Care to start that thread, on what to do with the 7E ? I never was good a thread subjects, thank you.

"Next release is on hold until PB re-appears."
That is... not a good news.

Don't take this wrong, because I didn't follow this thread or any other development for that matter, just use the nightlies since the beginning.

Is there any new feature that people are so eager to have, that a new release is paramount ?

Or is it just the even number release syndrome kicking in ?

When I was using ER9X before deviation, eons ago, there wasn't any releases at all, the firmware was in constant evolution a little like the nightlies (well with new things added, granted), so why the imminent and present need for a new release?

PB started this thread because he feels that some people are scared off by there not being a "release" to run. I actually proposed not doing releases and just having nightly builds - ala ER9X and OpenTx, which I came from - early in the thread, and he nixed it because of that.

And there are lots of new features and bug fixes in the nightly builds. New protocols is a big one. Support for the multimodule. A variety of bug fixes, including some protocol fixes. Support for extra switches on the 7E, with extra inputs on the 6S in the works. The last release is over a year and a half old.

Frankly, I agree with you - we should just punt the release. As part of doing the prep work for a release, I triaged the bug database, and we got to the point where all the serious bugs in the nightly were also in 4.0.1, and a fair number of serious bugs in 4.0.1 had been fixed. The online manual also describes the nightly, not 4.0.1. So the nightly has lots more features, fewer known bugs, and a more accessible and accurate manual. I no longer have any qualms about recommending people run the latest nightly.

Ok, before starting a new thread discussing what to do about the 7E (and the like), I figured I'd try and survey the user community.

You can find the survey I've created to do that at goo.gl/forms/3JR1CwDdYS . I'm posting it here, instead of creating a new survey, because at this point I'm looking for feedback on the form. Anything you'd like to see that I missed? Is it to long? Anything that should change - better wording,etc? Anything you think should be deleted?

If you fill it out before I announce it in a new thread, your answer is going to be deleted.

I think it's ok like it is, lets hope that a fair amount of people will fill it when the new thread is up, and give to the devs a good sense of where deviation stands. It would be nice that people that frequent other forums to link to that thread and explain the reason for that.

I do think, contrary to the actual belief, that deviation is used by a larger number of people that don't understand English and rely on their primary spoken language forums to gather information about it.

There is no indication of which way the ranking goes on one of the questions.