Narrative:

An arrival aircraft from sgf to dfw was given a descent clearance with no traffic observed. After this aircraft (aircraft X) was handed off to the next controller, conflict alert activated and the E120's (aircraft Y's) data block appeared out of nowhere, showing these 2 aircraft at the same altitude. There were 2 separate data blocks, 2 radar targets and the radar was tracking a history on both aircraft. After I pulled up the flight plan information on the second aircraft, I realized he was an aircraft that I had worked earlier (a departure of dfw landing fsm). This second aircraft should have already been on the ground at fsm, but somehow our radar was tracking him with a good solid target, history and data block information. Our radar has to be trusted to do this job. In sits like this, the radar distracts all our attention, scares the controller, and wastes a lot of time with the controller trying to figure out what is going on and trying to verify if this is a real conflict and what actions to take to resolve it. As a controller, I also lose a lot of confidence in the radar when we figure out it's a false target, history and conflict alert. There has been no explanation as to why or how this occurred, but it has happened a few times before. If the radar is showing a real target with histories and mode C, how are we to know that it is real or just some 'glitch in the system' that can't be explained? Callback conversation with reporter revealed the following information: reporter stated the E120 had been handed off to ZME. The E120 was in en route descent from dfw to fsm. The SF34 was in en route descent from sgf to dfw and the reporter had just effected an automated handoff xfer to the next low altitude, ZFW en route sector, which was approximately 40 mi southeast of mlc VORTAC. After the handoff, a complete data block of the previously handed off E120 began tracking the same direction (sebound) with the SF34. The target was displayed within 1 mi of the SF34, showing the same altitude, displaying a radar tracking history trail, activating conflict alert. The reporter advised that a traffic alert was given, but the SF34 flight crew could not see the issued traffic. The reporter initiated a computer route readout/display, and recognized that the E120 was an aircraft which the controller had worked through the sector and had handed off the ZME approximately 15 mins prior. Analyst asked if both aircraft had been issued the same transponder code, but the reporter advised that that factor had been overlooked. The false data block soon stopped tracking along with the SF34. The reporter could not remember if the dropped data tag transitioned into the controller's 'CST' list or dropped completely from the radar indicator. The reporter stated that similar instances have occurred in the last couple months in the same sector. The primary tracking radar site for the mcalester radar low sector is from the chelsa radar site, northeast of tulsa, ok. The reporter alerted this problem to the supervisor, and received an explanation that this was just a 'glitch in the system.' the reporter perceives that this problem will not be investigated because of 'other more important' factors happening in the facility. ZFW has just completed extensive xtraining, expanding from 6 operational areas to 7, and beginning transition into the new display replacement system room. The reporter believes this problem may not be resolved.

Related reports:

Google
 

Original NASA ASRS Text

Title: ZFW CTLR IS SUDDENLY AWARE OF DISPLAYED CONFLICT BTWN 2 ACRS. CTLR INVESTIGATION DETERMINES FALSE DATA BLOCK IS FROM AN ACR WHICH IS PERCEIVED TO HAVE LANDED AT AN ARPT JUST OUTSIDE OF CTLR'S SECTOR.

Narrative: AN ARR ACFT FROM SGF TO DFW WAS GIVEN A DSCNT CLRNC WITH NO TFC OBSERVED. AFTER THIS ACFT (ACFT X) WAS HANDED OFF TO THE NEXT CTLR, CONFLICT ALERT ACTIVATED AND THE E120'S (ACFT Y'S) DATA BLOCK APPEARED OUT OF NOWHERE, SHOWING THESE 2 ACFT AT THE SAME ALT. THERE WERE 2 SEPARATE DATA BLOCKS, 2 RADAR TARGETS AND THE RADAR WAS TRACKING A HISTORY ON BOTH ACFT. AFTER I PULLED UP THE FLT PLAN INFO ON THE SECOND ACFT, I REALIZED HE WAS AN ACFT THAT I HAD WORKED EARLIER (A DEP OF DFW LNDG FSM). THIS SECOND ACFT SHOULD HAVE ALREADY BEEN ON THE GND AT FSM, BUT SOMEHOW OUR RADAR WAS TRACKING HIM WITH A GOOD SOLID TARGET, HISTORY AND DATA BLOCK INFO. OUR RADAR HAS TO BE TRUSTED TO DO THIS JOB. IN SITS LIKE THIS, THE RADAR DISTRACTS ALL OUR ATTN, SCARES THE CTLR, AND WASTES A LOT OF TIME WITH THE CTLR TRYING TO FIGURE OUT WHAT IS GOING ON AND TRYING TO VERIFY IF THIS IS A REAL CONFLICT AND WHAT ACTIONS TO TAKE TO RESOLVE IT. AS A CTLR, I ALSO LOSE A LOT OF CONFIDENCE IN THE RADAR WHEN WE FIGURE OUT IT'S A FALSE TARGET, HISTORY AND CONFLICT ALERT. THERE HAS BEEN NO EXPLANATION AS TO WHY OR HOW THIS OCCURRED, BUT IT HAS HAPPENED A FEW TIMES BEFORE. IF THE RADAR IS SHOWING A REAL TARGET WITH HISTORIES AND MODE C, HOW ARE WE TO KNOW THAT IT IS REAL OR JUST SOME 'GLITCH IN THE SYS' THAT CAN'T BE EXPLAINED? CALLBACK CONVERSATION WITH RPTR REVEALED THE FOLLOWING INFO: RPTR STATED THE E120 HAD BEEN HANDED OFF TO ZME. THE E120 WAS IN ENRTE DSCNT FROM DFW TO FSM. THE SF34 WAS IN ENRTE DSCNT FROM SGF TO DFW AND THE RPTR HAD JUST EFFECTED AN AUTOMATED HDOF XFER TO THE NEXT LOW ALT, ZFW ENRTE SECTOR, WHICH WAS APPROX 40 MI SE OF MLC VORTAC. AFTER THE HDOF, A COMPLETE DATA BLOCK OF THE PREVIOUSLY HANDED OFF E120 BEGAN TRACKING THE SAME DIRECTION (SEBOUND) WITH THE SF34. THE TARGET WAS DISPLAYED WITHIN 1 MI OF THE SF34, SHOWING THE SAME ALT, DISPLAYING A RADAR TRACKING HISTORY TRAIL, ACTIVATING CONFLICT ALERT. THE RPTR ADVISED THAT A TFC ALERT WAS GIVEN, BUT THE SF34 FLC COULD NOT SEE THE ISSUED TFC. THE RPTR INITIATED A COMPUTER RTE READOUT/DISPLAY, AND RECOGNIZED THAT THE E120 WAS AN ACFT WHICH THE CTLR HAD WORKED THROUGH THE SECTOR AND HAD HANDED OFF THE ZME APPROX 15 MINS PRIOR. ANALYST ASKED IF BOTH ACFT HAD BEEN ISSUED THE SAME XPONDER CODE, BUT THE RPTR ADVISED THAT THAT FACTOR HAD BEEN OVERLOOKED. THE FALSE DATA BLOCK SOON STOPPED TRACKING ALONG WITH THE SF34. THE RPTR COULD NOT REMEMBER IF THE DROPPED DATA TAG TRANSITIONED INTO THE CTLR'S 'CST' LIST OR DROPPED COMPLETELY FROM THE RADAR INDICATOR. THE RPTR STATED THAT SIMILAR INSTANCES HAVE OCCURRED IN THE LAST COUPLE MONTHS IN THE SAME SECTOR. THE PRIMARY TRACKING RADAR SITE FOR THE MCALESTER RADAR LOW SECTOR IS FROM THE CHELSA RADAR SITE, NE OF TULSA, OK. THE RPTR ALERTED THIS PROB TO THE SUPVR, AND RECEIVED AN EXPLANATION THAT THIS WAS JUST A 'GLITCH IN THE SYS.' THE RPTR PERCEIVES THAT THIS PROB WILL NOT BE INVESTIGATED BECAUSE OF 'OTHER MORE IMPORTANT' FACTORS HAPPENING IN THE FACILITY. ZFW HAS JUST COMPLETED EXTENSIVE XTRAINING, EXPANDING FROM 6 OPERATIONAL AREAS TO 7, AND BEGINNING TRANSITION INTO THE NEW DISPLAY REPLACEMENT SYS ROOM. THE RPTR BELIEVES THIS PROB MAY NOT BE RESOLVED.

Data retrieved from NASA's ASRS site as of July 2007 and automatically converted to unabbreviated mixed upper/lowercase text. This report is for informational purposes with no guarantee of accuracy. See NASA's ASRS site for official report.