remove inversion control from Limits screen, add offset/limited output

[GoogleCodeExporter]

As it's unnecessary, because a channel's output may already be easily inverted 
by assigning it a negative scaling factor in it's model mix specification. The 
"Limits" screen should be left for limits related things.

Thereby the column otherwise used to display a channel's inversion state, could 
be used to interactively display that channel's offset and limited output 
value, either as a percent, or PPM servo pulse width as may be desired. (Which 
seems more useful to know, and more closely related to channel output limits.)

Original issue reported on code.google.com by sch...@comcast.net on 9 Jun 2012 at 4:34

[GoogleCodeExporter]

Ok, so I suppose that for reverting output to a servo with associated 4/5 mix 
in different flight phases you think is simpler to revert weights in 5 mix than 
reverting the output.
Please let me tell you that I do not agree, furthermore is completely out of 
standard with all existing ways of programming a radio and with the philosophy 
of a multiplex based radio.
you have inputs (rates/expos/curves)
you have mixes (weights/curves/offset/delays)
you have outputs (offset/limits/inversion)
Every step has its own processing methods and the some of them applied in 
different point of the chain bring same final result.
Sometimes is simpler to do in a way sometimes in another.

PS: please take care when using the issue report system to select the proper 
issue type, this is definitively not a defect.
Regards

Original comment by romolo.m...@gmail.com on 9 Jun 2012 at 6:15

• Changed state: WontFix

[GoogleCodeExporter]

Easier? Yes.

But relative to what?  As the scaling factors of a multiple input mix would 
likely need to be tweaked multiple times to get them right; changing their 
polarity should never need to be done more than once, if that.

As redundant features only tend to confuse the situation, not help; scaling 
(sign and magnitude) would likely be best specified in one place, not multiple.

So possibly in addition to being able to scale by sign and magnitude each input 
element of a mix, its composite output should also be able to be easily 
similarly scaled, and thereby channel inversion can be integrated there; and 
although a signed output scaling factor could be specified within a limits 
screen, it seems more like an element of a channel's mix specification. Doesn't 
it?

Original comment by sch...@comcast.net on 9 Jun 2012 at 6:59

[GoogleCodeExporter]

No I do not agree, limit, offset, and inversions are very often the result
of mechanical considerations on the model
If I want to limit escursions of a surface/movement I do not want to scale
movement: I want to say it must go from point A to point B  with center in
C and a certain direction (left to right or right to left)

BTW if you don't want to use limits and use mix, please ignore the screen.
PS: This is definitively not an issue and either not a thing that should be
discussed on an issue reporting system, this kind of considerations are
better discussed on the forum.

Original comment by romolo.m...@gmail.com on 9 Jun 2012 at 7:35

[GoogleCodeExporter]

"... limit, offset, and inversions are very often the result of mechanical 
considerations on the model ..."

Agreed.

With respect to "offset", which I remain a bit confused about; as if this value 
is meant to compensate for an otherwise non-mechanically centered servo, 
shouldn't this value be added uniformly throughout the entire output range, in 
effect linearly shifting the whole output function by the "offset" (presuming 
its not clipped by a channel's limits and remain within the mechanical 
capability of the servo), as opposed to being scaled to have no effect at the 
-/+ extents of the channel, and thereby in effect only shifting the logical 
center of the channel, but not its extents.

Or is if desired to shift the whole range of output by this offset, shouldn't 
the channel's "limits" be correspondingly offset (presuming the center of the 
channel remains as a logical 0%) and thereby in effect shifting the whole 
channel's specification by the offset, as if the servo had been mechanically 
re-centered?

(and I apologize for improperly marking it as a defect, I don't recall seeing 
the option to mark it otherwise.) 

Original comment by sch...@comcast.net on 9 Jun 2012 at 8:27

[GoogleCodeExporter]

Inversion in the LIMITS screen is something useful, even if it's not mandatory. 
This is the FW choice since the beginning. I don't see a good reason to remove 
it.

Original comment by bson...@gmail.com on 9 Jun 2012 at 8:54

• Changed state: Invalid

[GoogleCodeExporter]

Offset is offset, center is center that's why in open9x you have
possibility to adjust center too.
Offset can be used to asymmetry  a travel, ppm center does what you are
asking for, again two instruments that can be used to do the same job but
with different results.
Center move the center leaving symmetrical movement, but is limited in
doing so be PPM frame specifications, offset moves arbitrary the idle
point, but allow to select any point in the servo travel as the idle one.

With respect to "offset", which I remain a bit confused about; as if this

Original comment by romolo.m...@gmail.com on 9 Jun 2012 at 9:08

[GoogleCodeExporter]

Thank you.

Original comment by sch...@comcast.net on 9 Jun 2012 at 10:13

[GoogleCodeExporter]

If it matters, the reason for my confusion was that I thought the purpose 
"offset" was to shift the whole channel, thereby effectively electrically 
centering a servo, also more closely resembling the effect that input trim has 
on a output channel, and thereby similarly the expected result of "trims => 
offsets"?

Although I believe I understand the difference, its value seems less less 
clear; as if asymmetric extends were desired, it would seem better to define 
them by adjusting the channel's extents asymmetrically about 0, not by 
asymmetrically skewing 0 within its extents.

But regardless, thanks for the clarification.

Original comment by sch...@comcast.net on 9 Jun 2012 at 11:46