AIM-7M sparrow & the RWR
-
Took a quick look at DB and calculations.
Stock DB AIM-120 has a base chaff chance of 5%. Even in the best case scenario (notching and optimum range) this is degraded to 3,75%. So, it seems indeed possible to decoy the missile with chaff, but very unlikely.
And, indeed, even if the missile baits the chaff, it re-locks into the aircraft straight away.
Can you gues why I increased for testing the chaff chance value to 0.99 (and sometimes even more because of code built range dependency which is explained in RP5 manual)?
-
Keep in mind that MANY things of the RP5 manual are no longer applicable to BMS. And also that some values of the DB are not used the same way, or maybe even not used anymore.
-
Keep in mind that MANY things of the RP5 manual are no longer applicable to BMS. And also that some values of the DB are not used the same way, or maybe even not used anymore.
I know. Because of issues I cannot check the validity of ARH distance effect but for SARH and IR also seems to me still valid and was valued in all other previous Falcon before BMS4.
-
Shadow - It’s called a catch 22, screwed if you do and screwed if you don’t. Possible to get back on track of the original question now? Was it solved enough to your requirements Cik?
-Babite -
Hi Molni
I checked this a little deeper and indeed that is correct, ARH in BMS will not bite a chaff, or to be more exact they will bite it but then will drop the lock on the chaff and reacquire the original target, just as Ahmed described above (and also sent me a Mono print of the same).
But that said, this behavior in BMS is there by choice and it’s not a bug, if you like you can look at it as an uncomplete code. The AMRAAMs behavior in BMS isn’t the same as in other/previous versions of Falcon and it’s much more advanced, and the decision was to leave CM out of the game for it because it doesn’t makes sense to use for such advanced code the old “dummy” behavior of biting chaff only based on some chances and other DB numbers. CM is a more complicated topic to be based only on such dry numbers. And also, as noted above by Raptor, RL AMRAAMs will probably not bite on chaff because of sophisticated signal processing improvements, so in fact the current reality in BMS isn’t that far away from RL, and actually more accurate than other/previous Falcon versions.
Now, I see your point for other ARH types. But since the AMRAAM is the main ARH missile in Falcon, it won’t hurt to keep it this way. AA-12s probably also have some advanced signal processing to take care of CMs, so I guess the main issue here is with AIM-54s or other simulation of the older days. No big deal the way we see it. Maybe there will be some change for this missiles specifically, and maybe not. But from our POV everything is fine and realistic the way it is today.
-
as noted above by Raptor, RL AMRAAMs will probably not bite on chaff because of sophisticated signal processing improvements, so in fact the current reality in BMS isn’t that far away from RL, and actually more accurate than other/previous Falcon versions.
=> Speed rejection (CCM) making chaffs ineffective.
-
Hi Molni
I checked this a little deeper and indeed that is correct, ARH in BMS will not bite a chaff, or to be more exact they will bite it but then will drop the lock on the chaff and reacquire the original target, just as Ahmed described above (and also sent me a Mono print of the same).
But that said, this behavior in BMS is there by choice and it’s not a bug, if you like you can look at it as an uncomplete code. The AMRAAMs behavior in BMS isn’t the same as in other/previous versions of Falcon and it’s much more advanced, and the decision was to leave CM out of the game for it because it doesn’t makes sense to use for such advanced code the old “dummy” behavior of biting chaff only based on some chances and other DB numbers. CM is a more complicated topic to be based only on such dry numbers. And also, as noted above by Raptor, RL AMRAAMs will probably not bite on chaff because of sophisticated signal processing improvements, so in fact the current reality in BMS isn’t that far away from RL, and actually more accurate than other/previous Falcon versions.
Now, I see your point for other ARH types. But since the AMRAAM is the main ARH missile in Falcon, it won’t hurt to keep it this way. AA-12s probably also have some advanced signal processing to take care of CMs, so I guess the main issue here is with AIM-54s or other simulation of the older days. No big deal the way we see it. Maybe there will be some change for this missiles specifically, and maybe not. But from our POV everything is fine and realistic the way it is today.
Ok, in this case I understand the difference, but as you can explained this prevents customization and even the most older and most advanced has the same total immunity which is quite a strange abstraction.
I’m mechanical engineer therefore I do not know so much about EW but pls explain the following. How can it be that much more advanced and complex and powerful airborne fighter radars can lost easily the target because of chaff, beam and ECM the lock or even tracking in TWS can be broken but much smaller ARH radars in totally immune to any EW counteraction…? How can be validated an accepted such abstraction…? In this case why is not replaced airbore radars with the seekers of AMRAAM…?
-
-
what about if you are dropping big clouds of chaff behind you in a shallow dive, masking you from the missile LOS?
-
Chaff are small wire of steel/aluminium cut at pre defined lengh. Each lengh is for a given wave form (freq) … if the radar is smart enough and agile in freq, it can adapt its freq and simply see throug the chaff cloud (like X-Ray passing through a wood door) … this one of the reason most new generation radar are nearly immune to chaff.
In addition, some other CCM like speed rejection … etc …
-
you need to be a lot more agile in frequency than I suspect capable of a missile seeker to ignore the chaff cuts. Chaffs for self protection are cut at a variety of lengths because of this.
Sure, if your missile seeker is an L band radar, its not gonna be affected by SP chaff. Its also gonna have such a large radar resolution cell that it would be totally inappropriate for target tracking.
what about if you are dropping big clouds of chaff behind you in a shallow dive, masking you from the missile LOS?
This is actually a bad situation for the reason DeeJay mentioned earlier - if the Chaff is released while you are in a tail aspect to the missile, the chaff will slow down very quickly (it will do this regardless of WHAT aspect you have), and the missile seeker can disregard it and re lock you. Doppler filter on a monopulse radar. However, if you can maneuver out of both axes (horizontal and vertical) from the radar, it will have a harder time finding and relocking you. If you maneuver in only one axis, the seeker should be able to relock you significantly easier.
Now, if you chaff while beaming the missile, there is no doppler frequency shift from you relative to the chaff return, and the missile seeker cannot filter it as an invalid return based on frequency. So in short, against any missile seeker that can differentiate target velocity, chaff is much less effective in aspects far from the beam. However, your RCS in a beam aspect is larger than at a quarter aspect, too.
-
Quote Originally Posted by I-Hawk View Post
Hi MolniARH in BMS will not bite a chaff, or to be more exact they will bite it but then will drop the lock on the chaff and reacquire the original target…
But that said, this behavior in BMS is there by choice and it’s not a bug… And also, as noted above by Raptor, RL AMRAAMs will probably not bite on chaff because of sophisticated signal processing improvements, so in fact the current reality in BMS isn’t that far away from RL, and actually more accurate than other/previous Falcon versions.
This is exactly why i said, that chaffs are not “ultimate countermeasres” and why i only use them at very specific times. I.e. if i displace my position with jammers in order to deny an early enemy radar “burn-through” or “lock” … or to break enemies missile early from the rails (considering it was timed well) … or if ARH is about to pass my 3-9 line (or tail) very close. There is no point in pumping chaffs (or even flares) continiously out at wrong times !
This idea that chaffs act as “beacons” for missiles at all times - and this granted - might be a misconception from “other” sims … nor is it a good idea to “mod” those performances without understanding the background logic behind it in Falcon.
-
I’m mechanical engineer therefore I do not know so much about EW but pls explain the following. How can it be that much more advanced and complex and powerful airborne fighter radars can lost easily the target because of chaff, beam and ECM the lock or even tracking in TWS can be broken but much smaller ARH radars in totally immune to any EW counteraction…? How can be validated an accepted such abstraction…? In this case why is not replaced airbore radars with the seekers of AMRAAM…?
Well, I’m an electrical engineer and I do understand some about signal processing and radiation, but still I don’t have the knowledge to tell you much more than what I can guess. But 2 things I can think of, (1 Range - AMRAAM seeker work in relatively short range than AC radars. (2 It may very well be that AMRAAM radar has a better CCM capability simply because it has better HW/SW to deal with it than “normal” AC radars. If I’ll take an analogy from PC HW then it may be like comparing a CPU to a GPU, CPU is more general purpose HW and can do a lot of things better than GPU, but will be much slower to do specific GPU operations because GPU is dedicated HW. So the AMRAAM might as well have more dedicated equipment to deal with CMs because simply losing track suddenly for it isn’t the same as AC radar losing track momentarily.
But this are just guesses, I don’t know the real differences, maybe someone else can shed more light on the subject.
-
nearly immune to chaff and 100% immune are two different things - i think molni’s issue is that this ‘nearly’ doesnt actually exist as a result of a bug (which would make sense - if you make them supposedly 100% susceptible yet they still always track without a problem, it does indicate a problem). while we can all rationalise this away whatever way we want, its still rather disappointing that this fundamental part of EW/ECM modelling is flawed in BMS wouldn’t you say?
-
If I understood I-Hawks post, he said that they didn’t want it to loose track by chaff based on a random number. That it had to be more to it?
-
nearly immune to chaff and 100% immune are two different things - i think molni’s issue is that this ‘nearly’ doesnt actually exist as a result of a bug (which would make sense - if you make them supposedly 100% susceptible yet they still always track without a problem, it does indicate a problem). while we can all rationalise this away whatever way we want, its still rather disappointing that this fundamental part of EW/ECM modelling is flawed in BMS wouldn’t you say?
Oky.
And now what? … are you suggestion to rewrite the AHR code (which could delay the project by 2 weeks to 6 months or more) for a possible 0.1% of chaff chance?
-
Oky.
And now what? … are you suggestion to rewrite the AHR code (which could delay the project by 2 weeks to 6 months or more) for a possible 0.1% of chaff chance?
You simply take away the freedom of 3rd party developers to set and model whole class of AAMs. Sorry, but somehow I’m not able to be happy hearing this news…
-
nearly immune to chaff and 100% immune are two different things - i think molni’s issue is that this ‘nearly’ doesnt actually exist as a result of a bug (which would make sense - if you make them supposedly 100% susceptible yet they still always track without a problem, it does indicate a problem). while we can all rationalise this away whatever way we want, its still rather disappointing that this fundamental part of EW/ECM modelling is flawed in BMS wouldn’t you say?
Well, you can look at it as flawed, and you can look at it as an unfinished feature of a total AIM-120 upgrade in BMS. The easy way is to think of it ~same as why we didn’t implemented IFF till now or why JSOWs in 4.32 are still fake version of Mavericks. The answer to all is one - Unfinished code, and we choose to leave it this way and fix/finish it when there is more time for it, rather than just “fix” it same as code was working before (same as older/other versions) which is pretty poor solution for what should be a pretty complex simulation of the real thing. This is our choice to leave it like that until we fix it in a real way and not just to make someone happier. Maybe people aren’t noticing the small details, but in BMS things are being done as close as possible to reality (Of course in the limitation of knowledge), that doesn’t mean that everything is perfect, far from it, but we try to do things in a real way and not just “fix” things which are problematic.
And BTW, the real chance is probably pretty close to 0 anyway, so total 0 isn’t that different
-
You simply take away the freedom of 3rd party developers to set and model whole class of AAMs. Sorry, but somehow I’m not able to be happy hearing this news…
Yes Molni, BMS is focused on the BMS DB and mainly on current F-16 block 50/52, all else is bonus and this is how it should be treated.
-
You simply take away the freedom of 3rd party developers to set and model whole class of AAMs. Sorry, but somehow I’m not able to be happy hearing this news…
Prioritize.
Considering the low chance of deafeating an AHR AD with chaffs making curent model not as off as you might think … Does it worth to delay the release by several months? (Maybe something enhance for the 4.34 … But how and based on what exactly: it will have to be defined.)
And what is the point if 3rd party dev can never finish their work because of endless core code update invalidating previous works. Because the biggest problem that you have to face is not the fact that ARH might be buged … but rather the fact that all your loooong work will have to be restarted from scratch as soon as the 4.33 is there … And probably also when the 4.34 … Etc …
I-Hawk is right, while giving the possibility to 3rd party to adapt create and make changes, our work is not foccused on 3rd party accessibility. Some of us (not so much) are even for a DB lock (including me I must admit) … But this is not about to happen, do not worry.