Creating a complex throttle mix, with two safeties

Hi folks,

I'm trying to figure out how to do this, with complex mixers and virtual channels I'm sure there's a way to do it, I'm just not sure how.

I want to configure throttle hold for my nitro heli, but I'm after three separate flight modes:

Normal: Full -100 to +100 range, TH goes to -100 and cuts the engine.
Mode1: Normal flight, but ensures I can't drop below a safe idle figure.
Range approx -60 to +100, with TH going to -60 (idle)
Mode2: Idle up. Throttle at 80 or above. TH goes to -60 (idle).

Questions:
1. Can I achieve the above with a complex mixer?
2. Could I 'tune' the idle figure with a trim button or similar?
3. Is this plan completely bonkers?

I'm still learning nitro engines, so I may be misunderstanding, but my feeling is that the idle figure will vary with ambient conditions. I know this can be adjusted by tuning the engine, but I'd like to be able to quickly work out a throttle position for a good idle, and set this as both my minimum stick position, and the TH position for modes 1 and 2, with one setting controlling all of these.

I have a Devo-10 so I could use the AUX4 or AUX5 knobs, but these are a bit too easy to knock by accident. I'd prefer a fixed value that I had a quick and easy way to adjust after I've started the engine. The ideal would be to use a trim button for this, but I don't know if we can use them as standard inputs. Can I set a virtual channel with a trim?

Thanks for the suggestions. I've given it a go, and I think I'm close, but I'm obviously missing something.

I'm troubleshooting the throttle mix one step at a time, starting with the last stage; the idle throttle hold.

The behaviour I'm seeing is that if I put the trim up even a single step, I see this value smoothly increase from -100 to +100 in small steps. And as soon as I put the trim down even a single step below zero, I get the same behaviour in the opposite direction, with the value smoothly dropping to -100.

So I have something I can adjust, but it goes straight to the endpoints.

Would you be able to take a look at my model.ini and let me know where I'm going wrong?

Thanks

PS. I can't seem to add an attachment, it's disappearing each time I hit submit.

Just a model.ini file, being uploaded straight from my transmitter. I'm trying again after copying them to my computer.

I'm using the 'insert' button to add a link in here too:

Ok, I had a play this morning, while your suggestion should work great for the throttle hold, I also want this same value to be the minimum I can take the throttle to while in FMODE1 or FMODE2.

So I've added a 'max' mixer to keep this up, and had a play. I've definitely messed something else up now, but spotted something different with the trim behaviour:

• When I start, the trim is at 101.
• I can increase the trim all the way up to 200 in steps of 1, setting the value anywhere I like.
• I can then decrease the trim down to 100.
• As soon as I go one step beyond that, the value scrolls smoothly down to -101.
• From there I can go all the way down to -200 in steps of 1, setting the value anywhere I like.
• If I go back up, -100 is the midpoint of the trim, and going a single point above that causes it to scroll to +101 again.

It'

s close, but it's doing weird stuff lol.

I haven't looked into the config too deep but I had a similar behavior before. It seems to be that the output of the mixer is used as input (maybe not directly but via some other mixers) so every time the screen is refreshed and a new value is calculated it changes magically without intervention until it reached a stable state.
So I believe the range from -100 to 100 is unstable - somewhere is an offset which moves the active ranges to -200...-101 and +101 to +200 instead of -100 to -1 and +1 to 100 with an unstable range at 0.
I have no tx/emulator here so I can't check this but maybe this helps.

Aaah, thanks rbe, I think that makes sense.

I do have virt1 as the input for virt1. And I'm guessing that as soon as I add a trim to virt1, it's going to output slightly higher or lower than its current value... Which will then change its value... And so a +1 will just keep the value climbing until it hits the upper limit.

I've created a feedback loop... D'oh!!

I have tested yet. The easiest way to have a proper behavior is setting the mixer type to "None" for Virt1. This will prevent the loop.

Thanks, I'll try that.

I thought we needed both, my thinking was to use multiply rather than adding twice, so I setup a 3 part mixer for virt2. Would this have worked?

Page 1: Set initial value to fixed -100
Page 2: If RUD_DR1, replace to fixed +100
Page 3: Multiply, using a !FMODE0 as input, with a curve of -100 to +100
(so multiply by positive in FMODE1 or FMODE2)

Am I correct in thinking that multiply treats +100 as 1? Do we get this behaviour:

100 x 100 = 100
100 x -100 = -100
100 x 0 = 0

Thanks

Many thanks for all the explanations, it's helping loads.

There are definitely still bits I'm not understanding though. I can see you used an offset and a scale to get the trims working, and I was able to copy that approach to use Virt3 for Channel 5 too. I've not got a nice easy way to tune the gain on my giro when I set it up next week

Coming back to the throttle settings, throttle hold now works perfectly, and I have a full -100 to +100 curve on normal mode. I also have a MAX mixer added in so neither FMODE1 or FMODE2 can go below the idle that's been saved in Virt1.

However, the throttle in FMODE1 now won't go above 47, and FMODE2 is now outputting 27. The lower limits are correct, but it's had an unexpected side effect on the high end.

It feels like the MAX mixer I've added in is also acting to scale or multiply the end result (although I could be guessing completely wrong).

Don't you need to re-order that in order for the Throttle hold on FMODE0 to work.

[channel3]
failsafe=-100
min=-100
template=complex
[mixer]
src=THR
dest=Ch3
usetrim=0
[mixer]
src=THR
dest=Ch3
switch=RUD DR1
curvetype=fixed
scalar=-100
usetrim=0
[mixer]
src=THR
dest=Ch3
switch=FMODE1
usetrim=0
[mixer]
src=THR
dest=Ch3
switch=FMODE2
curvetype=fixed
scalar=80
usetrim=0
[mixer]
src=Virt1
dest=Ch3
switch=!FMODE0
scalar=20
offset=-70
muxtype=max


Loving this though, nobody else in my club knows a thing about this controller (they're all Spektrum or JR), but I'm getting to know this pretty well now and there's not much you can't do once you've worked it out.

Could I just ask how the scalar and offsets work with the trims. I understand they're needed, but I really don't know what they are doing, or how they interact with each other.

Also, what does usetrim=0 mean, does it prevent that mixer being effected by any trims?

And finally, did a find a bug in the MAX mux? What was causing those weird upper end scaling effects?

Aaah, I got it.

Regarding the scales, I should have been more precise. I understand the concepts, but what I don't know is:

- What is the normal range for the trims? -100 to +100?
- What effect does scale 20 have? Is that 20%, 2x, 20x?
- Which is applied first, scale or offset? (ie. is the offset scaled too?)
- Why do we need to scale and offset these? Is that just a workaround for the feedback loop?

It's a great feature though, using trim buttons for virtual channels is such a neat solution for setting idle and gain figures

Ok, I installed your new throttle settings, and we definitely have an offset here.

In FMODE1, with the stick at 100, I get 47% throttle.
In FMODE2, which is hard set to 80, I get 27% throttle.

In FMODE1 and FMODE2, changing the idle setting with the trim changes the available throttle range.

I think the !FMODE0 mixer is applying an offset to the whole throttle range, not just it's own output, and there's some interaction with the trim here too.

Is there any way round that while retaining the trim functions to adjust the idle?

Hmm, odd. If I remove the scale and the offset, and set the trim figure to zero F1 has a range of 0 to 100, and F2 is correctly set to 80.

If I take the trim down to -48, the upper bounds drop by -24. So F1 gets a range of -48 to 76, and F2 ends up at 56.

I think the scroll problem was due to Virt1 having itself as an input, the problem now seems to be odd behaviour of the MAX mux.