AIM-7M sparrow & the RWR
-
-
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.
-
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…
I understood very early that here is no way for “MY-BMS-FALCONs”, but a good way to take what is already given by BMS and make the best possible multiplayer and community expirience out of it - hence Falcon Online theaters and servers with respect to the BMS Dev work.
History has shown, that it is more effective if many pull in the same direction, than in a different directions. Not only can it be very confusing, but this can also create undesired “fronts” between “modders” and “devs”. I understand the passion of “MolniFalcon”, “ElectroniBattlefield Falcon”, “FreeBMSFaclon”, “OpenBMSFalcon” or aka “MyFalcon”…and what not … but reality is reality and fiction is fiction
-
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?
im not suggesting to stop everything and to fix this issue - but lets atleast recognise it as an issue. from there the discussion on solutions and how to implement a proper ARH model can start, if its worth it - i understand you dont think it is.
-
im not suggesting to stop everything and to fix this issue - but lets atleast recognise it as an issue. from there the discussion on solutions and how to implement a proper ARH model can start, if its worth it - i understand you dont think it is.
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
Yknow, from what I-Hawk said… it looks a lot like its already a planned subject to get work on. Id feel a lot more confident if it was promulgated as a CM, CCM, upgrade project, but just labelling it an AIM-120 upgrade is a start.
-
I simply not understand the process and the goal. If you wished the holy undefeateble it would be possible to set more insanely smaller chaff chance and in case a developer does not like still had too for change. Now the code is different currently we have no options. I simply cannot see what was the point is swap the customizable to a non customizable system which has the same result in case you set 0 chaff chance value…
-
because the customisable system is not VERY customisable molni… and its simply arcade. pop a chaff = percentage chance that the missile will miss. Not realistic.
Yes, you have no options. Well, you do have one option - wait for the new code stuff to be reflected by DB values if appropriate.
-
I simply not understand the process and the goal. If you wished the holy undefeateble it would be possible to set more insanely smaller chaff chance and in case a developer does not like still had too for change. Now the code is different currently we have no options. I simply cannot see what was the point is swap the customizable to a non customizable system which has the same result in case you set 0 chaff chance value…
You keep saying “undefeatable”.
I really do not understand at all what your problem is with defeating ARHs in BMS???
Defeating ARHs in BMS is infact EASY in almost all situations - pretending one knows what he is doing in terms of BVR (and that without that “put the <m>symbol on 10 o`clock on RWR and break into it”</m> trick btw!).
In AF Aim-120s were much much more difficult to defeat… and in OF and FF ARHs were a friggn JOKE !!! …waaaay too easy - made by “modders” who only flew on “editors” or in F4browse and i am getting really tired to be told from those “desktop specialists”, who never appeared in any multiplayer human vs human BVR-events, how our missiles and chaffs are supposed to be :-? . “I can´t dodge a ARHs, so the code must be broken” is not the correct logic. Grr, sorry, but sometimes this make me angry.BMS is an excellent “balance” between AF and modFalcons imo… Not only that… it makes common sense in terms of what variables have to be generally considered in BVR engagements and missiles defensives.
Examples:
- Exploiting the proportional navigation and CATA intercept nature of the missile, meaning draging the missile to an extended lead intercept pursuit course where the missiles looses “track-angle” ability by overshooting its own FOV. (This happens as the missile is dragged into to parallel flight-path and due to its excessive speed, the target falls behind its own seeker FOV).
- Exploiting Line of Sight (LOS) rate, meaning flying as fast as possible 90 degrees to the inbound missile in order to exploit the seekers update-rate (works nice versus Aim-9x ie.)
- The Beam or the Notch at possilbe ranges (those are clear in BMS) to break the tracking-guidance aka the planes radar first. As example to defeat semi-actives as they require constant lock till impact or to break locks of actives before they enter the terminal stage (this is where chaffs would matter), or to break lock of bandits before actives go MPRF > HPRF.
- Using Groundclutter to confuse the tracking or guidance with radar-returns from the ground (“look down” of missile radar).
- Geometrically, meaning fighting the missiles maneuverbility due to its exessive speed (Gs and turnradius).
- The Sun as distraction for heat-seaking missiles.
- Rmin, meaning exploiting the missiles fusing-time by staying closer to the launch-plattform (if possible).
- Most importantly and probably prior to all others >> Kinematically, meaning bleeding the missiles energy by provoking increased drag in its initial or/and terminal flight-path. Clasic example would be a cold “snaking-maneuver” versus a missile with possitive closure i.e. or an initial intercept path determination and energy bleed-off as missiles flight path obeys your own trajectory.
- using lower altitutes against the missile (higher drag)
- using higher altitues against the missile (drastically reduced turn-abilities)
- and last but not least CHAFFS and FLARES as distraction or as LAST INSTANCE to increace the miss probabilities, whereas “miss probabilities” are puropsly minute (as described above) and are not “fail gurantees”.
- etc etc …
All those things WORK in BMS !! (see tapes below).
http://www.as-private.com/ACMI/R-77-1.acmi
http://www.as-private.com/ACMI/R-77-2.acmi
http://www.as-private.com/ACMI/R-77-3.acmi
http://www.as-private.com/ACMI/R-77-4.acmi
http://www.as-private.com/ACMI/R-77-5.acmi
http://www.as-private.com/ACMI/R-77-6.acmi
http://www.as-private.com/ACMI/breaklockfromtherails.acmi
http://www.as-private.com/ACMI/FancyOne.acmi
http://www.as-private.com/ACMI/TheHook.acmi
http://www.as-private.com/ACMI/Shwiing.acmi
http://www.as-private.com/ACMI/counter-def.acmi
http://www.as-private.com/ACMI/funkydonkey.acmi
http://www.as-private.com/ACMI/omega.acmi
http://www.as-private.com/ACMI/seriously.acmi
http://www.as-private.com/ACMI/excuseme.acmiIf you really think, that countermeasures (chaffs) are the only (or the most the important) method to defeat ARHs, then i think you have missed a whole chapter in missile defense.
-
You keep saying “undefeatable”.
Of course by EW, I never said anything about kinematic defet here in fact many times I have commented because of over modeled RWR the kinematic defeat of ARH missiles is easier than SARH beause RWR is 100% accurate.