Possible brown outs ?

I 100% agree with you. I've got 5 of my buddies setup with devo's and after the nightmare that the first guy went threw on his own (with a step by step walk threw from me) I gave up and now I just have them get parts delivered to me and I do it for them.


I love devo and the guys here but I hate this Web site. Posts don't even show dates on mobile, search doesn't work, updated FW's are hidden in forum posts. I'm not a dev but I'd consider myself a "power user" and 90% of the time I can't find answers to my questions and have to post. The documentation for 4.0.1 is OK (not great but pretty good) but it's so far out of data very rarely does it answer a question I have about the nightlys.
I've made several requests to be given permission to edit documentation, they're not even responded to anymore even tho I include specific changes I'd like to make...

Again I LOVE deviation, I love what people here can do but I wholeheartedly agree with you that this site is terrible, could it be made better. Of course, but the ones of us that ask to arn't ever responded to and the ones who are in charge seem to have zero interest.

The 4.0.1 manual isn't likely to be updated. The source for the nightly manual (links in the left nav menu) is available in bitbucket.org/deviationtx/deviation-manual-rst , and you issue pull requests for it just like you do for the firmware. Ping a dev here if a PR sit around for to long.

The best way to deal with the sucky search is to use Google's site: keyword. Type in the search keywords, then site: followed (without spaces) by the URL for the forum, topic or thread. This not only works better, but you can do a thread search, which the site search doesn't have.

My blade 180cfx crashed yesterday due to brownout. Its FBL was working, but I could not control it with my devo 10. After power cycling my transmitter connection started to work. I think it was because I did recently enable telemetry, and I'm using the latest release with not so well known issue that locks devo 10's CYRF chip. Apparently it is fixed in nightly builds, but I would not dare to use some completely untested software. I rather stick some old version with more mileage by numerous users.

I like to use deviation and it think it is good project. It would be even better project with improved documentation and release process, where last known good release would be updated with critical bug fixes. Why there aren't any new releases? Which version new users should use? Is there more similar known issues that could cause crash?

What makes you think the nightly build is "untested"? Or has less testing than the release build? Or for that matter, less testing than what Spektrum releases?

As you noted, there are fixes in the DSM protocol that aren't in the release build. There are no new features in the protocol - even though we have some that we think would make things a lot better. Specifically because we didn't want to risk breaking the DSM protocol without more warning.

I run the latest nighly for everything - including my $1K aerial camera platform. I always (always, ALWAYS, ALWAYS) test that everything is working properly after any significant work, on either the aircraft or the Tx. This won't catch brownout issues, but as you noted, that's more likely with DSM on the release build than on the nightly.

To be exact deviation might not be _completely_ untested, but there is a big difference on how many people is using it and how often it's updated. Latest nightly build might be just few days old and with very few people using it. It gets very small test coverage compared to some common Spektrum model with thousands of people of using it over many months. Same rare bugs, like the brownout issue, don't get easily caught by tests done some individual developer. Where I come, software is considered untested if only few developers have been running it - we have separate group of people torturing sw and trying to bend it until it breaks. I don't think Spektrum developers are any better, but large number of people using daily kinda proves it stability and most critical issues has been ironed out in it's latest firmware.

Normally in every other project I would not think using some automatic nightly builds - they are almost never recommended to be used by regular users. Unlike most other open source software, deviation crash could cost many $$. It should aim for better than average stability & reliability. If nightly builds here are considered better and more stable than last release, why don't you just go ahead and make 4.1 release candidate? You could ask more people to do testing to find out last remaining bugs to get more stable release. I could volunteer for testing it and probably many others could also.

Deviation should aim to get rid of it good only for cheap toys status. It's reputation will stay such, if there is know critical issues in latest release. I think deviation could be as good and reliable as spektrum, futaba and others, but for that it should have stable release with known critical issues fixed. Bug fixes could be back ported to last known good release. That way there always would be stable release without any major issues. At minimum there should be list of known critical issues with the release. e.g. warning 'do not use telemetry while flying'. I could have easily avoided my latest crash, if I would have just known about issues with telemetry.

You're absolutely right - we don't have nearly the test coverage of a Spektrum transmitter. Further, if you fly with deviation instead of a Spektrum transmitter, you can't get Horizons support, which is really good. I keep a Spektrum Tx around to maiden all my DSM aircraft with, since if the aircraft fails & breaks, HH is likely to replace it if I use the Spektrum Tx but not if I'm using deviation. After that, I move them to deviation because it's so much more capable than Spektrum, and the Devo transmitter generally provide better quality for the cost.

On the other hand, the deviation coverage is worth a lot more than the Spektrum coverage. We have a public bug tracker so you can see what issues people are having, and possibly even get workaround or fixes for them. The problems are also discussed on the deviation forums. Spektrum has neither of those. They generally won't admit a problem exists until it's pretty much public knowledge anyway. THen most often all you get is a tech note hiding under the support tab on the product page that says "Don't turn Wifi video streaming on ...." or "Don't use the original ..." or "Check ... before flying to make sure that ....".

But you're not comparing it to Spektrum, you're comparing it to the release. And yeah, the nightly is just a few days old, but that doesn't really tell you how many people are using it and how long they've been doing so. For instance, changes that don't affect the firmware - like turning on the layout editor in the 7E emulator, or optimizing the build process - will trigger a nightly build. Changes to a specific protocol - or even adding a new one - which are the most common change we have - will have new code that won't be run, or even loaded into memory on the 7E and F7, unless you're using that protocol. Changes specific to a transmitter - like adding support for extra switches on the 6S, fixes to the 7E build, font fixes on the 12, and so no - won't affect the code on other transmitters. In fact, once you exclude those things and minor bug fixes - like making the Ext button work in USB mode - the last major change in the code in the nightly build was July. At that point, we were preparing for a release and had fixed most of the major bugs and brought the manuals up to date. Which is why I have no problem controlling four figures worth of aircraft with my Devo running a nightly build.

I pretty much agree on everything you said. Devo is better value than spektrum. I'm also big fan of open source software. Forums and bug tracker is good source for information, but it's also a bit too much - not everybody are following every thread and some information is a bit hard to understand. Experienced developers have much better understanding, but for newbie users, like me, it's hard to find out all relevant issues. If I need to start going through bug tracker tickets or change sets in version control system while guessing their impact to nightly builds, it's too much.

Novice users need some known good starting point. Currently from web front page I would go getting started guide and it says go to downloads, deviation releases. I did check, FAQ, Release notes and user manual. I did read many recent posts to forums I did not find anyone mentioning any serious issues. Even if information is available in some almost a year old tickets & forum posts, it's not easy to find.

I'm now building > 500$ helicopter and this makes me wonder if dare to fly it with my devo 10. I've been using deviation over a year with my other models and so far have been very happy using it and recommending it to others. However my recent crash makes me doubt, if I should downgrade my opinion on deviation back to 'only for cheap toys that are meant to crash often' and buy some known good tx to fly more expensive models. I really hope that quality of deviation would be such that I could use it without any doubts.

Why are you talking in this thread about (DSM2) BROWN OUTS when it was clearly not a problem of RX power voltage dropping < min RX voltage needed but more a HF link / chip hangup (loss of connection)?

I tought DSMx quick connect strategy has a different re-link concept so to be able to avoid brown outs??

BTW: How many threads "in that kind" do we have now on forums for the same issue either for OrangeRX, Lemon, DSM, Walkera active? 2? 3-5? More?


Question: Are you really 100% sure that is is only this RF channel fix on CYRF reset on this issue?
May there be any nightly-build DSM/Walkera code protocol changes >V4.0.1 which may have improved something too?


DSM release testing:

I have been successfully flying (testing flightlog telemetry) Spektrum DSMx@100mw since with nightly build fcd0669: bitbucket.org/deviationtx/deviation/comm...0194b07111d33db09bff

Successful report nightly build fcd0669 on "DSM telemetry support" thread: www.deviationtx.com/forum/protocol-devel...ktop&start=340#33913

Nightly build 92e1705 (PhracturedBlue repository) has been working for me too (flying Blade 200QX in 02-03/2015):
- which does NOT contain all the already made DSM telemetry enhancements (showing >255 numbers)
- which does NOT contain "RF channel fix on CYRF reset" from 2015-04-20 commit
- with Devo10: even with TURNED ON DSM telemetry / FlightLog. Not any holds or Framelosses>40, crashes, bind/re-bind problems.

I can't remember exactly but I guess I had also tried Release V4.0.1 for a short time on Blade 200QX to compare DSMx FlightLog telemetry with no overwrites vs 92e1705 nightly build overwrite bug (Fades/Holds/FrameLosses).
Not sure about 4503D/AR8000/TM1000...probably not.
For sure I was not running V4.0.1 release long enough as I had seen the 0xFF FlightLog issues soon and started my own nightly-build development.


Release candidates:

There have been 3+ threads already talking about new release candidates off a nightly build.
I have to give up on searching for more as the forum even does NOT allow threads/heading view only but always shows full postings-view on the search result.

Maybe you could move upcoming basic release / handling discussion (beyond the closed technical issue) there??

Release threads:
Preparing for next deviation release: www.deviationtx.com/forum/7-development/...xt-deviation-release
Is a Deviation v4.1 release on the near horizon: www.deviationtx.com/forum/7-development/...-on-the-near-horizon
Any Plans for Next Release? www.deviationtx.com/forum/7-development/...ans-for-next-release

Another thread e.g started a new discussion with Hexfet and me and had opened another code mixing change for CCPM120 heli...still untested on my side. Tim PMed me yesterday that it is not working on his side. I have now updated 3-4 heli threads. I am not allowed to link to the thread when I edit (too many links).

In general we did not process much further because of a little more expected telemetry / flightlog testing on DSM protocol (and probably Walkera).
We had introduced some telemetry flightlog enhancements while Indigos test build release also must be detail-tested for DSM protocol changes (and telemetry packet filter improvements) further...
This is why it's a developer (trunk/default) release...it does not need intensive / planned detail testing first for code commit.

Yes, you may be right. Maybe we had missed that release candidate point back in May to June 2015.
Looking at how many code changes are committed in general into nightly-build past months (congrats to all devs for their hard work), or code have to rollback 1-2 days (because of maybe a little merge mistakes), I guess we did so


Well, I do not own too many crash-proof planes / EPP planes (200QX Mosfet ESC burnt so no Armattan Morphite 180 testing). Other developers probably neither.
Other developers which are into detail DSM/mixing code may not even own the required full hardware for testing (e.g Spektrum TM1000, AR8000, AR6210, Paddle Flybar 120CCPM heli) and telemetry sensors
So it takes time, test concepts, back and forth enhancements to really get further for a new planned release candidate.

However I can also understand that no new DeviationTX pilot wants to scan the last 10-20 pages on a protocol thread if it is safe to fly.


Short-term suggestions:

- creating a new release V4.0.2 with this fix
- by: backporting 572e350 "Necessary RF channel fix after CYRF reset" from nightly-build to V4.0.1: bitbucket.org/deviationtx/deviation/comm...da07ab84befd1d48ae9a
- planning for a schedules nightly-build release candidate in the 2-3 other threads for DSM/Walkera protocols (including telemetry enhancements)
- defining a (ground range test + in-flight) test-strategy which also includes parallel testing Indigos bigger DSM protocol changes / enhancements (I guess there might be not be only one nightly-build RC4.x.x)

Updated ideas for documentation:
- creating a STICKY thread with links to other threads about V4.0.1 telemetry / hangup / freeze issue (if that is the case as I understand it now)
- mentioning V4.0.1 telemetry / hangup / freeze issue on entry DeviationTX homepage and need to upgrade / turn off telemetry (if that is the case as I understand it now)
- updating ReleaseNotes on V4.0.1 for telemetry / hangup / freeze issues (if that is the case as I understand it now)
- updating ReleaseNotes on V4.02 for included telemetry CYRF reset fix
- ReleaseNote for a future newer V4.1.x release candidate: including note for RF channel CYRF reset fix

Please let's split / move upcoming basic release / handling / branch fixing / branch parallel (well-tested) development discussions (beyond the answered technical issue) to one of the existing release threads or open a new thread. This feels to be the wrong thread for archive search for that?!

My 2 cents

Thomas

aivo wrote: I'm now building > 500$ helicopter and this makes me wonder if dare to fly it with my devo 10. I've been using deviation over a year with my other models and so far have been very happy using it and recommending it to others. However my recent crash makes me doubt, if I should downgrade my opinion on deviation back to 'only for cheap toys that are meant to crash often' and buy some known good tx to fly more expensive models. I really hope that quality of deviation would be such that I could use it without any doubts.

You have been flying with this / your DeviationTX version for 1 year for multiple planes and now you crash?
Sorry, I do not understand.

What have you changed? Transmitter? Release version? Protocol? Telemetry OFF/ON?


Yes, it makes IMHO no sense to fly a >500$ expensive helicopter without previous testing your installed build version some weeks with a crash-proof (EPP) plane or quad.

If you do it wrong with e.g a Spektrum DSMx equipment (cut off low voltage BEC which can not handle ampere of your FBL servos, CFK frame which fades antenna, no Spektrum FlightLog ground/flight testing, corrupt/low-power <18db HF-module in a Spektrum transmitter, etc.) you will be crashing anyways!

Thomas

Brownout was my first though immediately after the crash, but as you said it probably was not it. I just found this thread discussing similar symptoms and pointers towards CYRF reset issues.

I'm not 100% sure that it's the same issue. Symptoms do match, but I have not tried to reproduce the issue. It could have be something else. I just know that powercycling transmitter fixed my connection issue, so that is why I'm guessing it actually is TX issue and not brownout or other RX side problem. Are there some logs or anything else that I could look at to find true cause?

If you make 4.0.2 with fix for the issue, I can try testing it. If it helps I can also try to reproduce the issue, but if it is that old well known issue, i'm not sure if its worth the trouble.

Anyways thanks for your comments. IMO implementing your suggestions would help making deviation even better.

I used different tx (devo 7e) for over a year with super cp (cheap helicopter). Now about for a month I've been using devo 10 to fly super cp and blade 180 cfx (not so cheap heli). Last week I enabled telemetry and last weekend my 180cfx did crash due to issue mentioned above. I was planning to try devo 10 to fly my new and more expensive helicopter with devo 10, but I now think it failed the test with cheaper models. Atleast the 4.0.1 release that i've been using in my both TX. I wish to find the true cause & fix for it so I could do more testing before testing my new helicopter.

Well, try to hook up on a AR8000 or AR6210 or RX of that type + TM1000.
At least you do get Spektrum FlightLog with TM1000.
But you really need the Nightly-Build for it because of several FlightLog improvements.

There is a way to enable telemetry logging (Fades, FrameLosses, Holds).

However I was not 100% successful to read / convert the binary because of column mismatches.
Would have to re-test...
Last year I tried to enlarge the file size manually a little bit, but suddenly my model.ini files where not written anymore correctly.
They stopped in the middle, leaving out complete [] blocks
You really need model.ini backups!!

Yes, I believe that that once you upgrade to a newer nightly build and set it to at least 100mw output power you might see it working fine.
If I can fly my 4503D on AR8000 (more far away, not only hovering) you should be able to fly a smaller heli
Maybe try to get a V120D02s with just ~100g either with the Walkera FBL or upgrade to any other FBL (e.g Neuron FBL, ZYX-s, Spartan Pico, uBrain, GY280RX)??

At least you are already on DSMx...

Well, the 180CFX with almost 200g is not really the kind of heli you want to crash either.
Better try something IMHO more crash-proof, e.g Armattan Morphite 180 3mm CFK 3K frame with lifetime warranty.
Or some rc-factory 8mm EPP 3D plane...

The Deviation web site and version control have been out of whack for a long time. Ever since PB disappeared.

The release is way out of date. And what is left is an odd cross between beta and support.

About as reliable as a new Microsoft release ... :-/

Beta? I don't think so as my previous DSMx flight-tests including telemetry had successfully shown...

As mwm said: There have not been too many (fundamental) DSM protocol changes between nightly-build 92e1705 and fcd0669.

Could you check for fundamental / very many DSM code changes from V4.0.1 to nightly 92e1705 Richard?

I believe it was already mentioned in a thread by a developer that there have NOT been very many fundamental DSM code changes from V4.0.1/4.0 branch to 92e1705 / fcd0669 nightly builds as well as?


My personal opinion:
There have not been too many pilots actually activating / using DSMx telemetry, either like 180CFX/200SRX/230s/200QX FlightLog in-built or TM1000/TM1100.

e.g I had found telemetry bugs in 2015 in nightly-build 92e1705 (which are fixed) with limited 0xFF=255 FlightLog field width so there obviously have not been too many telemetry testers / users who come from (DX8/DX18/DX9) Spektrum gear and used FlightLog before.

Thomas

I updated above short-term suggestion block with some more ideas: www.deviationtx.com/forum/6-general-disc...-outs?start=20#44216

While there may have been lots of changes that's not the issue. Beta is short for Beta Testing.

There has not been nearly enough testing at each stage. Especially before heaping on new changes. The current organization of this site and the methods used to develop and control releases doesn't support it very well.

Good, controlled development of a software product has little interest in lots of changes and a whole lot of interest in testing per change.

I'm not trying to be critical so much as reporting what I see. I like Deviation a lot. But my current models are small and inexpensive. Deviation used to be better controlled. It's been partially rudderless for some time. It would be good to fix that somehow.

"Rudderless" is all to accurate. Our rudder - PB, the creator of the software and general project lead - has been missing more often than not over the past two years. People were even saying that the project was abandoned until I created the deviationTx team repository and started getting the active developers to commit to it and builds from that. PB reappeared briefly over the summer, and I put all my development work on hold to get the outstanding major issues fixed and the manual updated, but he vanished again before creating a release.

Unfortunately, the release process is undocumented, and as far as I can tell, the only difference between a release and the nightly build is that the release version is stagnant and has the "release" label. As you say, this means that it gets more use, so more problems get discovered. But they don't get fixed in the release, they get fixed in the nightly - which is why the current nightly build is more stable than that antiquated release. That wasn't true before our efforts this summer, and it might stop being true if there is significant work committed to the nightly build - but that doesn't seem likely in the near future.

if I could, I'd delete that old, obsolete release from the download area as the simplest solution to the current problem. But I can't. That I can't is also why there won't be a release any time soon. Sure, I could cut one and do whatever testing I deemed appropriate and put it up for download - but since I can't put it in the release download list, what would be the point?

While you may prefer the waterfall model for software development, deviation is currently using an agile development model. Whether or not it's the right choice is certainly open to debate, but it's not really something we can change in the current situation. If that makes you want to abandon deviation, that's up to you. I've never had an issue with people who insist on Spektrum (or Futaba, or whatever) at both ends for reliability reason. I do find it a bit odd if they only want to use Spektrum for one end or the other, or if they are flying aircraft they built themselves, as if hobbyist quality is good enough at one point in the chain, it ought to be good enough all the way through.