posted on Jun, 19 2015 @ 03:48 PM
It isn't that the pilot turns off the transponder. Rather the data feed from the FAA isn't filtering the data.
If you listen to a Janet landing at Groom, the comms follows this pattern. The flight starts out under a Janet callsign. When the plane reaches the
edge of the NTTR airspace, Nellis control (the main air traffic control for the region) does a hand off to Groom approach. Normally air traffic
control will give the pilot the approach frequency. But if you are landing at a "secret" air base, you can't give out the frequency to a place that
doesn't exist. So air traffic control simply states "frequency change approved". The pilot knows the Groom approach frequency. At this point, the
pilot drops the Janet callsign and goes to the callsign of the month. In addition, the flight number is changed. Groom approach will then give the
pilot a new squawk code for the transponder, usually in the form of 033x, where X is a single digit. This would allow ten planes to be in Groom
airspace, which is not likely. But once a plane leaves the air space, the squawk code can be recycled.
I don't know for certain what triggers the FAA filtering. If it was based on squawk code, you would think the system would never fail. Groom approach
monitors the squawk code, so if it was entered incorrectly, that wouldn't last long. If the filtering was based on geographical coordinates, you would
think that would be foolproof. So my guess is they filter on tail number or flight ID, and the wrong tail number or ID gets into the system. I've seen
flights where an O is used instead of an 0 (oh versus zero). The bug has to be something that isn't essential to air traffic control. Since it happens
rarely, the bug had to be something related to human error. Hence my guess being flight ID or tail number.
This particular landing is interesting since the plane had to orbit out of the way, probably to deconflict with another flight.