Protocol Stacks

FDR wrote: BTW the negative trim steps are displayed as "0.-5"

Nice. I fixed that too.

Found one more:
Somehow it doesn't store 1.0 trim step. It works with other values, but if I set 1.0, next time it will be the default 0.1

Sorry, that I find them one by one!

FDR wrote: Found one more:
Somehow it doesn't store 1.0 trim step. It works with other values, but if I set 1.0, next time it will be the default 0.1

Sorry, that I find them one by one!

It's all fine. This one is because there is a default defined in the ini and it had the wrong value. Fixed.

Today I've got a chance to fly some.
I repaired my Ladybird and flew it.
I used to use 150% servo extent for the rudder, to turn faster, and I think we miss that range now. I feel like the current maximum 100% is about equal to the original 100%, but now you can't reach over that limit.

The binding message doesn't automatically close when the protocol is WK2401 or WK2601, and doesn't even count down with the J6Pro...

FDR wrote: The binding message doesn't automatically close when the protocol is WK2401 or WK2601

I have fixed this (but not released the change yet)

and doesn't even count down with the J6Pro...

That is on purpose. the J6Pro uses a handshake, not a time-delay. So until it can talk to the model, it will stay in 'bind' mode.

A silly question about the WK2401 protocol:
Now the trims are mixed to the corresponding channel value and the trim "channels" are left zero, am I right?
Would it be possible to bound them to 4 other channels? Then I could simulate the original behaviour this way: the first 4 channels would be EATR as usual, but without trims, and the next 4 channels could be assigned to the trims as source.
It could be configured in the current way too, because if you don't assign the trims to the other 4 channels, they would stay at zero...

What do you think?

FDR wrote: A silly question about the WK2401 protocol:
Now the trims are mixed to the corresponding channel value and the trim "channels" are left zero, am I right?
Would it be possible to bound them to 4 other channels? Then I could simulate the original behaviour this way: the first 4 channels would be EATR as usual, but without trims, and the next 4 channels could be assigned to the trims as source.
It could be configured in the current way too, because if you don't assign the trims to the other 4 channels, they would stay at zero...

What do you think?

What is the problem you are facing? What works properly with the Wk2401 but not with Deviation? Understanding this would help properly solve this issue.

The proble is, that trims use up the range.
I've made some mechanical measurements of the servo travel (I don't have neither digital analyzer nor a storage scope ). Here are the avaraged result of three measurements of the aileron servo horn distance from the base in [mm]:

2402 without trim (i.e. trim=50%):
left stick: 13.53mm
middle stick: 14.95mm
right stick: 16.43mm
It means it have 1.42mm down range and 1.48mm in the upper direction, so it is symmetrical. (It cannot be measured too accurately)

The deviation without trim (=0%) is about the same:
13.56/14.93/16.2mm wich gives 1.36/1.27mm down/up range. It does seem a little less then the 2402 has, but it is hard to be sure, since we are talking about ~0.15mm here.

I found out that the trim range of the 2402 is less than I thought.
It shows 0-100% (with 50% in the middle), but it is only about the quater of the whole range.
2402 with 100% (i.e. full right) trim:
13.88/15.28/16.73mm It means the range remains symmetrical! (1.4/1.45mm)
The difference the trim gives is: 0.35/0.4/0.3mm (which is about the quarter of the throw.

However the deviation trim uses up the useful range. If I set the trim step 1.0, then it consumes the whole range in one direction, but it is too much as I've showed, but even with similar trim range the servo throws in the two directions will differ significantly: 1.59/0.8mm

That's why I would like to try to make the outputs indepent from the trims...

Thanks. Now the question is whether we should enable that behavior for all protocols or just for the Wk2401.

I could achieve this same behavior with the mixer by shifting the center point an keeping the existing range (i.e. when you move the trim, the range would go from (-100->100) to (-95->105). I'm not sure if it is a good idea or not though. Maybe an option on the trim page to toggle this behavior. We'd also need to figure out how to handle limits in this usage (maybe just ignore them...I dunno)

No, I'm not sure we should do that. The channel resolutions in the protocols are limiting us...

First of all: the 2401 protocol sends the trims separately, and the receiver will add them together. This way it uses the whole output range, which is 10 bits. I don't know what values we send at +-100%, but it already seems less then the 2402 does...
The 2402 doesn't have servo travel adjustment, it always use the whole range.
It is more "agressive" then the 2801 is in 2401 mode, since the 2801 has travel adjust, and it uses only 100% out of the possible 125% range by default.
But most of the 4 channel models need that whole range to move and react fast enough. Most of them are some kind of auto levelling type, like all the coaxes, and the ones with 45° flybars. These are the models, that often need the use of trims also. The 6 channel ones were all with normal 90° flypads, or later flybarless, which do not benefit from trims, because there is no auto hovering without touching the sticks anyway, so no need to trim for it...

So we should use the limiting 10 bits range of the old Walkera protocols as much as we can, and do not reserve for the trims. That's why the 2401 is unique, because it sends the trims separately, so basicly it can overshot it's 10 bit range with the trims added at the receiver.

I just ask to map the second 4 channels' outputs to this values. They are not in the physical channel order already anyway, since it is E, E-trim, A, A-trim, T, T-trim, R, R-trim, and we would send these channels to them: 1, 5, 2, 6, 3, 7, 4, 8. If channels 5-8 are not configured, they would be 0% anyway (deviation 0%, i.e 2401 50%=1FF), just like now.

Now the devo protocol is completely different, since it sends huge two byte values. The question is what are the absolute maximum valid value range that can be sent out with travel adjust and trims maxed out? Do we use that, or just a part of it? Here it might be possible to keep the range symmetrical and just offset it by the trims, but then the limits should be applied before the trims...

The devo protocol seems to be roughly 12 bits (even though the values are 16bits)
The WK2801 is 11bits total
The WK2601 is 10bits total
The J6Pro is 10 bits
The DSM2 is 10bits (16 bits, but only 10 are used)
The WK2401 is 10bits + another 10 for the trim, but the trim only works over 25%of the range.

I don't think that working around the WK2401 limitations is the right answer. We ned it to work out of the box without special configuration.

I see 2 options:
1) provide +/- 100% trim on the 2402 and use the trim as they were designed (i.e. just mimic the original behavior). you've been trying to get me to do this from the beginning but I am resistant because it adds a protocol-specific path to the mixer that I don't like.
2) provide 20bit +/-125% throw on the 2401. This would give you very high resolution and full throw capabilities, and treat it like the existing protocols.

Additionally, there is the question as above as to whether the trim should have the ability to shift the center point.

If I gave you (2) with the ability for trims to change the center-point, you'd have virtually the same behavior as the original, but more resolution and you'd have more control of the limits. But there is additionally the question of whether the trim can simply be treated as a fine-grain shift or if the Rx does something else with it (like adjust the gyro response).

Well, I thought I'd run some tests on my Devo8 as far as how trims work. Unfortunately, I seem to have killed my Saleae Logic. So I can't look at tehe protocol, but I was able to plug my old Tek scope into the servo plug and observe the output.

The Devo works like your WK2402:
200% trim results in a shift of the range by about 0.1msec which is about 20%. the range remains constant just like in your WK2401.

What this means is that I need to rethink how the trims are applied. I believe I now need to apply them at the protocol level, which means I'll be ale to properly handle the 2402 as well.

Currently trims are defined to apply to the inputs. So if you apply a trim to the throttle, it'll apply to both throttle and pitch. Th new approach seems like it will require applying to the outputs rather than the inputs. The problem is that if you have a complex mixing (like Cyclic), it is unclear how to apply the trim. I can probably deal with the built-in CYC controls, but if you tried to implement a cyclic mixer by hand, applying trims would be complicated. I definitely need to give it more thought.

PhracturedBlue wrote: Currently trims are defined to apply to the inputs. So if you apply a trim to the throttle, it'll apply to both throttle and pitch. Th new approach seems like it will require applying to the outputs rather than the inputs. The problem is that if you have a complex mixing (like Cyclic), it is unclear how to apply the trim. I can probably deal with the built-in CYC controls, but if you tried to implement a cyclic mixer by hand, applying trims would be complicated. I definitely need to give it more thought.

I think it would be fine if you apply them last, just before the cyclic mixing.
Nowadays nobody uses them anyway. It is done by the flybarless units...

wuselfuzz wrote: IMO, the proper chain for cyclics/rudder on a CCPM heli should be:

Input stick -> DR/Expo -> trims -> CCPM -> range -> subtrim -> out

If applied in this order, trims can be used to level your swashplate without moving the stick center point off the center of the expo curve. Subtrims are applied last, so these can be used to set up servo center positions.

I don't necessarily disagree but it is not possible with the current implementation. I am struggling to figure out how to do it at all without completely redefining the mixer implementation.

FYI, the way it is done today is:
Input stick->trim->CCPM->DR/Expo->subtrim->range->out.

This is also how the er9x does it (for cyclic) so I know it can work, though possibly not ideal.

I am thinking I needed a different setting fro range and servo limits. Normally you set servo limits to prevent breaking something. Trims should not let you go past those limits. On the same side, you want to be able to apply a final scalar to match your servo throw to the model.

So on a non CCPM model it should be:
Input stick->DR/Expo->scale->(subtrim + trim)->limit->out.

The above would be impossible in the WK2401 if we implement it how walkera did, but we could instead implement the protocol slightly differently...

The 2401 protocol as implemented by Walkera is:
10 bits for channel
10 bits for trim (1 bit is ~1/4 of a channel bit)

But since we know that the Rx seems to implement:
out = upper 10 bits + 0.25 * lower 10 bits

We could instead implement something like:
out = 20bit value
upper 10 bits = scale * out * 0.75
lower 10 bits = scale * out * 0.25

Which would give you full range without needing to pass the trim value to the protocol. But it assumes that the Rx implements the function above and doesn't use the channel and trims differently for the gyro inputs.

Well, I didn't payed too much attention to the CCPM mixing so far, because it is not necessary for the models I plan to use, since AFAIK the flybarless ones don't use it...

However, I have to aggree with Wuselfuzz:

wuselfuzz wrote: IMO, the proper chain for cyclics/rudder on a CCPM heli should be:

Input stick -> DR/Expo -> trims -> CCPM -> range -> subtrim -> out

...if the "range" means the servo-travel-adjust-like scaling and/or limiting.
I would only add the program type mixing to the table between the DR/Expo and the trims:
Input stick -> DR/Expo -> Program mix -> trims -> CCPM -> range -> subtrim -> out

Since currently DR, expo, and program mixes are all the same, we can use a simplified definition:
Input stick -> curves -> trims -> CCPM -> range -> subtrim -> out

PhracturedBlue wrote: I don't necessarily disagree but it is not possible with the current implementation. I am struggling to figure out how to do it at all without completely redefining the mixer implementation.

FYI, the way it is done today is:
Input stick->trim->CCPM->DR/Expo->subtrim->range->out.

This is also how the er9x does it (for cyclic) so I know it can work, though possibly not ideal.

However I see, why the er9x (and we) apply the CCPM on the sticks, nevertheless I think it is wrong: because the output channels should assigned a source, which should depend on that mixing, but the CCPM can't know which channels to use as input, only the sticks are exactly defined.

It can be solved, if we define 3 plus "dummy" channels as CYC1-3IN, to which we can assign the already prepared (expo,DR,mixes) channels, but then one have to know which channels should bound to which cyclic input. (One should know it anyway, because their outputs should be bound to that output channel anyway...)
Actually it can be done without any CCPM mixing using three dummy channels, but then one should do the CCPM on them too... Not too user friendly...

PhracturedBlue wrote: The above would be impossible in the WK2401 if we implement it how walkera did, but we could instead implement the protocol slightly differently...

The 2401 protocol as implemented by Walkera is:
10 bits for channel
10 bits for trim (1 bit is ~1/4 of a channel bit)

But since we know that the Rx seems to implement:
out = upper 10 bits + 0.25 * lower 10 bits

We could instead implement something like:
out = 20bit value
upper 10 bits = scale * out * 0.75
lower 10 bits = scale * out * 0.25

Which would give you full range without needing to pass the trim value to the protocol. But it assumes that the Rx implements the function above and doesn't use the channel and trims differently for the gyro inputs.

I don't really understand this one. Do you mean, that you would add the trims to the channel values as usual, but in the protocol always split it to two parts as if there were always a 25% variable value trim?
It might work, but it is a bit constrained.
If the goal is not to limit the usable range for the sake of trims, you could simply send the overflow to the trim channel if needed.

FDR wrote: I don't really understand this one. Do you mean, that you would add the trims to the channel values as usual, but in the protocol always split it to two parts as if there were always a 25% variable value trim?
It might work, but it is a bit constrained.

Almost. the goal is to have the high-precision of the trims (effectively add 2 more bits of precision) while still maintaing the full +/-125% range.
Basically, we'd let the protocol split up the (mixed and trimmed) signal to give you that accuracy (without needing to know what the trim value is). The above equation may not be quite right to achieve that goal.

Ah, like the floating point representation of the datetime values, right?

EDIT: ...just it would be fixed point of course...

FDR wrote: Ah, like the floating point representation of the datetime values, right?

EDIT: ...just it would be fixed point of course...

Wait a minute!
If this was the case, than you couldn't use it in later calculations as a trimmed value...