Radar Question
Thread Starter
Join Date: Jan 2010
Location: UK
Posts: 302
Likes: 0
Received 0 Likes
on
0 Posts
Radar Question
Off to Tehran, so having a look at the NOTAMs and came across a term that, despite an extensive search and being asked in multiple combinations of phrase, has yielded no answer. Any radar experts able to explain exactly what a track jumping problem is??
OIIE-A1955/17
From: 14/06/2017 09:16 UTC
To: 16/12/2017 23:59 UTC (EST)
OIIE PSR RADAR INFORMATION UNRELIABLE,
DUE TO TRACK JUMPING PROBLEM.
OIIE-A1955/17
From: 14/06/2017 09:16 UTC
To: 16/12/2017 23:59 UTC (EST)
OIIE PSR RADAR INFORMATION UNRELIABLE,
DUE TO TRACK JUMPING PROBLEM.
Join Date: Jan 2008
Location: The foot of Mt. Belzoni.
Posts: 2,001
Likes: 0
Received 0 Likes
on
0 Posts
They could mean 'Track Jitter', Dave.
It used to occur with SSR in the early days of processed radar. The trail dots behind the aircraft position symbol weren't presented in a straight line, and it gave the impression that a/c were making a succession of small turns.
It may depend on how their primary surveillance radar (PSR) data is processed.
It used to occur with SSR in the early days of processed radar. The trail dots behind the aircraft position symbol weren't presented in a straight line, and it gave the impression that a/c were making a succession of small turns.
It may depend on how their primary surveillance radar (PSR) data is processed.
Join Date: Jun 2001
Location: Wherever someone will pay me to do fun stuff
Posts: 1
Likes: 0
Received 0 Likes
on
0 Posts
A possible explanation - but from a controller's perspective only (not an engineer)....
In processed radar systems a position symbol is usually only presented to the controller when the radar boxes decide that there really is something there. With PSR the radar will think something is real when a certain number of updates show a target moving in a way that is consistent with an aircraft (I think that the characteristics of the return are also assessed in some systems).
When the radar has decided 'it' is real it will create a track and put a position symbol on the display. It will then start to predict where that target is likely to be on the next update and, if it finds a return in that position it decides it's the same aircraft and displays it to the controller.
All of this electronic trickery is to minimise the presentation of false targets, reflections and all of the other things that used to make radar displays look messy.
To help the controller to keep the identification of each target it is possible to associate a label with a particular track. The problem is that if two or more targets get close to each other it is possible for the radar to confuse which target should have which label and you can get track/label swap. Unfortunately the nice labels associated with PSR returns on a nice clean display look very much like the picture you get with SSR and it is easy to be lulled into a false sense of security and to think that everything is exactly as it looks on screen but if you have PSR only there are many potential gotchas to catch the unwary.
So track jumping may be a problem within the radar processing system......or, maybe something else completely.
In processed radar systems a position symbol is usually only presented to the controller when the radar boxes decide that there really is something there. With PSR the radar will think something is real when a certain number of updates show a target moving in a way that is consistent with an aircraft (I think that the characteristics of the return are also assessed in some systems).
When the radar has decided 'it' is real it will create a track and put a position symbol on the display. It will then start to predict where that target is likely to be on the next update and, if it finds a return in that position it decides it's the same aircraft and displays it to the controller.
All of this electronic trickery is to minimise the presentation of false targets, reflections and all of the other things that used to make radar displays look messy.
To help the controller to keep the identification of each target it is possible to associate a label with a particular track. The problem is that if two or more targets get close to each other it is possible for the radar to confuse which target should have which label and you can get track/label swap. Unfortunately the nice labels associated with PSR returns on a nice clean display look very much like the picture you get with SSR and it is easy to be lulled into a false sense of security and to think that everything is exactly as it looks on screen but if you have PSR only there are many potential gotchas to catch the unwary.
So track jumping may be a problem within the radar processing system......or, maybe something else completely.
Join Date: Dec 2006
Location: Florida and wherever my laptop is
Posts: 1,350
Likes: 0
Received 0 Likes
on
0 Posts
As lookingforajob has said there can be many reasons for track jitter - jumping is a little more difficult to achieve but I have seen it.
The first is a Kalman filter issue where as LFAJ explained the system extrapolates the next position of the aircraft from its previous radar track positions it puts a box around that and if the next position is anywhere in the box it recenters the track report in the box if the track was right at the edge though it will increase the size of the next predicted box this repeats and usually if it is track jitter the next report will be close to the predicted position. If the aircraft had started a turn the effect is for the aircraft displayed track to continue in a straight line for 3 or even 4 responses then suddenly the filter accepts it is not jitter and the displayed response jumps to where the actual response was - this can be disconcerting if you instruct an aircraft to turn for deconfliction and it appears to continue on the original heading.
Another track jump problem can be caused with primary returns in a 'mosaiced' radar display system where multiple radars are used. A secondary response will these days normally have mode 3/A and C so a position and an altitude. From this altitude the radar processing can convert the slant range to actual range to the plan position of the aircraft. If there is no altimeter then the processing still has to convert the slant range to actual plan range but now has to 'guess' (cough) use a default parameter. This would normally be something like 25,000 ft for an en-route radar. Now imagine that your mosaic has a PSR served area next to an SSR served area the PSR is using the default 25,000ft the SSR is using the actual 38,000ft it is actually possible to have two returns for the same aircraft in cases like this as the PSR thinks the aircraft is in its mosaic area and the SSR knows the aircraft is in its area. An intermittent altimeter squawk can also create two aircraft.
A final way to have problems is if the comms system from the radars to the control center is having problems and a simple buffering on overflow is happening. This can result in some PSR positions getting through on time and others sitting in a buffer. The controller sees intermittent position reports for the aircraft then the buffer releases the data being held and the controller suddenly gets old primary responses and the aircraft appears to jump back a few miles then the next response gets through and the aircraft jumps forward several miles and so on. Add in tools that use the last responses of the aircraft to 'predict its vector' usually a simple line ahead of the aircraft with a length equating to say a minute's flight - and now you have a recipe for confusion as the aircraft dances back and forth along its track the prediction similarly points back then forward with unrealistic projections of where the aircraft will be.
I would think that it is the last of the three that is the problem. I saw it sometime ago on a NATS system when the digitisers at the radar heads were being swamped by weather. However, Tehran doesn't seem to have that kind of weather so I would go for a ground datalink comms problem causing buffering of the radar returns from the radar head so they are being received by the processors in the control center in a semi-random sequence.
The first is a Kalman filter issue where as LFAJ explained the system extrapolates the next position of the aircraft from its previous radar track positions it puts a box around that and if the next position is anywhere in the box it recenters the track report in the box if the track was right at the edge though it will increase the size of the next predicted box this repeats and usually if it is track jitter the next report will be close to the predicted position. If the aircraft had started a turn the effect is for the aircraft displayed track to continue in a straight line for 3 or even 4 responses then suddenly the filter accepts it is not jitter and the displayed response jumps to where the actual response was - this can be disconcerting if you instruct an aircraft to turn for deconfliction and it appears to continue on the original heading.
Another track jump problem can be caused with primary returns in a 'mosaiced' radar display system where multiple radars are used. A secondary response will these days normally have mode 3/A and C so a position and an altitude. From this altitude the radar processing can convert the slant range to actual range to the plan position of the aircraft. If there is no altimeter then the processing still has to convert the slant range to actual plan range but now has to 'guess' (cough) use a default parameter. This would normally be something like 25,000 ft for an en-route radar. Now imagine that your mosaic has a PSR served area next to an SSR served area the PSR is using the default 25,000ft the SSR is using the actual 38,000ft it is actually possible to have two returns for the same aircraft in cases like this as the PSR thinks the aircraft is in its mosaic area and the SSR knows the aircraft is in its area. An intermittent altimeter squawk can also create two aircraft.
A final way to have problems is if the comms system from the radars to the control center is having problems and a simple buffering on overflow is happening. This can result in some PSR positions getting through on time and others sitting in a buffer. The controller sees intermittent position reports for the aircraft then the buffer releases the data being held and the controller suddenly gets old primary responses and the aircraft appears to jump back a few miles then the next response gets through and the aircraft jumps forward several miles and so on. Add in tools that use the last responses of the aircraft to 'predict its vector' usually a simple line ahead of the aircraft with a length equating to say a minute's flight - and now you have a recipe for confusion as the aircraft dances back and forth along its track the prediction similarly points back then forward with unrealistic projections of where the aircraft will be.
I would think that it is the last of the three that is the problem. I saw it sometime ago on a NATS system when the digitisers at the radar heads were being swamped by weather. However, Tehran doesn't seem to have that kind of weather so I would go for a ground datalink comms problem causing buffering of the radar returns from the radar head so they are being received by the processors in the control center in a semi-random sequence.
Join Date: May 2010
Location: Boston
Age: 73
Posts: 443
Likes: 0
Received 0 Likes
on
0 Posts
A final way to have problems is if the comms system from the radars to the control center is having problems and a simple buffering on overflow is happening. This can result in some PSR positions getting through on time and others sitting in a buffer. The controller sees intermittent position reports for the aircraft then the buffer releases the data being held and the controller suddenly gets old primary responses and the aircraft appears to jump back a few miles then the next response gets through and the aircraft jumps forward several miles and so on.
Join Date: Dec 2006
Location: Florida and wherever my laptop is
Posts: 1,350
Likes: 0
Received 0 Likes
on
0 Posts
It is streamed transient data from a radar head and it is not worth the overhead to put timestamps on the data; so it is actually better to just discard rather than buffer the data. But communications designs tend not to like discarding data. The amount of data is often underestimated an SSR sweeping a target at 100 miles will have more than 10 interrogation responses a primary radar (dependent on PRF) will also have multiple hits/reflections on most targets so you can lose a few without problem.
I expect considerable advances in surveillance / position reporting in the next few years that will make most of what is used (and even planned) now obsolete.
I expect considerable advances in surveillance / position reporting in the next few years that will make most of what is used (and even planned) now obsolete.
Join Date: Aug 2013
Location: PA
Age: 59
Posts: 30
Likes: 0
Received 0 Likes
on
0 Posts
I think in this case the track jumping potential may be due to a major upgrade going on to the system. (Thales)
As Ian noted, track jumping is typically when the aircraft track switches from one coverage to another, and the associated disconnect with creating a single track by discarding the outlyers.
Perhaps aniticipating coordinating/calibrating the mutliple radar systems.
We sometimes have issues sorting this when designing new tracks into areas where there were none previously.
EDIT: Ian, it was always a bit interesting to see the look on the drivers faces when they learn the radar image is an estimate of where the ac is based on the kalman filter!
As Ian noted, track jumping is typically when the aircraft track switches from one coverage to another, and the associated disconnect with creating a single track by discarding the outlyers.
Perhaps aniticipating coordinating/calibrating the mutliple radar systems.
We sometimes have issues sorting this when designing new tracks into areas where there were none previously.
EDIT: Ian, it was always a bit interesting to see the look on the drivers faces when they learn the radar image is an estimate of where the ac is based on the kalman filter!
Last edited by underfire; 1st Sep 2017 at 19:37.
