cheezit

There are a number of written accounts that suggest it was cooked up during AIMVAL/ACEVAL. Lots of squirrely stuff seems to have happened there.

Wasn't there an engine bug a while back where empty tanks had either negative effective weight or negative effective drag (or both)? If that was/is the case, getting performance right in any case where tanks are present is going to cause everything else to be wrong. It's got to be frustrating to be in HB's shoes. Lots of knobs to turn and they all interact. Same for everyone else trying to make a high-fidelity module.

Bust out the ol' VX-4 livery and see if it at least takes the edge off, imo

Interesting. When I plugged the numbers from the SR-71 charts into AeroToolbox, the Mach number for 350 KEAS @ 80k feet matched the Mach number on the Air Force's chart from the SR-71 flight manual, and the TAS was obviously correct for the Mach number and altitude; seeing this, I thought that they had to be using the equation for supersonic flow. Maybe I'll try calculating by hand and submitting a patch to AeroToolbox if I can figure out what's going wrong (I assume everything on that page is done browser-side in JS so source shouldn't be too hard to track down).

If my calculator's not wrong, the SR-71's typical cruise speed was about 800 KCAS. Nb. the charts are all in KEAS, and the compressibility correction for ~Mach 3.2 @ ~80k feet on an ISA standard day is going to be pretty significant. Unless I'm missing something, in which case hand me some shells to load my footgun.

I have now learnt that there are fundamentally only two arguments in comparative performance discussions: 1. Drawing lines on charts 2. "My dad could beat up your dad!"

To expand on this point, per the open literature (specifically, defense appropriations hearings where a redacted version of the live-fire portion of the test plan was included in the congressional record), the original AIM-54C (not the later AIM-54C ECCM/Sealed, nor the "AIM-54C+", nor the "AIM-C++"/"AIM-54C+ Upgrade"/"High Power Phoenix" with the TWT amp that was basically a design borrowed from the AIM-120A's amp but upscaled for the Phoenix) had more to its ECCM improvements than this: specifically, the test program called for live-fire tests against multiple blinking/blitting self-protection jammers in and synchronized configurations, various configurations of standoff jammers, combinations of self-protection jammers and standoff jammers, etc where simple HoJ capabilities wouldn't achieve anything useful. I think it was from the FY81 hearings, but I can look up the chapter and verse if you'd like.

Was looking at docs to distract myself from the realities of floor sanding and embedded development recently. Came across this gem, relevant to the previous discussion in the thread about how the AIM-54A was supposedly overmodelled wrt. ECCM: "Better than Sidewinder, even" - apparently having an analog front-end didn't make the thing completely dumb as some have said. Quelle surprise that a missile whose primary mission was to nail bombers and which had tons of board space for electronics due to its huge diameter did what it said on the tin. Sarcasm aside and despite all the obvious caveats here, this does makes me wonder what a circa-1980 Soviet bomber's ECM attack vector against an AIM-9L would have been (or the ECM attack vector of a standoff jammer working with said bomber). Off the top of my head I'm thinking the proximity fuze, since radar jamming does nothing to an IR missile while the target detection device was one of the ECCM upgrades done in the AIM-54A -> AIM-54C development program (with the 54C featuring a TDD that had two separate proximity fuses that operated on different principles). Or maybe I'm completely overthinking things and they're lumping flares and flare rejection in as part of ECM/ECCM.

Have you found any documentation about how the AIM-54C vs. boat ("surface target" in the congressional record, I assume it was a boat) test went, or if it was even carried out? The live fire test plan from the FY1981 defense appropriations hearings listed it as live fire test shot #4 in the OPEVAL, so it should have been carried out some time in late 1983 if it happened.

For the AIM7-vs-boat shots, was the target being illuminated in P-STT, PD-STT or flood/CW? The -54A seeker needs PD illumination of the target (whether by the AWG-9 or by its own radar) if I'm not mistaken. Obviously a surface ship isn't going to give a doppler return that survives the -54A seeker's doppler notch outside of exceptional circumstances.

I wonder if it was realistic for it to work in the past? Attacking surface targets was part of the live-fire test plan for the AIM-54C, but I don't think any of the results of that testing ever got declassified; heck, even the plan itself is half-redacted four decades later.

Drag equations that work for both subsonic and supersonic flow are too complex for me to do the math on a napkin, but a missile that can get to Mach 1.8 when launched at Mach 0.8 will achieve closer to Mach 1.7 than Mach 1.2 when launched from a standstill, ceteris paribus. Of course in the case of the missile being used as a SAM the "ceteris" are not very paribus with regards to your scenario when shooting against anything but a sea-skimming target. BTW, Hummingbird, have you tried duplicating the NASA AIM-54C simulated shots that I linked above in the thread? I know you and your squadron have done lots of testing work in the past, and I'm not able to try it out myself for the foreseeable future (in the process of moving => stuck with a laptop for a while, among other things). The High-Q one might be hard to set up, but I think High-Speed and High-Altitude would be doable in DCS without having to do too many goofy tricks to hit the launch parameters.

There is a flight regime that fixes this issue

Send Nicholas Cage to steal a copy of Tactical Tape 116D while I work on a CDC-5400B emulator based on this outdated spec from before the subassembly was even named . We'll get this done

I'm sure it'll never happen, but I really want to see the schematic for the circuit that implements this, as the normal/straightforward way one would implement a band-reject filter would preclude this. I'm mostly a firmware guy, but I can think of a couple of more complicated ways to structure things to allow this functionality, and I'm curious whether the guys at Hughes took the same approach. Especially considering that the AWG-9 was under development before packaged transistor-based op-amps became easily available, so the whole thing might be some clever MacGyveresque combination of a couple of BJTs and resistors. Man, I'd love to have a poster of that schematic for the wall of my 'office'.

The main-lobe-clutter filter is +/- 133 kts (relative to Vg) and the zero-doppler filter is +/- 100 kts (relative to 0 Vc) in all PD modes, no?

Is this knob supposed to affect the width of the main-lobe clutter filter, or something else? Doesn't seem sensible for it to affect the width of the zero-doppler-shift filter (ground clutter has a doppler shift roughly equal to that of the ground, not zero), and I don't have a good enough understanding of the system to think of anything else it might be doing. The AWG-9 had a fully analog front-end and a programmable digital computer back-end, the latter consisting originally of the CDC 5400B with a 24-bit word size and 1 MHz clock speed, 24k NDRO memory, 8k DRO memory, and 140k replaceable tactical tapes that acted as ROM. Were the doppler notches implemented in the analog front-end (eg. with band-reject/notch filters implemented with op-amps and passive components in the signal chain) or the digital back-end? A turnable knob could easily adjust either - eg. a trimpot could adjust the resistance of one part of a voltage divider in a filter circuit, or a rotary encoder could adjust filter parameters in a digital system. It's funny, by the way, just how many digital computers were in the "all analog" F-14A. You've got the MP944 in the CADC that everyone knows about, the CDC 5400B in the AWG-9 that I just mentioned doing target tracking and generating steering commands and keeping track of launch parameters and driving the TID and DDD, also the smaller CP-1050 in the AWG-9 that I think was used for stores management and a few other things. Were there more?

No object falling in an atmosphere gets faster and faster the longer it falls, unless it starts at too low an altitude to achieve terminal velocity before impacting the ground. Terminal velocity is simply the airspeed at which the force of drag on the object equals the force of gravity. It's not a constant, but changes with altitude (being lower at low altitudes where the air is thicker and thus drag is higher at any given airspeed). If the object starts out going faster than terminal velocity, it will be slowing down the whole time it falls. To illustrate this, consider the case of ballistic atmospheric re-entry of a spacecraft (eg. the Mercury or Gemini capsules, or the Apollo command module doing a non-precision landing). The spacecraft is getting slower the longer it falls! Why does this happen? The spacecraft starts out at a speed much higher than terminal velocity, and thus the drag force is greater than the force of gravity. The capsule will continue to slow until it reaches terminal velocity or smacks into something. In the real world, of course, we prefer that the astronauts live and eventually drogue chutes and a main parachute deploy to facilitate a safe transition from the aerobraking regime to hydrobraking or lithobraking, but the spacecraft coming from low-earth orbit has shed about 14,000 knots of airspeed without a parachute before that happens. The fastest Apollo re-entry slowed down by over 21,000 knots before parachute deployment! Now looking at lofting missile, we have a similar scenario. As the aircraft begins its terminal dive, it might be going Mach 4+ because the motor with a thrust of ~17000 N pushed it up into thin air and accelerated it that fast, but as it gets into thicker air the force of gravity acting on the missile (about 3000 N for an AIM-54A/Mk60 after motor burnout) remains constant while the drag force grows dramatically. The missile is above its terminal velocity for this entire phase of flight, and thus it is slowing down the whole time even though it is falling.

A quick question for heatblur - how close does the current model track the CFD work that NASA did for their AIM-54C based Phoenix Missile Hypersonic Testbed proposal back in 2007? I know some of that is probably hard to make out due to line width and resolution limits - I zoomed in on a local copy, and from what I can make out the launch parameters for both the High Speed and High Altitude tests are Mach 2.0 @ 55k feet. What's most interesting to me is that the shape of the curve for the NASA "high speed" simulation, which follows a conventional loft trajectory, is very different from that shown above from both the CFD that Heatblur commissioned and the current in-game performance. I'm not saying this is indicative of a flaw in the Heatblur CFD or the in-game AIM-54, btw - the major driver of this is probably the different nature of the tests/simulations. In the Heatblur-commissioned CFD run and the in-game test, the missile is holding a constant altitude of 12km/~39k feet and thus has an angle of attack that starts out small and grows with time-of-flight/distance as the slower missile needs more AoA to generate enough lift to maintain altitude, which in turn creates more drag and quickens the shedding of velocity/energy. In contrast, in the NASA CFD "high speed" scenario the missile follows an optimal-or-close-to-it ballistic trajectory, maintaining approximately zero AoA the whole time, keeping drag lower and thus shedding energy faster. It would be interesting to see how the -54Amk47, 54Amk60 and 54C in DCS do in this scenario.

My understanding per some other documents was that 21g was accurate for the -54A and 25g was accurate for the -54C. I'd have to scrounge around to find my source, though - off the top of my head I think it was the FY80 or FY81 DOT&E report. And of course, who knows how accurate the unclassified-and-uncontrolled documents are for this sort of thing.

It'd be cool (but impractical) to tie this to liveries. Eg. if you're in a VF-41 livery you get "Fast Eagle XYZ", if you're in a VF-84 livery you get "Victory IJK", etc where XYZ and IJK are autogenerated numbers in the plausible range. A man can dream!

According to the publicly available draft of the 1998 Navy Training Systems Plan/N88-NTSP-A-50-8511B/D, LANTIRN on the -A requires the PTID (relevant text in red):

To expand on this point, the AMRAAM has a sectional density of ~6.8 at launch whereas the Phoenix is around 4.6 at launch. After motor burnout it's something lower, of course. Sectional density is one of the major drivers of a given object's ballistic coefficient, which determines how well it maintains velocity going through a fluid at high speed and low AoA. It should also be noted that there are (engine/API-imposed?) limitations to fidelity on the thrust side of the equation for all missiles. Eg. ISP is not a constant for a given fuel type IRL, but rather it is also a function of nozzle design and external absolute pressure (and thus, in an atmosphere, altitude). That being said, probably every air-to-air missile in the world with a solid-fuel motor has a nozzle optimized for low altitude performance, where the change in ISP over the range of realistic altitudes will be minimal.

Did everyone catch the look on Bio's face when Fun told him that RWS in the APG-71 was a useful mode?