Jump to content

Upcoming TWS Realism ?


USA_Recon

Recommended Posts

Typically, ED always aims to make systems as realistic as the available declassified documentation allows.

 

Do you have a more specific question?

i7-7700K @ 4.9Ghz | 16Gb DDR4 @ 3200Mhz | MSI Z270 Gaming M7 | MSI GeForce GTX 1080ti Gaming X | Win 10 Home | Thrustmaster Warthog | MFG Crosswind pedals | Oculus Rift S

Link to comment
Share on other sites

Its the first time TWS will be implemented in a high-fidelity module. F-15C TWS doesn't count as it is a Flaming Cliffs aircraft.

Uhm, there is TWS in the M2000C and the F-14 already. They're both high fidelity modules.

Intel i7-12700K @ 8x5GHz+4x3.8GHz + 32 GB DDR5 RAM + Nvidia Geforce RTX 2080 (8 GB VRAM) + M.2 SSD + Windows 10 64Bit

 

DCS Panavia Tornado (IDS) really needs to be a thing!

 

Tornado3 small.jpg

Link to comment
Share on other sites

Reliability, time to scan, etc...

 

TWS is treated like a silver bullet in DCS but that is because it's nearly as reliable and fast as RWS right now

 

There's no reason to expect tws won't be simulated correctly. It's not rocket science, just math.

 

DCS doesn't model sensitive factors that affect detection probability, just line of sight and aspect. Otherwise RWS is modelled well. For purpose of this discussion, TWS isn't any other than the frame time restrictions. Check that, there's a lot of symology that they need to build and how the radar reacts to maintain highest priority trackfiles and such, but the geometry doesn't change. The elevation bar and azimuth scan restrictions are what they are, I'm sure they're published as every manual for the f-16 is online somewhere, if not the math is basic arithmetic based on azimuth scan rate and the ~3s update required for weapon solution.

 

If anything I bet it will underperform expectations. As you point out, tws isn't magic bullet. If your BVR procedures are bad tws will make them worse. Sanitize and meld procedures become more important and less forgiving, and the lack of RWR warnings for STT and guidance make adhering to your WVR transition even more important.

 

So no, I wouldn't expect tws to to be a magic bullet.

just a dude who probably doesn't know what he's talking about

Link to comment
Share on other sites

 

DCS doesn't model sensitive factors that affect detection probability, just line of sight and aspect.

 

The RCS results are fairly nicely out there to give some nice ideas about the sensitivities by aspect, and those are used in DCS. So you are less detected from rear or front than from a side.

 

But what I do not know or have ever read anyone to see, is the detection probabilities as echoes in the long range or even at closer ranges. Meaning that you will get a return and so on ping once but not every scan time, but like 1 of 10-15 scans can give you a return. Closer you get etc, then more likely you start to get returns. This would be a reason to change often the scanning azimuth to narrow to maximize the probability to find the target.

 

And this to be fast more important at the older fighters like MiG-19, but still important at the 4th get fighters as well.

 

The reliability of the radars is just too digital and too trustworthy.

At least in Hornet ED presented the virtual scanning beam technology, so that it won't be just line of sight and angle that matters but the beam needs to paint at target and from that is the calculation some, is it detected or not.

 

We still do not have chaff echos, denying to see through or even detect well someone front of it at close to it, chaff scattering around large wide areas in time (weather simulation) and so on chaffing would make the large areas hazardous for radars once one starts popping chaff. So further the chaff use goes, far more quickly radars operation in that mission/map goes very low.

 

And does anyone know, is the ED radar calculating the targeting and tracking gates at about correct updates periods, have the correct datalink update periods to missiles and have missile seekers scanning speeds, logic and beam widths somewhat modeled? As now it looks like that missiles spot targets as soon they are in range and overall FOV..

i7-8700k, 32GB 2666Mhz DDR4, 2x 2080S SLI 8GB, Oculus Rift S.

i7-8700k, 16GB 2666Mhz DDR4, 1080Ti 11GB, 27" 4K, 65" HDR 4K.

Link to comment
Share on other sites

in terms of realism, I think they need to add the following to their radar API:

 

 

Proper building of tracks - A trackfile has a position (lat/lon/alt), speed, and vector. A radar can detect range, altitude and doppler (relative velocity) on a single 'look' (think one scan/radar brick). However, a trackfile cannot be produced with a single brick because the target could have several possible vectors/speeds with a given closure rate. Thus trackfiles should take two or more detections/scans (radar bricks, or hidden bricks) to build a trackfile. by using two or more detections, target motion analysis can be used to determine the targets vector and thus their true velocity as well. (applies to TWS/LTWS) This does not apply to SAM or DTT as in those cases the radar stares long enough that its almost like its doing an interrupted STT (many continuous detections at once)

 

-----

 

Target extrapolation - Tracks continue to move between radar scans based on known aspect, velocity and position. ie the targets position is continuously predicted while the radar scans. When the radar gets to look the targets direction again, the trackfile updated with the actual position, and again from that last known position the track moves forward based on its known speed, vector, etc. (applies to TWS/LTWS/SAM/DTT)

 

-----

 

INS stabilized tracks - Currently radar and datalink tracks jitter around when you turn your aircraft. They should move smoothly across the screen as you maneuver to maintain their position in space. (applies to all radar modes)

 

-----

 

TWS/LTWS Age out logic - Tracks should not dim/fade before the the radar has returned to the same bearing/elevation again. Track fading should be related to the trackfile not being seen where it should have been seen. (ie a missed frame). (applies to TWS/LTWS/SAM/DTT)

 

-----

 

RWS Age out logic - Bricks in the viper should fade once per frame time. (frame = total time to complete scan with current azimuth & bar settings) ie they fade when the radar gets another 'look' at the same azimuth and elevation the brick was last seen at. (applies to RWS/VS)

 

-----

 

RWS bricks logic - RWS bricks should never update or move (the exception being your own maneuvers moving it on the radar display). If a target is sitting between 2 separate bars and get detected on both bars, the one target should generate 2 separate bricks. The reason is RWS bricks do not get correlated with one another. They simply indicate a detection. Right now DCS has the brick update its position when the same target is detected again. (applies to RWS/VS)

 

-----

 

Range/Doppler matching targets - Closely spaced targets, with similar dopplers, being detected as one target. This is a result of the two returns ending up in the same range and doppler bins. Also, being in the same bins, their two RCS being summed together and thus detected further out than had they been in separate positions. (applies to all radar modes)

 

-----

 

Doppler notch off in look up conditions - In many cases radars will turn off the main beam doppler notch when the beam is pointed skyward, as little to no clutter would come in those conditions. Thus the radar could track a beaming target, when the target was well above the horizon. (applies to all radar modes)

 

-----

 

Altitude notch - Everyone here is familiar with the "doppler notch" (ie the main beam notch filter) but there's actually two big notch filters in most air radars. The other notches out the "altitude line" which is the downward reflection of the radar energy that reflects in and out of antenna sidelobes. This notch stops clutter from coming in, but more importantly, makes it difficult to track targets who have a zero closure rate (ie they're flying away at the same speed as you), since the closure rate to the altitude line is usually also zero. (applies to all radar modes)

 

-----

 

HPRF range accuracy - With PRF selection, most are familiar with HPRF = good long range / head on detection but poor low doppler detection, and MPRF = good all aspect detection at the cost of reduced detection range. But you may not realize that HPRF has another flaw widely known to the public, they have poor range accuracy. HPRF radars use frequency modulated ranging (FMR) to determine target range. Range information is highly ambiguous while doppler is mostly unambiguous in HPRF. Thus range is not "detected", but rather resolved post detection with FMR. However, FMR is known to only be able to provide course range. Several scientific radar books claim the range accuracy of HPRF to be between 2 - 4 nmi. (applies to all radar modes using HPRF) EDIT: keep in mind range accuracy and range resolution are two different things.


Edited by Beamscanner
Link to comment
Share on other sites

Its the first time TWS will be implemented in a high-fidelity module. F-15C TWS doesn't count as it is a Flaming Cliffs aircraft.
Some people say FC3 F-15 TWS is more like a hybrid AESA radar. Its detection and refresh rate are too good to be true. I don't know if that claim is true or not tbh but I'd like to agree with them.

Mastering others is strength. Mastering yourself is true power. - Lao Tze

Link to comment
Share on other sites

in terms of realism, I think they need to add the following to their radar API:

 

 

Proper building of tracks - A trackfile has a position (lat/lon/alt), speed, and vector. A radar can detect range, altitude and doppler (relative velocity) on a single 'look' (think one scan/radar brick). However, a trackfile cannot be produced with a single brick because the target could have several possible vectors/speeds with a given closure rate. Thus trackfiles should take two or more detections/scans (radar bricks, or hidden bricks) to build a trackfile. by using two or more detections, target motion analysis can be used to determine the targets vector and thus their true velocity as well. (applies to TWS/LTWS) This does not apply to SAM or DTT as in those cases the radar stares long enough that its almost like its doing an interrupted STT (many continuous detections at once)

 

-----

 

Target extrapolation - Tracks continue to move between radar scans based on known aspect, velocity and position. ie the targets position is continuously predicted while the radar scans. When the radar gets to look the targets direction again, the trackfile updated with the actual position, and again from that last known position the track moves forward based on its known speed, vector, etc. (applies to TWS/LTWS/SAM/DTT)

 

-----

 

INS stabilized tracks - Currently radar and datalink tracks jitter around when you turn your aircraft. They should move smoothly across the screen as you maneuver to maintain their position in space. (applies to all radar modes)

 

-----

 

TWS/LTWS Age out logic - Tracks should not dim/fade before the the radar has returned to the same bearing/elevation again. Track fading should be related to the trackfile not being seen where it should have been seen. (ie a missed frame). (applies to TWS/LTWS/SAM/DTT)

 

-----

 

RWS Age out logic - Bricks in the viper should fade once per frame time. (frame = total time to complete scan with current azimuth & bar settings) ie they fade when the radar gets another 'look' at the same azimuth and elevation the brick was last seen at. (applies to RWS/VS)

 

-----

 

RWS bricks logic - RWS bricks should never update or move (the exception being your own maneuvers moving it on the radar display). If a target is sitting between 2 separate bars and get detected on both bars, the one target should generate 2 separate bricks. The reason is RWS bricks do not get correlated with one another. They simply indicate a detection. Right now DCS has the brick update its position when the same target is detected again. (applies to RWS/VS)

 

-----

 

Range/Doppler matching targets - Closely spaced targets, with similar dopplers, being detected as one target. This is a result of the two returns ending up in the same range and doppler bins. Also, being in the same bins, their two RCS being summed together and thus detected further out than had they been in separate positions. (applies to all radar modes)

 

-----

 

Doppler notch off in look up conditions - In many cases radars will turn off the main beam doppler notch when the beam is pointed skyward, as little to no clutter would come in those conditions. Thus the radar could track a beaming target, when the target was well above the horizon. (applies to all radar modes)

 

-----

 

Altitude notch - Everyone here is familiar with the "doppler notch" (ie the main beam notch filter) but there's actually two big notch filters in most air radars. The other notches out the "altitude line" which is the downward reflection of the radar energy that reflects in and out of antenna sidelobes. This notch stops clutter from coming in, but more importantly, makes it difficult to track targets who have a zero closure rate (ie they're flying away at the same speed as you), since the closure rate to the altitude line is usually also zero. (applies to all radar modes)

 

-----

 

HPRF range accuracy - With PRF selection, most are familiar with HPRF = good long range / head on detection but poor low doppler detection, and MPRF = good all aspect detection at the cost of reduced detection range. But you may not realize that HPRF has another flaw widely known to the public, they have poor range accuracy. HPRF radars use frequency modulated ranging (FMR) to determine target range. Range information is highly ambiguous while doppler is mostly unambiguous in HPRF. Thus range is not "detected", but rather resolved post detection with FMR. However, FMR is known to only be able to provide course range. Several scientific radar books claim the range accuracy of HPRF to be between 2 - 4 nmi. (applies to all radar modes using HPRF) EDIT: keep in mind range accuracy and range resolution are two different things.

 

 

Great post Beamscanner!

 

I'm curious if the tracking algorithms of radars use only a motion model like you seem to imply. Considering the Hornet's radar is capable of NCTR, I would assume some kind of appearance model (based off of the return waveform or the likes) could be use to enhance tracking and discriminate between closely spaced and maneuvering targets.

Link to comment
Share on other sites

in terms of realism, I think they need to add the following to their radar API: .....

Excellent stuff. Nice and comprehensive list. But my main question is exactly how does radar detection actually work, in high-fidelity modules, like the F-18, F-16, F-14 and the Mirage? What is actually simulated/calculated in real time? Is it a case of the game knowing where everything is and, according to a number of criteria and parameters, decides how/if it's going to display it to your radar scope or make the object appear in the radar return and be able to be locked? Or is there some sort of actual radar wave simulation taking place? I have read that DCS uses ray-casting to simulate radar functions (like the AG radar of the Viggen), but I don't know to what extent this is used for the aforementioned AA radars.

The vCVW-17 is looking for Hornet and Tomcat pilots and RIOs. Join the vCVW-17 Discord.

CVW-17_Profile_Background_VFA-34.png

F/A-18C, F-15E, AV-8B, F-16C, JF-17, A-10C/CII, M-2000C, F-14, AH-64D, BS2, UH-1H, P-51D, Sptifire, FC3
-
i9-13900K, 64GB @6400MHz RAM, 4090 Strix OC, Samsung 990 Pro

Link to comment
Share on other sites

Excellent stuff. Nice and comprehensive list. But my main question is exactly how does radar detection actually work, in high-fidelity modules, like the F-18, F-16, F-14 and the Mirage? What is actually simulated/calculated in real time? Is it a case of the game knowing where everything is and, according to a number of criteria and parameters, decides how/if it's going to display it to your radar scope or make the object appear in the radar return and be able to be locked? Or is there some sort of actual radar wave simulation taking place? I have read that DCS uses ray-casting to simulate radar functions (like the AG radar of the Viggen), but I don't know to what extent this is used for the aforementioned AA radars.

 

AFAIK ray casting is only used by Heatblur for simulating ground return.

 

Typical air to air 'simulation' has simple detection logic (ie, does a target exist within antenna beam, within doppler region and radar detection range limits for target RCS? If yes, provide range and display)

 

Targets are more filtered than detected within DCS. There's probably more to it, but its not at all a doing any wave simulation. Nor should it.

 

Wave simulation can get very complex when you have 100s of sources operating in the same RF range interfering with one another. This, even without interference can be CPU intensive.

 

You can fake pulse doppler air to air radar pretty accurately so long as you incorporate some of the details I mentioned in my previous post. Pulse doppler air to air are 'clean' screen displays and thus by design only display aircraft detections. In other words, you dont need to simulate RF clutter because those real radar modes work to eliminate clutter (for the most part).

 

Air to ground and old school 'pulse radar' are more difficult to simulate accurately due to the existence of clutter in the scope. Compare the F-14 AWG-9 pulse mode to the MiG-19 radar and you'll see how drastically different the level of simulation is between the two.

 

I do think that the level of simulation should increase, but it should do so with optimization in mind. No need to simulate radar waves when the radar range equation can do alot of the same at a much lower cost.

Link to comment
Share on other sites

  • 5 weeks later...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...