Control Mixer

On the complex mixer screen the graph still doesn't reflect the function selected...

Changing the order of the sources will complicate the code somewhat. I'm going to leave it as-is for now. If folks really feel strongly about it, we can change it later.
3-way switches are currently handled like in er9x. Basically there are 3 inputs (Mix0, Mix1, Mix2) each of which are either on or off. This makes them easy to use in the 'switch' functionality. We could also treat them as an analog channel '-100, 0, 100' but this would really only make sense as a source. Maybe I really do need to separate the 'analog' inputs from the digital ones to make this easier to use. As I said, for now I think this will do. Lots of other things to work on.

I've already considered putting 3 graphs there. It actually would not be too difficult to do...

May I have a few more suggestions?

On the expo curve screen there is the Pos/Neg spin button to change the meaning of the value. It has three options: Symmetric, Pos and Neg.
I think it would be better, if it hes only two option: if it is symmetric or not. Thet way in nonsymmetric case there could be two separate values, which would be easier to set both without the need to change between pos/neg, furthermore you can set them on the graph by clicking on the left (neg) and the right (pos) part.
In the symmetric case there would be only one value...

By the way I like Walkera's approach here: they always have two separate numeric spin box, but they have a common spin too. However it uses more space, and we don't have such widget anyway.

The other thing: can we use a click on the graph of the Expo&D/R screen to open the Expo screen besides the click on the function box?

Yes, as I mentioned, the current approach was crude. your concept is closer to my original idea. I was going to do something like in GIMP where you have a 'lock' icon to indicate the pos and neg are linked, which you can toggle on or off, and then have 2 values shown always in the expo screen. I didn't do it becaus eit would have been another couple hours of work to implement, and it is the kind of thing anyone can do in the future. Polishing the interface before we have basic functionality doesn't make much sense to me.

Any requests on how the timer should work?
How many do you need?

I looked at ER9x, and they have 1 timer which can be configured as count-up/down and can be configured to trigger on any switch/button, as well as mapped to a stick. When mapped to a stick they have the ability to have it only run when the stick is not zero. They also have the ability to change the speed of the counter based on stick position (so the timer runs more slowly at 1/4 throttle than 100% throttle.

The DEVO8 seems to have 2 timers, one goes up and the other goes down.

PhracturedBlue wrote: Yes, as I mentioned, the current approach was crude. your concept is closer to my original idea. I was going to do something like in GIMP where you have a 'lock' icon to indicate the pos and neg are linked, which you can toggle on or off, and then have 2 values shown always in the expo screen. I didn't do it becaus eit would have been another couple hours of work to implement, and it is the kind of thing anyone can do in the future. Polishing the interface before we have basic functionality doesn't make much sense to me.

OK, I can wait...

PhracturedBlue wrote: Any requests on how the timer should work?
How many do you need?

I looked at ER9x, and they have 1 timer which can be configured as count-up/down and can be configured to trigger on any switch/button, as well as mapped to a stick. When mapped to a stick they have the ability to have it only run when the stick is not zero. They also have the ability to change the speed of the counter based on stick position (so the timer runs more slowly at 1/4 throttle than 100% throttle.

The DEVO8 seems to have 2 timers, one goes up and the other goes down.

Any of the two DEVO 8 timers can count up or down. Countdown timers will sound an alarm. It would be great if they could be configured to different tones and/or volume. They can be mapped to some switches, but unfortunately you cannot inverse them as the er9x. But they can be started by a separately configured stick position switches. In addition it would be great if they could be started by channel value switches. That way it could be mapped to some minimal value of the throttle channel, and could handle throttle hold or idle up modes. (The current stick position switch doesn't stop if you hit the throttle hold, but stops if you use -100% of pitch while flying inverted.)

Using telemetry lowers the significance of timers, but they are handy and easy to implement, I think.

The slowly running timer is a nonsense IMO. I understand what are they after, but time is time. It doesn't elapse slower. The energy (or fuel) usage is not necessarily proportional with throttle (see idle up modes, where someone is on 100% throttle all the time).

FDR wrote: The slowly running timer is a nonsense IMO. I understand what are they after, but time is time. It doesn't elapse slower. The energy (or fuel) usage is not necessarily proportional with throttle (see idle up modes, where someone is on 100% throttle all the time).

I think you are still thinking about stick position. I believe they use the output of the throttle channel for their 'slow time' timer which may have nothing to do with stick position. I would guess that this is very close to proportional with Throttle. The motor will have to work harder if, for example, the blade pitch is increased or a model is in a dive, either of which changes the drag on the propeller, but I'd guess that over the course of a flight, throttle position maps pretty closely to flight time.

Anyhow, there is no need for anything like that now. I think I'll pass on the timer for the moment

I need to figure out how to deal with >100% servo travel, and then maybe I'll tackle virtual switches.

The Devo8 allows output scaling to 125% and allows servo endpoints out to 150%. I'm not sure how you can get to 150% throw if you can only have 125% scaling. Do we need to support 150% servo range? If so how do you get there on the Devo8?
Should the graphs all show -125% - +125% range?
Note that there is no way to go beyond whatever I choose as the max. So if you setup multiple 125% multipliers on a channel, such that Ch1 = THR * 125% * 125% the output is still only 125% (you just get there faster)

PhracturedBlue wrote:

FDR wrote: The slowly running timer is a nonsense IMO. I understand what are they after, but time is time. It doesn't elapse slower. The energy (or fuel) usage is not necessarily proportional with throttle (see idle up modes, where someone is on 100% throttle all the time).

I think you are still thinking about stick position. I believe they use the output of the throttle channel for their 'slow time' timer which may have nothing to do with stick position. I would guess that this is very close to proportional with Throttle. The motor will have to work harder if, for example, the blade pitch is increased or a model is in a dive, either of which changes the drag on the propeller, but I'd guess that over the course of a flight, throttle position maps pretty closely to flight time.

Anyhow, there is no need for anything like that now. I think I'll pass on the timer for the moment

I need to figure out how to deal with >100% servo travel, and then maybe I'll tackle virtual switches.

The Devo8 allows output scaling to 125% and allows servo endpoints out to 150%. I'm not sure how you can get to 150% throw if you can only have 125% scaling. Do we need to support 150% servo range? If so how do you get there on the Devo8?
Should the graphs all show -125% - +125% range?
Note that there is no way to go beyond whatever I choose as the max. So if you setup multiple 125% multipliers on a channel, such that Ch1 = THR * 125% * 125% the output is still only 125% (you just get there faster)

No. Read again, what I bolded.
I know they made the timer speed proportional to the throttle value. The point is there is not necesserily a direct relationship between the throttle and flight time. As you pointed out, often it is more dependent on pitch, than throttle.

Walkera allows range over 100% in the dual rate phase (it is in the beginning, I guess), and in the travel adjust (which is probably the last step).
However I do not understand your math. Ch1=THR*125%*125% is THR*156%. What you wrote is true only if there is a 125% limit. By the way IMO there should be an adjustable scaling and adjustable limit in the end.
All the middle calculations (for example the mixers) should stay at 100%, i.e. normalized. That way those calculations stay theoretical, and the range adjustments to meet the phisical requirements fall beyond that.

I ned to define the range of values that we work on. if we use -100-100 then there are only 200 steps total allowed of stick control. The A/D converter is actually 12bit (so we'd lose resolution if we use -100-100 whihc is only an 8-bit range). You also need to account for they fact that all math we're doing is integer math. the larger the range we allow the less rounding errors we have. Since I need to multiply values, and the largest supported type is 32bit, the largest data value I can eaisly manage is 16bit (-32k - +32k). Due to some other factors, practically I can only manage -16k - +16k. So if we say that the largest supported final value is '16k' then I need to map that to a servo throw. It can be 100% or 125% or 150% or 200%. I don't care much, but i need to define the maximum servo throw for this firmware. The larger the max-limit, the less precision we have (so we shouldn't set it any higher than it needs to be). That limit is then a clamp. If it is set at 125% then no value can be greater than 125% no matter what multiplication is done. This then becomes the maximimum servo endpoint.

I don't want to make this max value adjustable. It adds a lot of complication and I think the benefit is non existent,

You said:

All the middle calculations (for example the mixers) should stay at 100%, i.e. normalized. That way those calculations stay theoretical, and the range adjustments to meet the phisical requirements fall beyond that.

If I understand what you are saying, you mean that curves, scaleras and offsets should all be limited to 100%. At the very end, the final result is scaled by max-limit/100 such that at full extent the channel the servo is at the max-limit. that is certainly the easiest implementation, and you will never have to worry about multiple mixing stages going out of range.

I agree that it would be a shame to loose the ADC's resolution. (The er9x guys are working hard on extending their 10bit ADC resolution.)
I would like to avoid of the rounding error too. If you are working with small values (for example the mid stick with expo), and after that multiply with a larger number (for example with a scale), you will get quite ugly steps.
But I think we need some reserve of magnitude, to preserve the temporarily overshot values from clipping. For example if there are some calculations that flows over 100% (scaling, offset, or added mix) but after that there is a lower curve, or scaling down, then those clipped regions will presented as horizontal lines with less than 100% in the whole transfer function. However it's hard to say how much reserve is enough. I would say at least doubling the range is essential, but more is already may limit the resolution. So the ADC is 12bit, you said the max you can handle is 15bit, so it can be 13-14bit to use as 100%, that's +-4k or +-8k.

Another point:
I don't know what range the dfferent protocols send to the receivers. I guess there might be ones with 2byte integers...

I think 150% final range will do. I don't think servos can bear more...
By the way I didn' mean this limit to be adjustable, but within this range to protect some servos...

Oops! Your current code throws a compile error:

+ Building 'emu_devo8.exe'
objs/emu_devo8-w32/mixer_page.o: In function `limitselect_cb':
C:\MinGW\msys\1.0\home\FDR\src\deviation\src/pages/mixer_page.c:112: undefined r
eference to `MIXPAGE_EditLimits'
collect2: ld returned 1 exit status
make: *** [emu_devo8.exe] Error 1

I know, you did't say it's ready, I just realized there is a new version available...

Thanks. I forgot to check in a file.
I added a limits page, and started work on the 'main' mixer page. It isn't done yet, but it should compile now. I try to ensure that whenever I check in code it at least compiles, so if you ever find the code can't compile, let me know.

I bet you are busy flying you Ladybird, aren't you?

FDR wrote: I bet you are busy flying you Ladybird, aren't you?

It is a good guess. I have been having fun with it actually. I'm flying it with my Devo7, and I've found that the menus are pretty well laid out given the limitations of the screen.

I've had some other tasks that I needed to get done this week, and have family in town now. I expect to get back to working on the firmware next week.

OK!

Give a chance to the original DEVO 8 fw too!
Too bad it's only a 4ch model, a 6ch one would be more challenging...