Beamscanner

I'm using the HP Reverb and I find the MFD is way too dim. Waiting a MFD fix before I 'dive' into this jet

Very happy to see that target extrapolation made it to the Viper's TWS! Thank you ED! EDIT: Looks like multi-detection requirements for building trackfiles is also in there :)

anybody get pixel flickering in their HP reverb? I do not mean screen flickering, but random individual pixels scattered throughout the screen momentarily switching to green? Its very apparent against a dark background

Anyone else have to wear the reverb strap high on their head to get into the sweet spot?

There's got to be a STT IFF. otherwise WVR will be nearly impossible to engage without friendly fire

does pass the online integrity check?

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.

Ok, you guys are not thinking from the perspective of an RWR.. An RWR does not know if you are in STT.. It only knows what it sees. The only necessary difference between TWS/HPRF and STT/HPRF is the scan. All the other differences are in the receiver and would thus not be seen by an enemy RWR. STT means the radar is staring at the RWR, thus the amplitude is constantly strong. In TWS/RWS the amplitude varies with the scan of the antenna. A varying amplitude indicates a searching radar. SAM is not TWS. SAM is a sub-mode of RWS, hence all the raw hits around the priority track. Just because a priority target is selected does not mean that "bugging" a target in SAM works the same as "bugging" a target in TWS. TWS and SAM are two different things. A "bug" only mean that a priority was selected. ------------- The DCS SAM mode has the radar stare at the target periodically (by stare I mean the antenna is fixed on the target, ie a lock). Thus, I believe the SAM mode should generate a lock tone. Same would be true for DTT, since it is a 50/50 "STT" split between two targets. TWS would not generate a lock-on tone, because the antenna never stares at any target. TWS constantly scans, just like RWS.

This is what I see happening in the DCS Viper during SAM. If this is the case, a hard lock of 2 seconds would trigger an enemy RWR. Now you might think that during the small search phase of SAM that the enemy RWR might stop indicating STT. But the enemy RWR memory would keep the STT indication for a period of several seconds. Thus the RWR would constantly indicate a STT.

No, i'm saying its working correctly. SAM should give a STT warning to the enemy bugged in SAM. This is due to the radar locking the bugged target every 2 seconds for a duration of 2 seconds. (as indicated by the DCS video)

Typically elevation bars are separated by 1/2 the antenna's elevation beamwidth. Though they are sometimes made to be just slightly closer. See my example below

I am not incorrect. I know the difference between a soft lock and a hard lock. Watch the video below. During SAM the radar spends 2 seconds scanning and 2 seconds locked on to the bugged target. You can see this with the T bracket indicating antenna position. (3:30) A 2 second hard lock (the radar is staring at the target) should inform the the RWR of a lock on. This would be the same RWR indication if a Hornet locked switched between STT and RWS every 2 seconds.

after watching some videos of the DCS Viper I see that in SAM the radar does temporarily lock the enemy before doing a quick little scan (watch the radar "T" bracket during SAM). I would think that temporary lock could trigger a STT indication on the enemies RWR. If the DCS Hornet locks a target for 1 second and goes back to scanning does it inform the enemy of a STT? If so, than SAM should generate a STT or interrupted STT. I imagine the same would be true for DTT since it works similarly.

So would the below mock up be accurate?

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.

NVM

keep in mind the beamwidth of the APG-68 is different from the APG-73. The APG-68 has more of a fan beam. Meaning the beam isnt circular. Its beam is larger in elevation due to the smaller vertical aperture of the antenna.

I noticed some issues with the Brick ageout and potentially a misconception about bricks in RWS. Ageout: Issue: The DCS Viper video shows bricks dimming way too soon. Viper RWS bricks should dim once after the period of time it takes to complete a full scan with the selected bar/azimuth settings. Dimming again after that period of time has passed 2x and 3x. They should not dim before the radar's even gotten the chance to re-detect the target. Same is true for Trackfiles in both the Hornet and Viper. I provided a deeper explanation here Brick movement: Issue: The DCS Viper video shows bricks updating their position. It looks like when you had the same target detected on 2 separate elevations bars, and it updated the position of an old brick instead of drawing a second brick. RWS bricks / hits should be static objects on the radar display (fixed to a position in space), only moving due to ownship maneuvers. They do not update their position. Instead, targets are simply re-detected at their new position. Bricks can be associated to trackfiles, but not other bricks. Thus, each detection of target "A" should have a separate brick from the last. Brick dimming and lack of movement can be seen in this video: Please let me know if you have any questions on this. I hope this gets looked into. I haven't been in the Hornet in awhile, but I'm sure it would need to be fixed there too.

What do the non-trackfile radar hits look like? I've only found one picture of a Chinese radar brick, but from a different chinese fighter radar. Perhaps no IFF return = red rectangle??

Typo Page 185: "HANDOFF. Not applicable." to "HANDOFF. (Later in Early Access)"

Thanks LJQCN101 You guys are killing it As I've already stated, that video has nothing to do with the JF-17's KLJ-7 radar. I showed it because it shows that DTT modes do not search for targets and only track to two locked targets. The DTT in Deka's air to air video had the radar doing a normal 120 degree scan while in DTT, which was not correct. There is without a doubt different software, and AESAs do operate much differently than Slotted Planar arrays. But that's not what I was referring to. DTT is a technique, not a technology. Similar to say how High PRF detection logic is similar between many radars of different manufacturers and even between AESAs and mechanical radars.

DTT.. In all radars that have "DTT".. is just STT switched out between two targets. Otherwise it would just be normal TWS with two bugged targets. The reason is really beyond the scope of this conversation, but since ppl want to debate things they have no knowledge about: ------- What you are describing (tracking multiple targets while still scanning for others) is called TWS. DTT is separate from TWS and SAM. It does not track targets while scanning, otherwise its existence wouldn't be necessary. Unlike TWS, DTT only cares about two targets. It quickly switches between the target its locked on to to ensure a very high update rate on both threats. Now you may be thinking, 'well if the antenna has to sweep between each of the targets, it mine as well try to detect some new targets while it sweeps back and forth between the two targets.. However, you'd be wrong to think this. The speed at which the radar antenna scans is actually limited by the amount of time on target the radar needs to detect on object at range. These radars integrate many pulses in order to detect a target. If the radar scanned too fast, it may not transmit enough pulses on the target. Thus, fighter radars are slowed down to ensure the radar has enough time on target (which is also a factor of the 3dB beamwidth) to perform an integration of N pulses. In the case of DTT, the priority as determined by the pilot is just those two targets. To accomplished 'duel single target track' the radar needs to spend as much time as possible on each target, and as little time as possible scanning between them. In TWS/RWS/Every other scan mode, the speed is slowed down to emit N pulses within each beam width. In DTT the antenna speed = the max gimbal speed (just like how STT has a different antenna speed than RWS in other radars). Thus the radar moves too fast to transmit enough pulses to perform sufficient pulse integration. If it slowed down its scan, it's update rate on the two priority targets would suffer to the point that their "track quality" would come down to the quality level of normal TWS. Using the video of the JF-17 AESA was just used as an example of DTT logic, because it showed the radar ignore the azimuth areas that did not have the two targets. -------

Yes it does. They even show it in their Air to Air video... The point isnt AESA vs Slotted Planar Array Radar. The point is that DTT, fundamentally, only detects the two targets. It will not scan for any other targets like they showed in their video.

Questions about the radar shown in the Air to Air video 1. The radar is shown to have 4 bar 120 degree scan capability in TWS. Is this a bug or do you guys believe the radar can do this? I would think full TWS would limit scan volume to maintain trackfile update rate. The images below shows TWS go to a plus/minus 25 degree scan (50 degree total scan). Footage from this video shows TWS limited to a 50 degree sweep in a 3 or 4 bar (hard to tell) scan. 2. SAM mode should also limit the azimuth and bar area as seen in available SAM mode picture below. (plus or minus 30 degrees) Going off the information above, (SAM mode with a 4 bar / 60 degree total scan) the KLJ-7 would be able to do a 2 bar / 120 degree scan but not a 4 bar / 120 degree scan. 3. The left azmiuth indicator should read the plus & minus azimuth scan, not the total scan. 4. In VS and RWS you show trackfiles (target ALT and vector) instead of "hits" or "bricks". Was this intentional or another bug? VS definitely shouldn't have a target vector, and RWS probably wouldn't either unless Latent TWS was being performed. However, given that you have a target history option (M1, M2, M3, M4) that only applies to RWS and VS, it seems to me that those modes use bricks/hits, as there is no reason to display old trackfiles behind an existing trackfile.. Target history specifically exists to give the pilot SA to where the target is going when target vector isnt shown (ie brick movement over time). If every radar hit had a velocity vector, target history (M2, M3, M4) would serve no purpose. In fact, SAM and TWS would be completely useless if trackfiles are always present in RWS. Thus I think its very likely that RWS and VS use radar bricks / hits. They probably look like the F-16 radar bricks, since everything else looks like its been influenced by the APG-66/early APG-68 (likely acquired from the Peace Pearl project). Example of a generic radar brick: 5. Will the "EXP" option be added to TWS as seen in the first 2 pictures? 6. The lower left bearing and range indicator looks like it can also work when a target isn't locked or soft locked. Thus is must be relative to your own aircraft in that case. See pic below. 7. DTT mode should not continue to scan for additional targets. DTT is like STT but switching back and forth between the two targets. Proof below in KLJ-7 replacement footage. Watch the antenna position while radar is in DTT. (time start: 1:25)

thanks!