toilet2000

A1-FA18C-742-100 011 03 p.4 paragraph 19 contradicts your point.

Both modules have been demonstrated as behaving very unrealistically by SMEs. What you find "messed up" has nothing to do with realistic behaviors. To the contrary, the modules that you find best are those that do not behave like proper helis. Examples:

My pleasure! Honestly it's not very user-friendly to not be able to undesignate, so I absolutely understand the question. That's also why I'm not sure this is accurate or simply a WIP artifact.

Oh I agree with not rushing it. I apologize if my comments could be interpreted this way. My goal was simply to point to the correct information. I agree that rushing it is a bad idea, both because as you said what is shared by users and such can be wrong, but also because ED's quick interpretation can be wrong too. Take your time, I think I do not only speak for myself when I say that as long as "it's getting there someday", I'll be here backing ED. I think most people that are passionate can be patient if it means getting the correct implementation some days. As long as we get the "we're aware and will be/are working on it" from ED, I am personally satisfied. Anyway, I'll stop derailing the topic.

I had a talk with Razbam's and their radar SME (which I assume is Galinette) told me through their CM that while the Doppler shift is great, the return in itself is pretty small. The radar does not only need a proper Doppler shift, but also a proper signal-to-noise ratio, which the very small heli blades do not provide according to the SME. So even though the signature is recognizable, the range at which it has a signal significant enough to be detected is quite low. I myself don't have any experience in that regard, but I was curious and asked around. Just a thing to consider.

For the second part, I might be wrong but I think you have to be in INR mode currently (not sure if accurate) to undesignate. You were in SCENE mode. Again, not sure how accurate.

As far as I'm aware, you were shown proper documentation (ie that Google Docs) for most of the claims in this thread, but otherwise feel free to browse the following documents (no links, no files, just names): A1-F18AC-FRM-000 A1-F18AC-742-100 A1-F18AC-746-100 If I missed something or I'm unaware of anything about it, please feel free to correct me. Thanks.

While I wouldn't say that it is "completely broken", there are a lot of areas where it is not accurate. Unfortunately, the available documentation is often refused by ED. I can understand that if you have "insider knowledge" of ED's simulation of the APG-73 radar, you might have a good idea of if it is accurate or not according to the developpers, but we don't have access to that information and unfortunately we never got (so far) the radar whitepaper that was discussed some months ago. As such, we have to assume from what we have as users: the available real documentation and the end product we currently use in DCS. Comparing one with the other highlights some significant discrepancies. Some examples: - Jammer/Radar Priority - Waveform selection (should be able to make an STT track appear as if it is guiding an AIM-7 even if it is not) - PVU - Velocity Search - Terrain Avoidance - RWS horizontal slewing - Integration of sources with MSI and the radar, including having a L&S track without radar, getting range source from MSI on an AOT radar track, etc. - Proper trackfile death model that does not rely on the display-only brick age-out setting. Again, I do not condone hyperbolas such as "completely broken", but I personally believe that more than "a few areas to tune" is left to be done on the APG-73 to be "mostly accurate". Hopefully these will be covered and implemented at some point.

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.