need evidebnce of actual error Raw hits on HI PRF detections

[Tholozor]

Raw hits on contacts detected in HI PRF are not co-located with their respective trackfile, and are not drawn on every detection.

PRF_Detection_Brick_Position.trk

[Harker]

The trackfile's position on the display is extrapolated between detections, using the stored target velocity, to present a smooth and continuous picture to the pilot. It's reasonable to assume that even if the target is detected in a closer bin, the MC knows the target didn't physically jump there, given a stable velocity.

An alternative would be to present the trackfile always in the bin in which was detected, but that would disregard the extrapolation. That disagrees with the data I've found.

However, the third option, that I have observed in one video of the Viper's radar (can't find any videos of the Hornet's), is to have the trackfile be extrapolated in its current bin, and once the target is detected in the next bin, the trackfile jumps to the center of that bin and begins its extrapolated movement there. That way, you only have jumps when the target enters another bin, but a smooth presentation otherwise. This might be the best of both worlds, as it leans towards the side of caution. Ultimately though, I've found no public info other than "the MC extrapolates between detections to give a smooth target presentation".

NB. The same behavior happens in MPRF, but is harder to see, because the MPRF bins are smaller.

[toilet2000]

On 10/28/2023 at 6:43 PM, Harker said:

The trackfile's position on the display is extrapolated between detections, using the stored target velocity, to present a smooth and continuous picture to the pilot. It's reasonable to assume that even if the target is detected in a closer bin, the MC knows the target didn't physically jump there, given a stable velocity.

An alternative would be to present the trackfile always in the bin in which was detected, but that would disregard the extrapolation. That disagrees with the data I've found.

However, the third option, that I have observed in one video of the Viper's radar (can't find any videos of the Hornet's), is to have the trackfile be extrapolated in its current bin, and once the target is detected in the next bin, the trackfile jumps to the center of that bin and begins its extrapolated movement there. That way, you only have jumps when the target enters another bin, but a smooth presentation otherwise. This might be the best of both worlds, as it leans towards the side of caution. Ultimately though, I've found no public info other than "the MC extrapolates between detections to give a smooth target presentation".

NB. The same behavior happens in MPRF, but is harder to see, because the MPRF bins are smaller.

Considering the Hornet is built around MSI, it would be surprising if a track jumped between bin changes. To the opposite, a very basic linear Kalman target state estimator would smooth out these jumps given the high range measurement uncertainty (variance).

 

My guess would be exactly as is currently: raw hits jump, tracks are smoothly interpolated.

Edited October 30, 2023 by toilet2000

[Tholozor]

Thanks for the explanation @Harker, any thoughts on raw hits not being displayed on certain sweeps? I noticed that even on a 1B scan (with elevation adjusted so the contact would firmly fit into the scan volume), a raw hit isn't displayed until after a number of sweeps. Is this also part of the HPRF range bins?

[Harker]

Thanks for the explanation @Harker, any thoughts on raw hits not being displayed on certain sweeps? I noticed that even on a 1B scan (with elevation adjusted so the contact would firmly fit into the scan volume), a raw hit isn't displayed until after a number of sweeps. Is this also part of the HPRF range bins?

With the latest OB update, detection probability (PD) was implemented. It's possible to not detect a target in a particular sweep, even if the probability is high.

Based on the new trackfile memory scheme, you need 6 seconds without any target detections to enter memory, so you can miss a detection, and still have the trackfile remain perfectly fine.

[Tholozor]

3 hours ago, Harker said:

With the latest OB update, detection probability (PD) was implemented. It's possible to not detect a target in a particular sweep, even if the probability is high.

Based on the new trackfile memory scheme, you need 6 seconds without any target detections to enter memory, so you can miss a detection, and still have the trackfile remain perfectly fine.

Yea, noticed the Pd, well done on that, that's mainly why I tried to keep testing limited to large RCS contacts within 40nmi to keep Pd as high as possible. Just ran an additional test, and from what I can tell the raw hits are still being display on every sweep, but as you mentioned before, their positionally spaced according to their range bin (my original test was basically doomed from the start, ha!). Re-tested with multiple, large RCS contacts at varying ranges and bearings, which resulted in multiple raw hits positioned at the same range bin position, but at slightly differing angles due to the azimuth of detection, cool stuff!

Leaving this here for anyone who might've thought along the same lines I did originally. You can see the faded bricks from prior detections slightly offset from fresh hits.

Edited October 30, 2023 by Tholozor