OpenTX - Nightly builds for pre-2.0 testing

[marimach77]

Companion 1.99 downloaded from http://jenkins.open-tx.org/firmware/nig ... _06-52-32/ works fine on Windows 7 x64.

Missed "Maximize" icon for model configuration window.

[marimach77]

Companion 1.99 downloaded from http://jenkins.open-tx.org/firmware/nig ... _06-52-32/ works fine on Windows 7 x64.

Missed "Maximize" icon for model configuration window.

[marimach77]

Companion 1.99 downloaded from http://jenkins.open-tx.org/firmware/nig ... _06-52-32/ - works fine on Windows 7 x64.

Missed "Maximize" icon for model configuration window.

[mstrens]

Some telemetry informations can have more than one source.
I would propose to change the name of some telemetry fields in order to get more standardisation.

I suggest to take a convention like the one used for those 2 fileds : "RSSI Tx" and "RSSI Rx".
It means that the first part of the name identifies the type of information and the second part the source.

Based on this, I propose having:
Batt Tx (instead of Batt)
Batt Rx (instead of Rx Batt)

Spd GPS (instead of Speed) (note : there is also Vspd and Aspd)
Dist GPS (instead of Dist)
Alt GPS (instead of GPS Alt)

Alt Vario (instead of Alt)

Note : For Altitude, the name does not say if it is a relative or an absolute altitude.
When the source is the vario, only the relative altitude have really sense but for the GPS both could have sense.
Would it not be useful to specify in the name if it is Abs or Rel?
I did not check the number of char available on the different displays.

What is your meaning about this?

Michel

[rdeanchurch]

Would someone who knows tell me how to approximate SHdnS and SHDnL from 2490 with the
EDGE logical? Specifically, what are the correct entries for the to time parameters.

Thanks

[mstrens]

In companion9x 1.99, there is a wizard to create a new model.
It seems me that the assignments between inputs and channels are not (always) logical.
See attachment.
I think that companion9x take care of the values set in "chanel order" (defined in the window "general settings").
Still the wizard asks the user the expected channels. The answers given in the wizard should be taken into account (and not the values in channel order from "general settings").
The values in "channel order" from "general settings" should be used as default values in the drop lists displayed by the wizard.

[Kilrah]

Would someone who knows tell me how to approximate SHdnS and SHDnL from 2490 with the
EDGE logical? Specifically, what are the correct entries for the to time parameters.

Don't remember how long was considered as long, but maybe [0.0:1.0] and [1.0:10.0] for example... you can set it to your preference really, that's the point.

[Kilrah]

Regarding the wizard it's not finished, I've seen some commits and comments go by today regarding channel order.

See in the commit log and issues if your case is covered, and/or test the next nightly build.

[mstrens]

Some fields have been added by Bertrand for the vario on the panel where telemetry is defined (pitch at reference, pitch at max, duration of interrupt at reference). Those fields are not (yet) added in companion9X 1.99 from 2 april.
Note : this has already been communicated some days ago.
I write it here just in order not to forget it.
Is this forum the prefered place to notify remaining issues?
Is it not easier for follow up to write them in the issue list (on GitHub)?
Let me know what is the prefered way.

[dvogonen]

In companion9x 1.99, there is a wizard to create a new model.
It seems me that the assignments between inputs and channels are not (always) logical.
See attachment.
I think that companion9x take care of the values set in "chanel order" (defined in the window "general settings").
Still the wizard asks the user the expected channels. The answers given in the wizard should be taken into account (and not the values in channel order from "general settings").
The values in "channel order" from "general settings" should be used as default values in the drop lists displayed by the wizard.

The good news:
The channel order values will be used as defaults in the drop downs from the next nightly build. Checked that in a couple of hours ago.

The bad news:
There is a currently a bug that mixes up the channels in the Taranis. This is what happened to you. This happens if you use any channel order except RETA. This does not happen with the 9x. I do not know enough about the storage of channel order to sort this one out in time for the nightly build. Hopefully I can get some help from Bertrand.

[Kilrah]

Some fields have been added by Bertrand for the vario on the panel where telemetry is defined

No they are in the general (radio) settings, and are present in companion too.

Github is preferred BUT please try to only open issues if you're sure they are really issues, so discuss here first if in doubt to get help from other users (this wouldn't be one for example). When opening an issue you're sending a push notification to all devs, so it's always best when it's not user error

[Scott Page]

Using the Tx simulator which is from the tab in the model setup window I'm getting misbehavior. First of all as you can see in the attachment the backlight does not function. Second of all the Sticky command does not function.

I was going crazy trying to figure out the sticky command -- but it turns out I had it right in the very first place but was using this simulator window (invoked from model edit window).

When using the simulator invoked from the EEPE window it behaves correctly. Also works fine in the transmitter itself.

I'll let a developer either address this or open a issue for it.

I had emailed two developers thinking the sticky was the problem when in fact it's the simulator after all.

Clear to see in attachment that backlight is not "on". Harder to use image to demonstrate the problem with the sticky.

[dvogonen]

Using the Tx simulator which is from the tab in the model setup window I'm getting misbehavior. First of all as you can see in the attachment the backlight does not function. Second of all the Sticky command does not function.

I was going crazy trying to figure out the sticky command -- but it turns out I had it right in the very first place but was using this simulator window (invoked from model edit window).

When using the simulator invoked from the EEPE window it behaves correctly. Also works fine in the transmitter itself.

I'll let a developer either address this or open a issue for it.

I had emailed two developers thinking the sticky was the problem when in fact it's the simulator after all.

Clear to see in attachment that backlight is not "on". Harder to use image to demonstrate the problem with the sticky.

The backlight problem was reported as issue #898 a few days ago. Bertrand has fixed the problem, so the report is now closed.

[Scott Page]

Using the Tx simulator which is from the tab in the model setup window I'm getting misbehavior. First of all as you can see in the attachment the backlight does not function. Second of all the Sticky command does not function.

I was going crazy trying to figure out the sticky command -- but it turns out I had it right in the very first place but was using this simulator window (invoked from model edit window).

When using the simulator invoked from the EEPE window it behaves correctly. Also works fine in the transmitter itself.

I'll let a developer either address this or open a issue for it.

I had emailed two developers thinking the sticky was the problem when in fact it's the simulator after all.

Clear to see in attachment that backlight is not "on". Harder to use image to demonstrate the problem with the sticky.

The backlight problem was reported as issue #898 a few days ago. Bertrand has fixed the problem, so the report is now closed.

Just downloaded the April 3 build. The sticky problem in the simulator is not a problem with this build.

The backlight still does not work in simulator for Keys, or keys, or sticks & Keys.
Companion says "Stick + Keys" and simulator and transmitter says "Both" for the backlight setting.

Backlight works just fine in all modes in Tx.

I know simulator is a work in progress, but as of April 3 build it reverses Rudder and Ail for both Mode 1 and 2. So when I specify two aileron channels I get two rudder channels on the numbers I designated for Aileron.

[mstrens]

Tested with April 3 build.
In companion9x, when creating a new model (plane) with the wizard:
- drop lists to select channels for aileron (and flaps +airbrakes ) should best be active only if the plane has aileron (and flaps +airbrakes) ; currently, it is possible to say e.g. that there is no aileron and still to select 1 or 2 channels in the drop lists.
Note: for Throttle it works fine (channel drop list is not active when the user says that there is no engine)
If code is modified in order that drop list becomes active only when it makes sense, then please check all drop lists (I only testesd aileron , flaps , airbrakes fora normal plane).
- when creating a model with 2 aileron channels, both generated mixers have a weight of +100%; I presume one should be +100% and the other should be -100%

[mstrens]

Tested with April 3 build.
In companion9x simulation, it seems that Gvar on aileron differential does not work correctly.

I define a model with 2 ailerons.
In input I do not declare a differential.
In mixer panel:
- on channel 1 (first aileron), I declare that differential is based on Gvar1 (and on flight mode, I declare Gvar1 = 50)(wght = 100)
- on channel 2 (second aileron) , I declare that differential is -80 (wgth = -100).

When I simulate :
- on channel 2, I get a range -20 / 100 (=ok)
- on channel 1, I get a range -82.8 / 100 (NOK)

When I change the value of GVar1 in flight mode panel, range of channel 1 do not change.
When I select Gvar9 in the mixer (and I do assign a value to Gvar9), range of channel 1 becomes -75 / 100.

It seems first that the values set to Gvar in flight mode panel are not saved.
Still the values are saved because if I use Gvar as parameter for the weight (instead of Diff) of the mixer, then the range of channel 1 changes accordingly with the value of GVAR.

I do not know which value the simulator uses for the differential when set up is based on a Gvar


Note : I get the same issue if I try to set up exponential (instead of differential) based on Gvar1.
Selecting Gvar1 or -Gvar1 has well an impact (but not the value assigned to Gvar1)

[dvogonen]

Tested with April 3 build.
In companion9x, when creating a new model (plane) with the wizard:
- drop lists to select channels for aileron (and flaps +airbrakes ) should best be active only if the plane has aileron (and flaps +airbrakes) ; currently, it is possible to say e.g. that there is no aileron and still to select 1 or 2 channels in the drop lists.
Note: for Throttle it works fine (channel drop list is not active when the user says that there is no engine)
If code is modified in order that drop list becomes active only when it makes sense, then please check all drop lists (I only testesd aileron , flaps , airbrakes fora normal plane).
- when creating a model with 2 aileron channels, both generated mixers have a weight of +100%; I presume one should be +100% and the other should be -100%

I would have liked to do it like that, but found no good way of implementing context sensitive disabling of objects in the base class used for the Wizard. I wanted to keep the code clean and easy to extend, which is why I did not just hardcode all the dependencies for the fields. I am thinking of revisiting this issue, but can not promise anything.

[mstrens]

- when creating a model with 2 aileron channels, both generated mixers have a weight of +100%; I presume one should be +100% and the other should be -100%

Do you plan to implement this?

[mstrens]

Tested with April 3 build.
In companion9x simulation, with Stick mode = "Mode 1" in general settings, I have a strange behaviour of the trim.
When I move the right stick horizontally (alileron), I see the "x" value changing according to the stick position (= OK).
BUT, when I move the right hozirontal trim (which should normally be also aileron related), it is the "y" value that changes and not the x value.
I have the same issue with the vertical trim on the right side (moving the vertical trim change the x value).

Note : on the left side, it all OK (X and Y change accordingly for stick and trim)

Edit : it seems that the issue is only in the field (x or y) used to display the trim value because the mixers works fine (moving the horizontal right trim, change the channel assigned to aileron just like the horizontal stick)

[mstrens]

Tested with April 3 build.
In companion9x simulation, in the mixer panel there is (sometime) a tick box named "Include DR/expo".

I have 2 issues:
1) why the name DR/expo; it looks like DR would be for dual rate but I expect that openTx has no native dual rate (it is to set up using switches and mixer). Would it not be more logical to change the name according to the real use of the box. It is not clear for me what does the box (see issue 2) and if it concerns only expo or also other like curve, diff, funct. So I can't propose another name currently.
2) box named "Include DR/expo" is displayed if I select e.g. "I2[Ele]" but not when I select "Ele" as source.
I made this test :
- In the mixer, I select expo = 0
- In the input, I select expo = 90.
Then if I thick or untick the box "Include DR/expo", I always get the same result : expo is always applied.
I imagine that this is not the expected working.

[mstrens]

Tested with April 3 build.
In companion9x simulation, in the mixer panel there is (sometime) a tick box named "Include DR/expo".

E.g. the box named "Include DR/expo" is displayed if I select "I2[Ele]" but not when I select "Ele" as source.
If I select first "I2[Ele]" and I untick the box "Include DR/expo", then the list of mixers gives a text "No DR/Expo" (=OK).
Then I open again the mixer and I replace "I2[Ele]" by "Ele" as source; the box disapear from the mixer window (=OK).
When I close the mixer window and I go back to the mixer list, then the previous text "No DR/Expo" is still present (=NOK).
This text is not present if create a new mixer using directly "Ele" as source.

For consistency, the text should be erased when the user select a source that does not have the thick box.

Additional note:
In fact this text is not 100% clear because it apears also even I use this set up:
- use "I2"[Ele] as source
- untick the box name "DR/expo"
- set an expo value in the mixer itself
I get then a text "No DR/Expo Expo(20%)"
It is a little confusing having a mention No expo and Expo on the same line.
I suggest using other names to clarify use of tick box.

Perhaps would it be better too to display a text when the box is ticked (instead when untick) even is "ticked" is the default option.

[bertrand35]

Tested with April 3 build.
In companion9x simulation, in the mixer panel there is (sometime) a tick box named "Include DR/expo".

I have 2 issues:
1) why the name DR/expo; it looks like DR would be for dual rate but I expect that openTx has no native dual rate (it is to set up using switches and mixer). Would it not be more logical to change the name according to the real use of the box. It is not clear for me what does the box (see issue 2) and if it concerns only expo or also other like curve, diff, funct. So I can't propose another name currently.
2) box named "Include DR/expo" is displayed if I select e.g. "I2[Ele]" but not when I select "Ele" as source.
I made this test :
- In the mixer, I select expo = 0
- In the input, I select expo = 90.
Then if I thick or untick the box "Include DR/expo", I always get the same result : expo is always applied.
I imagine that this is not the expected working.

This checkbox should be hidden on Taranis (because we have Virtual Inputs)
https://github.com/opentx/opentx/commits/next

[bertrand35]

Tested with April 3 build.
In companion9x simulation, with Stick mode = "Mode 1" in general settings, I have a strange behaviour of the trim.
When I move the right stick horizontally (alileron), I see the "x" value changing according to the stick position (= OK).
BUT, when I move the right hozirontal trim (which should normally be also aileron related), it is the "y" value that changes and not the x value.
I have the same issue with the vertical trim on the right side (moving the vertical trim change the x value).

Note : on the left side, it all OK (X and Y change accordingly for stick and trim)

Edit : it seems that the issue is only in the field (x or y) used to display the trim value because the mixers works fine (moving the horizontal right trim, change the channel assigned to aileron just like the horizontal stick)

This one is fixed now.
https://github.com/opentx/opentx/commits/next

[dvogonen]

Tested with April 3 build.
In companion9x, when creating a new model (plane) with the wizard:
- drop lists to select channels for aileron (and flaps +airbrakes ) should best be active only if the plane has aileron (and flaps +airbrakes) ; currently, it is possible to say e.g. that there is no aileron and still to select 1 or 2 channels in the drop lists.
Note: for Throttle it works fine (channel drop list is not active when the user says that there is no engine)
If code is modified in order that drop list becomes active only when it makes sense, then please check all drop lists (I only testesd aileron , flaps , airbrakes fora normal plane).
- when creating a model with 2 aileron channels, both generated mixers have a weight of +100%; I presume one should be +100% and the other should be -100%

Disabling unused channel selections is fixed now.
As to the default weight of the channels:
The aileron and elevon servos are commonly installed mirrored in the wings, which means that they need to have the same weight to move in different directions. I guess that the flaps and airbreaks should have different weights by default since they should move in the same direction. I will fix that.

[jhsa]

option for servo direction?

[Kilrah]

The aileron and elevon servos are commonly installed mirrored in the wings, which means that they need to have the same weight to move in different directions. I guess that the flaps and airbreaks should have different weights by default since they should move in the same direction. I will fix that.

To me it's the opposite, flaps and airbrakes should have the same weight and ailerons opposite ones, simply because what matters is the surfaces' movement, and when you look at them flaps/brakes move in the same direction while ailerons move in opposite ways.

The way in which servos are installed or rotate is irrelevant to this and is to be accounted for with the servo reverse as needed.

But that's an endless debate. At least the doc is written based on this principle

[jhsa]

I disagree, but that is only me..

Gosh, I'm so happy you're not one of the developers

Sent from my GT-I9195 using Tapatalk

[mstrens]

If you look at this link
http://rc-soar.com/opentx/setups/f3f/index.htm
you can find a complete model set up for a typical f3f glider with 2 aileron and 2 flaps.

When you look at the mixer definition, it uses a + weight for one aileron and a - weight for the other aileron.
This seems me the most logical too.

[jonlowe]

Doesn't make sense to use + and - for aileron, since 99% of the time they are mirror images, so both servos have to rotate in the same direction.

Sent from my Nexus 5 using Tapatalk

[mstrens]

Tested with April 3 build.
In companion9x simulation, in logical switch it is possible to select "Sticky" as condition.
I make a test where I use it with V1 = SAup and V2 SAdown.
Without duration and delay it seems OK.

When I add only a delay (say 2 sec), the logical switch become ON 2 sec after I move SA up (=OK)
When I move SA on down, the logical switch goes OFF immediately (I presume this is the expected result)

When I add only a duration (say 5 sec), the logical switch become ON immediately after I move SA up and
- goes OFF after 5 sec if in the mean time SA is not up anymore (=OK)
- goes OFF after 5 sec and goes immediately ON again if SA has remained on up (I presume this is the expected result but I am not 100% sure because I do not know if it is expected that the logical switch is triggered by the position it self or by a change of position)

When I add both a duration and a delay, then logical switch never comes on ON. This is NOK.