GUI

PhracturedBlue wrote: I started looking at configuring the main page.
I think the configuration needs to be per-model (if my model has telemetry, or it is a plane, I may want the page setup to be different). Reading the configuration from the model.ini file is easy enough to do, but I'm not sure of an easy way to configure it from the Tx. i guess I could just have 4 spin-boxes numbered 1-4 which each can be set to 'hidden, a timer, a telemetry value, or an output channel. We could also list the 6 trims and determine if they are visible or not.

Any thoughts?

I thought we could have a few main page layout with different controls on them, like the two muckup I did. You could select a default layout per model, but probably I would allow changing layouts on the fly from the main page (for example with simple left/right buttons and probably some small icon click).
Not all the controls would be configurable on a layout, since it can determine a lot itself, like trims (4 or 6) of the first one or channel bars on the second one, etc.
I would allow to configure the box contents (but for example there could be a layout with a lot of boxes instead of the trims to show more telemetry data).
Every (fix) layout would have a similarly arranged configuration page, on which in place of the configurable boxes there would be texselects to select the value/timer/telemetry data to show in that box.
But I'm not sure so far, how would I store this in the model data...

...continued:

Probably each box of each layout should have a default, which value/timer/switch/telemetry it shows, so the model config only needs to store the differences...

Bug reports:
In the beginning the app crashed if I tryed to change the curve type on the simple mixer, but now it is working, I cannot reproduce it anymore...

However on the curve editor the ok and cancel buttons are on each other, so cannot click on ok.
EDIT: fixed, pushed

So, I will try to explain my confusion/question about the channel mapping in more depth:

1. First confusing thing is the emulator's right pane.
There are "Raw" an "Final" columns for each channel.
The final column is the calculated output value, that will be sent out, which is a function of the source(s) selected on the mixer page(s). I think it is clear. More about later...
However the raw column is not really a channel value, I guess, but the hw input values! These are mapped to the given named sources (which are selected as source) according to the stick mode selected.

2. The channel mapping to the protocol.
You have said it is handled by the protocol:

PhracturedBlue wrote: If you mean the channel number assignments (i.e. thr is ch 1 or 3 for different protocols) then that is handled by the protocol code today.

...but how is it handled?
I think the protocol should transmit the channels in the order they are defined on the mixer page. Otherwise how it will decide, which channel to assing to which transmit channel? Do you say, that the protocol knows about itself, that it is AETR or TAER, so it will look for a channel, about which it thinks it is the throttle, and send it to the 3. or 1. channel according to the mapping? I think that will not do! What if more then one channels share the throttle as source? Which one will the protocol choose to transmit as throttle?

And here comes, what I was missing: when you start configuring a new model, none of the channels source is assign yet. I see their sources default to AETR in order when I am trying to assign. IMO these defaults should change according to the selected protocol!
In that way if I choosed DSM2, than channels should offer TAER, but the DEVO will default to EATR, and Flysky would to AETR.
And all the protocols wouldn't care about anything, just send the channels in the order they defined.

Of course there are disadvantages:
- one should know the channel order (that is what those defaults would help);
- if you want to change the protocol, you would have to move the configured channels, i.e reconfiguring all of their mixers.

I think later we (actually you ) should allow these kind of editing capabilities on mixers, like move, copy or duplicate, etc...

FDR wrote: Actually I like the original implementation, in which the countdown alarms, when it reaches 0, but change color and continue to negative, so I can see later, how much I overrun.

I can do that

How can you reset the timer?

long-press

PhracturedBlue wrote:

How can you reset the timer?

long-press

...and without the pencil?

FDR wrote: 1. First confusing thing is the emulator's right pane.
There are "Raw" an "Final" columns for each channel.
The final column is the calculated output value, that will be sent out, which is a function of the source(s) selected on the mixer page(s). I think it is clear. More about later...
However the raw column is not really a channel value, I guess, but the hw input values! These are mapped to the given named sources (which are selected as source) according to the stick mode selected.

You understand correctly. That was really meant as a debugging aid more than anything else.

For the channel mapping protocol, My plasn was to map the 1st 6 channels as the rx expects them (TAERGF). The deviation firmware will de setup so that when you clear the model, it comes up as TAERGF (or whatever I choose). So yes, Ch1 on the Tx will become Ch3 on the Rx. I would reduce the confusion by renaming channels 1-4 to be the 'ChThr' or whatever.

However, now that I think about it though, it would be easier to have the defaults change per protocol. Then the channel names will always be 1, 2, 3..., but when you reset/clear the model it will put the channels in the right order.
My plan was to add 'template' to the 'File' spinbox, which would let you reset your models to relevant templates:
simple 4ch, plane, 6-ch heli, etc
If these mapped based on protocol that might be best.

I think later we (actually you ) should allow these kind of editing capabilities on mixers, like move, copy or duplicate, etc...

Yes, this is on my to-do list.

...and without the pencil?

Why would you use a pencil? My thumb works just fine
You can do it with the kb too. longpress-enter, up, longpress-enter

PhracturedBlue wrote: You can do it with the kb too. longpress-enter, up, longpress-enter

Nope, it doesn't work.
I have tryed both long press already...

PhracturedBlue wrote: For the channel mapping protocol, My plasn was to map the 1st 6 channels as the rx expects them (TAERGF). The deviation firmware will de setup so that when you clear the model, it comes up as TAERGF (or whatever I choose). So yes, Ch1 on the Tx will become Ch3 on the Rx. I would reduce the confusion by renaming channels 1-4 to be the 'ChThr' or whatever.

Yes, that would be my other suggestion: if those channels are dedicated to some functions, then they should be named accordingly. Instead of Ch1-4, they sould show THR, AIL, ELE, RUD on the buttons.

But I think it wouldn't be nice and clear, especially for the advanced users...

FDR wrote: Yes, that would be my other suggestion: if those channels are dedicated to some functions, then they should be named accordingly. Instead of Ch1-4, they sould show THR, AIL, ELE, RUD on the buttons.

But I think it wouldn't be nice and clear, especially for the advanced users...

I looked at all my Rx, and al but one label their channels by name. The WK26xx is especially annoying because it appears that they use different layouts for different Rx (so numbers may not make much sense). This lends strength to the idea of naming the output channels. But I think it will be confusing to try to understand the difference between the output 'THR' and the input 'THR', which is why I prefer the numbering scheme.

I think we'll try your idea of using the protocol to set the initial value 1st.

One other option.
since we have room on the mixer page. we could place to the right what the Rx expects in text. then the user would see Ch1-4 but it would tell them which ones map where on the Rx.
The templates would still map them properly initially.

PhracturedBlue wrote: One other option.
since we have room on the mixer page. we could place to the right what the Rx expects in text. then the user would see Ch1-4 but it would tell them which ones map where on the Rx.
The templates would still map them properly initially.

Cool!

FDR wrote:

PhracturedBlue wrote: You can do it with the kb too. longpress-enter, up, longpress-enter

Nope, it doesn't work.
I have tryed both long press already...

Fixed

On a different note, should the value of the trim show in the Throttle value on the main screen?
That is if the throttle is showing '50%' on screen and I push the up-trim button, should it go to 51% (or whatever)?

PhracturedBlue wrote: On a different note, should the value of the trim show in the Throttle value on the main screen?
That is if the throttle is showing '50%' on screen and I push the up-trim button, should it go to 51% (or whatever)?

I will check it later at home, but I think no.
I don't know how they do it, but their trim values have +-200 range!
So if it were count into the 0..100% throttle value, it would overflow soon...

EDIT: ...and there is the WK2401 protocol, which sends the trim values separately...

FDR wrote: EDIT: ...and there is the WK2401 protocol, which sends the trim values separately...

Yeah, well, I'm not planning on doing that. I'm just going to leave the trim values at 0, and adjust the channels to include the trim. I see no advantage to keeping them separate

PhracturedBlue wrote:

FDR wrote: EDIT: ...and there is the WK2401 protocol, which sends the trim values separately...

Yeah, well, I'm not planning on doing that. I'm just going to leave the trim values at 0, and adjust the channels to include the trim. I see no advantage to keeping them separate

Nooo!
I have such a heli I would like to fly with the new fw!

I think that was because that way the early versions of flybarless rx units couldn't distinguish stick input from trim value, i.e. is the value is intentional command of the user, so it doesn't have to correct against. If there was a stich value, the flybarless unit let it go without correcting. If the stick value was 0, then it would try to correct every movement. I guess this is from where the usual advice comes: trims fool the flybarless units, so don't use trims!
However Walkera sent the trims as separate channels, so the flybarless unit could use them without disabling the stabilization.
It can be true for the simple head hold gyro as well, to some degree...

FDR wrote:

PhracturedBlue wrote:

FDR wrote: EDIT: ...and there is the WK2401 protocol, which sends the trim values separately...

Yeah, well, I'm not planning on doing that. I'm just going to leave the trim values at 0, and adjust the channels to include the trim. I see no advantage to keeping them separate

Nooo!
I have such a heli I would like to fly with the new fw!

Well, you'll need to try it 1st the way it is now. As I don't have access to a Tx or Rx that actually implements it, all I have are the logs I got from renatopub, and I don't have any way to verify that I coded it properly. So I will stick to the parts I can test which will be to match the 6/8ch modes. If it really doesn't work, we'll deal with it when the time comes.

What is your thought behind having multiple main screens? i plan to reserve the arrow keys for virtual buttons, so you won't be able to use them (without a long-press-enter) to switch pages.

But I don't really see the value in being able to switch between multiple pages quickly for a given model. I understand choosing one of several templates and configuring the position, but not being able to quickly switch between them on the fly.

It isn't that it is technically hard to implement, but it will take a lot of time to develop multiple pages and have each one be configurable.