"Thrust Vectoring" phenomena with PFC Turboprop Qu

[J.C.]

Hi Pete,

I'm having a strange problem with some of the aircraft I fly when using the PFC Turboprop throttle Quandrant. I notice it especially on final approach with jets when the autothrottle is disconnected. When the throttles are adjusted, the aircraft responds as if it is being controlled by thrust vectoring, and I usually have to respond with opposite aileron in order to remain on the ILS. This usually results in wild directional fluctuations which can be quite annoying, especially on final approach. I've tried calibrating the controls, but to no avail. Do you have any recommendations that might help to resolve this dilemna?

Thanks in advance for your response.

J.C. (MYNN)

[Pete Dowson]

I'm having a strange problem with some of the aircraft I fly when using the PFC Turboprop throttle Quandrant. I notice it especially on final approach with jets when the autothrottle is disconnected. When the throttles are adjusted, the aircraft responds as if it is being controlled by thrust vectoring, and I usually have to respond with opposite aileron in order to remain on the ILS. This usually results in wild directional fluctuations which can be quite annoying, especially on final approach. I've tried calibrating the controls, but to no avail. Do you have any recommendations that might help to resolve this dilemna?

Sorry, no. I don't even understand the term "thrust vectoring". It sounds like you need to talk to someone who knows something about the specific aircraft model you are flying.

There is no difference in PFC throttle inputs between aircraft. It's just straight forward throttle axis position converted to throttle control value. Same with all aircraft. Watch the throttle lever positions on the FS panel graphic.

Regards,

Pete

[Pete Dowson]

It occurred to me that what you might mean by "thrust vectoring" is actually asymmetric thrust -- i.e. one engine providing more than the other? I tend to think of "thust vectoring" in terms of things like the Harrier jump jets.

If you are getting asymmetric thrust with the levers set the same, you could try re-calibrating them to be a bit closer. However, you will never get two pots giving exactly the same readings all the way along, even if the ends are exactly right. So always check the readsouts for N1/N2, or EPR, or RPM, or whatever your particular aircraft measures engine performance by.

There is also a Hot Key you can program (in a Registered FSUIPC) which enables a throttle sync function. This actually copies the throttle 1 input to all engines, so you are then bound to get identical performance from each, all other things being equal. If you use this just remember to toggle it off when you want to use asymmetric thrust to aid in ground steering!

Regards,

Pete

[airforce2]

Pete;

I too see an incessant wobbling about on my turboprops caused by unstable PFC inputs going to the prop RPM setting.

I'd like to put on request a powerful new feature in either/both of PFC/FSUIPC, in the form of a programmable "soft stop." It would be exceedingly useful to define, say 1-3 points in each axis range that represent a physical detent. When a preset value is reached, the output would "stick" and remain at that value until the lever is moved beyond a predefined threshold.

For example, in the Dash-8, I need the ability to set prop RPM to full (1200 RPM), 1050 RPM (climb), and 900 RPM (cruise). Full-scale needs no stop...but when I set 1050 RPM, pot noise causes the prop RPM input to bobble about +/- 3 units, which is enough to swing the nose about noticeably. I would like to define an input value and a threshold...in effect I would set it so that when the prop input reaches x units, it "sticks" at the corresponding output value until I move the lever at least y units (the threshold) away from the detent. Even better, forcing an audible "click" (play a wav file, perhaps?) when reaching the detent would be ideal. Additionally, sending a keypress upon reaching a detent would be useful for some panels (like the PSS Scarebus 320/330/340 panels) which use keys to advance/retard the throttle to the Rev/Idle/CLB/FLX/TOGA stops.

This would also be useful on the throttle axis at an idle detent...at the click, the throttles remain at idle...to go into reverse or forward, requires movement beyond the detent threshold (maybe 6 units or so?).

Alternatively, a function to manually freeze prop inputs until input lever is moved beyond a threshold would also be helpful...I'd like the ability to press a key or yoke button to lock the props and stop the constant hunting.

Cheerio

[Pete Dowson]

I too see an incessant wobbling about on my turboprops caused by unstable PFC inputs going to the prop RPM setting.

You shouldn't be getting a lot of such "wobbles". That's usually indicative of a poor power supply. I'm no hardware expert, however, so I think you should seek advice from PFC.

I have to hunt for positions on my PFC throttles where there can be such wobbles (presumably then due to dirt or temperature or humidity problems, I don't know). The value of '3' seems to be the resolution of the pots used by PFC -- the maximum range of 0-127 (rarely achieved) therefore actually only has about 40 discrete positions and I assume that anything part way between then is "ambiguous" and may therefore be liable to this "wobble", though as I say I find them difficult to find. But I did get a much more powerful (and smoothed) power supply than the one originally suggested.

With only 40 positions, any smoothing I might apply betwen adjacent readings (i.e. 3 apart) would have the bad side effect of effectively reducing the available positions to only 20, not enough at all. Either that, or making them slow to respond.

I'd like to put on request a powerful new feature in either/both of PFC/FSUIPC, in the form of a programmable "soft stop." It would be exceedingly useful to define, say 1-3 points in each axis range that represent a physical detent. When a preset value is reached, the output would "stick" and remain at that value until the lever is moved beyond a predefined threshold.

I've had on my list, for a long time, features for assigning programmable axis inputs for FS, with definable response curves, slopes and detentes. But this is a rather big project if I am going to be able to achieve it with a decent understandable user interface. Finding time for such things is my main problem.

Regards,

Pete

[Frank.O]

Hi Pete,

you will probably not remember but I emailed you about the same problem about a year ago but I misinterpreted the problem as spikes on the prop axis wich is wrong.

You shouldn't be getting a lot of such "wobbles". That's usually indicative of a poor power supply. I'm no hardware expert, however, so I think you should seek advice from PFC.

No sorry. This has nothing to do with PFC equipment. It is an FS internal problem and it was even there back in FS2000 times (King Air) when I didn't use PFC equipment. The nose swinging only occurs if you have separate controls (levers) for each engine. If you have only one control for both engines the rpm fluctuatin is still there but synchronized on both engines so the nose swinging does not appear. Every prop in FS has a regulating mechanism that adjusts the prop rpm to the value read from the input. Every time you change the prop setting the regulating mechanism starts and the rpm needle swings a bit and settles at the new value then. And this does not only happen when you change the prop setting but also when the environmental conditions change (barometric pressure, temperature) at least thet's what I'm thinking.

I have to hunt for positions on my PFC throttles where there can be such wobbles (presumably then due to dirt or temperature or humidity problems, I don't know). The value of '3' seems to be the resolution of the pots used by PFC -- the maximum range of 0-127 (rarely achieved) therefore actually only has about 40 discrete positions and I assume that anything part way between then is "ambiguous" and may therefore be liable to this "wobble",

That's exactly what I found too.

though as I say I find them difficult to find.

Do a one hour flight in the Baron. The problem starts as soon as you reach cruise altitude and reduce the prop rpm to cruise setting and it will vanish when you set the props to max again on final approach.

But I did get a much more powerful (and smoothed) power supply than the one originally suggested.

I too experimented with the power supply but this didn't help.

With only 40 positions, any smoothing I might apply betwen adjacent readings (i.e. 3 apart) would have the bad side effect of effectively reducing the available positions to only 20, not enough at all. Either that, or making them slow to respond.

That's right, 20 is not enough but I could live with a slow response. I think really correcting this is up to Microsoft. I found that adjusting the time constant of the regulating mechanism in the aircraft.cfg can help to make the nose swinging less bad. The default setting in FS9 is prop_tc=0.1 witch I changed to read prop_tc=0.04.

Making the throttle sync facility in FSUIPC not only synchronize the throttles but also prop and mix may also help. Even better would be a facility in FSUIPC or PFC that detects if the prop sync switch is on and if yes synchronizes all engine controls (throttle, prop, mix) to the controls of engine one.

Regards,

Frank

[Pete Dowson]

This has nothing to do with PFC equipment. It is an FS internal problem and it was even there back in FS2000 times (King Air) when I didn't use PFC equipment. The nose swinging only occurs if you have separate controls (levers) for each engine.

Ah, so it is an AIR file or CFG file problem, with how the aircraft flight model is defined? Have you searched the web to see if any one has made better models?

If you have only one control for both engines the rpm fluctuatin is still there but synchronized on both engines so the nose swinging does not appear.

Sounds like there needs to be a little more damping on the yaw axis sensitivity. I think that would be better than attempting to smooth the inputs, as the latter increases the latency and makes it more difficult to fly, like poor frame rates.

Making the throttle sync facility in FSUIPC not only synchronize the throttles but also prop and mix may also help. Even better would be a facility in FSUIPC or PFC that detects if the prop sync switch is on and if yes synchronizes all engine controls (throttle, prop, mix) to the controls of engine one.

I'll add both to my listwhat does the "prop sync switch" actually do on the aircraft at present?

BTW I am away from this Thursday till 24th October, so I won't be able to look at doing this till towards the end of the month.

Regards,

Pete

[Frank.O]

Hi Pete,

Ah, so it is an AIR file or CFG file problem, with how the aircraft flight model is defined? Have you searched the web to see if any one has made better models?

not recently but what I found back in the middle of the "FS2002-age" was not better than the standard at least in this special aspect.

Sounds like there needs to be a little more damping on the yaw axis sensitivity. I think that would be better than attempting to smooth the inputs, as the latter increases the latency and makes it more difficult to fly, like poor frame rates.

That's right, yaw damping also helps. I have increased all three stability values (pitch, yaw and bank) from 1.0 to 1.5 in the aircraft.cfg.

I'll add both to my listwhat does the "prop sync switch" actually do on the aircraft at present?

Nothing - at least I didn't notice anything. Even when it's turned on the props can still fall out of sync. From the XML code I can see that this switch operates the TOGGLE_PROPELLER_SYNC control in FS but I don't know what that does.

BTW I am away from this Thursday till 24th October, so I won't be able to look at doing this till towards the end of the month.

No need to hurry. It's just good to know there's light at the end of the tunnel :wink:

Regards,

Frank

[airforce2]

You shouldn't be getting a lot of such "wobbles". That's usually indicative of a poor power supply. I'm no hardware expert, however, so I think you should seek advice from PFC.

It appears this is the normal flip-flop of values when the input is on the border between two values. I'll call PFC...I have a nice HP regulated variable 0-40v pwr supply that'll make a test of that theory relatively easy. I suspect this is not the problem, though...it's normal for an A-D converter output to oscillate between adjacent step output values.

With only 40 positions, any smoothing I might apply betwen adjacent readings (i.e. 3 apart) would have the bad side effect of effectively reducing the available positions to only 20, not enough at all. Either that, or making them slow to respond.

True, but in the scheme I described, a loss of resolution would only occur close to the defined detent positions.

Another stabilization methodology would be to lock the output if there has not been more than a six-unit change in the input lever position in the last 10 seconds...and resume normal ops as soon as a 6+ unit change is detected...a variation on control acceleration.

I've had on my list, for a long time, features for assigning programmable axis inputs for FS, with definable response curves, slopes and detentes. But this is a rather big project if I am going to be able to achieve it with a decent understandable user interface. Finding time for such things is my main problem.

That'd be really nice...I also use a Thrustmaster Cougar programmable stick for my heli and combat sim flying...the programmable curves are very, very useful.

Would a key/button-assignable axis lock be within the realm of the possible? Basically a software interface to allow equivalent of checking/unchecking the "use this axis" checkbox on the PFC throttle quad page. That way I could set it where I want it, then lock it (by disconnecting the axis) until I manually unlock (reconnect) the axis.

I've tried all manner of tweaks to the air files (all my multi-engine turboprops have this problem) and I can reduce the effect of the asymmetric thrust wobbling, but with other unwanted side effects. The most problematic aspect of this problem is in virtual cockpit mode in FS2004, where the VC panel will see-saw back and forth when these oscillations occur.

Thanks

[Pete Dowson]

Would a key/button-assignable axis lock be within the realm of the possible? Basically a software interface to allow equivalent of checking/unchecking the "use this axis" checkbox on the PFC throttle quad page. That way I could set it where I want it, then lock it (by disconnecting the axis) until I manually unlock (reconnect) the axis.

That would certainly be possible -- maybe it ought to auto-unlock on a large input value change too? I can add it to my list of things to look at, at the end of the month probably.

I'll think about the smoothing problem too, but it isn't an area I really want to spend a lot more time on when I would rather plan a more thorough assignment utility, as I mentioned.

BTW there is already a smoothing action for PFC axes (all except toe brakes), active in PFC.DLL at present. It ignores reversals in direction if they occur within 150 mSecs. It needs three input values with the last two showing an up-down or a down-up and both within 150 mSecs.

This should stop normal pot ambiguities, a fast wobble around one value. Are yours occurring at a lower frequency and getting past this check?

The facility I am talking about is described in the documentation as added in Version 1.27:

"Automatic axis smoothing has been added, to prevent much higher frequency jitter which can (presumably?) be caused by poorly smoothed power supplies."

I think this is why I do not see jitter on my axes, or at least have to work hard to find it.

Regards,

Pete

[Pete Dowson]

Hi Bob,

I'm working on version 1.72 of PFC.DLL and I have list of possible enhancements, but I want to get some defaults sorted. Perhaps you can help by saying what you see in your problematic throttle inputs.

These are the proposed facilities:

1. Small jitter smothing with adjustable timescales.

Currently the smoothing operates on ANY value of change in quadrant inputs which causes a reversal of direction within 150 mSecs. i.e.

current (smooth) value is x

read value y at time t1, ok, new value = y

read value z at time t2

.... if t2-t1 > 150 mSecs, ok, new value = z

if z >= y >= x ok, new value = z

if z <= y <= x ok, new value = z

else, its a change in direction: discard value z, keep value y

This works for short-term jitters and spikes caused by power supplies and many other physical factors, but it won't fix "slow" changes by 3 units due to pot position being just on a border.

So I'm proposing to add another check, similar to the above, but where the difference between y and z is less than 5 PFC units. For this the time difference will be larger, and adjustable. I was thinking of a default time of more like 500 mSecs, but what are you observing as the jitter period?

2. Throttle + Prop + Mixture sync assignable control

A special control internal to the PFC driver to copy engine 1 values or all of these to the other engines. Assignable in the Yoke and Avionics button assignments.

I'll check what the FS Prop Sync control does, and maybe trap that for the same use.

3. Throttle + Prop + Sync connection toggle control

I'm less happy about this. If I did it it would be an assignable toggle to disconnect / reconnect the inputs for these three controls on all engines.

Would this really be necessary if the other things above were done? If I did it, should it automatically re-connect on a large change in any one of the axes? If so, how large? Half full range (eg 50 PFC units), or what?

I'd rather not do this if it isn't warranted. I can envisage folks complaining that their throttle quadrant doesn't work!

I'd appreciate your views on these things, as soon as you can please, as I need to get 1.72 out this week -- 1.70/1.71 don't work properly on Windows 98 (I'm having to make the restart/sync facilities conditional on Win2000/XP).

Regards,

Pete

[J.C.]

Hi Pete,

I was just wondering if you were still working to correct this problem in a future PFC dll. Thanks for your response.

J.C. (MYNN)

[Pete Dowson]

I was just wondering if you were still working to correct this problem in a future PFC dll.

What problem?

Please go get the latest PFC DLL version. There is nothing outstanding that I know of. You seem to have attached to a very old thread (October last year!!!). There have been lots of issues discussed and releases made since then!

Regards,

Pete

[vdkeybus]

Hi Peter,

Regarding the PFC throttle axis filtering you proposed. The problem seems to originate from noise and nonlinearity of the controls, although - from my experience in designing hardware - the noise usually predominates.

In that case, a good thing to do is to use a digital filter and get rid of the noise first. The result is a smoothed value that is the mathematically most likely estimate of the actual lever position. (Actually your proposed decision algorithm implements a filter, but in a rather awkward fashion.)

Then, after filtering, you could implement something like:

// Sample algorithm (thr1_in is the input from PFC, thr1_out is the output to FS)

// Second-order IIR digital filter:

thr1=thr1_2*a2 + thr1_1*a1 + thr1_in*a0;

thr1_2=thr1_1;

thr1_1=thr1_in;

thr2=thr2_2*a2 + thr2_1*a1 + thr2_in*a0;

thr2_2=thr2_1;

thr2_1=thr2_in;

// Evaluate the results and compensate for any nonlinearity

if (abs(thr1-thr2)) > e) {

thr1_out=thr1;

thr2_out=thr2;

} else {

thr1_out = thr2_out = (thr1+thr2) / 2; // Average both inputs

}

The filter and the e value depend on the PFC resolution. If you're interested I can give more details on the filter design. You could use the 30-day trial version of a program written by Nuhertz Technologies (http://www.filter-solutions.com) to make a digital filter. Or use a tool like Matlab.

Hope this may help you. I am currently interfacing similar hardware to MSFS and I intended to use this algorithm. I should be able to provide more feedback in a week or two.

Jeroen.

[Pete Dowson]

Regarding the PFC throttle axis filtering you proposed.

That was the algorithm actually implemented, and over a year ago now. It was originally specifically aimed at curing severe jitter on a user's system in Myanmar where the power supply was the jittery component.

All I did more recently (last October/November) was add an extra layer and allow the time value to be set by the user -- one or two users had much longer term "drift" (a better term than jitter for something not quick! :) ).

The problem seems to originate from noise and nonlinearity of the controls, although - from my experience in designing hardware - the noise usually predominates.

Yes, but the circuitry on the PFC controller board, and indeed its firmware, is supposed to deal with that. Here I hardly ever experience any jitter at all -- there are some specific positions of the levers which are, shall we say, "ambiguous" -- the value it wants to provide is half way between two of its measurements and it flutters a little between the two. That is the phenomenon my "filter" was designed to fix, and it works fine here.

Values from PFC axes (provided by the PFC firmware) can only extend from 0 to 127, but that range is never fully achieved and it usually provides something like 10 to 110, for example. The "granularity" appears to be 3, so in fact there are only between 30 and 40 distinct positions measurable.

In that case, a good thing to do is to use a digital filter and get rid of the noise first. The result is a smoothed value that is the mathematically most likely estimate of the actual lever position. (Actually your proposed decision algorithm implements a filter, but in a rather awkward fashion.)

Then, after filtering, you could implement something like:...

I think your proposals need to go to PFC? Or are you saying implement a digital filter in my FS module? I would be a little concerned over the effects on FS performance if there were too much processing going on. After all, FS wants to use the processor too from time to time, and with up to 15 PFC axes all throwing values at me all the time I need to make their processing as fast as possible.

// Sample algorithm (thr1_in is the input from PFC, thr1_out is the output to FS) ...

... The filter and the e value depend on the PFC resolution. If you're interested I can give more details on the filter design.

Thanks. I'd like to understand this a little more. Like what are the values a2, a1 and a0 -- are they derived experimentally or is there some way of determining what they should be? And you say 'e' depends on the resolution -- is this my "3" for PFC axes?

Oh, and isn't there some sort of elapsed time involved here someplace, or are these only ever concerned with the three most recent values read? If there's no time factor then I can see the long term "jitter" experienced by one of my correspondents still remaining.

Thanks for your ideas. I am struggling a bit to see the need for such added complexity and programming within the FS process, and, in fact, don't have any jitter problems in any case with any of my PFC gear. I don't understand why some folks do (excepting the site in Myanmar with dreadful mains power), and was quite pleased that the updates I did provide late last year seems to answer their questions. However, I am always seeking to improve things, so if you could just elaborate on the simpler parts of your proposals I'd be interested to try them.

Thank you,

Regards,

Pete

[vdkeybus]

Hi Peter,

I think your proposals need to go to PFC? Or are you saying implement a digital filter in my FS module? I would be a little concerned over the effects on FS performance if there were too much processing going on.

I just wanted to supply a possibly interesting solution to the problem. Maybe someone else finds it useful as well. Some cockpit builders may encounter noise somewhere in their quest, I guess. And I see many posts covering PFC.DLL, so I thought you had something to do with the software part. Anyway, I just noticed that your last post in this thread was over 4 months old... :oops:

Thanks. I'd like to understand this a little more.

The filter coefficients can be calculated, but it's not a straightforward back-of-the-envelope calculation. With the tool I mentioned earlier it has become a lot easier though.

The calculations assume that your input data is more or less regularly sampled. Supposing a sample rate of 18.2 Hz, I put the cutoff frequency at 2 Hz. Any signal variation beyond this frequency (noise) will be attenuated. The attenuation is determined by the 'filter order'. The higher the order, the higher the attenuation, but more computational effort and precision is required. An order of 2 is good for this application, I think. (Note that there are a lot more filter designs around, and this is only a simple example.)

I admit that choosing the filter parameters requires some insight, but in this case, setting the cutoff frequency at 2 Hz seems very reasonable as in reality, aircraft engines won't be able the follow such quickly varying throttle commands.

Using this data, one can instruct a computer to calculate the coefficients. (I used a Butterworth filter characteristic which leads to good all-round designs.)

And voila, there is the filter program (execute this at 18.2 Hz):

float filter(float in)

{

static const float a0=0.0790, a1=0.1579, a2=0.0790;

static const float b1=-1.0631, b2=0.379;

static float in_1=0.0, in_2=0.0, out_1=0.0, out_2=0.0;

float out;

out=a0*in + a1*in_1 + a2*in_2 - b1*out_1 - b2*out_2;

in_2=in_1; in_1=in; out_2=out_1; out_1=out;

return(out);

}

2 lines of code per channel. That's not complicated, is it ? And it doesn't use branching, which is nice for your Pentium's pipeline. An optimizing C-compiler will also allow simultaneous execution of the addition and the multiplication on the FPU.

How is this filter useful ? Let's return to the additional piece of code that has the e parameter in it:

if (abs(thrL_filtered-thrR_filtered) > e) {

thrL_to_FS=thrL_filtered;

thrR_to_FS=thrR_filtered;

} else {

thrL_to_FS=thrR_to_FS=(thrR_filtered+thrL_filtered)/2;

}

It is meant to avoid asymmetric thrust with controls that are not too well matched along their travel. The e should be set so that when the throttle controls are held together, e remains larger than any difference observed in the filtered values when the levers are moved together from bottom to top. Because the data have been filtered before, noise does no longer require you to select a high value for this one. I expect that in your case, e=6 or so should give good results.

Again, I will be able to comment on the workings of this algorithm during next month. I also have a simulated response to a noisy input signal with a spike, but I don't know how to attach a bitmap file in here.

Jeroen.

(And never use in your text - followed by a backspace to correct your error - in this forum editor :x )

[Pete Dowson]

The calculations assume that your input data is more or less regularly sampled. Supposing a sample rate of 18.2 Hz, I put the cutoff frequency at 2 Hz. Any signal variation beyond this frequency (noise) will be attenuated. The attenuation is determined by the 'filter order'. The higher the order, the higher the attenuation, but more computational effort and precision is required. An order of 2 is good for this application, I think. (Note that there are a lot more filter designs around, and this is only a simple example.)

I can't say I understand much of that. However, there is one problem, but probably easily dealt with. The PFC device provides values only once a second, unless they change. So there is no regular sampling from the PC -- the firmware is doing the sampling and all I see are the results. In order to "simulate" a sample rate of, say, 18.2Hz I would need to assume the previous last values seen, even up to a second earlier. Does this change your proposals? Presumably not.

And voila, there is the filter program (execute this at 18.2 Hz):

Okay, I can try this, though proving it's effectiveness will be difficult as very few folks seem to be having problems, and I am not one of them. Thanks!

2 lines of code per channel. That's not complicated, is it ? And it doesn't use branching, which is nice for your Pentium's pipeline. An optimizing C-compiler will also allow simultaneous execution of the addition and the multiplication on the FPU.

It is meant to avoid asymmetric thrust with controls that are not too well matched along their travel. The e should be set so that when the throttle controls are held together, e remains larger than any difference observed in the filtered values when the levers are moved together from bottom to top. Because the data have been filtered before, noise does no longer require you to select a high value for this one. I expect that in your case, e=6 or so should give good results.

Ah .... now this is a different subject. You seem to be assuming that the two separate potentiometers are identical in everything. I don't think they go to such expense. This is not a noise difference, it is a difference in the characteristics and linearity of two separate components. I don't see how anyone can expect 100% agreement -- even in the real aircraft I doubt it occurs between throttles due to slight differences in engine performance, in the connecting wires, leads, pulleys, whatever.

Regards,

Pete

[Pete Dowson]

How is this filter useful ? Let's return to the additional piece of code that has the e parameter in it:

if (abs(thrL_filtered-thrR_filtered) > e) {

thrL_to_FS=thrL_filtered;

thrR_to_FS=thrR_filtered;

} else {

thrL_to_FS=thrR_to_FS=(thrR_filtered+thrL_filtered)/2;

}

Actually, after further thought, this might well be useful -- with something like e=6, as you say. I don't think necessarily that the levers will line up, but it make it easier for the pilot to get a constant symmetric thrust, as the lever positioning will be a little less critical.

Of course there's more code that this, as I have to be able to cope with 2, 3 and 4 engines and throttle levers.

Thanks again,

Pete

[nmthomas]

Hi All,

Just where do we stand on this so-called thrust vectoring ? I ask because the default Baron wobbles (left-right) and 2 payware aircraft I have react this way. They are from a reputable developer.

It seems that all single engine aircraft perform flawlessly, but 2-engined aircraft seem to have a problem that is IMO wrapped around the prop levers. If all levers are forward and the only 2 levers (throttle / mixture) are moved the twin a/c flys straight and turns normal and not like a 2-wheel bicycle with square wheels and no wobbleing. If I reduce the prop rpm the wobbleing & bad turns return.

I, as the end user ask the program creator and the hardware mfg. and the developer of the payware aircraft why. My answer power supply, driver problem, we cannot duplicate the problem. I don't understand a lot of the answers but I know one thing this problem exists.

My problems all started when I invested in the throttle quadrant and apparently the I have a bad system that PFC says is ok.

Sorry about venting but I am throughly disgusted as I have invested money in a system that flys the aircraft that it wants to fly. I'll have to stay with the single engine until ???????????

Regards,

Nick :?: :?: :?:

[vdkeybus]

I do not own PFC hardware. From what I've just heard from Pete these controls have a fairly low resolution (i.e. 7-bit) and it is most probably due to this fact that you get 'asymmetric thrust'. Remember that you've got probably around 500 hp on the turbine shafts.

Adding only one bit drags one end of the plane by 4 hp. Especially at low output powers, this may create an asymmetry of more than 10% and apparently you've got noise in the order of 3 bits. No wonder the aircraft 'wobbles'. Filtering can possibly alleviate this a bit.

I do have an idea to fix this, but I need more data on the PFC output characteristics. Can someone give me a continuous series of samples from 2 (or more) of its throttle axes ?

Jeroen.

[Pete Dowson]

Just where do we stand on this so-called thrust vectoring ? I ask because the default Baron wobbles (left-right) and 2 payware aircraft I have react this way.

Sorry about venting but I am throughly disgusted ...

I am rather bemused by this sudden "attack". There was a long discussion on this several months ago which I thought was resolved. Have you looked through the other threads on this?

Which PFC.DLL version are you using? The more recent versions have additional "filtering" in (quite crude, I admit) which can be adjusted for longer-term smoothing, and also include a Throttle Sync facility which operates also on other axes. That facility has been working well since version 1.80. The current version is 1.83. Have you used Throttle Sync in any of these?

Since all this, back in October last year, I have heard no more until now. I don't know if that is because all the complainants have been on an extended holiday, or because whatever problems there were have gone away.

Coming out of the blue, in attack mode like this, doesn't help anyone at all. If you would like to be more specific, in particular about what you are using, what options you have tried, and what still remains to be done, I am here to listen and to try to figure it out.

The PFC throttles are the smoothest and most flexible I have used, and believe me I have been through many different sets (some of which are still in my junk box upstairs). For most every purpose they perform impeccably. If there is a specific problem in certain applications let's look at itbut I need information, not rants.

As you'll see from the recent messages I now have some suggestions for a more "scientific" approach to flitering and smoothing, and evening-out differences between axes. I may well try these out. Perhaps you would like to volunteer as one of the test sites if I do? But whether this is useful depends upon what appears to be the causes of your problem. That is something I don't know at all at present.

Regards,

Pete

[Pete Dowson]

I do not own PFC hardware. From what I've just heard from Pete these controls have a fairly low resolution (i.e. 7-bit)

Considering the step seems to be 3 out of the maximum (never achieved) range of 127, the resolution is more like 40 steps or a bit less than 6 bits.

However, as far as I can see, this order of resolution is quite normal with the standard sort of pot and AtoD chippery in use. I just checked the throttle on a Microsoft Sidewider USB and its smallest increment (at FS's maximum sensitivity) is 542 out of a range of -16193 to +16192. That's 60 unique positions -- the benefit of optical decoders I think -- but that's still less than 7 bit.

I do have an idea to fix this, but I need more data on the PFC output characteristics. Can someone give me a continuous series of samples from 2 (or more) of its throttle axes ?

At the moment the only way to get that is to enable my PFC DLL logging. This would contain lots of stuff you wouldn't want, so need a lot of editing. And it would basically be a log of received (optionally decoded) data sent by the unit to the PC when IT wants to -- that's a regular sample every second, approximately, and only changes in values in-between. I can supply something with all that if you thought it was any use, but ...

... After your suggestions earlier I have been thinking of how to get regular 18 Hz readings so that I can apply your filtering. I've had a look at my code, and it is a lot more coding than I had been prepared for, but I have plans for how to do it. It isn't a quick change, though. I have to separate the code reading the data and that scaling it and acting on it -- storing the former and sampling it on a timer (actually an FS timer tick chain call) before filtering it, scaling it and acting on it.

I will only apply this to throttle, prop pitch and mixture inputs. For aileron, elevator, rudder, spoiler, flaps and brakes I think it would be unnecessary and possibly give rise to delays and hence over control (in the main flght controls that is).

But all of throttle, prop and mixture controls will be potentialy contributing to asymmetric thrust. This is why the "throttle sync" facility I added in version 1.80 applies to all three sets of axes. I'm now wonering if the new compalinant is actually using any of the additionas I made.

Let me know what you want to see out of all this. I can't promise anything quick, mind.

Regards,

Pete

[nmthomas]

Pete,

Rewired cirrus yoke-throttle quadrant- 4 throttle setups, I use fsuipc 3.1.4.0 and pfc. dll 1.8.3.1 also include pfc's rudder pedals.

I have installed this system carefully following your instructions with many retrys and found that this system is really great with single engine aircraft.

As for prop sync in pfc.dll 1.8.3.1 are you refering to the axis smoothing of default 500 because it matters not if I increase it to 50000 there is no change. I get the wobbles and the bad turning and this occurs when I gently reduce the prop pitch. There are no radical movements of any levers and they are reduced in unison.

I used to fly and have been in twin engined aircraft but have never seen movement like this it is constant as soon as you reduce the prop pitch it never smooths out. The problem has always been with me and the payware a/c that I enjoyed flying, I don't use because of this. The ironic thing is that this developer makes a turboprop and with the turboprop controls and setting the throttle features precisely I don't seem to have a problem. My problem is with piston twins.

Pete I'm sorry about the attack mode but it was'nt meant to be that way. I really enjoyed using the system but when I used a twin-prop today I just lost it because it rained on my parade one to many times and after a while and with my limited computor knowledge I thought I tried everything and it keeps failing so I went into the attack mode.

Sorry again Pete, I'll just keep trying and reading your forum and hopefully this will be eliminated .

Regards,

Nick

[vdkeybus]

Hi Pete,

If you get data at a 1Hz rate, it is simply impossible to filter it at 18Hz. Do not put effort in it. The filter just won't work.

If it is impossible to crank up the PFC sample rate, I'm afraid we must resort to something like:

diff=thrL_in-thrR_in; // Get the difference

if (abs(diff) > e_large) {

thrL_to_FS=thrL_in;

thrR_to_FS=thrR_in;

} else {

avg=(thr_L+thr_R)/2;

corr=sign(diff)*(abs(diff)/e_large)^3;

thrL_to_FS=avg+corr;

thrR_to_FS=avg-corr;

}

The first if-clause (diff > e_large) ensures that the axes are independent when they're clearly different (Engine-out situation). Set e_large to 30 or so. In the second, small axis differences are made smaller, but large ones are amplified (play with the 3 to tune this somewhat).

It's only a rough idea...

From nmthomas I've got the impression that the other axes (mixture, propellor) are perhaps to blame as well.

Anyway, I should have some samples to test the above idea. Isn't there any way of getting the data from the PFC HW to a file in a simple program issuing commands to the COM port directly ? If no, just send me the sequence you've got. But please tell which data I have to look at.

But again, don't try filtering on a 1 Hz data stream. Filtering relies on the fact that samples are unpredictable (noisy). If you would interpolate 1 Hz data, they're no longer unpredictable. It'll be waste of your time and I wouldn't want that :wink: on my conscience.

J.

BTW I'm always willing to improve my vocabulary. What does 'bemused' mean ?

[Pete Dowson]

As for prop sync in pfc.dll 1.8.3.1 are you refering to the axis smoothing of default 500 because it matters not if I increase it to 50000 there is no change.

No, the timing you are referring to was the additional smoothing to stop any longer term "jitter" than the filter I had already incorporated (which was for less amplitude and only 150 mSec). Personally I saw no need for it, but someone else did and was happy with the result as far as I know.

The new facility I put in is a "Throttle Sync" control as documented in the PFC DLL user guide. To quote the explanation there:

"This toggles a facility to synchronise the settings of throttle, propeller pitch and mixture on all engines. Basically, when enabled, it uses the Engine 1 values for all the engines and ignores the inputs from the other axes. When toggled off, the current settings for the other axes are re-instated. This is not related to the “Prop Sync” switch fitted to some aircraft."

To use it simple assign it to a button.

I get the wobbles and the bad turning and this occurs when I gently reduce the prop pitch. There are no radical movements of any levers and they are reduced in unison.

The latter part seems to argue against the former part of this statement. I am at a loss to understand what is happening. How do you know it is due to the throttle quadrant then, or my presumed bad programming? Have you any other such controls to compare it with or to exonerate the FS programming or specific aircraft?

I used to fly and have been in twin engined aircraft but have never seen movement like this it is constant as soon as you reduce the prop pitch it never smooths out. The problem has always been with me and the payware a/c that I enjoyed flying

When you say "always", you mean with all versions of FS, and with all connected controls? I'm getting a bit confused now, I'm afraid.

There must be some way of determining WHAT it is that is causing the wobbles. You say the controls, graphically, seem to move smoothly and in concert, no apparent jitter there. Obviously the graphics may not have adequate resolution (though with only 40 steps I should have thought they would), but what about the instruments? Do they show any irregularity that could cause this? I'm not familiar with turboprop instrumentation so I can't tell you what to look for.

The other thing you can do is use the Monitoring in FSUIPC to watch the prop and throttle values actually being used in FS. Go to FSUIPC options (Alt M F) select Logging page. On the right enter these:

Offset 088C, Type S16 (this is Throttle 1)

Offset 0924, Type S16 (Throttle 2)

Offset 088E, Type S16 (Prop pitch 1)

Offset 0926, Type S16 (Prop pitch 2)

then check the "Adv Display" selection below and OK exit. You will get a window on screen where these values will be constantly displayed and updated as they change. See what happens, looks for too much fluttering, or differences where they should be similar.

You can also see the Mixture values (offsets 0890 and 0928) but you can only see 4 values at a time.

If there are always disparities between engines 1 and 2 when the levers appear to be together, this can mostly be corrected by better calibration in the PFC joysticks section. However, it is unlikely to get rid of them altogether. Maybe there are some points along the axes where the "linearity" is definitely different. It is this sort of thing where I'd hope to apply some of what has been suggested here earlier, to improve matters.

However, I feel that the only sure way to get two or more levers reading exactly the same is to use the Sync facility I've provided for just that purpose.

BTW how is it really achieved in the real aircraft? If they don't have some "sync" override, how can every lever guarantee the same setting at every equivalent position? It doesn't seem feasible. Wouldn't you even things up by checking the instruments, nudging one lever up, another down, to achieve parity? Or presumably do it all be feel when experienced enough? Not by simply lining up the levers, surely? (Unless it is fly-by-wire, but even then).

Regards,

Pete