Jump to content

GTM radar update with sweep animation


Recommended Posts

 

 

Is that a proper timing for it?

AFAIK the radar sweep should represent the realtime scan and processing, meaning the block position should be drawn only after the sweep is on it position or just after it. Now the block is moved before the sweep gets on it or past it.

 

VIdeo is frame by frame from Wags first-view video, and then after sweep has one to right, it is frame by frame backwards in time.

 

That update timing before sweep was on the target made the animation look somewhat.... wrong.


Edited by Fri13
  • Like 3

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 post
Share on other sites
  • Fri13 changed the title to GTM radar update with sweep animation

I'll admit it does look a bit weird, I guess we'll have to wait for more information on the mode to be shows and what it's like when it hits OB.

Modules I own: F-14A/B, F/A-18C, Supercarrier, F-16CM, AJS-37, F-5E-3, MiG-21bis, Ka-50, A-10C (+ A-10C II), UH-1H, Mi-8MTV2, P-47D, P-51D, FC3, MiG-15bis, Yak-52, CA, C-101, Hawk

Terrains I own: Syria, The Channel, SoH

 

System (RIP my old PC): Dell XPS 15 9570 w/ Intel i7-8750H, NVIDIA GTX 1050Ti Max-Q, 16GB DDR4, 500GB Samsung PM871 SSD (upgraded with 1TB Samsung 970 EVO Plus SSD)

 

VKB Gunfighter Mk.II w. MCG Pro

 

Dreams: https://uk.pcpartpicker.com/list/mBG4dD

Link to post
Share on other sites

It shouldn't be necessarily so, or that is my impression.

 

First big disclaimer, no idea on how the real system works.

 

Having said that, what you indicate @Fri13 would be correct if what you are seeing on the MFD is the analogue signal, instead of a digital track. The target track generated by the computer after the processing is done, could perfectly be updated based on the aircraft movement, so the bricks are getting closer cause you are flying towards them, and the sweep animation is just to let you know where your radar is looking now. I doubt the movement you are observing is the real target movement since the speed is too low. 

 

But let see if what i just described make sense or if someone with deeper knowledge could clarify.

 

EDIT: Looking at the footage again, it might also be that we are seeing the delay of the Radar computer between the sweep and the time it take to update the track, because otherwise it would be instantaneous more kinda an analogue display showing true non processed returns.

 


Edited by falcon_120
Link to post
Share on other sites
57 minutes ago, fabiof104 said:

when is the update expected?

 

 

No date set currently, we are on a break until the 11th, and we will let you know when we are ready.

 

thanks

  • Like 3

smallCATPILOT.PNG.04bbece1b27ff1b2c193b174ec410fc0.PNG

Forum rules - DCS Crashing? Try this first - Cleanup and Repair - Discord BIGNEWY#8703 - Youtube - Patch Status

Windows 10 Pro x64, NVIDIA MSI RTX 2080Ti VENTUS GP, Intel® i9-10900K 3.70GHz, 5.30GHz Turbo, Corsair Hydro Series H150i Pro, 32GB DDR @3000, ASUS ROG Strix Z490-F Gaming, HP Reverb G2

Link to post
Share on other sites
45 minutes ago, falcon_120 said:

Having said that, what you indicate @Fri13 would be correct if what you are seeing on the MFD is the analogue signal, instead of a digital track.

 

A digital or analog doesn't matter. The digital visual is generated from something, and if your digital presentation is wrong from the data you have processed, then becomes wrong in the end as well.

 

 

45 minutes ago, falcon_120 said:

The target track generated by the computer after the processing is done, could perfectly be updated based on the aircraft movement, so the bricks are getting closer cause you are flying towards them

 

If look carefully, the aircraft is moving constantly and so on the bricks should be constantly moving regardless the radar sweep. But the blocks gets updated only when the sweep moves close to them (not after or otherwise). So example when the sweep hast moved past the left most brick it will stop moving as there is no interpolation for the aircraft movement or the target movement. It is only pointing "there was a movement at the time when the radar swept the area" and nothing else. This is why you can't always detect moving vehicles or you get lots of false echoes as well. But the brick should not appear (be updated/created) unless the radar sweep has gone past it.

 

45 minutes ago, falcon_120 said:

and the sweep animation is just to let you know where your radar is looking now. I doubt the movement you are observing is the real target movement since the speed is too low. 

 

The radar scan zones etc are of course visual indicators that what is where. But they are as well indicators for accuracy that when something got detected, moved etc. Example the F-5 radar is old implementation that doesn't present the real F-5 radar scope that should be made from raw radar data, so you don't have a "radar beam" moving from left to right, but just have a non-visible scan line that you can only visually see as a line based the clutter it draws as it updates the scope. Then when larger detection are made they get drawn as well as larger blobs there.

 

This is similar thing with the F-14 radar, why the human RIO could detect something in the clutter patterns almost from twice smaller signal return than what the automatic detection system (digital one like Hornet etc). I don't remember correct orders but it was about -10dB difference for benefit of the human, as the human can just spot so tiny variations and make a educated guess "there is something" while automatic systems are more dependent from signal-noise ratio limitations.

 

The position change should be the real position in the display resolution limits. So if the target position (relative to aircraft) changes between updates, it gets properly moved on the display as well to that location.

 

45 minutes ago, falcon_120 said:

EDIT: Looking at the footage again, it might also be that we are seeing the delay of the Radar computer between the sweep and the time it take to update the track, because otherwise it would be instantaneous more kinda an analogue display showing true non processed returns.

 

There is no delay, there is the advance. The block gets updated before the sweep gets there. The video is first frame by frame forward (coming from left to right) and you can clearly see that the blocks position gets updted before the sweep reaches it. Then when the sweep is at the right, it is video played back in reverse frame by frame at little faster rate and you can see different way how the blocks gets updated.

 

Remember that the sweep can be switched to alternate between map and only with the sweep, this so that you could get a some kind idea that in what kind terrain area the movement was detected. And if your sweep doesn't get properly visualizing that, then how can the detection of movement be there any more accurate either?

 

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 post
Share on other sites

Same thing happens with the bricks on the A/A radar in RWS. It's either an issue with how the entire system works in DCS or that the radar sweep line is just an approximate representation of the actual sweep for the benefit of the pilot and shouldn't be taken literally. I have no idea which one is true.

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

1197644828_Screen_200911_044202-Copy.png.74d8c09ee9060cffd7408a75ab2c13ef.png

Z370 Aorus Gaming 7, i7-8700K, 2080Ti FTW3 Ultra, 32GB DDR4, 960 Pro, 970 Evo Plus, WD Gold 6TB, Seasonic Prime Platinum

F/A-18C, AV-8B, JF-17, A-10C (C II), M-2000C, F-16C, F-14, BS2, UH-1H, P-51D, Sptifire, FC3

Link to post
Share on other sites

Air to air hits are 100% wrong. It's possible that GMT hits are like pseudo trackfiles or something though. Honestly don't know. But I wouldn't be surprised if ED's implementation was wrong given how air to air hits have been wrong since release.

Link to post
Share on other sites
14 hours ago, Jak525 said:

Air to air hits are 100% wrong.

 

What is wrong with AA hits?

Intel Core i5-8600k + Cooler Master Hyper 212 EVO | Gigabyte GTX 1070 Aorus 8G | 32GB DDR4 Corsair Vengance LPX Black 3200MHz | Gigabyte Z370 Aorus Gaming 3 | WD Black SN750 NVMe 500GB | Samsung 850 EVO 250GB | WD Green 240GB | WD Caviar Black 1TB SATA 3 | WD Caviar Blue 500GB SATA 3 | EVGA 650 GQ 80+ Gold | Samsung CF391 Curved 32" | Corsair 400C | Steelseries Arctis 5 --- Razer Kraken X Lite | Logitech G305 | Redragon Dyaus 2 K509 | Xbox 360 | Saitek X-52 Pro | Thrustmaster TWCS | TrackIR 5

Link to post
Share on other sites
7 hours ago, Joni said:

 

What is wrong with AA hits?

They are sometimes correlated where when a new hit is detected the old one disappears. This should never happen. Once a hit is detected it's frozen at that position and will only disappear when the elapsed aging time is up. This creates a "history trail" effect. The longer the aging the farther back you can see.


Edited by Jak525
Link to post
Share on other sites
3 hours ago, Jak525 said:

They are sometimes correlated where when a new hit is detected the old one disappears. This should never happen. Once a hit is detected it's frozen at that position and will only disappear when the elapsed aging time is up. This creates a "history trail" effect. The longer the aging the farther back you can see.

 

 

Oh yeah, that doesn't happen right now.

 

But I thought it was due to trackfiles and the ability of the MC to "know" who is who. Maybe deselecting LTWS will give us the trail effect?

Intel Core i5-8600k + Cooler Master Hyper 212 EVO | Gigabyte GTX 1070 Aorus 8G | 32GB DDR4 Corsair Vengance LPX Black 3200MHz | Gigabyte Z370 Aorus Gaming 3 | WD Black SN750 NVMe 500GB | Samsung 850 EVO 250GB | WD Green 240GB | WD Caviar Black 1TB SATA 3 | WD Caviar Blue 500GB SATA 3 | EVGA 650 GQ 80+ Gold | Samsung CF391 Curved 32" | Corsair 400C | Steelseries Arctis 5 --- Razer Kraken X Lite | Logitech G305 | Redragon Dyaus 2 K509 | Xbox 360 | Saitek X-52 Pro | Thrustmaster TWCS | TrackIR 5

Link to post
Share on other sites
6 hours ago, Joni said:

 

Oh yeah, that doesn't happen right now.

 

But I thought it was due to trackfiles and the ability of the MC to "know" who is who. Maybe deselecting LTWS will give us the trail effect?

No, a trackfile and a hit are different things. A trackfile is represented by a HAFU symbol. A hit is represented by a brick and isn't influenced by trackfiles.

 

LTWS is also modeled quite incorrectly right now. LTWS right now "turns off" trackfile processing basically. What it should do is simply toggle whether cursoring over a raw hit displays its HAFU symbol, versus just the altitude of the hit. However, with LTWS deselected, the trackfile processing still happens under the hood and you would still see the L&S and DT2 as HAFU symbols, if designated, as well as, when MSI is boxed, any datalink-contributed trackfiles.

 

Regardless though, hits are intended to be raw radar data. Trackfiles (HAFU symbols) are extrapolated/correlated based off those hits. Hits themselves should stay in one spot in space.

Link to post
Share on other sites

please keep on topic for the thread please 

 

GTM radar update with sweep animation

smallCATPILOT.PNG.04bbece1b27ff1b2c193b174ec410fc0.PNG

Forum rules - DCS Crashing? Try this first - Cleanup and Repair - Discord BIGNEWY#8703 - Youtube - Patch Status

Windows 10 Pro x64, NVIDIA MSI RTX 2080Ti VENTUS GP, Intel® i9-10900K 3.70GHz, 5.30GHz Turbo, Corsair Hydro Series H150i Pro, 32GB DDR @3000, ASUS ROG Strix Z490-F Gaming, HP Reverb G2

Link to post
Share on other sites
9 hours ago, Jak525 said:

No, a trackfile and a hit are different things. A trackfile is represented by a HAFU symbol. A hit is represented by a brick and isn't influenced by trackfiles.

 

So shouldn't a brick then be created/updated on the moment the radar beam sweeps over the target, and so on not before or later than beam has passed?

As in the more modern radars there are various other features mentioned like capability track 4 air units and 10 ground units, but that is for tracking and otherwise radar system is capable to show all it can find but just as bricks?

So unless you designate multiple targets to be tracked, you get them all being anyways visible but designated ones create the track data as it has its history assigned to it.

And same way as in the air, to acquire the good track, you need multiple updates while on each the data is used to increase the prediction of target future position by knowing more accurately its speed and heading, something you can't get just with one or two sweeps.

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 post
Share on other sites

Sorry for going off topic here lol. Anyway:

9 hours ago, Fri13 said:

 

So shouldn't a brick then be created/updated on the moment the radar beam sweeps over the target, and so on not before or later than beam has passed?

As in the more modern radars there are various other features mentioned like capability track 4 air units and 10 ground units, but that is for tracking and otherwise radar system is capable to show all it can find but just as bricks?

So unless you designate multiple targets to be tracked, you get them all being anyways visible but designated ones create the track data as it has its history assigned to it.

And same way as in the air, to acquire the good track, you need multiple updates while on each the data is used to increase the prediction of target future position by knowing more accurately its speed and heading, something you can't get just with one or two sweeps.

What I said applies to air to air hits. I honestly don't know the proper behavior for GMT. In air to air, two hits is enough for an extrapolation. I don't really know how it's supposed to be for GMT. What you're saying makes sense but it all depends on whether the Ground Moving Target Indication (GMTI, the bricks in GMT) is a trackfile or not.

 

If GMTIs are completely raw then what we see in DCS is surely wrong and it should just work like A/A should work as I explained.

 

If GMTIs are extrapolated, then it wouldn't be wrong for them to move between radar sweeps. However, as you noted they should not move until there's been at least two sweeps, so that the heading/speed can be determined and then the position extrapolated. It's also quite weird how in the video we saw the hits "jumping" ahead before and after the antenna swept over them. If they're extrapolated then the movement should be smooth. The jumpy behavior would be more like true raw hits.


Edited by Jak525
Link to post
Share on other sites

FWIW, the A/A tracks also don't work correctly, since now even one sweep is enough to generate a trackfile. A trackfile should require at least two hits that can be correlated. I believe the Viper's TWS works more correctly in that regard, requiring at least two hits before a TWS track is generated, at least it did last time I checked.

Seems like the brick and track logic in the Hornet needs a small rework.

  • Like 1

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

1197644828_Screen_200911_044202-Copy.png.74d8c09ee9060cffd7408a75ab2c13ef.png

Z370 Aorus Gaming 7, i7-8700K, 2080Ti FTW3 Ultra, 32GB DDR4, 960 Pro, 970 Evo Plus, WD Gold 6TB, Seasonic Prime Platinum

F/A-18C, AV-8B, JF-17, A-10C (C II), M-2000C, F-16C, F-14, BS2, UH-1H, P-51D, Sptifire, FC3

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...