-
Posts
1572 -
Joined
-
Last visited
-
Days Won
2
Content Type
Profiles
Forums
Events
Everything posted by Маэстро
-
Hi GGTharos, 1) In HOJ mode used PN, but instead of closing velocity used missile inertial velocity(assume we can't measure closing velocity due to jamming). Yep, it will be applied for some other missiles based on old missile API. AIM-7 was switched to new API a long time ago, so it uses PN in HOJ and normal mode since switching. Can't promise anything about ECM. There are many difficulties from both implementation and game design points of view. 2) That means old missile API by default use parallel navigation in normal mode and pure pursuit in HOJ. There was fundamental reason for such choose of guidance law. At the moment proportional navigation may be enabled for any missile if needed.
-
Missile always go active at certain range to INS cue, this cue also defines targeting data for seeker - assumed target range, closing velocity, LOS angular rate etc. When you lose lock you drop datalink. Because target does maneuver in tracks(yes it does - it accelerates) seeker does not lock target.
-
[OB 2.7.18.30348] AIM-120 does 40G loop/backflip when fired in maddog
Маэстро replied to Default774's topic in Weapon Bugs
Known issue. -
I already fixed this internally, so it will be released soon, but not in the next patch. I think yes, this how old API works.
-
Will switch R-27 and R-77 to conventional PN.
-
It definitely will. Kalman filter estimates target acceleration and quality of this estimation directly affects missdistance against maneuvering target.
-
Yep, we know. However, target size should not change triggering radius, but explosion delay only. Hope we will add this feature one day.
-
[FIXED] [OB 2.7.16.28157] SD-10 nozzle_exit_area value incorrect
Маэстро replied to DSplayer's topic in Fixed Bugs
Many thanks indeed! -
That's not a proximity fuse issue. There was some issue with Kalman filter. Already fixed internally.
-
investigating AIM-120 Can't track through 360 turns
Маэстро replied to comie1's topic in Weapon Bugs
It's already fixed internally. Missile will better track target in such conditions(and even will hit target in q4 and q3 tracks). -
[FIXED] [OB 2.7.16.28157] SD-10 nozzle_exit_area value incorrect
Маэстро replied to DSplayer's topic in Fixed Bugs
Very useful drag charts, thanks. Do you have the same for 5v28? -
investigating AIM-120 Can't track through 360 turns
Маэстро replied to comie1's topic in Weapon Bugs
I'm sorry, but i still see launch distance for AI is set to random between Rmax and NEZ in these tracks. -
investigating AIM-120 Can't track through 360 turns
Маэстро replied to comie1's topic in Weapon Bugs
The lack of energy is that I see in attached tracks from the first post. Could you please attach one more track where you expect missile energy is sufficient for intercept? Unfortunately, acmi or GIFs can't help with debugging. -
investigating AIM-120 Can't track through 360 turns
Маэстро replied to comie1's topic in Weapon Bugs
There will be some improvements soon. However, above tests not qute correct. It's better to set missile launch distance as NEZ for AI in advanced waypoint options. The main reason of such behaviour is not tracking issue, but low closing velocity(rear aspect after maneuver) and lack of missile energy. -
AIM-54 Hotfix PSA and Feedback Thread - Guided Discussion
Маэстро replied to IronMike's topic in DCS: F-14A & B
Hi, can you please try on more thing? Retain PN_gain = 4, but replace these numbers (just above DLZ data): 36.0, -- характеристика системы САУ-РАКЕТА, коэф фильтра второго порядка K0 7.8, -- характеристика системы САУ-РАКЕТА, коэф фильтра второго порядка K1 1.0, -- характеристика системы САУ-РАКЕТА, полоса пропускания контура управления with these ones 1.2, -- характеристика системы САУ-РАКЕТА, коэф фильтра второго порядка K0 1.0, -- характеристика системы САУ-РАКЕТА, коэф фильтра второго порядка K1 2.0, -- характеристика системы САУ-РАКЕТА, полоса пропускания контура управления This should reduce excessive guidance smoothing and make missile more agile. Simple increasing of PN_gain is not the way, bc it's not realistic. There is some limitations on this value IRL(increasing may cause overall system instability or/and missdistance growth). Also higher values are not optimal in terms of kinetic energy saving. -
fixed internally
-
That's not an autopilot bug. There is a problem with missile catapult mechanics. Already reported, will fix.
-
investigating AIM-120 Can't track through 360 turns
Маэстро replied to comie1's topic in Weapon Bugs
Hmm..will investigate. -
There is no notch in look up conditions. It's a part of antichaff logic - lock on targets with extremely low radial velocitiy is forbidden. Will think about this problem, maybe will add some trajectory shaping.
-
Lateral Missile Guidance Bug - AIM-54 and AIM-120B/C
Маэстро replied to Whiskey11's topic in Weapon Bugs
That's not correct to directly compare AIM-120 and AIM-54 guidance, them use different API and different guidance laws. There is no issue with AIM-120 guidance. It's ok if missile has almost straight trajectory but not exactly straight. Regarding AIM-54 - such big arc is a result of guidance tuning of this particular missile. I will contact Heatblur. -
investigating AIM-120 still can not chase simple Split S manuever.
Маэстро replied to opps's topic in Weapon Bugs
I’m sorry, but that shows you misunderstood how range bins really work and how range ambiguities may be resolved. I highly recommend you to read chapter 12 of Introduction to Airborne Radar by Stimson. It very clearly describes these things. For ones who have no access to this book I will try to briefly explain it right here. To measure range, pulsed radars may use pulse delay ranging. The idea is simple – you just need to measure time between pulse transmission and target echo receiving. Then knowing that pulse travels with speed of light you may calculate range (by simple multiplying of measured time by speed of light). However, any pulsed radar has its own unambiguous range(s) which equal to Ru = SpeedOfLight * T / 2, where T = 1/PRF – inter-pulse period, dividing by 2 means that pulse should make two-way travel – to target and back. For 10KHz PRF this equation gives Ru = 15km. Why there is Ru? Because radar should use identical pulses (for several reasons) and cannot differ one from another, so it should start new time measurement after each transmitted pulse. Suppose we have two targets, one at 5km and another one at 22km and Ru equals to 15km. Radar transmit first pulse and measures time of echo returns. Echo from 5km target comes back within one inter-pulse period, so distance measured correct. When second impulse transmitted, first impulse echo from second target is still on the way and had covered 30km distance (SpeedOfLight * T), so it still needs to travel 22 * 2 – 30 = 14km. Second impulse should travel to first target forth and back only 10km, so radar receives it first and only after this receives first impulse echo from second target (which left to travel 14km). So radar see two targets now – one at 5km(where it really is) and second at 14/2 = 7km. Note, when PRF is changed Ru changes too, so “visible” range of second target will also change(visible range of first target will be unchanged until it within Ru). Thus, second target has unambiguous range. About range bins. In modern digital radar range bins is a set of memory cells. Each cell stores signal from radar receiver, which come in corresponding moment of inter-pulse period. For example, if PRF is 10KHz (T = 100 microseconds) and radar have 10 range bins, then each range bin should store 1/10 part of inter-pulse period (10 microseconds). So, first range bin stores signal for 0-10mcs interval, second for interval from 10 to 20mcs, and so on up to 100mcs. Each 10mcs corresponds to 1.5k range. If such radar will look at two targets from example above targets will fall in 4th and 5th bins correspondingly. In other words, range bins just filled with signal received during inter-pulse period and can contain range-unambiguous signal. Range bins do not do any ambiguity resolving themselves, just store signals. Range resolving can be made by signal processor. For this purpose, you need to save signal from each range bin (after Doppler filtering), change PRF and see how targets jumps from one range bin to another with respect to previously saved data. As was stated posts above, to calculate real range to such jumping targets Chines reminder theorem may be used. Now imagine that radar sees very extended target which length exceeds Ru (as ground clutter may be in certain conditions). In this case range of such extended target cannot be resolved. Switching of PRF gives nothing because all range bins stay filled with target signal and radar does not see any target jumps between bins. Yes, and exactly this way it works in DCS. The power of ground return spreads over range bins making target detection more possible. But range gating helps a lot to contend with side lobe clutter(the main reason of using range gating) and may not help in case of strong mainlobe return(which usually simply cuts off by clutter cancellers in fighter radars). No. As it already was stated above by Beamscanner ADAPTIVE single PRF gives you some advantages in case of STT. And there is no any problem with tracking while target is outside of mainlobe CENTRAL LINE clutter. All issues with eclipsing and notching by clutter harmonics easily solved by adaptive PRF change when target get close to such problem regions. The only region where this does not work is central line mainlobe clutter. Please try to understand that we talk about different parts of clutter. You talk about clutter harmonics which doppler frequencies changes with PRF switching (so regions previously obscured by clutter may be cleared even in case of range ambiguous mainlobe clutter) and I talking about clutter central line frequency, which stays unchanged with PRF switching. The central line clutter is the only clutter which can make you some troubles in DCS. Theoretically it possible and some fighter radars do that, but for missile system it may be a bad solution. In LPRF mode radar can track in range and angle, but cant perform robust velocity tracking, so radar became very sensitive to chaff. Properly designed extrapolation (inertial tracking) more robust in that case. Yep. Fighters have bigger dishes, consequently narrower beams, this gives them an advantage of narrower doppler frequencies band (each harmonic will be narrower) of mainlobe clutter return and smaller beam footprint (smaller power of ground return). And how do you know how many research I did? Aren't too much accusations? There was no any cherry picking. You are mixing different things. This paper not about clutter ambiguity resolving. Author just uses simplest clutter model and trying to improve performance of matched filtering in presence of clutter, but with POSITIVE SCR. There is no clutter separating or range gating. Moreover, calculating SCR in this paper looks not clear for me (looks wrong to be precise). Equation 4.14 assumes that target and clutter located at the same distance, but MATLAB code uses this one SCR=(sigma_target*4*altitude)/(10^(sigma0_surface/10)*pi*(altitude^2+distance^2)*deg2rad(beamwidth)) And that’s not equivalent of 4.14 with 4.12 substitution. Its equivalent of 4.14 multiplied by [sqrt(altitude^2+distance^2) * deg2rad(beamwidth)]. Such equation gives SCR for clutter at range Rc = sqrt(altitude^2+distance^2) and target at much closer range which equals to Rc / quadroot(Rc * deg2rad(beamwidth)). Of course, that’s much better SCR than eq.4.14 gives. All this looks weird to me. Thoughts? Also note that missile have much wider beamwidth than fighter. 15deg vs ~3deg, five times wider. This results in SCR 25 times worser (because footprint area 25 times bigger) at the same circumstances. Guys, in my opinion there are no major issues with notching itself. Of course, there may be some tweaks on normalized rcs of surface or we make different values for different surface types, but this will not change situation drastically. BUT In this particular case (see first post of topic) the problem is that INS data does not updated by seeker measurements, so without datalink updates missile performance after losing track of maneuvering target is degraded. We know about that and missile development in part of merging seeker data, datalink and INS data is not finished. Such systems may be built in several ways and I have some thoughts on that, but it is not as simple as it may looks like and good solution requires additional research. There is no any contradiction if we suppose that range at wich missile stops to incorparate data links is less then Pitbull range. The paper is a very useful, thanks. Thank you! These patents are really interesting, but I’m afraid that’s not a solution. Not a full at least. See explanations below. Admit right now we have 100% probability of detection (and lock) for 2dB SCR, and 1.5dB for detecting at all (extremely low values!). Of course, if I’ll try to implement this thing missile tracking capabilities will grow up to 15 or maybe 30% at 1dB SNR. But practically you wont notice any difference because in most of cases SNR is much lower that 1dB. It could easily be -10dB or worse! So, even this new method will provide very low detecting probability in such circumstances. Additionally, there will be troubles for radar if beaming target will use chaff That’s not quite true. First of all, angle difference limited by beamwidth. If you track a target seeker LOS is pointed at the target and difference limited by half of beamwidth. Practically it will be even less than half because you need to put some ground surface inside of beam to have significant return. In case of ambiguous clutter return when patches of clutter superimposed in range bins angle difference may be small(signal from several patches located at different angels for radar will look like signal from one bigger patch located at some average angle). Also, it’s hard to say what average angle of clutter will be in most DCS situations. As I said the missile has such extrapolations, but there is a problem with updating data for extrapolation. It will be solved. I did not say exactly that. There is no any problem with resolving range ambiguity for ordinary target. I was talking about extended target (about ground clutter in particular). Please see explanations above. Be assured modern PD radars still have problems with beaming targets tracking and try to contend with this generally by inertial tracking(extrapolation) or LPRF using. If it’s the ESA radar there are several additional methods to contend with this issue. BTW. Proposed method does not look as good improvement for fighter radars because they usually have narrow beam 3 deg circa. (so only 1.5 deg halfwidth…) Yep, but we have lots of different high-priority tasks, so can’t promise such features soon. Will add to wishlist.- 102 replies
-
- 11
-
-
-
reported Aim-120 weird behavior (wobble) in final stage of flight
Маэстро replied to Moonshine's topic in Weapon Bugs
Reported. Thanks -
investigating AIM-120 still can not chase simple Split S manuever.
Маэстро replied to opps's topic in Weapon Bugs