Swift.

Just to put some visual examples up for everyone: Clip showing HUD FIX used whilst GPS is active. It can be seen that the jet doesn't take the full update because, as vader says, its just feeding into the kalman filter and so is blended into the existing solution. Clip showing HUD FIX used without GPS. It can be seen that the jet takes the full update and that FIX is working as first demonstrated in Wags' video. Clip showing a 5x time accelerated 1hr orbit of a target. It can be seen that the inertial position varies from the true position as expected, but it can also be seen that the GPS is holding the inertial solution roughly on the true position. The maximum error observed was about 18m and was seen only briefly. For 90% of the time the inertial solution was within 10m of the true position. Giving an approximate CEP90 of 10M/33ft horizontally. I would love to see if anyone has a track/video of this alleged 200ft disagreement between inertial and true position. As I haven't been able to reproduce that condition.

Alright, I'll try and see if I can replicate this. Thanks for the info

Do we know what the precise mechanism of this bug occurring is? I've seen it happen myself but seemingly quite randomly. Is it when any new PPLI is created after your own jet has started up? ie if a player joins after you?

The interesting question would be whether that switch controls receiver functions or just the transmission power. Because false alarms are a processing function on the received radiation. So even if nothing is being transmitted, so long as the receiver is still receiving noise itll still show false alarms.

https://www.globalsecurity.org/military/library/policy/navy/ntsp/jhmcs-d_2002.pdf I think this will show what I'm talking about.

As I recall the uplook reticules are a different projector. Which is why they never change shape or size. Only turn on or off.

Do you know which F-16 manual you saw that in? The ED one doesnt seem to describe that behaviour.

If the pilot has two bags and bombs, and then drops all the bombs as you describe, he should be in CAT I. So the light illuminating to warn him of that fact is correct.

I'll need to sit down and run some tests myself then. He executed a 4 minute test, which is not exactly long enough to see a trending behavior over time. Especially considering the first minute is spent acquiring GPS signals. Do this test yourself, put yourself in an orbit for a long enough time, lets say 45 mins. And observe how the positional error never exceeds a certain amount but rather wonders around the true location.

The GPS is fixing the drift, its just the GPS is noisy enough that it still induces errors. I've been trying to find some videos or such of an equivalent situation in real life so we can report any errors in magnitude of the effect. But pretty much everything I find is for an EGI jet, which is clearly going to perform better than what we have.

I'm not ED, I'm just trying to explain to you what is happening in the SIM because you appear to have questions. The decision between CAT I and III is not purely weight based. When you look at some references for this, you'll see that there are odd behaviours with different combinations. ie TGP+CL tank is CAT III, TGP+Wing tanks is CAT I. I appreciate that it's confusing, which is why I tried to help out by making that flow chart to clear up what it seems is happening in the sim.

@bladewalker Remember in you testing that FA-18 hasn't received the new GPS simulation yet (unless I've missed something in the changelog). So if will for sure behave differently to F-16. Also remember that our FA-18 should have a full blown EGI, rather than the 'rudimentary' INS+GPS that our F-16 should have. So even when both are fully modelled, they shouldn't be behaving identically.

To my knowledge, the purpose of the CAT thing is an aerodynamic limitation, not a mass or G limitation. Which is why it limits AOA and roll rate, not max G. So that the bags weigh more than the harm is meaningless. The 4 sidewinder loadout you have is interesting, because I'd have expected that to be CAT I as per the tested logic. Perhaps its not '6 AAMs' but 'AAMs on all the underwing pylons'. And as for the last image, you don't have wing bags loaded. So as per the logic I posted previously, that makes it CAT I. Please provide any tracks you have of that 'firing 2 AAMs' occurrence you mentioned. I would be curious to see if the missiles being fired are from the wingtips or from the pylons.

Ah I see, so you are saying: 2 bags with nothing else = CAT I 2 bags with AA weapons = CAT III My understanding is the logic between I and III is more complex than just bags and bombs = III. So it would be good to know what specifically you are loading on the jet. For example 6 amraams and two bags would be CAT III, but 2 amraams and 2 bags would be CAT I. Edit, did some testing in DCS and this seems to be the logic for warning light illumination:

It works, but like all measurements there are tolerances. You can't expect to be hitting the exact atom you planned for, IRL or in DCS.

There are different effects at play here. What ED have done is a CFAR. What everyone else seems to be talking about is sidelobe ground returns. The former is why you see false alarms whilst 'high'. And the latter is what you see in that video and what is obvious in razbams modelling. What ED have done is 'accurate', but just incomplete. Once we get sidelobes modelled, we should start to see more like what you all seem to be expecting.

What about ECM? I dont think that has any weighting to false alarms.

Are you saying that its prompting you to select CAT III when you load 2 bags on the ground. But its prompting you to CAT I instead if you drop bombs but retain 2 bags in the air?

It might be that you also mentioned a bug with CCRP in this thread which was user error as you identified. Keeping it one bug per thread will prevent this type of hiccough. As to your original bug, I am unable to open your track file (not sure whats wrong with it). But I suspect what you are experiencing is the new GPS+INS modelling: ED have added appropriate positional errors to the GPS and INS simulations and applied a kalman filter logic, as the real jet uses, to combine the two systems. In short a GPS derived position will generally be in the right area, but will have a lot of jitter and uncertainty. Whereas an INS derived position will be smoother but can drift away from the actual location. Combining the two you end up with a smooth location that is generally in the right area, but as you are experiencing it can sometimes be a few metres away from the actual location. NB. remember that our jet doesn't have EGI, it has a more primitive INS+GPS which is why you might have been expecting a better performance out of the system?

Yep and you'll find in that book too, it mentions CFAR. Edit, in fact if you turn to page 144, you'll see it mention: 'In radars for fighter aircraft, for example, a false-alarm time of a minute or so is generally considered acceptable.'

Im pretty sure they are trying to model Constant False Alarm Rate (https://en.wikipedia.org/wiki/Constant_false_alarm_rate), rather than the 'birds' you'd see on something like the Razbam radar modelling. So perhaps not 'unrealistic' just not what you were expecting. See also: https://www.radartutorial.eu/01.basics/False Alarm Rate.en.html

Im curious where you are getting your info on for this. Because that is not what literally everything I've ever read on this says. Absolute = At GPS acquisition, GPS pos is compared to INS pos and INS pos is updated to match. Meaning the weapon will hit the target location as the GPS sees it. Relative = At GPS acquisition, GPS pos is compared to INS pos. The offset between the two is stored and applied to the target location. Meaning the weapon will hit the target location as the INS saw it prior to GPS acq.

With JDAM, you have to remember that Absolute targeting and Relative targeting are a thing. Absolute being what you describe where you program known coordinates into the bomb and it will fly to those exact coordinates as best it can (ie using the alignment transfer from the jet until it can get its own GPS fix, where it will correct any offset). Relative is what we have in DCS, where you use an aircraft sensor to generate coordinates to feed the bomb. The bomb will then in effect fly to that location (relative to the aircraft, hence the name). And wont correct any offset at GPS, but will maintain it (ie not allowing any more drift). They are both 'correct' and both have their uses. We are just missing the Absolute mode from DCS currently, so we experience the pain of having the INS errors carrying over the alignment transfer and causing issues on preplanned coordinates. In viper the mechanization should be Relative when CZ is shown (ie cursor slew has been applied), and Absolute when CZ is removed (ie no cursor slew).

Remember that the viper we have doesn't have EGI. So its not a 'full fledged INS + GPS combined'. I'm not quite sure the specifics, but it could be something like our viper takes a GPS fix every 60 seconds or something, and that would still be 'INS + GPS', but would clearly allow for 60 seconds of drift between each fix. Additionally, GPS isn't perfect. There is always an error, the shape of that tolerance zone will change based on where the satellites are in the sky, but it always exists.

That seems quite low for this type of munition. Have you tried pushing it to the upper extreme just ot check function? ie does 3000ft burst height work? It's possible the weapon is functioning too low for the vertical velocity it has, and the skeets are hitting the ground before they can deploy.