FS2004 Nosewheel

[floda]

Something for Roby !

Our Metropolitan CV440 has problem when turning on ground (taxi).
It works ok from 0-5 knost but it slipes straight ahead when increase speed.

The angle is 65% in contact point.

Thank you in advance.

Floda

 

[FSAviator]

Non complaint steering wheel angle induces skid, not yaw

Greetings Floda,

If you are asking the flight dynamics developer of an unreleased product for advice concerning pilot errors you perpetrated during alpha testing I suggest that you do so via e-mail. If on the other hand you need help to eliminate pilot errors while using the Calclassic CV440 release, I may be better placed than 'Roby' to explain the pilot error my code is detecting, before it imposes the real world consequence.

The pilot error detected is anyway generic. It arises from failure to understand the difference between rudder steering and (nose) wheel steering. It is very common virtual pilot error perpetrated by many / most flight simulator enthusiasts who have never had the opportunity to pilot real aeroplanes from different eras of aviation history.

The Curtiss Jenny biplane is from the Pioneer Era of aviation history. It has a fixed tail skid. Both in flight and on the ground, yaw is induced by vectoring the lift from the fin using the rudder. Yaw inputs in Pioneer Era aeroplanes are the same as must be made to steer a boat. *Only* if a vessel has *rudder* steering yaw rate maximises at maximum rudder deflection.

The Convair CV440 is instead from the much later Classic Era of aviation history. It has the same nosewheel steering mechanism as a bicycle. It is not a kind of boat. It does not use a rudder to steer (invoke yaw) during ground handling.

If you have ever used a bicycle you will know what happens if you turn the front wheel to more than 60 degrees at high velocity. If you have ever driven a car you will know what happens if you turn the front wheels to more than 60 degrees at high velocity.

In vehicles with wheel steering that simplistic pilot error induces skid, not yaw.

If a vehicle has *wheel* steering yaw rate does *not* maximise at maximum *wheel* deflection. With wheel steering yaw rate maximises at *compliant* wheel deflection. If anyone obtained a 'racing car simulation' that required full wheel lock, or random wheel deflection, as the means to steer round every bend, in every race track, at any and every velocity, they would no doubt be very disappointed, yet for some reason many flight simulation enthusiasts expect flight simulation dynamics to not notice that simplistic driver error, and not impose the consequence of that simplistic driver error.

Flight simulation enthusiasts must learn to moderate the applied steering angle to match current vehicle velocity during ground handling within flight simulators, else realistic dynamics will continue to demonstrate that excessive steering wheel angle invokes skid, not yaw. You can of course see that your pilot error is inducing skid not yaw by switching to chase plane view and watching the nosewheel skid due to non compliant applied steering angle.

In real life, in the Classic Era of aviation history, the means to 'push back' were rarely available and propliners often parked parallel to the terminal, or 'somewhat nose in' within closely spaced parking bays. They need(ed) a very large maximum steering angle to enter and exit those parking bays at very low velocity, but that real maximum steering wheel angle has no compliant application above 5 KTAS.

After you practice moderating steering wheel angle to match current vehicle velocity (just as anyone must in almost any vehicle driving simulation) you will be able to follow any real world curving taxiway radius at up to 20 KTAS. You should never taxi a CV440 at more then 20 KTAS. At 20 KTAS a bicycle won't make a right angle turn along a marked yellow right angle centreline, and neither will a CV440. Trying to turn hard at 20 KTAS in either vehicle is also pilot / driver error.

The real world consequence of each driver error will be imposed during flight simulation whether you are asking about new or old flight dyanmics for any functionally realistic CV440 release.

FSAviator.

 

[floda]

Best FSAviator

Thank you for your detailed lesson on taxi with a Metropolitan.
I have compared the "Air file" from Calclassic CV-440 with our Air file and could
not find a solution for making it possible to taxi with 15 KTAS without skid.

I would be happy if our model could make taxi turnes like our DC10 at 10 KTAS. I would be very happy if it could work at 15KTAS.

The reason why I wish to make it work for at least 15KTAS is due to our visitors wich have problem keeping the speed low .

Any suggestion from you is very much appreciated.


Best regards:

Floda

 

[FSAviator]

Hi Floda,

In order to cover the topic in the depth necessary this post is in two parts.

PART 1 – consumer misconceptions and developer design time choices.

Thank you for clarifying that you were testing / using somebody else's flight dynamics for a CV440. I was busy yesterday, but since I have some time on my hands today, and the underlying issues are very poorly understood, I will highlight the generic ground handling issues which allow you to have the mistaken belief that there is a problem in the FD in use, that you (and your visitors) cannot learn to control by making compliant inputs, in place of non compliant inputs.

I will try to explain why the problem you describe is explicitly user input related, not flight dynamics code related. If that is not the case why not simply use *all parts* of my (the Calclassic) CV44 dynamics to solve all relevant problems. My CV44 FD respond realistically to subtle throttle inputs to control vehicle velocity, and to steering angle variation versus the current vehicle velocity to control yaw rate, from 0 KTAS to at least 20 KTAS.

The consumer must of course comply with the RPM lever positioning mandated in the supplied handling notes else the consumer loses control of (rate of change of) THRUST versus (rate of change of) MAP. Sometimes consumers believe they can allow many input variables to randomise and that the simulation output will remain compliant. That isn't what happens!

Consumers are always inclined to regard non compliant simulation output as somebody else's fault, but the harsh reality is that consumers habitually fail to achieve operating compliance, and in most cases never even develop the intention to learn what constitutes operating compliance. That problem cannot be resolved by creation or use of different FD. As in this case different FD just deliver different randomised output during identical uncomprehending consumer non compliance.

The critical case is minimum taxi weight. At 34,000lbs (versus MTOW = 49,500lbs) my CV44 FD allow a 180 turn within the width of a small VFR runway and the consumer who has the intention to prevent velocity increase by variation of throttle can restrain velocity to less than 1 KTAS throughout the turn *without ever using the brakes*. The inner wheel barely moves.

It follows that the consumer who develops the intention to achieve operating compliance (with or without use of brakes) can easily restrain my (the Calclassic) CV44 FD < 15 KTAS, even at very light taxi weights. Consumer impatience to end their flight simulation session as fast as possible is not an FD problem.


<<The reason why I wish to make it work for at least 15KTAS is due to our visitors wich have problem keeping the speed low .>>

Do the FD you are testing have a min_throttle_limit = value far above zero, preventing realistic shedding of thrust during ground handling?

[GeneralEngineData]

engine_type=0

Engine.0=-6,-12.5,-1
Engine.1=-6, 12.5,-1
fuel_flow_scalar=1
min_throttle_limit=0 <<<<<<<<<

If not I see no reason to conclude that the problem is really in the FD you are using whoever created them.


<<I have compared the "Air file" from Calclassic CV-440 with our Air file and could not find a solution for making it possible to taxi with 15 KTAS without skid.>>

An aircraft.cfg and an air file are not 'mix and match'. Within my (the Calclassic) FD when used as provided, in the worst = very light case, < 34,000lbs, an input of 2 x 13 MAP yields 2 x 1200 RPM (in LO blower ratio at full RPM lever advance), and sustains 7 KTAS straight line nil wind on default FS concrete or tarmac, but I seriously doubt this is in any way about my air file versus somebody else's. Unfortunately like almost all such threads this is almost certainly all about consumers expecting uncomprehending and random consumer inputs to somehow deliver compliant output, but I will address the design time issues anyway.

The propensity of a vehicle with wheel steering to skid has several components. For the purposes of this thread the only important components are Centre of Gravity (CoG), vehicle inertia, nose oleo compression ratio, and nosewheel damping ratio.

If you place a heavy load into the rear of a station wagon or a pick up truck, moving CoG aft, the efficiency of the contact between the steering wheels (at the front) and the surface is reduced. With aft CoG less weight presses on the front tyres and fewer square centimetres of rubber contact the surface. The steering feels 'light' and is 'inefficient'. Skid will occur at reduced vehicle velocity. MSFS calculates accordingly. Within all recent versions of MSFS default CoG is coded in the Aircraft.cfg by various means, not the air file.

In real life inertia is the consequence of mass and distribution of mass. In MSFS if 'realism' is the goal of the developer then the code must be calculated accordingly. The flight dynamics developer is required to 'calculate' the inertia in each plane of motion.

*The encoded inertia is thus explicitly and intentionally 'divorced' from the encoded mass*.

Consequently the flight dynamics developer can choose to encode the inertia of a radio control model of a CV44, allowing the aliased MDL in MSFS to 'turn on a dime'. That is one part of the process of developing 'real easy' dynamics in place of 'realistic' dynamics. In MSFS that is just a choice made by the developer to match the ability of the target consumer. The dynamics can be 'dumbed down' in many ways to meet the needs of a given target consumer. The developer chooses whether to give the consumer a bicycle with stabiliser wheels on the back, or a bicycle which they must develop the understanding and skill to ride without falling off. Again the chosen (real easy, else realistic) inertia values are encoded in the Aircraft.cfg.

However when FD are dumbed down in various ways, because an aircraft.cfg and an air file are never 'mix and match', the internal values of the aliased air file must be dumbed down to match any dumbing down in the aircraft.cfg and that is a potentially complex process. The whole content can be 'realistic' or the whole content can be just a 'real easy' radio control model aeroplane.

The nose oleo in the CV44 substitutes for the shock absorbers or springs of the pick up truck. Under braking the nose dips. During braking more square centimetres of rubber are pressed onto the surface, and during acceleration fewer. The propensity of the nose wheel oleo to 'bounce' up and down (causing loss of steering efficiency during half of each bounce) is a function of non compliant consumer input. The propensity to recover from consumer induced bouncing of the nose oleo is a function of the encoded damping of the oleo or spring.

Again the developer (who understands how MSFS works) chooses whether to encode 'real easy' or 'realistic' behaviour for the target consumer. The nose oleo code is in the Aircraft.cfg, not the air file. If a consumer 'rides the brakes' they will induce oleo pitching which increases propensity to skid. Consumers should instead anticipate the need to reduce velocity approaching a turn and reduce THRUST accordingly. If consumers 'ride the brakes' they will induce vigorous 'nose dip under braking' and consequential oleo bouncing. The code is written to encourage elimination of that unnecessary consumer input error.

So, (moving over a compliantly coded tarmac or concrete bgl surface), if you cannot steer the FD you are testing at 7 or 15 KTAS, by compliant moderation of the steering angle, EITHER one or more of the variables above has been miscalculated by the FD developer and is 'worse than realistic'. ELSE the consumer / beta tester has misloaded the aeroplane causing unlawful and unsafe CoG. ELSE the consumer / beta tester has still not mastered real time variation of steering angle versus turn radius and vehicle velocity.

The way to test whether you have mastered moderation of nose wheel steering angle, is to *halve* the encoded maximum steering angle. If afterwards you find steering easier (at any velocity) you are steering badly, since halving the error you can possibly make, leading to more accurate steering, with less lurching and skidding, has demonstrated that that the problem was habitual consumer input error.

Of course if you leave the maximum steering angle at only half real world, to halve consumer error consequence, within 'real easy' dynamics, you will no longer be able to turn 180 degrees within a VFR runway at very low velocity to back track that narrow runway. Allowing the consumer the 'realistic' values, instead of 'real easy' values imposes a requirement for high levels of consumer acquired knowledge and skill to moderate the real maximum value compliantly to much less, in real time.

Allowing a consumer the opportunity to make (realistically) large errors does not cause the consumer to make those errors. The compliant smaller input value is always present as the compliant option. Just because consumers see erroneous output does not mean that the code is wrong. It means that they do not understand what input is compliant and habitually make non complaint inputs because they have no understanding of how to monitor and impose compliance.


Continued in Part 2

 

[FSAviator]

The solution - parallax compliance monitoring

PART 2 - The solution - parallax compliance monitoring

The real issue here, as in almost all such threads, is identification of the real source of the reported output error, avoiding the casual assumption that a consumer can possibly achieve that. Consumers simply don't have the necessary experience or understanding of FS developing and testing of multiple concurrent compliance criteria. The cause of the reported problem is hardly ever an error in the FD, even though they all have some errors. The real issue is almost always identifying which consumer input was non compliant and caused the observed non compliant output.

In practice it almost always requires the developer to deduce what whole area of the required knowledge base the consumer lacks and which is causing the consumer to have no understanding of how to monitor and impose compliance upon themselves.

This forum does not exist to teach aeroplane operating skills, but the reality is that consumers habitually perceive FD to have errors whenever those FD successfully detect and impose the cumulative consequence of consumer error, under circumstances which the consumer has never learned to recognise as consumer input error. Unable to understand what constitutes compliance, and unable to impose it, the consumer mistakenly reports non compliant output as being 'caused' by the FD. In consumer forums all over the web, almost every week, that false assertion is gladly accepted by other consumers and the blind are soon leading the blind around in circles.

In the ground handling case, and all other cases that relate to 'head up flight' most of the problem is the almost total absence of head up operating skills, and even the underlying concepts, among most flight simulation enthusiasts. Most flight simulation consumers have no concept of parallax compliance monitoring, or the need to impose parallax compliance, and consequently never achieve either in any phase of any sortie. Every time the consumer undertakes type conversion they must teach themselves the parallax compliances of the individual aeroplane, and then learn to impose them.

I explained this at some length for open cockpits which require a 'head out' technique within the Ansaldo SVA 5 release, and for enclosed cockpits which require a 'head in' technique within the Breda Ba 65 release, both available from Avsim. I do not intend to repeat that substantial content here. Consumers and developers who have no significant understanding of parallax compliance monitoring and its role in 'head up flight' should study both.

For the purposes of this thread (assuming use of the default Calclassic files) the relevant parallax compliance that must be learned and imposed during CV44 type conversion uses the the left hand air vent on top of the panel as the internal object of reference (the reticle) and the runway or taxiway centreline marking as the external object of reference (the target), both viewed from the default P1 eyepoint.

The reticle must be placed over the target, and as target vector changes the parallax compliance (steering one over the other) must be maintained by simple variation of yaw rate. If varying yaw rate to sustain the reticle over the target as the target changes vector is not 'simple' the velocity of the vehicle versus the target is non compliant. In this case if a consumer finds steering the reticle constantly over the target 'difficult', by slight motion of the hardware controller they personally purchased, then the consumer must slow the vehicle down.

The safe taxi velocity of a CV44 is not a given. It is a function of acquired consumer skill, in exactly the same way that it must be in any Grand Prix Racing simulation. The physics are identical, the skill is identical, but the 23 tonne CV44 tricycle is much harder to steer at any velocity. The extra difficulty is not a code error. Steering a 23 tonne tricycle is supposed to be more difficult!

The skill of anticipating the need for velocity reduction ahead of a turn (if travelling too fast) is identical, but the reduction must begin earlier, and ideally so early that the brakes are not used, since ground handling in a CV44 is not some kind of 'race'.

Once a consumer learns the concept of imposing *smooth and continuous* reticle versus target compliance, and the consumer learns to recognise the relevant internal object of parallax compliance in any aeroplane as part of their type conversion training, it becomes obvious to the consumer that the motion of the nosewheel to sustain the parallax compliance in real time is only slight at any velocity much above 0 KTAS. Having acquired the *understanding* and the *intention* to monitor and impose reticle versus target parallax compliance *continuously and smoothly* the consumer ceases to taxi too fast to comply, and also ceases to make wild and erratic maximal motions of the nosewheel causing skid. Each deflection of their controller is gradual and incremental as the target vector changes incrementally. Just like driving a real bicycle or a real car 'head up' !

It is a simplistic, but learned skill. Consumers who never understand it, and never learn it, just make random inputs of velocity and yaw rate and lose control of both, while they mimic someone who never learned to ride a bicycle. A five year old can taxi a CV44 compliantly in a flight simulator, because it is in fact easier than learning to ride a real bicycle, but somebody has to help them to understand and then learn the required skill! Compliant ground handling is just a learned knowledge base and a learned skill like everything else in flight simulation.

Stopping the vehicle from 'lurching' from one wheel lock to the other, when instead the nosewheel should be gently and incrementally turned (more like a change of applied pressure, than a movement) to sustain parallax compliance of the reticle versus the target vector is the missing skill that must be learned. If it is never learned the vehicle will 'lurch' one way or another across the target vector, or worse the consumer will lose control of the vehicle vector and will induce skid.

Once a consumer understands the concept of parallax compliance monitoring and imposition, they will find themselves varying throttle to control parallax compliance, not just very gradually altering yaw status with the nosewheel. Just like they do in their car ! After around 10 minutes of practice it requires no thought or calculation at all, just like riding a bicycle. Moderating velocity to allow the time needed to achieve the necessary yaw rate becomes part of an 'obvious' process, but only after the concept of continuous parallax compliance monitoring is understood and imposed.

Of course if consumers try to use MSFS as a radio control model simulator, or an 'aircraft spotter' simulator, and are therefore not occupying the cockpit, and therefore have no parallax compliance references, they are doomed to fail. That is just part of the problem of never trying to learn what pilots do, or how they do it.

Every so often the pilot scan must go 'head down' to check RPM. At light weights while a CV44 is moving in a straight line (using all parts of my FD) if RPM exceed 1200 the vehicle will be accelerating beyond 7 KTAS on a flat concrete or tarmac encoded surface (not just texture) in nil wind, and that may be wholly undesirable.

In MSFS 99.99% of airfields are entirely flat and consumers have the opportunity to learn specific input values that will cause specific output values at specific weights. The harsh reality is that consumers simply don't bother to learn, and they instead choose to believe, and tell everybody else, that it is difficult to prevent CV44 FD accelerating beyond 15 KTAS during ground handling.
It isn't at all difficult to learn to taxi even a very light CV44 in a straight line sustaining 7 KTAS on tarmac or concrete using my (the Calclassic) FD. What is missing is the intention to learn.

Inside MSFS relevant RPM input values for high weights and grass or dirt or gravel bgl surfaces can also be learned and then imposed as the compliant inputs for straight line ground handling under other frequently encountered circumstances. This is of course just one example from many compliance criteria that require consumers to make explicit not random inputs in pursuit of explicit not random output targets, while occupying a suitable designed cockpit environment, if they ever hope to understand what real pilots do, and how they do it.

Leaving the superchargers in HI blower ratio to taxi after landing is of course a consumer error which can induce excessive taxi velocity!

Consumers who do not understand the process of compliant operation, will never achieve smooth and compliant output, but that does not imply that the FD do not enable smooth and complaint output, after the consumer makes the effort to learn what it is, and how to impose it.

If intending to turn through a right angle, with no curved yellow line as the target to impose the reticle upon, the consumer must learn to 'imagine' the yellow curved line that links the two runways or taxiways at right angles. The reticle must be imposed on the imagined line and *progressive* turn initiated accordingly. If velocity is moderated compliantly with THRUST the brakes are never needed, and no nose dip or oleo bounce ever develops. These are some of the real world skills that (along with many others) my CV44 FD allow consumers to learn and then impose.

Flight simulation flight dynamics exist explicitly to detect and illuminate virtual pilot and captaincy error, in order that the virtual pilot / captain can understand that they are making non compliant inputs, and can learn to instead make compliant inputs.

Learning how to ride a bicycle with no stabilisers is actually more interesting than asking someone to add 'stabilisers' to dumb the dynamics down so that nobody ever has to understand how real pilots monitor and impose multiple learned parallax compliances, aircraft by aircraft, during 'head up' operation and why they don't struggle to control vehicle velocity versus required yaw rate during ground handling.

Once consumers understand the concept of parallax compliance monitoring and imposition, most consumers can learn how to avoid falling off a bicycle with no stabilisers in around 10 minutes of self training. Consequently there is no reason at all to encourage the production of a thousand different dumbed down bicycles with stabilisers always attached, either because consumers are unwilling to learn to impose compliant aircraft operation, or because most developers never explain the concept or the mechanistic process to their consumers.

If you have a compelling need to use other CV44 FD you (and your visitors) must learn what RPM, at full RPM lever advance, in LO blower ratio, else with blower ratio selection automated, deliver a sensible taxi velocity (say 7 KTAS at light weights) as their 'straight line' velocity output, on a bgl which imposes tarmac or concrete surface friction, and you must learn to impose 'their' compliant RPM in pursuit of identical compliant velocity output, for that phase of the flight. The need to understand and learn parallax compliance monitoring and imposition, to deliver only incremental change of nosewheel facing, to avoid skid, is entirely independent of the FD in use.

There is a perfectly good reason that the relevant extensive knowledge base and skill set is highly paid in real life. Operating a potentially 56 seat aeroplane is not a 'make any old random nonsense up as you go along' kind of process. It is a whole series of concurrent input and output, head down and head up, operating compliances that must be learned and then imposed. That can only be achieved while a consumer uses a simulation control interface (panel or VC) that provides suitable parallax compliance cues for ground handling, having already imposed the learned RPM value that delivers the target straight line velocity in between each turn.

If consumers learn what parallax compliance monitoring is, and consumers learn to impose it, and consumers also bother to learn to taxi at less than 15 KTAS, they won't need to brake, or to reduce thrust, to slow down for each turn, and they will learn how to give the virtual passengers a smooth ride instead of a roller coaster ride. Velocity will just diminish a little in the turn and then return to less than 15 KTAS on the straight. It is the consumer's job to learn those skills of smooth compliance using real world techniques.

The ability to demonstrate ground handling compliance is in every set of FD. The problem is that consumers fail to learn what is required.

The FD you are using are not AI FD. They deliver the consequence of your inputs, which need to become fully concurrently compliant in ways you (and your visitors) have never even contemplated, but that I have now explained. The output of your simulation will become compliant just as soon as you learn how to monitor and impose your own compliance. It is 'only' lack of understanding of the entire concept of parallax compliance = 'head up flight' that is missing.

FSAviator

 

[floda]

Greetings FSAviator.

Thank's for all the time you have spent trying to solve my (our) problem.
It will take me a couple of days to study your last 2 reply so I will start by
asking you where I can find your CV440 wich I thought was the one I examined
earlier.

Best regards

Floda

 

[FSAviator]

Downloading and testing CV44 components from Calclassic

Hi Floda.

My Convair FD are hosted at;

http://www.calclassic.com/convair.htm

Each type of Convair Liner has specific dynamics. The CV44 'base back' is at the bottom of the page. Note the warning that ..... "You must download and install the United CV-340 above to get the proper panel and sounds"

Some parts of my prior post assume use of the relevant 2D panel within the CV34 base pack while learning parallax compliance monitoring during ground handling from the P1 eyepoint in a CV44. A different panel (or VC) can be used of course, but may require consumer identification and then use of a different component as the 'reticle'.

<< .... where I can find your CV440 wich I thought was the one I examined earlier.>>

You may indeed have examined it earlier, but the issues of installation also require multiple compliance. In your second post you said;

<<I have compared the "Air file" from Calclassic CV-440 with our Air file and could
not find a solution .........>>

The "air file" is not the point, which is why I explained that all relevant aspects of the steering are encoded in the aircraft.cfg. You cannot take the aircraft.cfg from one developer and then alias the air file from another developer from it, without causing major simulation output errors.

The encoded ability to impose 2 x 1200 RPM, (full RPM lever advance and LO blower), to target a constant 7 KTAS, at minimum taxi weight (< 34000lbs), as the straight line terminal velocity, moving over a flat concrete or tarmac bgl encoded surface, (not just texture), is cross encoded between the Calclassic cfg and the Calclassic air file. You cannot test the calclassic air file with any random aircraft.cfg.

Remember I am not saying my FD are superior, I am saying that both of the reported errors are entirely external to either set of FD, and that both excess velocity, and invocation of skid via excessive steering wheel angle, are caused entirely by random (uncomprehending) consumer input in both cases.

I have been explaining how you (or anyone else) can prove that conclusion is true, while also explaining what consumer inputs are instead compliant, and how the informed consumer monitors whether their inputs are compliant.

Remember that you will need more RPM to induce more thrust to overcome the 'static inertia' of the object at rest, and must *reduce* to the target RPM, that delivers the target TAS, once the object has begun to move.

FSAviator

 

[vololiberista]

If I may I can add something from the real world! The VC10 has a nominal maximum steering angle of 55degrees but will go up to 70deg in an emergency. Continuous use of "full lock 70deg" steering puts excesive strain on the supports. Most simmers are very poor judges of ground speed and indeed one sees many posts of "I can taxi my 747 at 40kts around bends!"etc etc. Apart from the fact that most busy airports impose speed limits, think about being a passenger in a 747 going round a bend at that speed!! Also think about the forces imposed onto the airframe!!

Maximum ground speed should be no more than 15-25kts in a dead straight line where there are no obstacles and the way is totally clear, and only if the airport authority allow it!!!!). Round bends fast walking pace is the maximum recommended.

When taxiing with jet a/c it is not necessary to constantly change the engine thrust. Going back to the VC10 as an example 68% n2 is breakaway thrust, thereafter taxi on idle. If one is taxiing up a slope a little more thrust may be necessary but in any event it is never necessary to exceed 68%n2 even at max auw.

alweays remember even with other vehicles, cars, boats etc the same rule applies the slower the speed the tighter the turn.

vololiberista

 

[floda]

Hi FSAviator and Vololiberista.

Best FSAvistor, you have realy spent a lot of time and energy telling as that
we don't know how to taxi with a aircraft.

I think it is time to tell you who we are. We are a small group running 4 simulators at our hometown museum. We are all pilots and two of as have
been flying the heavy birds in SAS for 30 years. One of us, a pilot as well has been working in Kopenhagen as an aircraft engineer in there simulators

I think that we know how to taxi, and we can taxi the CV440, and have done so for 6 years but as I have discovered the power of this forum, I thought that we might improve the steering in the CV440.

We can compare the steering from the DC10, Airbuss 320, Focker 28 and they behave so much better.

To put an end on this issue I like to thank you very much and pleas give my greatings to Tom Gibson, one of the big souls on the forum.

Best regards and happy steering.

Floda

 

[robystar]

Hi Floda,

I was astonished and humbled by your mentioning my name on this topic I am not an expert in.
As a consequence of the (I feel wronged) replies, I have refrained from answering.
I am not sure if I can be of help although I would like to.
I am not in for how a certain aircraft handles in the real world as I am only trying to get it behave as I would want it to in my FS world.
On the other hand, I am not sure what you are asking for (maybe, and I apologize if this is not so, your question provoked the replies you got, due to lack of information).
Are you by any chance referring to AI? Are you trying to get a CV440 doing something different than it does in reality?
I need some more info on that. What are you trying to do?
By the way, I am not sure if I found an answer to your question in the elaborate explanations of FSAviator.
Did you?

Roby

 

[floda]

Hi Roby !!

As you are asking I will tell you the problem in a few words.
Our Metroplitan simulator is probably the most loved one of the four.

Pilots, and I mean professional pilots from whole scandinavia are coming to us just to fly the CV440. They don't complain on anything. But we would like it to behave as the other three simulators when it comes to steering on ground at 8-15 KTAS.

That's all we like to improve:
Just for you, take a look at the CV440 in panorama.

http://www.4pisr.se/AllFullScreen.php?id=MetropolitanSimulator

Best regards Roby

Floda

 

[jx_]

I didn't read all the responses, but with regards to the original post....

In FS, when the aircraft loses the ability to turn as speed increases, it usually means there is a reduction in weight on the steerable wheel caused by lift or a pitch moment. The steerable wheel loses contact with the surface. In the digital world this could be 0.00001 inches and you would still lose all steering.

The cause could a few things including the center of lift or the moment arm being too far ahead of the main gear, or bad weight and balance. Adjusting contact points can sometimes fix this.

 

[floda]

Hi

I agree with you ! Do you want my aircaft.cfg file so you can fix it?
Just let me know.

Best regards

Floda

 

[FSAviator]

Greetings Floda,

Who you are is irrelevant. You asked MSFS developers to address two problems your visitors were having during realistic operation of a CV44 and I have therefore addressed the knowledge base of your consumers, while assuming that your understanding of the inner workings of MSFS were minimal.

The type of input devices you are using to control MSFS may be highly relevant. Your problems may relate entirely to calibration of the hardware input devices in the CV44 cockpit environment you are using to make the steering inputs to MSFS.

I have already explained that during ground handling simply reducing;

empty_weight_yaw_MOI=

below a realistic value will allow any yaw rate you desire, at any velocity you desire, right down to coding a radio control model CV44 that can 'turn on a dime'. If you just want 'easier' steering, or even need to offset errors in your cockpit hardware calibration that is all you need to do.

That does not explain why you have difficulty teaching your vistors what CV44 engine input delivers the (any) target TAS for ground handling, or why you need MSFS developers to help you with that simple task.

FSAviator.

 

[mgh]

Greetings Floda,

Who you are is irrelevant. You asked MSFS developers to address two problems your visitors were having during realistic operation of a CV44 and I have therefore addressed the knowledge base of your consumers, while assuming that your understanding of the inner workings of MSFS were minimal.

FSAviator.

Hmmmmmmmmmm?

 

[WarpD]

I think the only thing left to say is wow.... just wow.