Narrative:

Aircraft X was an arrival to pns descending to 11;000 feet from the east direct pensi direct pns. This routing places the aircraft in a position to enter the pns south MOA after pensi if pensacola approach does not descend the aircraft. In this instance; the aircraft was flashing to P1E and everything looked normal. 10 miles east of pensi; I called pensacola east for a handoff. The controller said that he did not see anything. I stated the code and position and he again said that he did not see anything. I was perplexed and decided to turn the aircraft; so I jumped off the land line and turned aircraft X right to a 300 heading. The aircraft did not make a fast turn and ended up entering the 1C block of the pns south moa at 11;000 feet. A different controller at pns approach called back and asked about the code. I stated the call sign and position again and he said that he only saw a primary. I questioned this and he said a beacon primary. I have never heard of a beacon primary; but asked again if he sees the code and he said yes and that he would be radar contact when he was clear of the MOA. He never told me if there was an aircraft in the 1C block; but from what I could see; I did not see anyone in that portion of the MOA. I turned aircraft X to a 360 heading around one of my blocks that was active in the pns north MOA and then the pensacola controller called back and said that he was radar and to descend him to 9000 feet. At the same time I was fighting with ZHU over pns arrivals from the west because they continually want to use a flash through procedure that does not exist and put the aircraft straight on pns approach. They have been told numerous times to not do this; yet they continue. This is dangerous because our arrivals from the west and east are both at 11;000 feet direct pensi; head on and we have nowhere to turn anyone without hitting a moa. After investigating the cause of this handoff problem; I found that the fusion tracker at pns had tagged up on a helicopter off of mob southbound to the oil rigs. The code that aircraft X was on; appears to be an ADIZ code for helicopters; but is not restricted in our computer; so pns stars never correlated our track with the real aircraft; it only showed it was a * with altitude. That is also why the controllers at pns were confused about identifying the aircraft. We have had numerous incidents with handoffs to stars facilities using fusion tracker. This is the 3rd in the last two weeks and shows how much trouble this can cause; because the controller has no indication that a handoff is not working until the aircraft is close to the boundary. We have spoken to the terminal automation and eram interface leads and they are getting confused on what it is doing as well. The fusion tracker will still keep tracking a plane even after we change it to a different code and will never look again for the code. The other issue is that eram (enroute automation modernization) is sending stars (standard terminal automation replacement system) a track update position and position as part of the handoff message; yet the fusion tracker does not care and tracks the closest target on that code. In this instance; there was no room to maneuver or time to avoid the airspace deviation; but I mitigated it as much as I could. In this corridor; there is no room to maneuver and if the automation does not work and you have no indication; there is not much we can do.

Related reports:

Google
 

Original NASA ASRS Text

Title: A ZJX Controller attempted to handoff an aircraft to a neighboring facility while also maneuvering the aircraft away from a MOA. The receiving Controller was unable to immediately identify the aircraft due to conflicting beacon codes already used for ADIZ helicopter operations within the area. The problem may have arisen due to errors between ERAM and STARS not interacting correctly resulting in separate beacon codes not being tagged to incoming aircraft.

Narrative: Aircraft X was an arrival to PNS descending to 11;000 feet from the east direct PENSI direct PNS. This routing places the aircraft in a position to enter the PNS south MOA after PENSI if Pensacola approach does not descend the aircraft. In this instance; the aircraft was flashing to P1E and everything looked normal. 10 miles east of PENSI; I called Pensacola east for a handoff. The controller said that he did not see anything. I stated the code and position and he again said that he did not see anything. I was perplexed and decided to turn the aircraft; so I jumped off the land line and turned Aircraft X right to a 300 heading. The aircraft did not make a fast turn and ended up entering the 1C block of the PNS south moa at 11;000 feet. A different controller at PNS approach called back and asked about the code. I stated the call sign and position again and he said that he only saw a primary. I questioned this and he said a beacon primary. I have never heard of a beacon primary; but asked again if he sees the code and he said yes and that he would be radar contact when he was clear of the MOA. He never told me if there was an aircraft in the 1C block; but from what I could see; I did not see anyone in that portion of the MOA. I turned Aircraft X to a 360 heading around one of my blocks that was active in the PNS north MOA and then the Pensacola Controller called back and said that he was radar and to descend him to 9000 feet. At the same time I was fighting with ZHU over PNS arrivals from the west because they continually want to use a flash through procedure that does not exist and put the aircraft straight on PNS approach. They have been told numerous times to not do this; yet they continue. This is dangerous because our arrivals from the west and east are both at 11;000 feet direct PENSI; head on and we have nowhere to turn anyone without hitting a moa. After investigating the cause of this handoff problem; I found that the fusion tracker at PNS had tagged up on a helicopter off of MOB southbound to the oil rigs. The code that Aircraft X was on; appears to be an ADIZ code for helicopters; but is not restricted in our computer; so PNS STARS never correlated our track with the real aircraft; it only showed it was a * with altitude. That is also why the controllers at PNS were confused about identifying the aircraft. We have had numerous incidents with handoffs to STARS facilities using fusion tracker. This is the 3rd in the last two weeks and shows how much trouble this can cause; because the controller has no indication that a handoff is not working until the aircraft is close to the boundary. We have spoken to the terminal automation and ERAM interface leads and they are getting confused on what it is doing as well. The fusion tracker will still keep tracking a plane even after we change it to a different code and will never look again for the code. The other issue is that ERAM (Enroute Automation Modernization) is sending STARS (Standard Terminal Automation Replacement System) a Track update position and position as part of the handoff message; yet the fusion tracker does not care and tracks the closest target on that code. In this instance; there was no room to maneuver or time to avoid the airspace deviation; but I mitigated it as much as I could. In this corridor; there is no room to maneuver and if the automation does not work and you have no indication; there is not much we can do.

Data retrieved from NASA's ASRS site 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.