Jump to content

Is PRF backwards?


Recommended Posts

Yesterday I was talking to a friend of mine who has had some training with radar systems and he told me that HPRF and MPRF is back to front in the sim. Basically, he said that HPRF is limited to shorter ranges and MPRF is better suited for detecting targets at long range, and briefly explained why. But in DCS we use HPRF to see people at longer ranges and MPRF when they're in closer. I did a quick bit of googling and it seems to corroborate what he's saying. I'm not going to pretend to be at all knowledgeable when it comes to radar in the real world. I like to think I have a basic understanding, but it's just that, basic. So I'll ask here, are the PRF settings backwards? Is it something that's known but just hasn't been addressed yet as it's not super important? Is it something that has been overlooked? Or is there a reason that HPRF is for long range and MPRF is for closer in in the sim?

[sIGPIC][/sIGPIC]

Link to comment
Share on other sites

...So I'll ask here, are the PRF settings backwards? Is it something that's known but just hasn't been addressed yet as it's not super important? Is it something that has been overlooked?

No. It's not backwards. At least not according to the real world Su-27SK manual.

YouTube Channel: https://www.youtube.com/channel/UCU1...CR6IZ7crfdZxDg

 

_____

Win 10 Pro x64, ASUS Z97 Pro MoBo, Intel i7-4790K, EVGA GTX 970 4GB, HyperX Savage 32GB, Samsung 850 EVO 250 GB SSD, 2x Seagate Hybrid Drive 2TB Raid 0.

Link to comment
Share on other sites

Every piece of radar employment literature in the context that we employ it here claims the head-on detection range is greatest for HPRF, and tail-on detection range is greatest for MPRF (much shorter than HPRF typically anyway)

 

Yesterday I was talking to a friend of mine who has had some training with radar systems and he told me that HPRF and MPRF is back to front in the sim. Basically, he said that HPRF is limited to shorter ranges and MPRF is better suited for detecting targets at long range, and briefly explained why. But in DCS we use HPRF to see people at longer ranges and MPRF when they're in closer. I did a quick bit of googling and it seems to corroborate what he's saying. I'm not going to pretend to be at all knowledgeable when it comes to radar in the real world. I like to think I have a basic understanding, but it's just that, basic. So I'll ask here, are the PRF settings backwards? Is it something that's known but just hasn't been addressed yet as it's not super important? Is it something that has been overlooked? Or is there a reason that HPRF is for long range and MPRF is for closer in in the sim?

[sIGPIC][/sIGPIC]

Reminder: SAM = Speed Bump :D

I used to play flight sims like you, but then I took a slammer to the knee - Yoda

Link to comment
Share on other sites

Setting the PRF on your radar should not be a consideration of range, but rather aspect.

 

Is the target(s) heading towards you (closing), away from you (extending) , flanking (neither) or unknown?

 

Use AWACS, EWR or your own radar to determine aspect.

 

Russian aircraft:

Target is closing = use HI PRF

Target is extending = use MED PRF

Target is flanking or unknown = Use ILU PRF

 

American aircraft:

Target is closing = use HI PRF

Target is extending = use MED PRF

Target is flanking or unknown = Use INT PRF


Edited by Winston60

Link to comment
Share on other sites

Hmm, ok. Thanks everyone for the clarification.

 

The clarification is only partial. In some respects, your friend is correct. On its face, you should have to use H-PRF for shorter ranges than M-PRF. It's because of this thing called time. How a simple radar works is: A pulse goes out. An echo returns. You measure the amount of time that passed, do the math, and the result is an unambiguous range to the source of that echo. Successive echoes allow you to measure aspect and speed as well. But it all requires those unambiguous range readings. And you have more time between the pulses in M-PRF than H-PRF.

 

But here's the problem that your friend was having. When the object is distant, a pulse goes out. No echo returns. Another pulse goes out. An echo returns. Which pulse does the echo belong to? The first or the second? The range is now ambiguous. The system can't tell how far away the object actually is and all the math falls apart.

 

What your friend didn't mention is that modern pulse Doppler radars, in very simplistic terms, massage each outgoing pulse in some manner. When the echo returns, the software matches those distinct characteristics carried on the echo to the outgoing pulse. And we're back to unambiguous measurements of range.


Edited by Ironhand

YouTube Channel: https://www.youtube.com/channel/UCU1...CR6IZ7crfdZxDg

 

_____

Win 10 Pro x64, ASUS Z97 Pro MoBo, Intel i7-4790K, EVGA GTX 970 4GB, HyperX Savage 32GB, Samsung 850 EVO 250 GB SSD, 2x Seagate Hybrid Drive 2TB Raid 0.

Link to comment
Share on other sites

The clarification is only partial. In some respects, your friend is correct. On its face, you should have to use H-PRF for shorter ranges than M-PRF. It's because of this thing called time. How a simple radar works is: A pulse goes out. An echo returns. You measure the amount of time that passed, do the math, and the result is an unambiguous range to the source of that echo. Successive echoes allow you to measure aspect and speed as well. But it all requires those unambiguous range readings. And you have more time between the pulses in M-PRF than H-PRF.

 

But here's the problem that your friend was having. When the object is distant, a pulse goes out. No echo returns. Another pulse goes out. An echo returns. Which pulse does the echo belong to? The first or the second? The range is now ambiguous. The system can't tell how far away the object actually is and all the math falls apart.

 

What your friend didn't mention is that modern pulse Doppler radars, in very simplistic terms, massage each outgoing pulse in some manner. When the echo returns, the software matches those distinct characteristics carried on the echo to the outgoing pulse. And we're back to unambiguous measurements of range.

 

Ah. The part that he explained to me was this: "A pulse goes out. An echo returns. You measure the amount of time that passed, do the math, and the result is an unambiguous range to the source of that echo." So the problem of sending out another pulse before the echo of a previous one returns has been solved?

[sIGPIC][/sIGPIC]

Link to comment
Share on other sites

Ah. The part that he explained to me was this: "A pulse goes out. An echo returns. You measure the amount of time that passed, do the math, and the result is an unambiguous range to the source of that echo." So the problem of sending out another pulse before the echo of a previous one returns has been solved?

A qualified "yes". As with everything, there are compromises. But the solutions bright minds can come up with are simply amazing...and oftentimes incomprehensible to layman like me.


Edited by Ironhand

YouTube Channel: https://www.youtube.com/channel/UCU1...CR6IZ7crfdZxDg

 

_____

Win 10 Pro x64, ASUS Z97 Pro MoBo, Intel i7-4790K, EVGA GTX 970 4GB, HyperX Savage 32GB, Samsung 850 EVO 250 GB SSD, 2x Seagate Hybrid Drive 2TB Raid 0.

Link to comment
Share on other sites

It has been solved half a century ago :)

 

Ah. The part that he explained to me was this: "A pulse goes out. An echo returns. You measure the amount of time that passed, do the math, and the result is an unambiguous range to the source of that echo." So the problem of sending out another pulse before the echo of a previous one returns has been solved?

[sIGPIC][/sIGPIC]

Reminder: SAM = Speed Bump :D

I used to play flight sims like you, but then I took a slammer to the knee - Yoda

Link to comment
Share on other sites

You can read about some methods in the radar bible - not all apply to this topic, but there are things like pulse compression, chirping, etc.

[sIGPIC][/sIGPIC]

Reminder: SAM = Speed Bump :D

I used to play flight sims like you, but then I took a slammer to the knee - Yoda

Link to comment
Share on other sites

You don't necessarily need to encode each pulse uniquely, as you can also alter the delay between pulses (essentially PRF) using well though out pattern so you can later figure out the target range comparing multiple pulses and their timings.

DCS Finland: Suomalainen DCS yhteisö -- Finnish DCS community

--------------------------------------------------

SF Squadron

Link to comment
Share on other sites

You can read about some methods in the radar bible - not all apply to this topic, but there are things like pulse compression, chirping, etc.

 

While pulse coloring is an option, radars are rarely ever designed that way. More often then not, those techniques are used to improve range resolution and S/N ratios.

 

A qualified "yes". As with everything, there are compromises. But the solutions bright minds can come up with are simply amazing...and oftentimes incomprehensible to layman like me.

It's not all that complicated, at least this particular aspect isn't.

 

 

As stated above all you do is change the PRF/PRI, and compare all the different echo ranges you receive in a single dwell period. The inaccurately measured echos will change position when you change your PRF. However, the accurate echo range won't change.

 

Example:

If I have a constant PRI of 100usec, then my max unambiguous range is 8.09nm

(the time it takes light to travel 1nm is 6.18usec)

(for a two way path, it's 12.36usec)

(divide our 100usec Pulse repetition interval by 12.36 and you get 8.09nm)

 

If a target exists at 10 miles I would get my first return after I have already fired a 2nd pulse.

10nm equates to a period of 123.6usec of travel time. Subtract the 100usec period from our first pulse period and the remainder is simply 23.6usec(the time our radar thinks it took the 2nd pulse to leave and come back) which is 1.9nm in distance for light speed.

 

So we have our first inaccurate echo at 1.9nm.

 

Radar engineers understand this dilemma, so modern radars are designed to consider that the echo wasn't from the most recent pulse, but the one before that one. Or perhaps the pulse even before that one. So on and so forth.

 

So eventually, there is a bin that holds a number of range possibilities for the target, based on which pulse it could of been from.

 

To calculate the range if fired from and earlier pulse, simply add one pulse interval period for each subsequent transmission possibility.

 

If we were to file these potential ranges based on it being from the most recent transmission to the oldest it would look like this.

 

(PRI is still 100usec/real target is still 123.6usec away aka 10nm)

Range BIN for PRI 1

1.9nm (if returned from most recent transmission)

10nm (if from the pulse before that one ^)

18.09nm (if from the pulse before that one ^)

26.18nm (etc..^)

34.27nm (etc.. ^)

42.36nm (etc.. ^)

and this could continue until a range the engineers decide is to far for the radar to see based on other factors.

 

But If i cycle the PRI so there is a second and third PRI, we will see all of those false ranges change position but the real target range wont.

 

(PRI of 80usec/real target is still ~123.6usec away)

Range BIN for PRI 2

3.5nm (if returned from most recent transmission)

10nm (if returned from the pulse before that one ^)

16.47nm (etc.. ^)

22.94nm (etc.. ^)

29.41nm (etc.. ^)

 

(PRI of 60usec/real target is still ~123.6usec away)

Range BIN for PRI 3

0.29nm (if returned from most recent transmission)

5.14nm (if returned from the pulse before that one ^)

10nm (etc.. ^)

14.85nm (etc.. ^)

19.7nm (etc.. ^)

 

As you can see, only one range doesn't change between the different PRIs, 10nm. This process is known as range match filtering. Though, more than three PRIs may be used IRL, as to eliminate harmonic blind zones.

 

(Illustration below is just an visual aid, and is not based off figures above)

 

t4zs8CK.png?1


Edited by Beamscanner
Link to comment
Share on other sites

  • Recently Browsing   0 members

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