openrcforums

makes sense... thanks for the clarification and example!

ya, there is a workaround (apply 100% mix along with offset, and then weight the result of that into the output you're after)...

...was just pondering as to what the intended operation was, maybe it can make a return as a checkbox. all good. guess you can kill that github issue.

oh look, it's a bug. I honestly thought it was simply working as intended :) It's in the current nightlies, but rolling back to 2923 it's considering offset with the weight. simple to test: new model, add an elevator mix to ailerons. set weight at 50, and offset at 50. servo output should start at 2...

a question for the devs... am curious about mix offsets. Playing with using GVars as trim values, all works pretty well to use them as offsets, and it can do some pretty nifty things, but there's a hiccup in how offsets are applied. In the mix chain, offsets are applied without consideration of the ...

if it was a Lua script, that would be just about as easy to activate as a checkbox... could be a really nice middle ground, and OpenTx could find out if it's popular or not.

The only v2 feature is the sticky switch... which I should have realised, the sticky switch feature is actually just a simplification on what was already possible. You can replace any sticky switch with a GVar, two functions, and a logic switch. In the previous openTx... the logic switch: a~x GV1 10...

this is using 1.99

...can't say I've played with it in Companion at all, I just set stuff up in the radio.

Is the "sticky" switch set by the first input and cleared by the second one? Just asking regarding compatibility. I've recently been adding a "latch" option to er9x/ersky9x custom switches which probably does the same thing. Mike. ya, the sticky switch in this example is working...

it needs 1.99 for sticky switches, and to look at "Ail" instead of the "IAil" for mix source to get the difference of the instructor. the graphic has "OpenTx v2" just under its title.

a graphic explanation and the eeprom (zipped bin). the bin contains a model with just aileron movement triggering the return of control, and another model that has "bump either Ail, Rud or Ele and instructor gets it back".

I simplified the setup for my own general use... - for the trainer setup, make all stick axis which bumping will return the control to the instructor ADD mode (showing "+=" on the trainer screen). - add some mixers on an unused channel, adding (100 weight) all these root input axis (Ail, E...

so the above spiel with the logic switches was fun, the only issue was that it didn't actually work :) ...I made the switch logic (which works fine), but OpenTx bakes the control from the student so deep that you can't differentiate the instructor moving the stick from the student moving the stick. ...

I think the essence of this thread is "everything is already possible, operate the way you feel is best for your situation"... momentary switch as usual, non-momentary, the fancy "just fly the plane and you get control back" via the logic switches, the "Add" mode... all...

I think there's a transition of needs... "Add" is great for the totally uninitiated... regular trainer switch for the "starting to get a feel for it".... but like ImRich mentions, there's "getting well along" student where it's just a pain to hold the switch as for 99% ...

Thanks for the idea(s) and the setup to try. I will try it when I get a moment. Different instructors use different methods when teaching and of course, it will vary greatly as the student progresses. As you know, at some point the student is doing almost all of the flying (including take offs and ...

reckon that with setup, just starting to fly the plane again is a solid way to get control back, may as well simplify a little and clear one of the OR lines (no need for press of switch to get it back, just fly the plane)... L1 .. OR ..... SH↓ ... L3 L2 .. Edge .. SH↓ ... [5.0:--] L3 .. Stcky .. L2 ...

...and you could also add the "bump the sticks" in logic switches also (one line per stick axis that you want to monitor). I gotta say, that is a rather good idea, rather than switch actions, just set about recovering the darn airplane :) edit... ok, here's the whole tamale (I wanted to se...

I played with the idea just for practice/giggles... in logic switches... L1 .. Edge ... SH↓ ... [5.0:--] L2 .. Stcky ... L1 .... SH↓ L3 .. OR ..... SH↓ ... L2 ...the Sticky switch (L2) does most of what you want, but it doesn't have the "long hold" on the start of it to activate. L1 does t...

MikeB wrote:You need to check that when the protocol is changed, or the module disabled, that all timers etc. are correctly re-configured.

Mike.

isn't that all the init_* init_no_* setup_* disable_* code in pulses_driver.cpp?

many thanks for the info! very cool. from looking at the code path, the protocols come together at the top of pulses_driver.cpp which farms out the specific work. menu_model.cpp seems to have the only divergent code which seems to only be setting up the menu and the selections. I'm just curious what...

...following the post above to look at menu_model.cpp, the menu options prevent PPM from being shown/selected, but all the follow-on code seems to reference port arguments. sure seems like this used to be a feature.

For giggles I did some more poking around the source code, specifically "pulses_driver.cpp" that Mike pointed out. As far as I can gather, it already has code to support PPM output to the internal module. For all the *_pa7_ppm code, there is *_pa10_ppm, which *_pa10_ppm is all about PPM fr...

dvogonen wrote:Bertrand added a Lua page in the OpenTX development wiki yesterday, so you find what you are looking for there.

...which is this page here: https://github.com/opentx/opentx/wiki/L ... -in-OpenTX

Then there is all the code in pulses_driver.cpp to configure the hardware and action all the interrupt routines. Mike. yup, never said it would be a free/trivial feature, it's just a request that seemed to make some sense. If I knew how to hack the code, I'd just issue a PR, but it's just a request.

There is a lot of code "behind" each of the protocols you can select. There is FAR more to adding any extra protocols to the internal connection than just allowing them to be selected. Mike. yup, I understand there's a little background coding to go along with it. I poked the source to se...

no, the radio doesn't allow swapping out the internal module. But only because the firmware only outputs D16, D8 and LR12 to the internal port. The *external* port gets all the fun options like PPM and DSM, but it's the ability to hack out the internal module which I think would be fun and amusing. ...

Pretty simple request (I hope): simply allow the same module options for internal module as the external module. It is a pretty simple hack to Taranis (compared to all the other hard hacks people are doing with it), to disconnect power to the internal module (or even remove it completely) and wire i...

sounds fancy, not all that hard to do with OpenTx... add an extra line on the mixer screen for throttle, assign the switch/position, assign the curve... set what you want the throttle to do with the curve. Do the same with flap channels, voila.

Just out of curiosity; Do you have a specific interface in mind to add support for? Or is your idea to create a new interface that is better than the two digital interfaces OpenTX supports today? the latter. both OpenTx and XPS can handle more channels with less latency, only thing missing is the i...

Only thing that matters is how it is in its current form (or we may as well go over every possible problem, argument and hassle that every other manufacturer has ever had). I came after Nano's and the hopping changes... but to say it has been rock solid is an understatement. I have brought a lot of ...