a few more cosmetic issues

[GoogleCodeExporter]

- As the function of the memories are likely more important than their type, 
please consider:

    "Write EEPROM to Tx"  =>  "Write Tx configuration"
     "Read EEPROM from Tx"  =>  "Read Tx configuration"

    "Write EEPROM memory from file" =>  "Update Tx configuration from file"
    "Read EEPROM memory to file"  =>  "Archive Tx configuration to file"

    "Write Flash memory"  =>  "Update Tx firmware version"
     "Read Flash memory"  =>  "Archive Tx firmware version"

- The name of the "Tx configuration file" could be stored as part of the Tx 
configuration, so that when read/written, it may be compared against the then 
current configuration name, and if different, ask if it should be overwritten.  
Thereby one could also easily "Archive Tx configuration to file", and have it 
simply update the one previously loaded and named.

- very minor, but... the height of the text box within the window which allows 
the Rud/Ele... Expos/DR setting to be adjusted are too short, as is the window, 
thereby it needs to be enlarged manually to read the text clearly, other text 
boxes in other windows don't seem to have this problem?

Original issue reported on code.google.com by sch...@comcast.net on 26 May 2012 at 1:42

[GoogleCodeExporter]

1) Cosmetic issues: it's something historical also in eepe.
Not a problem to change but maybe better to discuss on the forum.
2) Storing name in the tx configuration requires eeprom changes (if I have well 
understood) And therefore it's firmware dependent, not only c9x one and will 
require a change in all firmwares.
3) screenshots please... I do not understand which window is small as no 
windows here behaves as you are stating.

Original comment by romolo.m...@gmail.com on 26 May 2012 at 2:43

[GoogleCodeExporter]

a basic screenshot showing the text boxes being a bit too small.

Original comment by sch...@comcast.net on 26 May 2012 at 3:05

Attachments:

• [Screen Shot 2012-05-26 at 11.02.41 AM.png](https://storage.googleapis.com/google-code-attachments/companion9x/issue-51/comment-2/Screen Shot 2012-05-26 at 11.02.41 AM.png)

[GoogleCodeExporter]

UI should be fixed, just need to be checked on MACOS

Original comment by romolo.m...@gmail.com on 26 May 2012 at 3:18

• Changed state: Started

[GoogleCodeExporter]

A few more regarding "Expos/DR" setting window (and Open9x firmware itself).

- The order of Rud/Ele/Thr/Ail does not corresponded to the order defined in 
general settings, which I presume it should as it says "Channel Order (for 
Templates)". If I set my default to mode 2 (RTEA), the order as they appear in 
for Expos/DR is not effected, it would be nice if they reflected the default 
selected order.

- lastly, it would be nice if Expos/DR also supported negative weights as can 
be specified for mixes, and thereby instead of having to define a negative 
curves, the control may simply be given a negative weight,
(I thought this worked before, but I must have been wrong.)

Original comment by sch...@comcast.net on 26 May 2012 at 3:36

[GoogleCodeExporter]

And a few more (presuming this to be a display problem):

The calibration data for my Tx is displayed for Stick1 for example as:
Negative: 961 Mid: 1002 Positive:926

Which dose't make any sense to me, presuming Negative means Min, and Positive 
means Max (which should also be how they're labeled)?

Original comment by sch...@comcast.net on 26 May 2012 at 4:34

[GoogleCodeExporter]

No your interpretation it's wrong.

They means:
negative span
value at the center:
positive span

Original comment by romolo.m...@gmail.com on 26 May 2012 at 6:07

[GoogleCodeExporter]

Regarding neg/mid/pos; thanks that makes sense; sorry.

Original comment by sch...@comcast.net on 26 May 2012 at 6:20

[GoogleCodeExporter]

I will change the label, it's not such a big effort :)

Original comment by romolo.m...@gmail.com on 26 May 2012 at 6:29

• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

Actually the current labels are likely fine; I had simply wrongly assumed the 
calibration data would represent the measured ADC values; sorry.

Original comment by sch...@comcast.net on 26 May 2012 at 6:37

[GoogleCodeExporter]

Well Negative span, Mid value and Positive span should be better or not ?
I committed in this way, then we can always roll back.
BTW: when I started coding on eepe/c9x it was a little meaningless and cryptic 
also to me.

Original comment by romolo.m...@gmail.com on 26 May 2012 at 6:44

[GoogleCodeExporter]

yes, that is better.

Original comment by sch...@comcast.net on 26 May 2012 at 6:49

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

about comment 4)
dr/expos are applied to inputs (sticks) not to outputs, so the order the dialog 
is the internal order of sticks and is not affected by channel order.
About weight: a negative value there is meaningless if you think in the logic 
of inputs: It's a travel limiter not a travel inversion, it's better to do it 
in the mixer.
For expo instead a negative value is allowed as it increases sensibility in the 
center of the stick.

Original comment by romolo.m...@gmail.com on 26 May 2012 at 7:51

[GoogleCodeExporter]

I'm not english natively speaking (and also my English is rather broken) so 
maybe u can explain me:

"Write EEPROM to Tx"  =>  "Write Tx configuration"  ??? Where ???
"Read EEPROM from Tx"  =>  "Read Tx configuration"  ??? From ???

Wouldn't it be better to say:
Write configuration to TX
and
Read configuration from TX

"Write EEPROM memory from file" =>  "Update Tx configuration from file"
"Read EEPROM memory to file"  =>  "Archive Tx configuration to file"

Also why update here and write before ? I suggest:
Write configuration to TX from a file
and
Save TX configuration in a file

"Write Flash memory"  =>  "Update Tx firmware version"
"Read Flash memory"  =>  "Archive Tx firmware version"
As it's not and update for sure (it can be also a rollback or a firmware family 
change) isn't better:
Flash a firmware to TX ?
and
Read firmware from TX and save to file ?

I ask just to learn English a little bit better...
Thanks for your consideration.

Original comment by romolo.m...@gmail.com on 26 May 2012 at 8:35

[GoogleCodeExporter]

- All linear and/or expo input scaling is -/+ about its mid value; nothing else 
makes any sense. ???

Being no different than if it were scaled within a mix, the only difference 
being that by scaling an input, it effects each use within a mix, without 
having to modify each mix independently? Being why I thought there were 
separate Expo/DR input settings?

????

- Regarding ordering; its just a cosmetically nicer for the order of inputs in 
the Expos/DR section to appear in the same order as their default channel 
order; isn't it?

Original comment by sch...@comcast.net on 26 May 2012 at 9:52

[GoogleCodeExporter]

Expo/DR follows a consolidated standard of many commercial radios. +/- for expo 
a positive scale factor for proportional part.
In commercial radio they are calculated once to do load to much the CPU.
In 9x it still makes sense to have exponential calculate once, especially for 
cpu load considerations, but being 9x a multiplex based radio, is even 
disputable if it make sense to have proportional adjustment on sticks. 
Personally I do not like the idea to have 5 different methods to invert a 
channel.
(they will be dr/expo weight/curves, mixer weight/curves, inversion in limits). 
Understanding radio programming will become a mess, but these are only my 2 
cents.
Channel order will require a lot of flash in open9x, and i would like to keep 
consistency between the two.
Also as I have said default channel order applies to output... 
Those are inputs..

Original comment by romolo.m...@gmail.com on 26 May 2012 at 10:25

[GoogleCodeExporter]

Regarding: "Write EEPROM to Tx"  =>  "Write Tx configuration"  ??? Where ???

verb: "write" object: "Tx configuration" (being what, and thereby implicitly 
where; or "Write Tx's configuration", configuration belonging to Tx)

(Believing its more useful to know it's the configuration settings being 
written, the fact that it may be stored in an EEPROM is incidental.)

Upon further consideration: "Write Tx settings", etc. may be a better choice, 
as they're referred to as "settings" in most windows already.

As just a thought.

Original comment by sch...@comcast.net on 26 May 2012 at 10:32

[GoogleCodeExporter]

And ... I agree "Update" implies to a newer version; being I suspect this is 
what most would be doing, although it may also used be used to load an older 
version if desired.

On May 26, 2012, at 6:32 PM, Paul Schlie wrote:

Original comment by sch...@comcast.net on 26 May 2012 at 11:28

[GoogleCodeExporter]

I agree with your philosophy, essentially that less with greater flexibility, 
is often more.

And thereby I believe it may likely be better to eliminate the Expos/DR window, 
in favor of having all input scaling defined within channel mixes; and ideally 
try to even further reduce redundancies within it as well:

- as virtual output channels can already be defined as inputs to multiple other 
channel mixes when needed, but it might be nice to be able to symbolically name 
them?

- and in the sprit of trying to remove redundancy, I wonder a canonical form 
for all mixes can be defined, possibly something like:

output = [ if [cond] then [input] *[curve] ]+

cond :: [input] > 0

input :: [stick | switch | trim | output]

curve = [value | min-value,min-expo,mid-value,max-expo,max-value]  {i.e. a 
constant, or two exponential curves between three points.}

As just a thought, and being fairly close to what's already been implemented in 
open9x; but knowing it's far easer to throw suggestions around, than to 
actually implement them.

Original comment by sch...@comcast.net on 27 May 2012 at 2:15

[GoogleCodeExporter]

Original comment by romolo.m...@gmail.com on 8 Aug 2012 at 10:41

• Changed state: Fixed