OpenTX - Nightly builds for pre-2.0 testing

[Daedalus66]

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

I would have said 50-60%, but the real point is that there's nothing particularly logical about one or the other.

I'm generally skeptical about arguments based on what's "logical" or "intuitive" because they nearly always boil down to "Be reasonable, do it my way."

[jhsa]

Do it my way works very well for me
But I guess it doesn't work for the wizard

[Scott Page]

Just downloaded April 4 CompanionTX.

The Wizard is looking better all the time. I found one issue however.
In General Edit I have Channel Order (for Templates) set to TAER
The wizard follows that order - however after applied the mixer does not follow the wizard.

[rdeanchurch]

4Apr v1.99
Wizzard. I use TREA and the wizzard work great for all but two things (IMHO.)_
for 2Ail servo and 2 Flap servo, Ail were on put on Ch. 4 and 5. Good

Flaps were put on Ch6 and 8.
Why not 6 and 7 ?
and
Flap Sw is set to SwA.
Is there a logical reason for it to be Sw A?
.....my prefernece happens to be SwD. Should this be user selectable?

[dvogonen]

Just downloaded April 4 CompanionTX.

The Wizard is looking better all the time. I found one issue however.
In General Edit I have Channel Order (for Templates) set to TAER
The wizard follows that order - however after applied the mixer does not follow the wizard.

4-3-2014 8-12-56 PM.png

4-3-2014 8-13-16 PM.png

That is strange. I thought I fixed that problem yesterday. It should be in the build. I will check.

[dvogonen]

4Apr v1.99
Wizzard. I use TREA and the wizzard work great for all but two things (IMHO.)_
for 2Ail servo and 2 Flap servo, Ail were on put on Ch. 4 and 5. Good

Flaps were put on Ch6 and 8.
Why not 6 and 7 ?
and
Flap Sw is set to SwA.
Is there a logical reason for it to be Sw A?
.....my prefernece happens to be SwD. Should this be user selectable?

The selection of channels is made in several steps. The last is to resolve conflicts. Both flaps had gotten channel 6 as primary selection. The second one was then assigned the highest available free channel. Always picking the highest available channel to solve conflicts saves some complication and avoids booking channel 1-4 for non RETA functions. But I may revisit that.

There is no hard logical reason for picking SA over SD. Both work just fine. For now, the switch selection for flaps and airbakes is hardcoded. This might be changed further along the line, but right now you have to change switch manually in the editor if you are not OK with the default selection.

[Kilrah]

Since about a week ago the build server has been configured to also build standard binaries for sky9x, gruvin and stock boards. It would be great if some could also test these versions so that we can fix any problems before release - for now it seems nobody uses these anymore!

[dvogonen]

That is strange. I thought I fixed that problem yesterday. It should be in the build. I will check.

There is some kind of bug in the bug fix Originally only RETA as channel order used to work. Now RETA and ATER (which I used for testing) works. I thought that this meant that all combinations worked, but the combination Scott used (TAER) still fails...

[Daedalus66]

It particularly important to get the TAER sequence right because there are so many people using DSM2 and DSMX receivers. On most of these, failsafe only works on CH1.

[Scott Page]

Running Taranis - OpenTX from April 5

Basically it seems that the wizard chokes on anything that starts with Throttle on first channel. I did not try all combinations, but several - enough to know that it's not fixed.

C:\Program Files (x86)\OpenTX\simulator.exe now works correctly with the backlight functioning from keys or controls. I did not give that program a thorough go over yet, but I did check the backlight.

However the two simulator locations within Companion (one from EEPE edit window and one from model edit window) still do not work with the backlight being activated by sticks or buttons. In fact - the simulator.exe works -- which it did not last night. It crashed on me when I tried it last night (for the first time).

I'm not clear why there is a separate simulator application. It seems to be separate completely from CompanionTX.

Also - pointed out earlier and it's not a functionality item, but cosmetic and consistancy. Where the OpenTX firmware refers to Sticks and buttons as "BOTH" the Companion has "Keys + Sticks".

Untitled-1.png (22.18 KiB) Viewed 13437 times

I'll do further checking tomorrow. I'm very excited that OpenTXCompanion works in the 8" Dell Tablet I'm running with windows 8.1pro - it has atom processor - so i was curious how that would go -- so far so good. I'm testing on the tables and a standard laptop with 64 bit Intel processor.

[Kilrah]

Basically it seems that the wizard chokes on anything that starts with Throttle on first channel. I did not try all combinations, but several - enough to know that it's not fixed.

Kjell merged the channel order fixes at 1:01am my time so I'm not sure it made it in tonight's build. Not sure exactly when the build is started as there's a time difference with the server.

I'm not clear why there is a separate simulator application. It seems to be separate completely from CompanionTX.

It is completely separate indeed. It's meant in the future to replicate past companion functionality of simulating other firmwares like er9x, th9x etc as that has been removed from companion, but isn't quite there yet. Also allows working with raw eeproms and having debug information as it dumps stdin and stderr to text files.

Also - pointed out earlier and it's not a functionality item, but cosmetic and consistancy. Where the OpenTX firmware refers to Sticks and buttons as "BOTH" the Companion has "Keys + Sticks".

It's intended. In the firmware there isn't enough room but in companion we have space so we make use of it to put something more explicit. There are several options and settings that are a bit more descriptive in companion.

[mstrens]

Tested with April 5 build.
In companion9x, if I define some global var on the window "editing model ...", the global var is not used when simulation is called from this windows. The values are wel saved because if I close and reopen the window, the values are kept.
In fact, I have seen that if I call the window simulation using the button "Simulate Tx" on the main window of companion, then the global var are not the same.
Update on one side are not reflected on the other side

[Kilrah]

Can't reproduce. Please give an exact list of actions that leads to the problem.

Changes from the radio simulator called with "simulate TX" are never carried back, that's normal.

[mstrens]

Can't reproduce. Please give an exact list of actions that leads to the problem.

Changes from the radio simulator called with "simulate TX" are never carried back, that's normal.

Please look at the attachment. I hope it can help.
Wou will see in the attachment that I got an additional issue during the test (screen with "outputs" was locked - no updated when moving the sticks).

What do you mean by "Changes from the radio simulator called with "simulate TX" are never carried back".
You will see in the attachment that some changes made in model set up (in the windows with all tabs) are carried to the taranis screen (called from the list of models).
I presume that the opposite should work too.

[Kilrah]

OK. So companion has a bug when passing the expo value to the firmware, and simply converts GV1 to 17.
Simulator not responding is not a lock, for some reason it takes about 5-15secs to start responding, then works ok. We'll have to find out why.

You will see in the attachment that some changes made in model set up (in the windows with all tabs) are carried to the taranis screen (called from the list of models).
I presume that the opposite should work too.

Yes of course when you edit something then open a simulator, the simu is opened with the changes you made. BUT what you change on the simulated LCD and buttons does NOT get carried back to the edit window.

[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.

Will this be handled as a bug or is it some reason for this behaviour?

[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

I think there were no reaction on this proposal.
Will it not be implemented?

[Kilrah]

Will this be handled as a bug or is it some reason for this behaviour?

Looks like a bug indeed.

I think there were no reaction on this proposal.
Will it not be implemented?

Not in this form. The whole telemetry system is in need of a complete overhaul which will be one of the next big tasks, so until then it will stay that way. We don't actually have that many values with more than one source at this point anyway, Alt is the only one if I'm not mistaken.

Note that we currently only have 4 chars available, so "Dist GPS" wouldn't work anyway. And I prefer "GPS Dist"

[mstrens]

Tested with April 5 build.
In companion9x, the option "smooth" does not work in the same way:
- in the window "Editing model", the points of the curve remain connected by a line even when option Smooth is selected
- in the window that simulates the Tx (called from the list of models), the points are connected by a smooth curve when the option Smooth is activated.
Is it logical having 2 diffenrent ways of presentation?
The second one seems better because the user see immediately the result of activating the option smooth.

[bertrand35]

Should be an issue as well, with less priority (some time is needed for this one ...)

[Scott Page]

Has it been reported that models backed up prior to installing 1.99 onto the SD card can't be loaded to a model using Restore Model?

[pmackenzie]

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

The sign of the weight must be different for the differential to work properly.
It is also most logical this way, so for flaperons for example the aileron input will be of different sign but the flap input will have the same sign.

Same reasoning applies to V-tail mixing and Delta wing mixing. Elevator mixing will have the same sign, rudder/aileron opposite.

If in the end you need to correct the physical motion then use the INV settings in the SERVOS screen.


Pat MacKenzie

[Helle]

hy,

old Problem, programming at PC or direkt at Tx and Modell line by line

But this is my opinion too, for programming:
First the mixer mathe has to run corrrect with all mixerlines,
then I have to set it to the real servo movement at the modell
so I allways see whats happen.

There are three old rules in aviation:
1. Positive stick inputs has to follow positiv or right side mixeroutputs
2. First aileron is the right aileron and its positiv
3. After complete mixing and testing, then go to the modell and make a servo reverse

The Template wizzard can't know the real servomounting and servomovement
its allways wrong with his outputs and potential movements)
so make the mixer mathe correct and all ist fine
because you allways has to change it later with sero reverse

Cut off the old pigtails!

Helle

[jhsa]

And you will end up reversimg the servo twice. Once in the mixer with a negative value and then again in the servo menu..
For me, ailerons have the same signal and flaps different signal. I guess we could stay here the rest of the month argueing about it but at the end of the day the devs will do it the way they like it
Obviously there is more than one way to skin the cat I will stick to my way..

Joao

Sent from my GT-I9195 using Tapatalk

[ReSt]

For me, and thats my opinion, surfaces that have to move differently on the model (ailerons), should also move differently in the simulator. And surfaces that move in the same direction (flaps) should move in the same direction in the simulator also.

Finally change the output for the servo with servo reverse, if required.

But that could mean, that servo reverse should not affect the display in the simulator

Reinhard

[Kilrah]

Has it been reported that models backed up prior to installing 1.99 onto the SD card can't be loaded to a model using Restore Model?

It's normal, backup/restore can only work within a same eeprom version.
The automatic conversion system can only work on the entire eeprom contents, not on a single model (as there is currently no way to know the eeprom version of a single model to know if it needs conversion and if so how).

[pmackenzie]

For me, and thats my opinion, surfaces that have to move differently on the model (ailerons), should also move differently in the simulator. And surfaces that move in the same direction (flaps) should move in the same direction in the simulator also.

Finally change the output for the servo with servo reverse, if required.

But that could mean, that servo reverse should not affect the display in the simulator

Reinhard

It actually might make sense to remove the limits,reversing and safety channels from the simulator, since they don't factor into the calculations.
Or perhaps have two ways of viewing them: servo outputs that include limits and safety channels, or mixer outputs only that don't include them?

To explain what I mean, if you set up something like:

ch1 100% THR

cs1 a>x ch1 -90 (To start the timer whenever the motor is on)

cf1 (some switch) safety channel1 -100

You might expect that CS1 would be off if you activate the safety channel.
Or that if you reverse the throttle servo CS1 would now be backwards.
Or moving the limits on ch1 would affect the operation of CS1.

Each of these would change the servo monitor display, but they won't have any affect on the operation of CS1.
But this is the way it should be, since you want setups to be as completely portable as possible.
Limits and reversing are (and should be IMO) the final step that adapts a program to the physical model, in effect insulating it from the model.

Otherwise you could be in and endless loop of making changes. Move a limit and you have to go in and edit every mix,custom switch, cure, etc that uses it.
This could then affect other channels, so the custom switches that they might use would need to be changed as well.
Invert a servo and go back and change ever mix that feeds from it
Rinse/lather/repeat

I will have to see how the new curves applied to the servo outputs are handled, but they too should be completely outside all of the calculations in the same way.


Pat MacKenzie

[shadowjig]

Switch position warning on the Model Setup screen:

I tested this feature and it alarms with A^ is selected and the switch is something other then up. But if I have it on "A ", then there is no alarm. I know this is a new feature. But do you now only have the option of up or off. How about middle position or down as an alarm option?

Thanks

[rdeanchurch]

CompanionV1.99
In Functions does ThrTrmUp act as an event that is true for each movement of the ThrTrm or a value or ??

I ask because this Function:
ThrTrmUp Adjust GVARx Increment +1 does not work.
but this Function
SCup Adjust GVARx Increment +1 does work.

[Kilrah]

But do you now only have the option of up or off. How about middle position or down as an alarm option?

Set the switches where you want them, then long press ENTER on the <] icon. Setting positions has always been done like this
And yes, no symbol = no warning for that switch.