New v4.0.1-ef0d76d

Hi, I have seen that there is a new build but I can't find any information regarding the improvements or things that has been upgraded. Is there a link somewhere? Thanks.

Check the repository and the commits there. All the ones leading up to that hash are included in the build.

bitbucket.org/deviationtx/deviation/commits/all

The list of merged pull requests is a bit higher-level, but not as easy to tie to a specific hash.

+hexfet, do you believe your recent channel reordering fixes deal with the occasional cases we've seen where the channel order winds up wrong, so people switch modes to get the throttle where they want, or tweak the mixer than have to go edit the Safety settings? I believe we have an open issue for this, but have never been able to reproduce it.

Two incorrect behaviours were fixed:

1. Scrolling through the protocols all the way to PPM then back to a radio protocol would cause the aileron and elevator channels to be swapped
2. Loading some of the template files would result in mixed up channel order because the templates were not written for AETR EDIT: EATRG (which is assumed when loading templates)

It's possible these explain some of the reports of reordering...

Heli Cyclic CCPM Cyclic1/Cyclic2: www.deviationtx.com/mantisbt/view.php?id=624

Do you think this is fixed for the simple heli mixer GUI (simple heli template)?
I still believe it is more of a bug because of fixed code in the mixer_standard.c.

It is N O T channel / protocol specific (neither works with DEVO + DSM) too. Not sure because of Mode 3.

Both helicopter templates were updated, so the channels should now be correct after loading the template. If you see an issue without using a template then it's probably still an issue.

Updated the #624 Mantis bugtracker with link to one more open CCPM thread Can't figure out CCPM settings for flybar

Thanks for your answer Hexfet.

Well, that leaves the WRONG channel assignment of the static mixer_standard.c code for channel 1 = Cyclic2 and channel 2 = Cyclic1??!??
That part was correct in the templates .ini files before (CH1/CH2) but Virtual1/Virtual2 input mappings have been wrong too (AIL vs ELEV).
The specific template ini mappings seem to be just being ignored when loading the standard mixer GUI code model or template (overwritten internally)??!??

There are now 5 open threads about CCPM problems and linked in the mantis bugtracker id.
Let's move the CCPM detail discussion to one of them.

Thomas

hexfet wrote:

Loading some of the template files would result in mixed up channel order because the templates were not written for AETR (which is assumed when loading templates)

[/ol]
It's possible these explain some of the reports of reordering...

@hexfet
Question: Is there a specific thread for heli templates or template reordering or changed source code yet?
Then I would like to move my following text for in-detail discussions there instead of this thread.


Isn't the heli template written for Devo protocol EATR? "EATR" in commit log. So was bad typo.

CH1 Cyclic1
CH2 Cyclic2
VirtualChannel1 was input AIL - is now ELEV
VirtualChannel2 was input ELEV - is now AIL.

What ordering are we talking about? CH1/CH2 or VirtualChannel1/2?

The funny thing is that for CCPM heli the advanced heli template WAS working with
CH1 Cyclic1
CH2 Cyclic2

and

VirtualChannel1 was input AIL
VirtualChannel2 was input ELEV


I tried switching between DSMx and Devo protocols back and forth. Worked (all Mode 3).
Model setup reset, loading new template, etc. Worked.

I will see what I get with new tests once I upgrade to the latest nightly build.

Too bad that it is nowhere written down so far how CH1/Cyclic1 is mapped to Virtual1 (as it was AIL input before but still worked).

Yes, I made a mistake above. The template files must be written for EATRG channel order.

I made the wrong fix in the heli templates in pull request #75. The channel mixer assignments needed to be changed, not the virtual channel assignments. You're correct that the code always assigns virtual channel 1 as CYC-AIL (cyclic1) and virtual 2 as CYC-ELE (cyclic2). Please try these heli templates with the latest nightly and see if there are still issues.

Thanks for the testing and keeping after this!

Hi Hexfet,

now I am even more confused

Have you already tested it (CCPM) in the channel monitor with and without your changes on latest nightly-build?
Have you seen correct (full) nick (elev) movement on the three output channels, especially ELEV?
I did N O T on nightly-build fcd0669.


So now (again) VirtualChannel1 is left to be mapped to input AIL and VirtualChannel2 is left to input ELEV.
Just like before in the templates (which worked, I wonder why).


As noted by many people in all 5 updated old CCPM heli threads >=6-12 month before (I posted on all of them) and me describing CCPM Cyclic1 bug in MantisBT #624:
- CH1 (ELEV Devo protocol) should be Cyclic1 (back/front cyclic servo plugged into ELEV port)
- CH2 (AIL Devo protocol) should be Cyclic2 (left cyclic servo plugged into AIL port)
- CH6 (Cyclic3) works (right cyclic pitch servo plugged into CH6 port)

That has been working with the 6ch advanced heli template only. So was correct before!

If you swap Cyclic2/1 like your template changes the mapping now, CCPM (elev) will be N O T working.
That have been my tests on tracking own bug #624 so I raised the issue about wrong cyclic1 mapping for standard heli mixer GUI.

The mixer_standard.c code already maps CH1 to Cyclic2 and CH2 to Cyclic1 (standard template is ignored / overwritten).
That is wrong. It is N O T working!!!

Probably this issue has nothing to do with auto channel mapping, as:
- no protocols where swapped
- no PPM->Devo/DSM protocols where changed / scrolled

as the model # setup has been fresh or resetted before applying (heli advanced) templates / loading standard heli mixer GUI.


My answers on MantisBT #624 are unfortunately unanswered until today how CH1 (ELEV) Cyclic1 mixing code is mapped to Virtchan1 (AIL input). It is some kind of magic. But working

The same (good) questions in the "standard mixer GUI development thread" are unanswered until today too how this "cyclic1-3 mixing and CH1 (ELEV) to Cyclic1 and VirtualChannel1 magic" works

There must be some C code mixing magic how "Cyclic 1, Cyclic2 and Cyclic3" are added together??!??
So the exact right order counts (CH1=ELEV to Cyclic1).

Have you changed any "Cyclic1+2+3" C mixing code files lately? What are the files named? What code places?


I can already assure you 100% that my (and other people) previous tests proved that CH1 (ELEV) to Cyclic2 mixing code (ELEV input) was N O T working on nightly-build fcd0669 and has not been working in firmware versions >6-12 months before.
The only standard heli mixer GUI bug fix seems to be (after setup) to edit the model.ini and swap back CH1/ELEV to Cyclic1 (as posted in the CCPM flybar thread).


Please please stop changing code / templates without in-detail CCPM heli mixing tests and pre-discussing Mantis #624 issues on nightly-build fcd0669. This might make nightly-build development trunk unusable for heli flyers


Which brings me back to an issue I noticed between nightly-build 2015 version changes (I posted already about this circumstance in DSM telemetry support thread):
I had to change CH6/pitch cyclic servo reversed->normal (or the other way) on a CCPM 120 heli.
The servo was suddenly traveling in the wrong direction.

Thomas

Thomas.Heiss wrote: Have you already tested it (CCPM) in the channel monitor with and without your changes on latest nightly-build?
Have you seen correct (full) nick (elev) movement on the three output channels, especially ELEV?
I did N O T on nightly-build fcd0669.

Yes, I tested the updated templates in the emulator and saw the expected outputs.

Thomas.Heiss wrote: As noted by many people in all 5 updated old CCPM heli threads >=6-12 month before (I posted on all of them) and me describing CCPM Cyclic1 bug in MantisBT #624:
- CH1 (ELEV Devo protocol) should be Cyclic1 (back/front cyclic servo plugged into ELEV port)
- CH2 (AIL Devo protocol) should be Cyclic2 (left cyclic servo plugged into AIL port)
- CH6 (Cyclic3) works (right cyclic pitch servo plugged into CH6 port)

This does not correspond to the cyclic assignments in Deviation. As I mentioned previously, the mixing code expects aileron input on virtual channel 1, elevator on virt2, and collective on virt3. This is consistent throughout the code (with "=" meaning "corresponds to"):
Aileron input = cyclic1 = CYC-AIL
Elevator input = cyclic2 = CYC-ELE
Collective input = cyclic3 = CYC-COL
So the templates assign the AIL source to cyclic1, ELE to cyclic2, and THR to cyclic3.

When a template is loaded the output channels are assigned according to the protocol's default channel order. So the aileron output channel of the currently selected protocol is set to cyclic1 and the protocol's elevator channel to cyclic2.

Thomas.Heiss wrote: My answers on MantisBT #624 are unfortunately unanswered until today how CH1 (ELEV) Cyclic1 mixing code is mapped to Virtchan1 (AIL input). It is some kind of magic. But working

The same (good) questions in the "standard mixer GUI development thread" are unanswered until today too how this "cyclic1-3 mixing and CH1 (ELEV) to Cyclic1 and VirtualChannel1 magic" works

There must be some C code mixing magic how "Cyclic 1, Cyclic2 and Cyclic3" are added together??!??
So the exact right order counts (CH1=ELEV to Cyclic1).

Have you changed any "Cyclic1+2+3" C mixing code files lately? What are the files named? What code places?
I can already assure you 100% that my (and other people) previous tests proved that CH1 (ELEV) to Cyclic2 mixing code (ELEV input) was N O T working on nightly-build fcd0669 and has not been working in firmware versions >6-12 months before.
The only standard heli mixer GUI bug fix seems to be (after setup) to edit the model.ini and swap back CH1/ELEV to Cyclic1 (as posted in the CCPM flybar thread).


Please please stop changing code / templates without in-detail CCPM heli mixing tests and pre-discussing Mantis #624 issues on nightly-build fcd0669. This might make nightly-build development trunk unusable for heli flyers


Which brings me back to an issue I noticed between nightly-build 2015 version changes (I posted already about this circumstance in DSM telemetry support thread):
I had to change CH6/pitch cyclic servo reversed->normal (or the other way) on a CCPM 120 heli.
The servo was suddenly traveling in the wrong direction.

Thomas

I'm not able to duplicate what you describe in #624 with the latest nightly plus the two template files. I loaded both templates, swapped GUI interfaces in both directions and the channel outputs remained the same.

No changes have been made to the ccpm mixing code since 2012 - cyclic1 (virt1) has always been the aileron input. The code is in mixer.c MIXER_CreateCyclicOutput.
No changes have been made recently that would cause an existing heli model to change behavior, so no explanation for that one.

The template files clearly need to be fixed so I plan to push that change tonight. Then every thing will be internally consistent. With those changes everything looks correct in the simulator. I'll test on my 450 tonight.

The problem is in the CCPM mixing calculation. The equation for the aileron servo is being used to calculate the value used for elevator, and vice-versa. As best I can tell from the commit log it's always been this way. Didn't notice in the simulator because the correct channels were changing, but not to the right values.

A fix is in my repo , and I've updated bug 624. I've tested it on my 450.

Beware that this fix will break all existing heli model files with a swashtype other than None. I haven't been able to think of a non-breaking fix - ideas? My first thought was to things swap things internally so cyclic1 is elevator and cyclic2 aileron. The only visible change would be the swapping of the CYC-ELE and CYC-AIL in the mixer list, and anyone who's made a working CCPM model file probably already ended up with cyclic1 as the source for ELE (or swapped servo connections, or fixed it in the mixers manually!). But they could've assigned cyclic2 and 3 either way to AIL and PIT and made it work, so it's likely at least some model files would break (like the one I already had for my 450).

I've reverted the change to the standard heli template, so both heli
templates work properly. I've tested them on my 450. This change will be in the next nightly build.

I pm'd PB and further changes will await implementation of model file
versioning, which will allow changes witout breaking model files. Until
then the situation is as follows.

For the advanced GUI, the data flow is:EXCEPT when swashtype is None. Then cyclic1 -> AIL and cyclic2 ->
ELE. This is important because some CCPM heli setup procedures are
done with tx ccpm disabled (at least with my 3GX).

For the standard GUI, a problem exists when reading the template file.
The bug is somewhere in lines 1429-1434 of src/config/model.c but don't
have time to track it down right now. The end effect is that the
template file has to be written with virtchan1 sourced from ELE and
virtchan2 from AIL to make the final sources end up the other way
'round.

I am really glad Hexfet, that you took a look on this issue and code places and you are interested to find a final / good / working solution.

I would love to discuss the issues and how the DeviationTX system works behind the scene online.
Like IRC chat, ICQ, Skype, maybe VoIP.
This forum and the Mantis comments have reached a level where I believe we do not get further.
It's hard to ask questions and track multiple code places to get the big picture...


To be honest Hexfet: I still do understand maybe 20-30% about the C sources, templates, overwriting code places and mappings as well as problems I tracked down.

The relevance between cyclic1, some input and cyclic1 to ELEV or AIL channels are still unknown. At least to me.

The other problem is, that there is not any document where it is written down what servo should be connected on the swashplate to what receiver channels. So there might be different solutions too.
For some FBL systems like ZYX the graphics clearly tell you what you should do (what servo to which channel).
Same is for BNF helis like Blade 450 3D (flybar).
Not so for DeviationTX.

My testings proved that the ELEV/Cyclic1 and AIL/Cyclic2 solution should be working either for CCPM 120 as well as None.
Advanced mixer GUI was the same on me.
Channels order and output behaved the same for 120/None.
Standard GUI is not working anyways (without manually adjusting template) and Cyclics are interchanged.

For the CCPM None/FBL setup I have a Walkera V120 with ZYX FBL to test with too.
Just the tail servo is not working, so its not flying. But I can move the swash / pitch. Advanced 6ch heli template setup worked before.


Hearing that there will be channel assignment differences for CCPM 120 and None settings feels not that right to me?!?
Is there no solution where the channel ordering stays the same no matter if Flybar or Flybarless?
For the older sources and advanced heli template this is the case?? Or am I wrong?

Maybe I need to recheck my Blade + V120 model files and channel orderings as well as connected servo to receiver channel order.

Thanks for jumping on the train Hexfet and your help!

Thomas

Good

I received the V383.... seems to be KN protocol based with CPPM120 ....
Good everything will be included in next NB

Stingray clone with variable pitch?
Where are your 3 servos per arm? Are they?
I am almost sure that there is a FC which controls everything so you have to choose CCPM None / FBL?!?

Thomas.Heiss wrote: Stingray clone with variable pitch?
Where are your 3 servos per arm? Are they?
I am almost sure that there is a FC which controls everything so you have to choose CCPM None / FBL?!?

Yes the stingray clone ...

No only 1 servos per arm ... Well in the documentation it's written CPPM120 and the radio seems the same then the V966 (reference on the TX PCB).... so should be the KN protocol. I am learing this machine first before my first flight ....

I confirm the V383 is compatible with the KN protocol ....