For the past several weeks I’ve been receiving reports from FlightBox customers of “missing traffic” – traffic observed visually or on some other system (TIS, TCAS) but not seen on their EFB application from ADS-B. In some cases the answer was a simple misunderstanding of the way ADS-B traffic currently works, but a subset of the reports sounded suspiciously like we had a problem – somewhere. Either a bug in the Stratux software that powers FlightBox, or something going on with the ADS-B network.
Yesterday morning I decided to figure out what’s going on – or at least give it my best shot. From my own experience and from customer reports, we have no problem seeing aircraft that are equipped with ADS-B Out. What is missing is the rebroadcast secondary surveillance radar data – the copy of “everything in your hockey puck” that you’re supposed to get if you have ADS-B Out. I figured that one of the following was happening:
A) Stratux was not getting the data because of poor reception
B) Stratux was receiving but ignoring ATC traffic data due to a bug
C) Stratux was not getting the data because the FAA towers are not sending it
D) Secondary surveillance radar was not picking up the traffic
To figure out which of the above is causing the problem I put together a simple, practical test.
I own an Appareo Stratus 2 which I use as the ‘control’ in my experiments. If the Stratus has data flow from a tower but FlightBox does not, it could be failure mode A – poor reception. If both devices connect to and receive the same data from the towers, that essentially rules out condition A. If the Stratus receives and displays traffic that is not visible to the FlightBox, the root cause might be failure mode B – a bug in the Stratux code. But if both devices display the same traffic, that rules out condition B. Failure modes C and D take a bit more effort to test.
My 1976 Grumman Tiger is equipped with FreeFlight Systems RANGR Lite UAT transmitter, and I regularly request status reports from the FAA. As of the last test (a few months ago) I was 100% ADS-B Out compliant. In other words, I should absolutely trigger the towers and receive a “puck” of ATC radar data for aircraft in my vicinity. To test if the ATC radar is making its way to the ADS-B network, I enlisted the help of my friend Larry. Larry flies an Arion Esqual – a precursor to the popular Lightning homebuilt – which has a standard Mode C transponder but no ADS-B Out. His job was to fly in relatively close formation with me to present a controlled traffic target.
Yesterday morning Larry and I took off from Roosterville (our home airport). I had two iPads running ForeFlight – one connected to the FlightBox and the other connected to the Stratus 2. I took off first and climbed to 1000’ AGL where both systems showed solid connection to two ADS-B towers. When Larry took off, I kept an eye on the iPads looking for him to appear on ForeFlight.
We flew south from Roosterville towards Liberty Landing. I let Larry stay roughly a half mile ahead and 200 feet above me. He did not appear on either iPad at 2,000′ MSL (~1100′ AGL). After roughly five minutes at 2,000′, I asked him to climb up to 3,000′. At roughly 2,500′ MSL, he appeared as an ADS-B traffic target 100’ above me an less than a mile head. Ok, it appeared to be working as expected.
To figure out the “bottom” – the lowest altitude at which it worked – I asked him to descend. He dropped off the screen at roughly 2,200′ MSL. We made a turn out towards the east and decided to see where he re-appeared. He began a steady climb that eventually topped out at 3,500′ MSL, without reappearing on either device. A quick check of the Weather tab showed that FlightBox was continuing to receive ADS-B data from the towers. Both the Stratus and the FlightBox continued to show both 1090-ES and UAT targets, but all appeared to be direct.
We flew for another 30 minutes at various altitudes. Larry only appeared again briefly, at 3,900′ MSL. On the off chance that we were too close – that ATC saw one target instead of two – we diverged to at least a mile separation. No joy. We contacted Kansas City approach to make sure that we being seen by radar. They had us 5-by-5 in exactly the right spot. Larry was at 3,900′ and I was below him at 3,200′. That would seem to eliminate the admittedly far-fetched failure mode D.
To review the facts:
Later in the day I went back up alone and spent some time in the airspace below the Kansas City class B directly along the approach path for runway 18 at MCI. I was within 10 miles of the ADS-B tower at Dearborn, Missouri and maintained a solid connection to it. I spent twenty minutes or so visually observing airliners arriving and departing above me. None of them appeared on either ADS-B system.
All of this seems to indicate that the cause of the missing traffic is failure mode C – the ADS-B network simply is not sending the data. The next question is, of course, why? My ADS-B Out transmitter was running. I should have had a puck that included Larry and the MCI traffic. Why wasn’t I able to see either?
Hard to say. It might be that the only radar that feeds into the ADS-B system is ARTCC (“Center”) and the altitude range we tested (2,000′ – 4,000’ MSL) was below the visibility “cone” for their radar. But they did have Larry as low as 2,500′ MSL for a while. It seems more likely that whatever gateway feeds ATC secondary surveillance radar data into the ADS-B network is flaky. Or that the software in the towers that calculate the “pucks” has a problem.
Whatever the cause, never assume that ADS-B provides a complete picture of traffic – even if you’re equipped with ADS-B Out. We’re still very much in a “see and avoid” world, and probably will be until at least 2020.
If you have two ADS-B In systems and a friend who’s willing to play along, please try to replicate my experiment. I would love to have enough evidence to take this to the FAA and get some kind of response.