KlarSnow

Just one thing I wanted to note on this, in the outsiders view for the 110 mile shot, it states the phoenix topped out at 103,500 feet and travelled a distance of 72.5 nautical miles to impact the target. Note how closely the current AIM-54A Mk47 matches that. Tops out at 103,943 feet (103,500 for the real world) and travelled a ground distance of 74 Nautical miles to impact the target. That's.... quite close.

And here is what that looks like in DCS. I fired a 54C-Mk60 and Mk47, and then repeated with a 54A-Mk60 and Mk47 so you can see that all missile variants meet the performance. Fired in PD-STT. Only difference from the real test is the AI wont fly at 50,000 feet. Highest I could get the Backfire was 43600 feet. All missiles impacted with ~50 seconds of battery life to spare. 110NmPhoenix shot.zip.acmi 110NmPhoenix-A shot.acmi

Your missiles battery died 200 seconds in. You launched it at .8 mach, against targets that are going .6 mach. This is what the actual 110 mile shot profile looked like, from the Outsiders View of the Awg-9 weapons system. F-14 at Mach 1.5, Target at Mach 1.5

Get higher, get faster. If the targets elect to turn around, they aren't shooting you. Either way. Higher, and faster are your friends. You have a mondo radar that can see them well before they can see you, use it to get up to altitude and fast and shoot longer rather than shorter. Phoenix47C_cleansweep.zip.acmi

And all of those missiles are just below mach 1 when they impact as well. So again, what exactly is the point. The claim was can't hit a maneuvering target, that is obviously false. So now the parameters have changed to cant hit a smartly maneuvering target and its too slow when it does, and of course the AI is dumb so its not valid. So what would constitute a valid test. All that has been said here is the shots aren't valid for some reason because 1) the AI is dumb and 2) the missile terminates subsonic. If you get hit by a subsonic missile are you not just as dead as if it is supersonic? Basically this is a very silly deflection, either give an actual parameter for the missile to be tested against and why it is/isn't valid, or stop making nebulous claims like "can't hit a low altitude target". That is demonstrably not factual. In either case why is this a defining issue for the missile. I don't have any reason to believe the real thing should be particularly good or bad in this scenario, none of these results seem to be surprising at all. And how does this apply to whether or not the results Ironmike posted or the tactical utility of the Phoenix are reasonable or not.

And what missile would hit any maneuvering target at 2,000 feet AGL from 50 miles? Cause last I checked the AMRAAM cant do that, and the phoenix can. The point was not that it was the deadliest missile in existence, the point was that it had capability which is still unique to the Phoenix. Of course the bandits all could have immediately turned around and run away and the missiles wouldnt have hit.... but neither would an AMRAAM, or an R27ER, or an SD-10, or an R-77. None of those would have come remotely close to what the AIM-54 did in that shot. One of them did drag out and that missile did not connect. Again, Could any other missile in DCS fired under the parameters IronMike Presented do any better?

Just so we are clear here @DSplayerwhat they are saying there is the FILTER for MLC is removed, IE the piece of software that just nulls all returns that are in the MLC band. It says nothing about removing the actual clutter. What this allows is the target to get closer to, and/or compete with the clutter in the MLC instead of just auto dropping it because the radar is deleting/ignoring all returns there. the OP is correct this should not result in an unnotchable radar. Nowhere does HB say this, all they say is it makes it hold lock better and more reliably. It should be HARDER to notch (which it is) but not impossible (Which I have not tested to see if it is or isnt). There is a lot of confusion about this because MLC in respect to the AWG-9 means two things the Filter which is called MLC, and the Main Lobe Clutter itself, also referred to as MLC, which is always there in lookdown regardless of the filter being present or not.

https://books.google.co.jp/books?id=u4TDQLsLDtgC&pg=RA2-PA14&lpg=RA2-PA14&dq=M61A1+dispersion&source=bl&ots=55qvZUGTWY&sig=ACfU3U2nldSdATZ7rnMzCTdRKHkrnUGMTg&hl=en&sa=X&ved=2ahUKEwiHyarFnf33AhXaqlYBHXUMDws4ChDoAXoECBMQAw#v=onepage&q=M61A1 dispersion&f=false 4 mils for the gun itself. There is a difference between the spec and what actually happens though as depicted in the image below from that article. Either way the actual bullet stream is definitely tighter than 8 mils, where the center of that bullet stream is located however may wander based on the mounting. l

By default every detection is multiple returns integrated in these cases. Scan rates are determined by a requirement to have a certain number of pulses hit the target as the sweep goes past. These pulses are then integrated to determine if a detection occured. So in a very straightforward system 2/3 pulses that return = a target = displayed on the scope. If only 1/3 show a return, then it is assumed noise. If you slow the scan rate down (or increase the pulse rate) you increase the number of pulses getting integrated, thus increasing your SnR. This is why STT minirasters can acquire at longer range than search, instead of a search sweep only getting say 3 pulses on target as the beam sweeps past, in STT it sweeps back and forth inside its beam width, so in a second 50-100 pulses illuminate the target. Getting 30/100 pulses returning may well be enough to establish and hold a track, whereas in sweep you may have only had 1/3 returning. The other advantage here is that in STT your cursor placement and a previous hit (if one exists) pre-sets the range, velocity, and azimuth gates and helps the radar solve ambiguities (start in the PRF without a blind zone at the cursors range, ignore ambiguous returns that are at the incorrect range or velocity from the cursors position etc...) Spotlight is an inbetween, and the specifics may vary jet to jet, the highlight is it very quickly illuminates (think many quick re-rolls on the probability of detection dice) an area of interest, if you just do the math, with every single pulse being even on detection. In a normal RWS or TWS sweep where the target is illuminated every few seconds, that means for example if you are at a range where the Probability of Detection is .3, then you are getting a single return every third sweep. THat may result in an intermittent contact that fades before it can update, or you just arent getting enough hits as the beam revisits to even make a contact show on the radar. In spotlight in the same amount of time you will have many revisits, this is really the primary purpose of spotlight, you have a cued search, which you can center around an intermittent or weak return, and then very quickly potentially get several hits which you can then transition into a track (STT) mode.

It honestly isn't really relevant, Like this is all stuff that happens well after the missile is kinematically done and has no chance of hitting anything that isn't flying at the missile and trying to run into it. IE from a gameplay perspective the simulation could just let it go dumb once it hits these kinds of slow speeds, so the "realism" of it is just extra. IE I don't know if an AIM-9B can do that kind of thing, and it really isn't all that much again, think of a plane, when you are at max AOA at 100 knots, can you unload and point your nose down instead of up? That's all the AIM-120 is doing here, Its just loaded up in a turn, so it unloads and then loads up in the other direction. Any thing that has an AOA limit should be able to point its nose within that limit regardless of speed (assuming it has enough airflow over its control surfaces to be controllable). The only way to improve on this is that IRL it probably would not be that stable at that AOA after the battery/autopilot system died, and would probably tumble out of stable flight eventually as transients made it pitch over a stable AOA, but again, I really see no point in modelling that in DCS since its quite a bit of extra work for a portion of the missiles flight that is incredibly irrelevant to gameplay. The much more important thing is getting the missile API good enough, and then getting all the older API missiles moved over onto it so they all have this kind of advanced 6DOF flight modeling going on.

Its not really stalled tbh its just at max AOA and slow, and as I stated even in a stall you can still move control surfaces and affect the nose of an aircraft, just look at the hornet, or the Mig-29 or the flanker, or really anything. Push the rudder from one side to the other ad the nose will fall off in that direction. Thats all thats happening here. IE just because the wings are stalled doesn't mean the tail is stalled. I think you are seeing this behavior in the AMRAAM because it is one of the only missiles on the new API that has a full 6DOF flight model going on. I don't think the older API missiles are quite there yet.

That very much depends on how the control actuators work. This is how ED has decided they work. There is nothing unrealistic about it. Non reversible gearing is a plausible thing in a fin actuator like this. I don't know if the real AMRAAM behaves like this after battery death, but I also don't know if the real thing doesn't behave like this. Both are plenty plausible.

Yes, they have done this for well over a year at this point in the AIM-120 IIRC when they fully modeled the flight controls of it. As it and the sparrow are the only missiles on the new API that models all of that, they are the only ones that exhibit that behavior. Everything else just goes completely neutral controls after battery death.

It did not reacquire, it just continued in the turn it was in prior to the battery death. Fly an aircraft at a constant AOA with the flight vector pointed up. Your aircraft will not remain pointed up if you maintain the AOA and turn your engines off. That is what is happening here.

The missile just locks its controls and continues turning as it was until it stalls out or hits the ground. IE the fins just stay in whatever the last position they were commanded to. You can see this in the tacview posted at the start of this thread, the battery is dead at 100 seconds of flight, and it just continues its turn falling to the ground. There is nothing remotely questionable about any of the physics at display in this tacview or any of what has been presented except the Sawwing back and forth that happens prior to the "physics defying" acceleration and turn. That to me appears to be a net lag artifact since this is not the shooters tacview. Other than that I dont have an explanation for why the missile did that. Its acceleration and deceleration and AOA performance all match what any object moving through the air should do.

I'm sorry but you cannot ignore the direction and pitch angle of anything in flight. That is ludicrous. If things are changing you are not in equilibrium. Its pitch angle is changing, its heading is changing. The tiny .1G here doesn't matter, we are talking about miniscule increases or decreases in drag here that are more than made up by gravity as it falls. Again the object is not in equilibrium so it will not and cannot remain static, once it has stopped changing its flight path, then it can sit in perfect equilibrium as you describe.

Until the highlighted line (flight path) stops changing, the missile is not in equilibrium, no matter what the AOA is. Thus it will change airspeed, up or down. depending on what that flight path angle is. Since it is changing and increasing its descent it must accelerate to reach equilibrium, equilibrium will be reached when that line stops increasing or decreasing and is steady.

This is why my first question at the start of this whole thread was we need to see more than just the graph and the telemetry, you cannot know anything without knowing what the flight path is doing.

Where it starts out Where it ends up

Here 1 l 2 3 4 5 Tacview HUD view of the missile in question during the time period in question. It is falling, its pitch angle is decreasing, so it MUST accelerate.

Or your flight path falls, and the gravity vector increases your speed. You are ignoring the affect that the flight path angle has on all of this. You cannot be in equilibrium if the flight path is changing. The flight path of the amraam in your tacview is changing, so it will change airspeed. If its flight path has a more upward component it will decelerate because its drag component adds to gravity, If its flight path has a downward component then that gravity is removed from the drag vector and added to the velocity vector. If it goes from going up to going down, it must accelerate. This is what the AMRAAM in your tacview does. The missile is NOT in static equilibrium as you are describing because its flight path angle (and pitch angle) continues to fall. Once it stabilizes, like it does around 195 knots after the battery dies, then all the forces are roughly equal and it will not accelerate anymore. You are removing the 3D component from all of this, just like you did at the start, you cannot do that, you must take into account the object going up or down and whether or not the flight path is changing or not. If it is changing, it is not in equilibrium.

The extreme example of this is what is the drag force of a stationary object. Zero. What is the AOA of a stationary object? Is the drag of a 5 Knot object the maximum it could possibly be? No its very low. Slower or higher AOA does not necessarily equal maximum drag. It depends very much on the situation, the aerodynamic properties of the object as Exorcet describes, and what is happening.

Yes, but that all only applies in level stable flight, the flight path is changing, so that will not remain constant. Again, the missile just before its airspeed gain was going up.... so gravity was decelerating it more than if it was in equilibrium, so it was NOT at terminal velocity, it than starts going down, so it will accelerate to regain that equilibrium, which in the instance you have shown, appears to be ~195 knots. Also there will always be transients, so no it will not sit at a static single lowest airspeed as it falls, it will vary around that equilibrium point. It is not in equilibrium until the flight path angle is stable vertically, the airspeed has stabilized, and the AOA has stabilized, once all that happens then it will be static. The missile at all of the acceleration points you are pointing out, is doing none of those things, so its airspeed will change. Again think back to throwing a rock straight up. When it reaches the apex of its arc, it is and always has been at the equilibrium of AOA, lift, drag etc... But gravity has slowed it down, none of its "AOA, or "Drag" has changed, but it MUST Accelerate because gravity is pulling it back down. This is precisely what is happening to the missile. You seem to be assuming that for the given AOA that the terminal airspeed of an AMRAAM in DCS is the lowest airspeed it reaches during its flight, again, point it straight up, its lowest airspeed will reach zero, so should it not accelerate as it falls off the apex? Or as you seem to be saying it must sit at zero airspeed and hover in the air.

Shooters client is law and always has been for any weapons employment, unless ED has changed that without telling anyone, its still like that as far as I'm aware. The issue with a non shooter track or tacview is that any network inconsistencies get magnified. Tacview does not have a great sample rate since it is deriving data from positional data essentially, so you can see artifacts related to that. IE a tiny wiggle can get magnified to a big AOA change due to net lag and then tacview interpretation. This stuff is not super precise for looking at the actual mechanics that are going on. Your best bet is always and has always been the shooters track or tacview. Server is next best, other client is third.

Again, that ten second period where it has swapped from being nose high, to buried nose low, you seem to be thinking this is an unexplained acceleration. If it was at the same AOA nose high, slowed down, and then maintained the same AOA nose low.... it should accelerate since it should have decelerated below the equilibrium while the nose was up. This tiny acceleration is entirely related to it re-establishing equilibrium as it falls, which appears (after the battery dies and it is completely ballistic) to be around 195 knots which it roughly holds until it impacts the ground. Again you would see this exact behavior in any aircraft that flew a similar profile. This is an object that is going up, curving over the top and then coming back down. It MUST accelerate if nothing else changes. If it didn't in this scenario then it needs to increase its drag, which it cannot do since it is already maxed out at AOA. The small dip in AOA which matches the nose swap fromright to left also corresponds with it building up a few more knots, this is also expected. As to the Nose of the missile snapping back and forth, quite honestly that looks like a net issue more than anything else, so I wouldn't pin that on any flight model issues, remember you are looking at "your" tacview, which is not what is generating the aerodynamics of this weapon and will have latency and potential innacuracies compared to the shooters tacview. I'll bet if you looked at the shooters tacview, that strange sawing back and forth wouldn't exist. Keep in mind the only "truth data" about what a weapon is actually doing is the shooters client, there can be significant network artifacts when looking at a track or tacview from a client other than the shooter.