Deviation v5.0.0 build with latest protocols

kmewes wrote: Can someone please fix the problem with the DSM2 protocol that still seems to exists as of NB 9-11 with the Cyclic1 and Cyclic2 being switched when using the Swash 3servo 120 setting?
It seems that the Aileron and Elevator labels/assignments need to be swapped in the D/R settings.
It only works for me with the Blade SR when I swap AIL from Cyclic1 to Cyclic2 and ELE from Cyclic2 to Cyclic1.

There are so many side dependencies (including mixer C code).
There is NOT an easy "one fits all" solution.

This has already been described by me in the offical "5.0.0 release" thread: www.deviationtx.com/forum/6-general-disc...eased?start=60#53953

You can download some heli templates from my "Heli developer analysis" thread.

Thanks for clarifying this. I just assumed that the Blade SR was a common DSM2 Spectrum 6CH configuration. But there are probably many DSM2 configurations out there. It is not a big deal as long as Deviation users are alerted to the fact that they need to check these aspects of the protocol and make changes if necessary. Seems there are no clear standards since this is an open development system and many people having access and input, which are btw doing a great job, and that includes you (-:, in providing an excellent and useful product for many of us.

Thanks again and Best Regards.

Actually, part of the problem is that DSM & DSM2 are closed source, proprietary protocols that have been reverse engineered - to a degree. There are a number of issues with our implementation, but they are largely relatively minor meaning the effect relatively few people, there's an easy workaround, or both. This hits the last one: it only affects people who are using older FBL helii's, or insist on using a CYCLIC mix where it isn't required (and yes, I know why you would want to), and the easy fix has been outlined here. Personally, I've got a project that have been on hold for years now because Deviation's implementation of DSM won't talk to some of the Spectrum DSM flight controllers with integrated receivers if you set them to more than 7 (or is it 6?) channels. There is no workaround, but that's a situation that even fewer people run into.

Thanks MWM for that info and clarification. I realized, especially since I am setting up the new Jumper TX that all software can be user configured given there are options built in. Deviation seems to let all the crucial settings be configured and there is no need to get caught up in 'norms' or 'standards' that much anyway. As long as the transmitter can reliably communicate with the receiver in the end everything is fine and I have the means to get there in software. I have coded quite a bit myself before I retired and I really do appreciate the skill and all the work/time everybody has put and will put into this development project and am glad and thankful you all did.
To all keep up the good work and happy flying.

excuse me，Is it possible to add a voltage trimming function in the next version?

52dgj wrote: excuse me，Is it possible to add a voltage trimming function in the next version?

It's possible, but unlikely. It's been discussed a number of times, and never happened because:

1. Getting most voltages correct requires trimming multiple variables
2. The correct function may have a different forms for different transmitters
3. It's just not all that useful.The only important use is setting the alarm, and you can adjust that already
4. So most developers feel there's better use of their time

That said, someone (you?) may decide it's worth fixing for their transmitter and create a pull request for the resulting changes, so it may show up.