Policy discussion: Traffic target update preferences

[cyoung]

Currently Stratux does not prefer any source or attempt any "intelligent" processing with regards to traffic updates. A traffic target is uniquely identified by its ICAO address. For emphasis: when receiving a traffic update, the update is merged into a target in Stratux' "target list" IF AND ONLY IF it has an equal ICAO address of a target in that list.

The purpose of this ticket is to discuss the impact and necessity of adding preference to data sources in dual band receivers. One proposed change (by @Ergonomicmike) is to add preference for direct 1090ES data when also receiving rebroadcasts for the same target:

https://github.com/cyoung/stratux/commit/4480c9d05aac287c8ff811cdaee436ccea7a32ba

[kdknigga]

One proposed change (by @Ergonomicmike) is to add preference for direct 1090ES data when also receiving rebroadcasts for the same target

Can't you also receive directly from aircraft on 978? Perhaps the preference should just be direct over rebroadcast without regard to frequency.

On Tue, Jan 17, 2017, 08:15 cyoung notifications@github.com wrote:

Currently Stratux does not prefer any source or attempt any "intelligent" processing with regards to traffic updates. A traffic target is uniquely identified by its ICAO address. For emphasis: when receiving a traffic update, the update is merged into a target in Stratux' "target list" IF AND ONLY IF it has an equal ICAO address of a target in that list.

The purpose of this ticket is to discuss the impact and necessity of adding preference to data sources in dual band receivers. One proposed change (by @Ergonomicmike https://github.com/Ergonomicmike) is to add preference for direct 1090ES data when also receiving rebroadcasts for the same target:

4480c9d https://github.com/cyoung/stratux/commit/4480c9d05aac287c8ff811cdaee436ccea7a32ba

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/cyoung/stratux/issues/562, or mute the thread https://github.com/notifications/unsubscribe-auth/ANN_wEZaPpyk3-ePV12yNsFauKciwGw1ks5rTMzggaJpZM4Llsz9 .

[cyoung]

You're right. There's a line in there on the 1090ES receive for ADS-R target type when UAT data already exists for the target.

[ghost]

TL;DR: ADS-R is just as accurate as direct ADS-B transmissions; it's just on a ~1 second delay. To maximize the accuracy of the merged data, I'd reject ADS-R / TIS-B updates if the old ti.TargetType == TARGET_TYPE_ADSB during a tighter lookback interval: stratuxClock.Since(ti.Last_seen) < 2*time.Second, regardless of source.

---

I'd tread carefully with excluding ADS-R / TIS-B messages from updating the traffic objects -- you don't want to lose valid ADS-R data from one band if direct ADS-B transmissions on the other band are intermittent. There is also no reason to outright prefer one band over the other -- as @kdknigga notes, direct ADS-B transmissions can be received on either frequency.

The worst-case scenario we see with our current traffic handling (re-duping issues on the display layer aside) is a ~1 second latency that will be introduced if an ADS-R retransmission "overwrites" the data for a direct ADS-B report received for the same ICAO code during that transmission interval. I don't remember if the ground stations do any trajectory predictions on ADS-R targets; if not, targets could appear to pause, or jump by a few hundred feet.

If you miss one direct ADS-B data message (i.e.ti position data is between 1-2 seconds old) an ADS-R retransmission will be equally accurate as the last received previous ADS-B message. Beyond two seconds, the ADS-R messages will by definition be more accurate.

[Ergonomicmike]

Glad to have AvSquirrel involved.

To be clear, I'm not advocating always excluding ADS-R/TIS-B from the mix. (Because there could be missed direct xmissions and it might be prudent to fill in the blanks sometimes. (Although some EFB's coast - so no blanks to fill?)) I simply (hah!) envision an algorithm that favors direct over indirect.

My concern arises from the fact that because a participating aircraft only gets ADS-R/TIS-B when another aircraft is in his puck, any such traffic is "close" by definition. Therefore all traffic that qualify for rebroadcast are more of a threat, where time is of the essence.

So I would want the most up to date position information I can get, and that data comes direct. (Not sure what AvSquirrel means by "accurate." No doubt both direct and indirect broadcast contain accurate data. Just not necessarily timely data.) As I understand Stratux's current algo, if it happens that TIS-B data is the first that the Stratux receives, then the pilot in the puck will most likely continue to receive delayed data. That doesn't sound good to me.

Ignoring processing time in the Stratux, the FAA allows up to 6 seconds to rebroadcast indirect data. (I don't recall reading that the FAA massages the traffic message either. So I'm assuming it's "stale" (or staler) position data than direct when finally rebroadcast.)

6 seconds of a delay doesn't sound like much, but, apparently with all the other system delays (and/or a missed rebroadcast), coupled w/ fast moving aircraft, it can be unsettling. Admittedly anecdotal, I read a report from someone flying around SoCal with a single freq Stratux (but in a buddy's puck) who was very disappoined that air carriers had moved far ahead of their painted positions. He was on 978 getting TIS-B. He reported that things were much better when he added 1090. (Don't know if the FAA can meet its 6 sec spec in SoCal. Can be a zoo there.)

Naturally, if an intelligent Stratux algo adds too long a delay to sort things out and if it's faster end-to-end not to sort much, then whatever produces the most timely traffic report should win.

Maybe that means dumb? Dunno.

[cyoung]

[ghost]

@Ergonomicmike - it sounds like we're all drifting in the same general direction on this, and that the devil is in the details.

What I mean by "accurate" is that the position source for both ADS-B and ADS-R transmissions is a WAAS-augment GPS receiver installed in the aircraft. The functional intent of ADS-R messages is to be equivalent to direct ADS-B messages for aircraft that are unable to receive on that frequency.

For air-to-air / air-to-ground broadcasts, the ADS-B specifications (DO-260B / DO-282B) and regulations (14 CFR §91.227) specify that ADS-B systems, regardless of which frequency they operate on, must have a total latency of 2.0 seconds between the time position is measured and the time the ADS-B position message is broadcast by the aircraft. Additionally, a maximum uncompensated latency of 0.6 seconds is allowed; if the transmission is sent any later, then the original position needs to be extrapolated along the aircraft's trajectory.

Pretend I'm a GDL88 UAT transceiver with a ground speed of 165 knots. I'm attached to a GNS-430W, which I'm using as a position source. The time right now is 05:13:00.10Z, and the 430W just passed me a position and velocity update with a timestamp of 05:13:00.00Z. I have until 05:13:02.0Z to take take the data, format it into a UAT position message, and broadcast it. Since I need to avoid stepping on anyone else's transmissions, I also need to calculate when during the next second I'm going to transmit. (The method to do that is part of the UAT spec.) So, I do that math and realize that my next transmit opportunity is 05:13:00.82Z. Rats. That's more than 0.6 seconds, so I need to do a little math to add ~230 feet to the original position before I hit "send" and blast that message out for everyone to see.

Less than a millisecond later, about six ground stations receive and start processing that ADS-B position message. During that same second, one of those stations received an valid ADS-B message from a different aircraft that not only is within 15 NM and ±5000' of me, but it is signalling that has 1090 In and no 978 In capability. It knows that the other aircraft can't see me, and it wants to help. It's ADS-R time.

For this next bit, I'm referring to a document titled "Surveillance and Broadcast Services Description Document" (SRT-047), from the FAA Surveillance and Broadcast Services Program Office.

Functionally, the ADS-R message is exactly the same as the original ADS-B message, just repacked to fir the message format of the other transport layer. It adds about extra half second more latency compared to the air-to-air message, but it also compensates for latency by extrapolating an updated position from velocity data sent with the ADS-B position message. The net result is that in most cases there should be little if any practical difference between an ADS-B message and a corresponding ADS-R rebroadcast.

3.3.2.2.3 ADS-R Latency: The additional latency introduced by the ground infrastructure is less than the latency required by the most stringent applications in the SBS CONOPS minus the inherent airborne latencies on both ends.

The maximum delay between the time of message received of an ADS-B Message that results in the generation of ADS-R Uplink Messages and the transmission of the first bit of any corresponding broadcast Message on the opposite link technology is less than or equal to 1 second. The service provider ground infrastructure design is such that the time it takes for a received ADS-B message to be processed into ADS-R format and sent to the ADS-R transmission scheduler is 400 milliseconds or less. This ADS-B to ADS-R transmission latency is compensated in the ADS-R horizontal position by linearly extrapolating to the time of transmission. Therefore the uncompensated latency added by the ADS-R Service is negligible and the end-to-end uncompensated latency for ADS-R (Air-to-Ground-to- Air) is equivalent to the expected uncompensated latency from ADS-B (Air-to-Air).

TIS-B is a bit of a different animal, since those positions are derived from radar data. The SRT-047 document states that update frequency depends on what kind of radar is painting the target, and how many radars sites are painting it. Highest update rates (~1 Hz) will be at the surface of major airports where ASDE-X is in use; lower rates will be seen on ASR and Center radars. A target being painted by a single Center radar in the middle of nowhere? That could be 12 seconds between refreshes. Terminal areas? About 5 seconds. Looking through some logs I've collected, I see similar results: 3-5 second intervals for airborne targets near B airspace, and 1-2 second interval for targets on the ground at MSP.

There is a system latency from sensor (i.e. radar hit) to TIS-B transmission of under 3.25 seconds; this delay is compensated. But it does not appear that the FAA system does any sort of interpolation between radar hits.

Where this gets really tricky is that (in theory) TIS-B targets should not be created to represent the location of any aircraft with valid ADS-B Out. There will be some exceptions (e.g. targets are now generated to represent SIL=0 uncertified / unapproved position sources / transmitters; that was behind the FAA memo that confused everyone last year) and there might be some corner cases where radar is able to paint a target, but for some reason the ADS-B ground stations aren't receiving it. In other words, if you see TIS-B, especially near busy terminal airspace, there's usually a reason for it.

@cyoung - ah, the old Mode S TIS. About all it has in common with TIS-B are three letters, and the fact that targets come from radar data. In that case, the 6-second refresh rate is function of the system: relative bearing, relative altitude, and distance information is sent by the radar antenna as 1030 MHz uplink messages, and are addressed to a specific Mode S address. (Compare TIS-B, where pressure altitude, lat/lon, velocity, position accuracy, etc. are broadcast in the clear.) An ASR-9 antenna takes about 5 seconds to spin around once,. Adding a little data processing time to account for everything seen in the previous sweep gets you to six seconds.

[Ergonomicmike]

I flew to KFFZ today. iFly also shows some dupes when a flight school aircraft is in the area, pinging the ADS-B tower. (I totally forgot to test Avare. Rats.) I took a Stratus v2 with me, to see if it has the same problem. But it doesn't talk to iFly.

After I digest my dinner (the Steak & Stone serves good food, but the restaurant itself is kinda crummy), I'll post a couple screen shots to aid in troubleshooting. I probably should have run some Stratux logs too, huh?

I might have an opportunity to do this test again next week with a borrowed Stratus and a borrowed FF tablet. I'm very curious to see if they figured this out already. +++++++++ Here are the screen shots. Notice that all three dupes are colored blue in the Traffic Page.

[Ergonomicmike]

I'm getting ready to post some more about this, but before I do, is it still the case that the current build of dump 1090 doesn't tell us the source of 1090 traffic, per https://github.com/cyoung/stratux/pull/268 ?

I have also sent the screen shots above, and the iFly raw adsb binaries to iFly for analysis to get some insight from an EFB's perspective.

[Ergonomicmike]

Here's a screen shot I forgot to post. We know, from prior work in the github, that the PA aircraft in Phoenix are 1090 Out. So this screen shot confirms that the dupe problem we're seeing here is due to a TIS-B rebroadcast on 978. (Notice also the 17 second delay.)

Now, it occurs to me that the FAA probably never envisioned dual band ADS-B receivers. That is, the FAA probably expected that an aircraft is either on 978 or 1090, but not both.

If so, then this might be a problem of our making. If so, then do EFB's still have to de-dupe? (Maybe they do when you receive duplicate targets on the same frequency from re-broadcasts over multiple towers?)

I don't know how many dupe cases there are in the Stratux. And perhaps most of them are already taken care of. Whatever, I am thinking we should focus on one at time and focus on this one first? It hasn't been much of a problem. But as more and more aircraft become ADS-B Out, we'll see more dupes.

[Ergonomicmike]

And this screen shot shows why I think it important to try to minimize duplication of 1090 Traffic rebroadcast on 978 TIS-B.

I don' t know for sure that the two targets shown are dupes. But it seems probable.

Notice that the TIS-B re-broadcast is coasting. (Probably because there is flight school aircraft to ping ADS-B tower anymore and I'm no longer in someone's puck.) The 1090 direct is the more timely/accurate, in the sense that it more correctly shows us where the aircraft last was.

[kdknigga]

@Ergonomicmike

I went flying southwest of Chicago Saturday with Avare. The was a lot of traffic, but nothing that's obviously a duplicate to me.

http://m.imgur.com/a/64Y8S

On Mon, Jan 23, 2017, 10:10 Ergonomicmike notifications@github.com wrote:

And this screen shot shows why I think it important to try to minimize duplication of 1090 Traffic rebroadcast on 978 TIS-B.

[image: duplicate target way off] https://cloud.githubusercontent.com/assets/15025888/22211611/d63eb1de-e14a-11e6-96a6-34dab703e77d.jpg

I don' t know for sure that the two targets shown are dupes. But it seems probable.

Notice that the TIS-B re-broadcast is coasting. (Probably because no flight school aircraft is pinging the ADS-B tower now and I'm no longer in someone's puck.) The 1090 direct is the more timely/accurate, in the sense that it more correctly shows us where the aircraft last was.

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/cyoung/stratux/issues/562#issuecomment-274531203, or mute the thread https://github.com/notifications/unsubscribe-auth/ANN_wIEQNOE7inYohf6aVZWjsUrUMXPqks5rVNDQgaJpZM4Llsz9 .

[Ergonomicmike]

Thanks for the report.

Are you ADS-B Out? I don't see anyone near you, so if you're not ADS-B Out, it doesn't seem like you could be in someone's puck.

On a side note, kinda sad to see so little 1090 traffic when you're within receiving distance of O'Hare. (Implies few airliners are ADS-B Out.)

[kdknigga]

I am not ADS-B out.

On Mon, Jan 23, 2017 at 10:47 AM, Ergonomicmike notifications@github.com wrote:

Thanks for the report.

Are you ADS-B Out? They only show up when you're in a puck. (I don't see anyone near you, so if you're not ADS-B Out, it doesn't seem like you could be in someone's puck.)

On a side note, kinda sad to see so little 1090 traffic when you're within receiving distance of O'Hare. (Implies few airliners are ADS-B Out.)

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/cyoung/stratux/issues/562#issuecomment-274543661, or mute the thread https://github.com/notifications/unsubscribe-auth/ANN_wNFcRjF_XbWezKY6aYAJsJB4-Kd0ks5rVNmrgaJpZM4Llsz9 .

[Ergonomicmike]

Okay, I had a chance to test a Stratus 2S for dupe targets. When FF was connected to Stratux, FF showed dupes. When FF connected to Stratus, no dupes. (Compared same targets seen on iFly/Stratux showing dupes to Stratux/FF showing no dupes.) Since FF showed dupes with Stratux, it appears that FF is not deduping any better than iFly. And since no dupes with Stratus, it appears Stratus is deduping correctly.

I enabled logging on the Stratux for one isolated dupe target, so hopefully that will help the gurus understand the issue better. Will plan to upload the logs shortly.

Edited to correct where I mistakenly typed "Stratux" instead of "Stratus."

[Ergonomicmike]

Here are short logs files from when I saw one dupe target while flying out in the middle of nowhere in the target's puck.

Sorry that I wasn't smart enough to take a screen shot right then to document the ID of the aircraft. But there should only be a few targets at most in the log file, so I'm hoping it will be easy to see the dupe. (It was the closest to me. I had my EFB set to hide other traffic.)

one.dupe.target.logs.zip

[Ergonomicmike]

From http://ipadpilotnews.com/2012/08/understanding-ads-b-traffic/ (emphasis mine)

ADS-R Targets: these are ADS-B Out equipped aircraft, but rebroadcast by the ground station. This exists because you could have a 978 In receiver that would not see the 1090 air-to-air transmission. So the ground stations sends the 1090 traffic back up to 978 In aircraft. Because the GDL 39 is dual band, these ADS-R targets are usually duplicates, and the number is 0. But since ground stations are higher power than the air-to-air transmissions, this could occasionally fill in the gaps you might miss.

Contrary to their statement about higher power ground stations, our experience (Stratux users) is that receiving direct 1090 xmissions is not a problem (from a sensitivity standpoint).

[Ergonomicmike]

I got an email back from iFly about de-duping. Reading between the lines, they don't de-dupe at this time.

[ghost]

@Ergonomicmike -- thanks for the logs! This one's fun, because it's a weird situation. (Surprise, surprise.) In this case, the original target and its TIS-B dupe were on the same datalink.

The main ADS-B target was transmitting using version 1 of the UAT link, which lacks several message elements (SDA, squawk code, "In" indicators, etc.) that are required by §91.227. (In short, the owner was an early adopter, and hasn't updated their UAT software to the latest and greatest yet.) The ground stations therefore treated it as a non-ADS-B aircraft, and created a TIS-B target as it passed through another UAT aircraft's puck. The dupe is a normal UAT TIS-B target that was created to represent the position of that plane. It has a track file ID, rather than using an ICAO address. It therefore can't be deduped in traffic.go simply be looking at the ICAO address.

I plotted distance and bearing from your traffic data, split out by address qualifier. In other words, direct ADS-B = 0, anonymous UAT ADS-B = 1, ADS-R = 2, If I'm interpreting your notes correctly, you saw the dupe targets to the WSW, about 10 NM away. Plotting by address qualifier shows a dual-track here: some points are ADS-B (0), some are TIS-B (3). This is unusual -- I'd expect an ADS-R to show up with an address qualifier of 2.

Zooming in on this region and replotting in 3D (distance vs bearing vs time) by ICAO hex code confirms weirdness: two tracks in very close proximity. with different ICAO identifiers. A6629F is a real aircraft ID (one of the UND fleet: N510ND, transmitting as NDU10), and is an ADS-B track that continues westbound after the dupe disappears. The other (2684C8) is a TIS-B track file ID.

For reference, here's one of the ADS-B messages from 510ND:

08a6629f2eb62d63aed61c2a001e2c801809e5bba8e6c40678a08200001c60000000

It would decode like this:

[Ergonomicmike]

You are correct that the aircraft was WSW. And my pax mentioned something about it being a U ND aircraft. (Perhaps someone should contact UND to suggest they update the UAT's in their fleet?)

Since this appears to be a strange case, I will endeavor to fly to FFZ again soon to get some logs from there for the more normal cases. (Unless someone else (@dribble7 ) wants to do it.)

Although, IIRC, my buddy's Stratux/FF managed to dedupe this strange target.

[Ergonomicmike]

Actually, now that I think more about it, my buddy got a dupe on the UND target when he first switched to his Stratus. Then it stopped duping. We wrote it off to having old data from my Stratux still in FF. But it's more logical to believe that he stopped getting a dupe because the target moved out of range. (?)

On another note, how do you suppose that the UND aircraft handles his ghost if his call signs are different?

And how is it that the FAA ordered Skyguard out, but not old UAT's?

Update: Corrected NavWorks (sic) to Skyguard

[Ergonomicmike]

FWIW, here's a composite of two screen shots, taken near KFFZ. On the left is N3117A showing a duplicate with Stratux/iFly. On the right, same aircraft absent a dupe with Stratus/FF.

[Ergonomicmike]

Okay, here are some logs of dupes. And no dupes, for comparison purposes. First, these were taken on the ground, engine off, at KFFZ. Second, apparently the flight school there, that generally triggers the ADS-B tower, stops flying after about 4:30 pm on Saturdays. So not as much duping as I would have liked. In fact, I only noticed air carriers duping on this run. (As opposed to both Air Carrier and GA last time when I forgot to log, per the screen shot in my last comment, above.) Still, perhaps this is a start. Kill off the dupes one at at time? I started and stopped the logging so as to not overload the Stratux. Hopefully it simply appends the log file when I toggle logs on and off. I didn't know whether I should enable Verbose or not. Chris tells me not, but, at the time, I enabled it to be safe. Apologies if wrong. And if there's a better way to gather these logs, take me by the hand and tell me. Here's the logs: dupes.of.aircarriers.KFFZ.zip In chronological order: AAL 1034 - dupe. SWA 2629 - no dupe. (Presumably no one near me to ping the ADS-B tower?) AAL 14xx (1458, per next?) - dupe AAL 1458 - strange dupe, where iFly shows the dupe coasting on a cardinal heading. I've seen this happen before. I don't know if it's an iFly problem or Stratux.

[Ergonomicmike]

Oh, one thing that changed in the test above is that I'm running Stratux v1.2r1.

[ghost]

@Ergonomicmike:

All of these appear to be cases where Stratux has successfully deduped the data between the two data links, but iFly is re-duping it, presumably by treating the same traffic (ICAO code) as separate targets depending on the traffic source (address qualifier).

One of these cases (AAL1458) also illustrates what will happen to a re-duping EFB if one source cuts out, or if the traffic source for any given ICAO code changes -- one target will temporarily persist at the last seen location, while another target will continue tracking.

AAL1034 Primary target is 1090ES, with 24-bit ICAO code of ACF975 and an update frequency of about once per second. Secondary TIS-B data was received on the UAT link at irregular intervals of 1-4 seconds, also with the same 24-bit ICAO code, and was deduped into the same traffic object within Stratux.

The es_messages table and dump1090 console showed that a set of airborne position (type 11) and airborne velocity (type 19) messages were received about once per second while this aircraft was in view. However, no type 29 (target state and status) or type 31 (aircraft operational status) messages were received during the ~4 minutes that your logs had data on this airplane. Those are the messages that provide data on system position integrity integrity (e.g. SIL/SDA), ADS-B version, and aircraft capabilities. Without those messages, this aircraft would be treated as a TIS-B target.

The UAT messages were transmitted with an address qualifier = 2, which could indicate either ADS-R or TIS-B. However, the use of a UAT version 2 message, the lack of data for emitter category and aircraft capability and operational modes in the UAT messages, and the irregular transmission intervals all point to this being radar / MLAT derived TIS-B.

AAL1458 Similar situation to AAL1034.

The 0° track is an ancient Stratux bug in traffic.go dating back to 0.1r2 -- as written, this if statement only executes if both the north-south and east-west velocity components are greater than zero. In this case, the aircraft was tracking due west, and the N-S velocity was zero. The track was therefore not calculated. I'll open a separate issue.

N4405Q You didn't point it out, but there are also two targets for N4405Q on your 5:12 PM screenshot. This aircraft was outputting the full complement of 1090ES version 2 ADS-B messages, including the type 31 (aircraft operational status) message.

The ground station therefore transmitted ADS-R rebroadcasts with the same 24-bit identifier, once per second, which included emitter category, capability code data, and direct translations of all integrity and containment data from the 1090 air-to-ground broadcasts. Because this data is functionally identical to the primary 1090ES broadcast, the two targets in iFly are right on top of each other.

[Ergonomicmike]

@AvSquirrel Fantastic. I will copy & paste your comment to IFly.

Guess I shoulda tried AvAre to see if they've figured it out. (Next time.)

Except for the old bug, are you comfortable that Stratux is handling dupes properly? (That is, close this issue for now?

[Ergonomicmike]

@AvSquirrel After sleeping on it, I'm having a conceptual problem and perhaps not understanding correctly.

You said

All of these appear to be cases where Stratux has successfully deduped the data between the two data links, but iFly is re-duping it, presumably by treating the same traffic (ICAO code) as separate targets depending on the traffic source (address qualifier).

If the same traffic is being received through two different traffic sources, I thought that that was the definition of a "dupe." And so the Stratux would figure out what source was the primary (direct) source and only allow the primary (direct) signal to pass through to the EFB.

(For now I am overlooking your earlier point that a TIS-B could be more accurate than a delayed direct broadcast and treating this as tho that never happens.)

So what is the definition of a duplicate target?

Is a dupe a dupe any time that it's a retransmission of the "primary" (direct) transmission? Or if it's a retransmission within 2 seconds? Or if it's a retransmission within a certain distance delta? (Wouldn't work for hovering helicopters.)

I was thinking that a dupe was any rebroadcast on the alternate frequency, regardless of whether the primary (direct) transmission was received all the time.

From your explanation earlier, I now realize that sometimes a direct broadcast might be missed but the "rebroadcast" might be received. In that case, I would still opt to discard the rebroadcast and let the EFB continue to coast based on data from the earlier primary (direct) signal. If the direct was missing for x seconds, but the rebroadcast was being received during that time, then the Stratux would switch and start to send only the rebroadcast to the EFB.

Just brainstorming.

[Ergonomicmike]

Along the same lines as my conceptual problem, I don't understand why it is that when Stratux feeds ForeFlight, FF shows dupes, but when Stratus feeds FF, no dupes. It seems to me that FF is not depuping with ICAO, since it shows dupes when fed from Stratux. But the Stratus is doing something different than Stratux that keeps FF from showing dupes. What is Stratus doing different? (iFly has a way to capture an adsbraw.bin file. Does FF have a similar log to study?)

[joshua-wyatt]

Info I got from FF tech support on how to collect ADS-B logs:

With the iPad connected to the stratux, turn on "Logging" in More > Devices > then tap the ADS-B box. On that page, scroll down on the right and turn the "Logging" switch ON. You can then extract the log file from the iPads using iTunes. NOTE: You'll be looking for files in the form: "2017-01-26-21-24-51Z.ADS-B.gdl90log"

The log files I collected from stratux appear to be a straight dump of the incoming gdl90 strings. I haven't looked to see what is logged when connected to a stratus, but I do have an original stratus on the counter at home I could try out.

[Ergonomicmike]

@semaphore-digital Thanks. (BTW, from your name, you wouldn't happen to run an Avionics shop in Lafayette IN would you?)

Good to know that there's a way to extract adsb data from a Stratus. That could help a lot. (I will ask my buddy if we can do that with his Stratus 2 someday.)

If you've been following this thread, the issue we're gathering data on only happens when you get both direct and rebroadcast traffic (on 1090 and 978) when near an ADS-B Tower and when in a puck. (Either yours or someone else's.)

Is an original Stratus a dual band unit? And is your counter at home near an ADS-B tower?

[joshua-wyatt]

@Ergonomicmike negative, I'm a lowly broadcast engineer in the MSP area.

My old Stratus I is 978-only, unfortunately, so it won't be of much help with this particular problem, but if the logging works perhaps someone with a more modern unit could do a capture for analysis. I'm not near any towers at home, but I pick up several in the pattern at my airport.

[Ergonomicmike]

What if dual band Stratux simply didn't process ADS-R, on the assumption that they are always dupes, per my quote above about ADS-R in the GDL-39?

[ghost]

@Ergonomicmike -

Are you comfortable that Stratux is handling dupes properly?

As you noted in your followup messages, it depends exactly what you mean by dupes. ICAO aircraft addresses are unique to each aircraft, so ADS-B, ADS-R, and TIS-B targets with the same "real" ICAO address should all correspond to one airplane. TIS-B targets that have random track file IDs are also unique to from one another at any time, though there is the possibility of "duping" with non-rule compliant ADS-B out traffic (as was the case with NDU10 a couple weekds ago -- I'd have to compare the actual position / track vs time of TIS-B targets versus all other traffic to de-dupe these, and that's beyond the scope of how we've handled this -- or how I want to handle this.) The one possible exception to "one code = one aircraft" would be anonymous UAT addresses. Those are a generated as an XOR of initial position versus assigned ICAO code, and there is a small but finite possibility that the resulting 24-bit anonymous code could match that of another aircraft.

My perspective has been, and still is that the 24-bit ICAO code is both necessary and sufficient to identify an aircraft (with the exception of anonymous UAT targets), and that EFB clients should not care what data source is providing that data -- i.e. that graphical targets that they paint on screen should represent a unique aircraft, rather than a unique target. However, I also recognize that using ADS-R and TIS-B messages to update the position of an aircraft identified by its ADS-B transmissions could result in some positional jitter, even if the EFB treats messages from multiple sources as the same target.

Part of the confusion / ambiguity, I think, stems from something that was noted in #561 -- that the GDL90 spec considered the combination of the ICAO address and Address Qualifier to uniquely identify an ADS-B or TIS-B participant. Note that the spec also cautioned display vendors to "take appropriate measures" to identify and deal with duplicate targets.

3.5.1.2 TARGET IDENTITY The identity of a target is formed by the combination of the Address Type “t” along with the Participant Address "aaaaaa". Together these form a 28-bit field that uniquely identifies a given ADS-B or TIS-B participant. The Address Types are defined as follows: t = 0 : ADS-B with ICAO address t = 1 : ADS-B with Self-assigned address t = 2 : TIS-B with ICAO address t = 3 : TIS-B with track file ID. t = 4 : Surface Vehicle t = 5 : Ground Station Beacon t = 6-15 : reserved

MFD Recommendation: The Display should determine the appropriate style of traffic symbol for a target by using a combination of Address Type, Emitter Category, NIC value, Air/Ground state, and Traffic Alert status.

MFD Recommendation: The uniqueness of the Target Identity depends primarily on the equipment installer configuring the ADS-B equipment with the correct ICAO address. For TISB targets, uniqueness also depends on the ability of the ground-based TIS-B processor to fuse radar and ADS-B reports into track file IDs accurately. Neither of these processes can be expected to always generate a unique identification. Therefore, Display vendors are advised to take appropriate measures to cope with the possibility that the Target Identity alone may not always be sufficient to uniquely identify duplicate targets. This caution includes the possibility of reception of an ownship “shadow” TIS-B target.

However, the GDL90 was a first-generation UAT transceiver, and that the spec was last revised in 2007. Two additional factors have come into play with Stratux. One, we are in most configurations a dual-link receiver. We will have to handle simultaneous ADS-B and ADS-R target reception, which is something the GDL90 did not need to do. The other is the FAA's policy change to generate TIS-B targets corresponding to non-compliant emitters, as we saw on the NDU and AAL flights mentioned in previous messages.

As far as suppressing ADS-R targets on dual link receivers, I don't have access to RTCA/DO-317B, which contains the "recommended requirements for the processing and display of traffic," and is the basis of TSO-C195B. However, the original TSO C195 (2010) contained the following recommended change to RTCA DO-317, which implies that it should be acceptable to not process ADS-R:

Dual Link Receiver ASSAP requirements and test scenarios and the reference system design in Appendix C do not address the case of dual link receivers on the ownship. The FAA Ground infrastructure utilizes bits in the Version 2 ADS-B transmissions to detect the receiver capability on the aircraft. However, dual link receivers may receive ADS-B on one link and ADS-R on the other link for the same aircraft. In this case, ADS-R may be disregarded. While it is not prohibited to use ADS-R to update a track, it is not a minimum requirement.

So, I think I'm on board with using ADS-B as a primary position source, and suppressing ADS-R if a valid ADS-B position for that aircraft has not been seen in the past three seconds. Ground stations won't transmit ADS-R if SIL / SDA / NACp of the ADS-B message don't meet the requirements (i.e. if a valid ADS-B message is received by Stratux, any EFB should be able to display it).

The fly in the ointment is with TIS-B, and how Stratux (and EFBs) should handle "noncompliant" ADS-B emitters. If we receive a TIS-B messages that has an ICAO code corresponding to an ADS-B aircraft, it means that there's something that the ground station doesn't like about the ADS-B transmission: it could be a V0 emitter, it could be transmitting with SDA / SIL = 0, or NIC / NACp < 5. Certificated receivers are programmed to ignore these noncompliant transmissions, and rely on the TIS-B broadcasts to see noncompliant traffic. From the policy statement linked above:

Per DO-317A (TSO-C195a), any ADS-B emitter broadcasting SDA=0, NACv=0 or NACp<5 will not be displayed on a TSO-compliant ADS-B-In system

If I suppressed the TIS-B positions for these aircraft, some EFBs will not seem them if they are programmed to follow the standards of TSO C195 / DO-317. If I suppress the noncompliant ADS-B targets, there needs to be a compliant TIS-B client in the area to trigger the TIS-B messages, and both I and the non-compliant target need to be line of sight to the ground station.

Because of that, I'd rather just leave the TIS-B handling as it is.

[ghost]

The fly in the ointment is with TIS-B, and how Stratux (and EFBs) should handle "noncompliant" ADS-B emitters.

On second glance, this should be easier than I initially thought.

The only integrity and accuracy parameters passed in the GDL90 traffic message (or on traffic JSON messages) are NIC and NACp; we therefore don't track, pass, or otherwise have to worry about how EFBs use SIL, SDA, NACv, or any of the newer integrity parameters.

I ran a quick test with six EFBs (ForeFlight v8.3, WingX v8.6.9.1, iFly v9.8.4 iOS, FlyQ v2.4.3 iOS, Avare 7.2.2 Android, and Fltplan Go v3.2.6 Android) using a modified version of the updateDemoTraffic() function to see how they handled reductions in NIC and NACp.

Avare, Fltplan Go, FlyQ, iFly, and WingX all displayed traffic regardless of NIC or NACp, even with both parameters set to zero. ForeFlight suppressed traffic only if NIC == 0, and essentially ignored NACp. Among those EFBs, TIS-B suppression should leave the ADS-B targets visible as long as the ADS-B NIC > 0.

This raises questions of "should we?":

• Should we allow ADS-B positions to be passed to the GDL90 output if SDA or SIL = 0? I'd say yes. SIL is a function of system-level testing for integrity, not of the current accuracy of a reported position. I want Stratux to be able to see airplanes with non-TSO position sources (e.g. an experimental feeding a Trig TT22 using a GRT HXr), and/or the low-power beacon systems for UAS, gliders, etc. Even if these haven't been vetted through a formal process to be used for aircraft separation, these position sources are more than adequate for feeding an advisory device like Stratux.

• Should we allow ADS-B positions to be passed to the GDL90 output if NIC / NACp < 5? For clarity's sake, we're passing those messages now. Those performance levels are equivalent to containment greater than a 1 NM radius (NIC) or less than a 95% probability that the actual position is within 0.5 NM of the actual position (NACp). Low NIC / NACp is an indication that real-time accuracy or integrity of the reported position can't be trusted, and it could be better to exclude degraded data, if it would cause confusion. ForeFlight already excludes NIC = 0 ("unknown containment"), so I see no reason not to do the same... and if we're doing that, we may as well exclude any positions whose integrity is larger (literally) than a country mile.

• Should TIS-B messages be suppressed if SIL = 0 ADS-B messages are passed? Suppressing TIS-B data for SIL = 0 should be safe most of the time, though there is a possibility of corner cases where a transmitter doesn't identify an integrity fault, and broadcasts an incorrect position.

Hmm.. maybe a test build with the following changes would answer these questions:

• Add NIC > 4 as a criterion to consider ADS-B messages valid
• Suppress ADS-R messages if a valid ADS-B position message has been received in the past 3 seconds
• Suppress TIS-B messages if a valid ADS-B position message has been received in the past 3 seconds

[Ergonomicmike]

Very impressive analysis and very impressive writing about it. (The latter unusual for Engineers.) Glad that you're on the Stratux team.

There's a Proverb in the Bible that applies to you:

Do you see a man skillful in his work? He will stand before kings; he will not stand before obscure men.

(Does not apply to me.) . . . . So, my few thoughts:

Last week I sent iFly your previous comment about them reduping targets

This week there is a fix in the latest version that says "Traffic ghosting issues fixed." It's v9.8.7 if you have access to their beta program. (Although there's no "b" suffix, so maybe they pushed that out thru normal channels.)

I haven't had a chance to fly with it yet to see if it helps reduce dupes in and of itself.

On reducing dupes in Stratux:

I'm thinking that, for now, if your proposed changes prevent 90% of dupes, that that is good enough for now. Perhaps as EFB's get on board (internally deduping for dual band Stratux-like receivers) the combined dupe reduction might be 99%.

Also, as the fleet becomes more ADS-B Out (if the fleet ...?), we can see if dupes become a problem in the future. We could revisit it then if need be. Who knows - maybe the FAA will change the way the system responds after it sees how the system really works with everyone pinging towers and the Stratux would have to adapt?

Last, I'm not ADS-B Out in the Glasair, so I can't help much here except for the KFFZ excursions. Hopefully those two competing University teams will come up with a cheap ADS-B Out solution soon that can be tested in Experimental aircraft. Then I could help more.

[Ergonomicmike]

Heard from iFly. No, they haven't implemented de-duping yet. So when a Stratux test-build comes out, it will be only one variable that changed.

[Ergonomicmike]

@AvSquirrel Hey, I've got a fantastic data set for you to replay in your de-dupe test branch to see how it works.

Was flying today. Another GA aircraft flying below, same course for about 15 minutes. Apparently he was Out, 'cause I had continuous dupes of him. I enabled verbose logging for you.

Unfortunately I keep forgetting that the logs are on the SD card, not in my browser and I left the card in the Stratux in the plane. I'll try to make a run out to the airport tomorrow to get it for you.

[Ergonomicmike]

@AvSquirrel Here is the sqlite log for the long lived dupe. Would be interesting to run the replay with normal Stratux and then compare to your dedupe branch.

in.puck.dupe.zip

[cyoung]

I just looked at the sqlite log and see that N8163E was received from multiple sources but always with the correct ICAO address AB226C.

[Ergonomicmike]

I was half way between two ADS-B towers and wondering if I was getting info from the 2nd near KPAN. If so, then an even better data set than I could have hoped for, since timing of received positions will be all over the place.

[Ergonomicmike]

I get it that, since the ICAO address was always the same, this issue should fall to the EFB manufacturers to eliminate dupes. And, interestingly, iFly was ready to look into doing that two weeks ago. (I put them off for now, telling them that the Stratux team was working on this and that the data stream was in flux.)

My thinking is that since the Stratus V2 dedupes (when coupled with FF), the Stratux should do similar. (I'm assuming that FF is not depuping when it sees that it's talking to a Stratus. But who knows? Maybe the Stratus sends FF extra data so that FF itself is deduping?)

Any extra de-duping by an enterprising EFB shouldn't be a problem and might help catch any stragglers that get thru the Stratux.

[Ergonomicmike]

@AvSquirrel Here's another dupe in flight. Sorry I didn't get his call sign in the screen shot, but it's a PA. He's 1090 Out. The FAA must have put another tower nearby, 'cause I'm picking up his duplicate on 978. (I'm in his puck for a while.)

The flight was on 4/29 and it's the first flight on that day. (That is, near the end of the log file. stratux.single.dupe.zip