toilet2000

You're comparing a Mirage 2000-5 or 2000D, not the same at all. The Mirage 2000C is actually a nowadays very outdated 4th gen. It's definitely better than the F1 (a 3rd gen), but it does not get a radar "as good as it gets" other than AESA. It's actually a very limited (for a 4th gen) radar. The RDI has a mix of analog and digital radar scope, with only a single target TWS mode (PSID, poursuite sur information discontinue, or a pseudo-TWS with a single target tracked while scanning for hits). The Cyrano IV of the F1 actually has a similar mode, yet much more rudimentary. It has limited target filtering with a lot of false contacts. Its AG radar modes are very similar to the Cyrano IV of the Mirage F1, albeit with a AG ranging mode (which the F1M with the Cyrano IVM will get). But to be noted, the RDI is a Pulse Doppler radar whereas the Cyrano IV is a Pulse and MTI radar. It also does not "carry most, if not all, of the precision weapon in the Western arsenal", only LGBs which it doesn't have any onboard designation (or even search and track) sensors. It has a basic CCRP/CCIP/CCRP-VP bombing computer for unguided munitions (rockets, GP bombs both in LD and HD, cannons, cluster bombs and anti-runway Durandals). Its AG weaponry is very similar to the F1 actually, but with the more modern touch of having CCIP/CCRP. For the AA weaponry, it's also very similar, with Magic 2s and Super 530D (much, much better missile than the EM R530). Other than that, it gets an INS (non-GPS), a much superior RWR and Jammer suite and allows for installation of the D2M rear-facing missile warning system, although it was not mounted IRL and those were kept for the 2000Ds. It's also a delta wing and has a full FBW, giving it very good maneuverability. Otherwise, the upcoming F1M will most likely be very similar in capabilities and weaponry (with the 530F instead of the PD guided 530D), albeit with less maneuverability and a worse engine.

You realize this isn’t a Doppler radar right? It’s an MTI radar and for sure there’s going to be clutter. The classic knowledge of MLC/SLC and the rest doesn’t apply the same to MTI radars.

It's pretty easy to see that it's not. Look at an individual point and you'll see that it's clearly not static.

Lots of differences. The F1 is not a ground attack aircraft at first, it's an interceptor on which was added unguided ground weapons. Also, the CE is a 1970s version whereas the AJS-37 is an early 1990s upgrade of a 1970s base aircraft. Notable difference: - Ground radar: AJS37 has more advanced modes with better details, including radar targeting. F1 has basic visualization and no targeting. - Nav systems: AJS37 has an INS with TERNAV automatic fixes, whereas the F1CE has no INS whatsoever. - AG Weaponry: AJS37 has both unguided and guided weapons, F1CE only has unguided weaponry. - AG systems: while the AJS37 has dedicated ground attack modes and targeting systems, including early CCIP/CCRP with radar ranging or nav ranging, the F1CE is all manual releases (no CCIP/CCRP). - Low-level navigation: the AJS37 has a dedicated terrain avoidance mode and radar altimeter with dedicated indications for ground collision avoidance, including on the HUD. The F1CE has none of that (including no radar altimeter).

Don't forget that it's the max attainable roll rate, not the roll rate in every condition. Not sure how accurate DCS is on that part, but it's something to consider when testing that. Loading up your F-16 with stores even in CAT I will most likely lower the roll rate you can reach, meaning it's going to close the gap between CAT I and III.

The UFC upgrade is not directly related to the Suite. Some very recent suites still add the old UFC, so it has no impact on the timeline done by RB. In the end, they said they'd be modeling both and you'll be able to choose. It wouldn't change anything about the avionics and its usage, as it's basically the same exact UFC in terms of usage, just with a different look and different screens.

Thanks a lot for the info! I figured there was some control logic that would apply here, but couldn't find any relevant info after a brief search. As you said it's indeed not a "feedback loop" as would generally possibly lead to unstable behavior, even though there is some information fed back, so AFAIK my speculation seems to still be appropriate, but feel free to correct what I said if you have more info or knowledge! We're not talking about being able to trim. We're talking about auto-trim. The F-16 FLCS auto-trims in pitch, meaning you don't have to trim in pitch generally for the aircraft to fly at 1G.

Don't want to derail it either but I figured this might be some info worth sharing: Basically, it's not because you have a model of something that it is easy to predict its behavior. A dynamical model (a missile moving through the atmosphere) is made such as there is no specifics on the output (range, altitude over time, speed over time, available g over time, actual g over time or whatever). You make a model, and you use that model to simulate the missile in-game. Outputs such as range are not the direct "outputs" of the model. This means that if you want to know the range of the missile, you have to do as you would with an actual missile: simulate it over time with the initial values and check the range against some criteria (range until available g falls below a threshold or whatever is needed for Rmax and Rne). Now this might be quick, but what makes it problematic is that the initial values can have a huge spread and be highly dimensional. Just think about it: the missile could be launched from anything from 0 kts to 1200 kts, from any altitude from -2000 ft to 50000 ft or more, from any launch g from 0g to 10g (or w/e), from any temperature from -60 to 60 C. Now if you want to infer the range from that while the sim is running, you'll have to generate look-up tables for those parameters, which are then going to be used for range estimation. This can be a time intensive process and it has to be redone every time something changes in the sim, be it the atmosphere model, the missile guidance parameters, the missile's FM, the missile's engine model, etc. Now I'll keep quiet and stop derailing this thread, sorry!

Since the question was somewhat already answered, I'll use some of my limited control theory experience to speculate on the reasons. I would think the same as you, but I'll add more possible details: Auto-trim means the control loop requires at least an integrator to get rid of the steady-state error (so that it actually auto-trims). Those are always used cautiously, as they can definitely deteriorate the transient response. From my limited research on the subject, the roll FLCS doesn't contain any feedback loop. This is generally done because as someone else said, the roll is stable but adding a control loop could lead to instability, especially so if for some reason there's an unforeseen delay in the control loop (phase margin) or a big perturbation (gain margin). An integrator makes it simply much more likely to happen as it removes 90 degrees of phase meaning you're already half-way there. All this to say, it would have drastically complexified the roll control system and made it possibly unstable, whereas it was stable to begin with (which was not the case on the pitch axis). This adds a ton of complexity to the stability analysis, especially given complex maneuvering as is the case for military fighters, and the F-16 was one of the first aircraft with FBW controls. There's generally a saying in control theory that anything straying away from the natural response of a system should not be done except if needed. IMHO this is the case for the roll-axis in the F-16.

That's not how complex dynamical system modeling works. Most often in these scenarios, there are no "analytical solutions" to a "perfect range equation" as the school system often implies when teaching math. They'd have to run their own sets of optimization/simulation scenarios and generate either a simplified model for range estimation or most likely look-up tables. Not to imply this is not an issue/bug, it definitely is, but it is not a simple as you describe.

Indeed, the TFR is housed in the Nav pod of the LANTIRN suite. AFAIK, you can not do both at the same time on the APG-70. You can easily alternate between both, and you can use a frozen image of the AG radar while the radar is in AA, discussed in this video:

Not at all. An IFF interrogator is a radar itself (called secondary radar, basically what ATCs use) and will generate contacts that can be then combined through MSI with radar contacts to generate tracks and their related HAFUs. As was discussed extensively before, IFF should be not only a contributor to the MSI picture, but actually a full-on sensor in itself. That's why you can steer and define IFF scan ranges on the AZ/EL page.

To add over @Frederf 's very good answer, the very basis of an INS is integration of multiple state data sources with varying degrees of accuracy and precision. This is generally done through state estimators/filters (with the most widely used family called Kalman Filters/Extended Kalman Filters), which allows the estimation of the state (such as the position) coming from multiple noisy data sources. I'd recommend reading on those if inertial navigation systems are of interest to you, but the details of it doesn't serve a real purpose in DCS though! :)

What information? There is not a single document describing that behavior. Also, there is not to my knowledge a single ground radar acting this way in any aircraft. And finally, it makes 0 sense to do so because that means for a significant amount of time, the designation cross is pointing at a location that does not fit at all with the actual designation. Anybody with knowledge of sensor systems and HMI knows this is a big no-no and a high risk. By 2005 such a behavior (if it existed to begin with) would have been fixed. Also, it makes the AG radar unusable in anything but freeze frame because it is impossible to know how much to move the cursor otherwise. There’s a reason why Wags couldn’t do it without freeze and active pause in the video. As Northstar linked, there is a ton of evidence to the contrary.

Well, you’re absolutely right but this is 100% not correct as-is indeed. See the JF-17 for a correct implementation. The current implementation makes literally 0 sense.

That's a wrong implementation of the slew action. It's a bug and IIRC it was already reported a long time ago.

TSE is basically the core of a ballistic computer. Aiming at a point and getting the range to it with the LRFD should be used in conjunction with the INS to allow the weapons to compensate for the aircraft motion AND the target motion (if you're tracking it via the upcoming IAT or manually). Right now the gun for example will adjust for range, but any type of motion will lead to rounds falling short, long, left or right depending on the motion. TSE should eliminate that.

Resolution not changing does not imply the same return intensity. If the return is very dim at 10 nm, you won't see it at all at 40 nm. SAR is not magic.

Most likely you have an axis bound to the radar elevation and it stays at 0, preventing you from zooming in.

For datalink, you need to press the UFC DL button twice to select Link 16 (once gets you Link 4 for ACLS), and then press ON/OFF to turn it on.

Choosing with WEP selects the right channel and the right pylon to configure on the SMS. Even without a label, select the OSB where the SLAM option would be in the WEP menu still sets the DL channel to that station.

Why would you use SteamVR with an Oculus headset? SteamVR will just eat performance and do nothing more. Use the native Oculus SDK as it is available in DCS. Don't even need OpenXR. Actually running the Oculus SDK implementation with vrperfkit will further improve performance over OpenXRToolkit + its implementation of foveated rendering.

Indeed, it's been doing that for a long time. Everytime the server browser UI refreshes, there's a huge lag spike, as if the UI thread was waiting for a long time for some background thread to sync up.

Yeah that ITAR excuse is really just an excuse. There’s hardly anything done by ED that doesn’t use ITAR covered info. There’s really nothing wrong with knowing ITAR covered information. The issue happen if you are a US person sharing and exporting with non-US persons. There’s nothing illegal about having those document as a non-US person. ITAR is very different (and much more lax) than classifications. At this point it’s just used by ED because it sounds official.

That misconception comes from the fact that the ATFLIR was never really upgraded. The LITENING was first fielded in 1999 while the early ATFLIRs were in 2003 ish. Moreover, IIRC our LITENING is an early AT model (2003 ish), whereas the most well known LITENING is a 2008+ G4 with much better resolution. So for our Hornet, the ATFLIR is the better and more recent pod. For any Hornet after 2010-ish, the LITENING is the better pod because it was upgraded.