OpenTx - what is the fuss really about?

[IanR]

Hello Kevin,

I really like the fact that, with Matty's Logical Switches, the throttle cannot be activated until the throttle stick is at zero. Does your use of Special Functions do that, also?

Cheers, Ian.

[Kevin Fairgrieve]

Sadly not Ian.

My method rely's on me not knocking the throttle once SF has been activated.

Has not been a problem for me since I started using a Taranis in 2014.

Matty's way is much safer than mine.

Kev

[MattyB]

Ian, not a problem - let me get the kids to bed and I will post you up a simple solution.

[IanR]

Matty, much appreciated.

[MattyB]

OK... here are the two switches we set up in my original example:

To reverse the direction for which switch SF activates the throttle cut you need to reverse BOTH references to SF in logical switches L1 and L2. That means the additional AND condition in L1 needs to be set to SF↑, and variable 2 (V2) in switch L2 needs to be SF↓. Try it and see - modifying the template I uploaded to RCSettings seems to works fine in Companion.

Edited By MattyB on 28/04/2017 10:47:07

[MattyB]

PS - Remember if you have switch checks enabled on startup you will also need to reverse the direction of SF there too. This will ensure it the TX requires you to switch on with throttle cut enabled (though the "sticky" functionality does mean the motor can't jump into life even if you did; still, safety first!).

Edited By MattyB on 28/04/2017 10:53:59

[MattyB]

To help others I have updated my Sticky throttle cut example on RCSettings - instead of 1 setup there are now 4 within the same file catering for different tastes:

1. StickyThr1 - Cut enabled using an additional mix line with "Replace" logic. Throttle inhibited when SF↑.
2. StickyThr2 - As StickyThr1, but switch reversed (throttle inhibited when SF↓)
3. StickyThr3 - Cut enabled using Override CH1 special function. Throttle inhibited when SF↑.
4. StickyThr4 - As StickyThr4, but switch reversed (throttle inhibited when SF↓)

This is a good example of the modular nature of OpenTX - different approaches can be combined from individual components (i.e. the same sticky switches L1 and L2 can be used to trigger different actions - in this instance inhibit via a mix line, or inhibit via the Override special function).

Edited By MattyB on 28/04/2017 12:08:10

[IanR]

Thank You, Matty. You've done it again. It works a treat.

Ian

[MattyB]

NP at all, happy to help.

Edited By MattyB on 28/04/2017 13:57:07

[IanR]

I have flaps set up on a 3 position switch. I have set the duration from up to mid, and from mid to down, at 3 seconds, each. However, when I go directly from up to down, by-passing mid, it still takes 3 seconds. Is there a way to make this a 6 second duration?

Thanks in advance, Ian.

[Attilio Rausse]

IanR

Assuming flaps on CH8 and three pos switch is SD (change these two values to suit)

In mixes on line CH08 should read SD Weight (+100) slow (u3:d3)

achieve this by editing CH08 Source is SD Weight is 100 Up slow 3 Down Slow 3

Hope this is what you need.

Til

[IanR]

Thanks, Attilio - I'll try this.

Ian

[IanR]

Attilio, many thanks. It works perfectly. Companion shows me that the flaps will move at a uniform speed taking twice as long to go from up to down as from up to mid etc.

Great stuff. Open TX just seems to keep getting better.

Ian.

[Chris Bott - Moderator]

For anyone interested - OpenTx 2.2.0 full release is finally available. ***LINK***

Congrats to the developers for all the hard work.

[trebor]

Is this a version for the Horus and qx7 or is it ok for the x9d+ ? I'm new to this, forgive me for asking.

[IanR]

Good question, Trebor. The announcement which Chris has linked to doesn't make it clear. But even if it is ok for the x9d+ I shall be holding off installing it on mine because

"...This is a .0 release. A lot of testing has been done by developers and beta testers, but inevitably some issues only pop up with large scale use and particular use cases, if you’re not very adventurous hold off for a few releases until things are well ironed out..."

Is there any other industry where getting a new model comes with this type of caveat? If you bought a new version of a car or vacuum cleaner or TV, or whatever, you would expect it to function as required. Only with computers and software, which is what these transmitters basically are, are you told from the start that they may not work properly.

Ian

[Andy Meade]

Although to be fair, vacuum cleaners have very few upgradeable parts from the manufacturer. Cars do have recalls and also ECU updates (Toyota and VW, in very recent times for instance). TV's also these days have software updates to increase functionality over time. The fact is that not all the testing can be done in-house by the OpenTX team - their resources are very limited as they do it for free, so some testing will / does need to occur in the "wild".

[IanR]

My point is that software developers often point out that their products may - or even - will not work properly out of the box and have said so from the very beginning. When I was nobbut a lad (in the 60's) the company I worked for introduced a computer system which worked mainly from punch cards. The cost of this system included a full-time person from the software company, who remained on site for 1 year, to iron out bugs. I think that we have become so used to this that we accept it without complaint.

Having said that, I am not complaining, just making an observation.

In this instance, I accept that I will have to wait until others have said that 2.2 is robust enough even for the not very adventurous among us to give it a go. And I do love playing with my Taranis and OpenTX.

Ian

[Chris Bott - Moderator]

Yes this major release is for all the tx types mentioned above.
It has been available as various "release candidates" for many months and while is has been fully safe to fly with all the way along, it has improved with each release. To the point that the developers are happy to call it a complete version.

It will even convert models between TX types. This is probably the buggy part of the software still, so converted models need to be checked carefully.

[trebor]

Will this cure the model delete where the Rx is still on memory and you can't run the wizard to program another model in. ? Or am I missing somthing.

[Andy48]

Posted by IanR on 31/05/2017 13:04:31:

My point is that software developers often point out that their products may - or even - will not work properly out of the box and have said so from the very beginning. When I was nobbut a lad (in the 60's) the company I worked for introduced a computer system which worked mainly from punch cards. The cost of this system included a full-time person from the software company, who remained on site for 1 year, to iron out bugs. I think that we have become so used to this that we accept it without complaint.

Having said that, I am not complaining, just making an observation.

In this instance, I accept that I will have to wait until others have said that 2.2 is robust enough even for the not very adventurous among us to give it a go. And I do love playing with my Taranis and OpenTX.

Ian

The point is that any OpenTX update is a mixture of bugs and enhancements. The latter are suggested by users out in the field, and the cumulative effect of these enhancements is what makes OpenTX as powerful as it is.

[Andy48]

Posted by trebor on 31/05/2017 16:31:39:

Will this cure the model delete where the Rx is still on memory and you can't run the wizard to program another model in. ? Or am I missing somthing.

It is likely this is a deliberate safeguarding feature.

Select a new model then use the wizard, problem solved.

Edited By Andy48 on 31/05/2017 18:28:26

[trebor]

I've moved a model after programming it in but what happens if sell a receiver or it packs up. There must be a way to delete the bind to that particular Rx.

[Andy48]

Just change the receiver number on the setup screen.

[Chris Bott - Moderator]

Or rebind with that model number to your replacement receiver, in this model memory or another. It's completely flexible.

I tend to bind a new Rx to an unused Rx number and stick a number on the Rx. If ever the Rx changes planes, I can check the number on the Rx and change the Rx number in the new model memory to match. As I say, complete flexibility.