Muchocracker

Cant't really help you if you don't give us trackfiles showing what you're running into. Check your scan volume in azimuth and elevation to make sure the target is within the frame. Reduce the azimuth setting to decrease the frame time and get more hits to build trackfiles at long range. And use the correct PRF for the target's aspect. I use the radar mutliple times a week and have no problems detecting and tracking fighters at +60nm.

It absolutely does. For DPCA and thus STAP to work. It requires many different receiver channels (commonly done at every single antenna element) and digital beam forming to process and filter the main lobe clutter by weighting normalized dopper and look angle. Thus requiring a phased array antenna. The difference is the SU-27's IRST is not a fully integrated sensor into a unified trackfile processing architecture. It can't use it in the same way the F-35 can.

EOTS, DAS, RWR, and MADL donations all contribute weapons quality track data to its closed loop sensor fusion

I think you misunderstand how these fuses work -The Mk-339 is a mechanical time clock fuse that functions based on time from release. PRI and OPT are just 2 different timing sets that can be chosen. -The FMU-140 is a radar altimeter proximity fuse with a secondary time of function. VT1 is rad alt, VT2 is time function. Your problem is not with the accuracy, your problem is with their spread. Which you can change by editing the fuse settings to either burst lower (VT1) or by setting a longer function/release them lower. Not comaprable weapons in the slightest. The 97 and 105 are sensor fused weapons with heat seeking submunitions, of course they're going to be more effective. The 99 and rockeye are not designed for killing heavy armor.

This is evidently not true anymore considering the update some months ago that allows it to reach upwards of 60 AoA now.

And that's what makes it so powerful.

It's still very much an issue with AESA's, no radar is immune to main lobe clutter. But being a phased array it's afforded some advanced processing algorithms that you can't get with mechnical types. Space Time Adaptive Processing as i understand through the limited reading i've done on it significantly reduces the minimum detectable velocity around the main lobe clutter. (makes the notch window extremely tight) Can't really just do that either, By scanning at very high rates you cut your dwell times significantly. That reduces the amount of pulses on target, and reduces integration gains. It would be a huge step back in the radar simulation in doing so.

What is ED's information. Because there is zero documentation of the amraam's TDD on the internet. I can't even find out what designation it has

TEF and Aileron scheduling in HALF and FULL flaps configuration has been a problem for ages. Best practice is to drop to HALF below 200 knots. Then select FULL at 160 and lower. It'll stop the ballooning.

post a track

They show as unknown if there is no offboard correlation.

just because the radar works out to that range, doesn't mean it's actually tracking and shooting you from that range.

only if you're using Pre-Planned with the manual lat-long input. It doesn't care about the jet's current selected format in TOO

Yeah i dont ever remember it working for SRS I balance my pri and aux to full left/right to know which radio i'm transmitting on.

could be a control gain issue, entirely speculation on my part tho. I havent looked at the files for it or know how they schemed the autopilot/guidance.

6 years ago bro

When you make the handoff to the selected JDAM that information stays on your HUD as it's the steering release cues for that bomb. When you undesignate you're removing the aircraft's designation. They are 2 separate things but they're going to share some symbologies. to remove all of it you have to switch to a JDAM with no handoff information, deselect jdam's, or hit the erase jdam option to wipe the info. To update the handoff information on the bomb you have to do another handoff. Which is by TDC depress, or by creating a new designation.

As it says. It is the transmit power of the MIDS terminal

You have to designate and step to the next station and designate for the first 4. Which will input into TOO1 with no additional work. You then have to switch to TOO2 and designate, switch stations and select TOO2 then designate for all 4 stations. Then when you drop. You pickle the first 4. Then on the 5th swap to the OTHER TOO preset, pickle, then do the same thing for the other 3 stations.

Yes. That is what the jet should be doing

That is the DUD cues being bugged and i believe has been reported previously, and it's a problem with a bunch of weapons. The SMS gets told what the timings are when the weapons codes are loaded by the ordinance handlers.

You don't have to. The Bombing computer accounts for it in both CCIP and AUTO.

You're still missing the forest for the tree's. As others have already brought up in this thread, plenty of old API AAM's are effected by the loaded barrel rolling maneuvers and have miss distances similar to the amraam (in its best kalman filter state which was before this last tuning change iirc). The common theme is all of them have sufficient warhead proximity fusing to make the miss distances not matter. We can debate all day of whether ED's decision to run head first into the wall of fully reverse engineering every single detail is the right one, but it's going to be pointless. The reality is this kind of maneuver is an actual challenge to solve for in the real world and it's already been an issue this whole time in DCS even before the new API. So we've been complaining about the wrong thing. I'm going to keep pounding the table on this proximity fusing thing because imo the real solution.

As maestro has already stated in this thread. The amraam is the only one directly effected by this because it's the only missile on the new API (besides the PL-12) Said new API seems to simulate almost every possible source of noise in the missile. It eventually adds up. - slight imperfections in the fin servo's that create inaccuracies in the readout of the position of the fin or in executing those commands (over/under deflects) - imperfections in the seeker gimbal servo's for the same reasons - inaccuracies from the seeker for any number of reasons like the range resolution, imperfection of monopulse's angle measurement, digital signal processing lags, automatic tracking lags like the range gate loops. There's a ton here that could contribute, we'd be here a while if i listed every one of them. - scintillation or otherwise known as glint phenomena that can radomly cause the seeker to think the target has suddenly moved 200 feet to the left from one pulse to the next. The Kalman filters that maestro mentions are there to smooth all of those noises out before it sends the final control inputs through the guidance autopilot. But those filters can also introduce their own lags depending on how its tuned and what weights it's given. It can be made super stable and resistant to noise but then it's sluggish to react to the target's true movements when they are rapid. Or it could be made more reactive but then those noise's have more effect. For better or worse the new API is what it is. It's excrutiatingly detailed in every possible way you can and can't think of. Like maestro has repeated it's not as simple as adjusting the kalman filter and the problem is gone entirely. And we'll just have to take his word for it that it'll never be. I think hobel and others are right that the proximity fusing is where the focus should be at. I for one don't understand why the proximity distance has to be so rigidly within the 100% kill radius of the warhead. A zero radial velocity trigger if the missile passes within a certain extended miss distance would be enough to at least cause some damage.

post track