Forum: Technology

Never said you couldn't enter the deep stall from a nose high wings level, just said we didn't. Was a lot more fun to throw the jet around and then go "oops...imagine that". Smile

F-16.net Sponsor

A couple of questions.

1) In the F-16, when the control stick is centred with zero trim entered, what is the input to the FLCS? Does read an input of roll rate zero or something else?

2) Generally with automatic flight control systems, in modes such as attitude hold do aircraft with this facility become over-damped?

Thanks
Obi

OK, we have CAT I, and CAT III. What happened to CAT II?? I heard the answer once but was under the influence of golden beverage at the time and it has totally left me...

The Categories are for different classes of external stores. Cat I is mostly air to air loadings without external tanks, Cat II is air to air loadings with external tanks, and Cat III is air to ground loadings. The Full Scale Development (FSD) F-16 (1976, 77) did not have a Cat switch, and all flight control computer functions were the same for all external store loadings. During Envelope Expansion flight test, all went well with flight controls, but during operational tests, it was discovered that certain heavy loadings and low airspeeds did not play well together, and different AOA and roll limits were developed for the three categories I described above. These new limits were all pilot-observed limits, not programmed into the flight control computer.

Cat I limits were unchanged, Cat II had the same AOA limit but was limited to 180 degree full command roll rather then 360 degrees. Cat III had reduced AOA limit, reduced roll rate command, and 180 degree full command roll limit. As soon as the computers could be re-programmed, the new AOA limiter and reduced roll command (and some other refinements) were incorporated.

So, the panel has Cat I and Cat III switch positions, with Cat II loadings are flown in the Cat I position, since the only difference between Cat I and Cat II limits is a pilot-observed limit (180 degree full command roll). At one time, the switch had labels which read Cat I/II and Cat III. Maybe it still does, I don't know.

When all tanks or air to ground stores are separated, the category can change. You can look in the -1 Section 5, External Store Limitation Chart, to see what the new categories are (called "revert to").

Interestingly enough, the flight control g-limiter for all loadings is 9.0, so any loading with a g limit less than 9, the limit is pilot-observed (or should be).

One other thing while I'm thinking about it. Several posts have stated that one of the advantages of a digital flight control computer is that it is easier and faster to update with different control laws. Just software, right? Seems logical, but is totally wrong. Changing a control law is as simple as changing a number in a look up table, but that is only the beginning of the process. The really messy part of flight control software is redundancy and failure management. You have multiple pilot inputs (pitch, roll, yaw), with three channels of each, then you have multiple inputs from airplane motion ( y-axis and z-axis accelerometers, x, y, and z axis rate gyros) three channels each, angle of attack, three channels, air data (airspeed, altitude, static pressure, Mach number, control surface positions, leading edge flap position, all coming into the computer, all subject to failure. The computer has to figure out what is good data, what is bad, and how to get rid of the bad data, all the while keeping the airplane flying how the pilot wants it to.

So, that simple little control law change ends up taking months to get to the airplanes, due to all the checks, tests, verifications, and validations to prove the redundancy and failure management has not been screwed up. It ends up taking just as long to modify a digital program as to modify an analog board.

Don't get me wrong, digital is the only way to go, for many reasons. But faster, easier changes is not one of them.

Salute!

Johnwill speaks the truth.

We always felt good pulling symmetrical gees, as the original Vipers had strain gauges in the wings that helped the gee-limiter. Problem was with rolling gees, hence the Cat II designation.

Roscoe can help here, but one problem with a "light-weight" fighter is doing hard maneuvers with assymetric loads on the wings or basic heavy loads on the wings. Older jets "let you know" when you were about to get into trouble. The Viper just tried to do what you wanted. So roll-coupling that was beyond the FLCS functions (coded in firmware in early days) could result in a "yahooooo!!!".

It could also result in deformation of various structural members of the jet that could be bad news later on.

Seemed to me that the original FLCS control laws were for a A2A configuration, and if that's what you had that day, then no problem.

Johnwill is correct about "simple" changes made possible with digital, software-controlled FLCS. You have body/mass moments to consider, hence the reduced roll-authority of the original Cat III change. AoA was limited with that mod to help keep roll-coupling down to something that all the control surfaces could handle.

**************** Opinion note ***********

I worked for about 14 years after I had to quit flying the Viper. I worked with many folks who were designated "software engineers". I didn't see one that was a real engineer. They were all "hackers" or "coders". The real engineers wrote the specs and the software geeks coded it to the spec. Then real engineers tested the software in actual, physical models or even real jets. The software folks didn't have a clue about aero, mech or physics.

The worse part was that they didn't apply fundamental engineering disciplines to the task at hand. New computer systems allowed them to sit in front of a CRT and hack away until their programming efforts got the desired result. No flow charts, no written documentation until their hacking efforts produced the specified result, etc, etc. ad nauseum.

One great example was the update rate for a Maverick control doofer. The sfwe geeks wanted an asynchronous system based upon discrete operator inputs using a stick/mouse/force-transducer, etc. They didn't understand hysteresis effects on the seeker and the need to smooth the input data to make the targeting easy for both the operator and the missile seeker. So we systems engineers ( including pilots like me that actually had used the Maverick) demanded that they use a 50 or 60 hz time slice for sampling both the seeker movement and the operator inputs. When they tried their asychronous approach and the thing was impossible to control by normal folks, they caved in.

The original Space Shuttle HUD was much the same. My old roomie (who flew four times on the Shuttle and spent a few months on the MIR) related a few good war stories about the first Shuttle HUD displays. The display was jerky due to the update rates for the data and the actual processing by the HUD. This was sad, as we had had great HUD's on the A-7, Jaguar, 'vark, Eagle and Viper for years. The sfwe geeks couldn't understand why consistent update data made it real easy for other systems to smooth the data for display.

END OF SERMON

********************

Good thread...

Last edited by johnwill on Aug 26, 2007 - 03:04 PM; edited 1 time in total

Gums,
I always admire your direct, no BS approach to explaining a situation. You are entirely correct about the original control laws were for air to air loadings and had to be modified later after problems were found with some air to ground loadings.
I am probably more tolerant of software weenies, since all my work with them was flight control, not avionics. Flight control software types always worked under the close supervision of "real" stability and control engineers. Your comments are well placed with regard to avionic types, however. Most of those guys could not tell you the difference between an airplane and a computer because to them, there was no difference. I'm not knocking the contributions they make to the success of the weapon system, it's just that they are not airplane people.

One point you made needs clarification. The wing strain gauges in F-16A/B were not used in any way as part of the flight control system. There was a proposal to do that early in development, but it never happened. The gauges were installed to help keep track of individual airplane wing loads as an indicator of structural usage. As you know, durability (similar to fatigue) tests on the ground are based on Mil-Spec usage, so if the airplanes are used in a different way from spec, then adjustments in structural inspection intervals have to be made. The strain gauges helped to define actual usage. The C/D models used a more elaborate recorder (CSFDR - crash survivable flight data recorder) eliminating the need for the gauges.

Best Regards -

Elite 1K Joined: Aug 19, 2004 - 09:19 AM Posts: 1092

Wouldn't the use of strain gauges in the flight control laws of the F-16 constitute some sort of open loop system? Actually, I don't know too much beyond the basics of flight dynamics and control. Has there ever been any successful testing of open loop flight control systems on combat aircraft or even prototype aircraft?

I am no flight control expert, but I can tell you how the strain gages were planned for the early F-16. At the time, the required g capability was 7.33 at the basic fight design gross weight (22,500 lb), with 9g capability at reduced weight and non-critical mach/altitude. The gages were calibrated to measure wing bending moment. The flight control computer would, in effect, plot the wing bending moment vs g as g increased, say from 4 to 5 to 6 and extrapolate the wing load to limit load, thus calculating a continuously varying g limit. In that way the wing limit load could not be exceeded. Strain gage reliability was a question mark.

However, structural analysis showed that we could strengthen the wing and fuselage attachment enough to handle 9g at all conditions for the basic loading of two AIM-9s and full fuel with a weight penalty of only 22 lb. USAF decided that was the way to go (they were right), so the strain gage plan was abandoned.

Is that some sort of open loop? Beats me, you'll have to ask a control systems expert.

johnwill wrote:

Don't get me wrong, digital is the only way to go, for many reasons. But faster, easier changes is not one of them.

Not fast nor easy...but way faster and easier than changing an analog computer.

As an example of fast changes on an analog computer, consider overnight changes to the YF-16 computer during the competitive fly-off with the YF-17 in 1974. Happened several times, saw it myself. Granted, those were not production-quality changes - but it illustrates what can be done if required. In the middle of the fly-off, filters and a variable g limiter were added, and horizontal tail roll gain changes were made, among others. It was amazing what could be accomplished under the pressure of competition.

The last program I worked, T-50 in Korea, routinely required 4 or 5 months for the simplest digital change. Those are not apple to apples comparisons, no doubt.

Once the changes are fully verified, of course the digital is far easier to apply to airplanes in the field. But getting the changes verified is very time consuming.

Salute!

I am going with John-boy, Roscoe.

The tests required for a software change are more extensive than for replacing a resistor in an analog circuit.

Considering the nature of the sftwe folks, and their insistence upon C++ versus Ada or something that demanded discipline and could be "pseudo-coded" for we systems engineers to be able to read .... well, you get my drift and heinous opinion.

After leaving the flying and having to actually earn my pay, I learned a lot about sfwe testing that I had never thot about. Poor sfwe is a bitch to thoroughly check out. Highly structured sfwe written by disciplined folks is lots easier to check, as long as you have many interim tests along the way. The more modular the code and the better the spec from the systems engineers, the faster stuff can be implemented. So we systems folks share the blame if we don't provide good stuff for the sfwe folks.

Back to the thread:

I am presently up in rarified air at an undisclosed location in Colorado, and I don't have the original GD documents re: FLCS. So I'll check in a month or so to see what I can see. One of these days I'll find a super scanner and have those booklets in PDF for all to see.

John-boy is prolly right about the strain guages. However, my recollection was that they did, in fact, limit gee in the pre-production jets.

During our first few months at Hill, we often noted that some times we could get the full 9 gees, or more, and other times maybe 8.6, 8.7, etc.

The original analog FLCS seemed pretty straightforward when you looked at the various function generators and how they were wired together. The digital FLCS had the advantage of lower cost field upgrades, but I venture that initial development and verification was quicker and cheaper for the analog doofers. We also liked the ability to no sierra cut out the Cat III functions with one switch. Ask the demo pilots that did the half-cuban eight maneuver after takeoff. If they didn't get the full 25 deg AoA (nominal), they could check the Cat III switch or roll back to erect and know something was seriously wrong.

Youse guys must remember that I was honed on analog systems even prior to solid state ones. We had shoebox op amps and used actual pots to set values for integrators and differentiators. No kidding, large patch boards with many wires to plug here and there. Saw my first IC down in Dallas at the TI plant in 1962 - it was the size of a postage stamp, but most of the components were etched in silicon, and a few were still discrete resistors and caps and inductors. Only digital doofers around were mainly used for admin stuff and we were just getting into Fortran for engineering apps, using punch cards to enter our code. Apollo and Gemini got us moving into digital real fast, and soon we had a digital system on a real jet - the SLUF. Seems LTV borrowed the same computer that was being developed for Apollo's LEM.

Oh well, enuf war stories tonight

out,

***************

Gums,
Old farts like ourselves have to stick together or these youngsters will begin to believe they know more than we do (probably do anyway). Your mention of the old analog computers brings back memories of the Pace unit we had in the Engineering Systems Lab of the ME department at Texas A&M in 1961. That was my first exposure to analogs, along about the same time I learned Fortran IV on an IBM 650 - punch cards and all. Then GD still used analog-digital hybrids for flight simulation on the B-58, F-111, and YF-16. F-16 went full digital for simulation.

Two F-16 FSD airplanes (and several others since then) were fully equipped with strain gages to measure airframe loads (about 60 channels worth) for Flight Load Test, which clears the maneuver envelope for loads. That is (was) my specialty, spent 40 years doing it. Design the strain gage positioning (hundreds of them), calibrate, define the flight test program, monitor the tests real-time, analyze the results, write the reports. Great fun - could not have asked for a better way to spend my time at work.

These may have been the strain gages you were referring to, but again, they were never linked to the flight control computer.

Best Regards

Salute!

I wish to publically honor john-boy for great corrections to my feeble memory and his support for the advantages/disadvantages of the older analog sytems.

I want to cause John-boy a super flashback: Remember when the analog sytems were mechanical?
*************************
The original F-101, F-102, F-106, F-100, F-104, F-105 and F-4 "computers" used no-kidding cams and gears to "compute" your launch timing and steering. I'm not making this up, folks.

Electric signals and servos tilted and slewed your gunsight, and they controlled the release/launch of your missiles. No electronic positioning via a digital or even analog processor.

On head-on intercepts, the gears and cams would jam or get jerky, no kidding.

The SLUF was completely digital with a few hard-wired electronic analog doofers. The Viper had the same mix for all except the FLCS. The FLCS was a collection of electronic analog chips and discrete components. Very reliable and relatively immune to EMP or lightning.

*****************

John-boy and I worked with PACE and TRAC analog computers in the early 60's. Ones I worked with were from Martin - defunct Dynasoar project hand-me-downs to USAFA.

These suckers used vacuum tubes, potentiometers, resistors, inductors and capacitors to do the differential and integration math functions. We had to keep them at a constant temperature for long tests, so our secret deal was the air-conditioned labs that the "mech" boys didn't enjoy, heh heh.

We checked our results using sliderules, as pocket calculators didn't come along for another ten years. Remember that we went to the moon using sliderules, for the most part.

********************

Digital versus analog?

Even today, there are dedicated chips in our computers for several math functions and logic functions. They are small, and extremely fast compared to doing it all in software. See your video boards in your PC if you do any gaming. Same deal.

I can re-program functions easily in the digital world. But that costs me timeslices that could be useful elsewhere Parallel processing can help here, but interfaces are crucial, as well as standards interface protocols.

Hard-wired analog doofers can easily be replaced/re-programmed without the extensive testing that a software change involves. Why? 'cause the software for the main doofer is one big collection of bits and bytes. The effect of a single change in those requires testing every damned function the main program is supposed to perform.

all I gonna say for now.

Analog or digital? I see a value in both.

out,

Gums,

Believe it or not, my nick name at GD/Lockheed was John-boy. The youngsters around here never heard of the Waltons, so they don't know about John-Boy.

Thanks for the kind words. Analogs were vitally important in WWII also, as they were the core of the Norden bomb sight and the Navy's torpedo and big gun aiming systems. These were similar to Gum's description of the century series computers, cams, gears, servo-motors, etc. The most complex analog I ever ran into was on the B-58. It was about 10 cubic feet crammed full of electro-mechanical hardware, all to make that beast flyable at a wide range of speeds, altitudes and engine-out conditions.

And of course, you are exactly correct about software testing.

Forum: Technology

Analog and Digital flight control systems