Policy discussion: Traffic target update preferences #562
Comments
|
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 ***@***.***> 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
<4480c9d>
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#562>, or mute the thread
<https://github.com/notifications/unsubscribe-auth/ANN_wEZaPpyk3-ePV12yNsFauKciwGw1ks5rTMzggaJpZM4Llsz9>
.
|
|
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. |
|
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 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. |
|
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. |
|
|
|
@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.
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. |
|
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.
|
|
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 #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. |
|
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. |
|
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. |
|
@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 ***@***.***> 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
<#562 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ANN_wIEQNOE7inYohf6aVZWjsUrUMXPqks5rVNDQgaJpZM4Llsz9>
.
|
|
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.) |
|
I am not ADS-B out.
…On Mon, Jan 23, 2017 at 10:47 AM, Ergonomicmike ***@***.***> 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
<#562 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ANN_wNFcRjF_XbWezKY6aYAJsJB4-Kd0ks5rVNmrgaJpZM4Llsz9>
.
|
|
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." |
|
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.) |
|
From http://ipadpilotnews.com/2012/08/understanding-ads-b-traffic/ (emphasis mine)
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). |
|
I got an email back from iFly about de-duping. Reading between the lines, they don't de-dupe at this time. |
|
@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:
It would decode like this:
|
|
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. |
|
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 |
|
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.
|
|
Okay, here are some logs of dupes. And no dupes, for comparison purposes.
|
|
Oh, one thing that changed in the test above is that I'm running Stratux v1.2r1. |
|
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 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 The 0° track is an ancient Stratux bug in traffic.go dating back to 0.1r2 -- as written, this N4405Q 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. |
ghost
mentioned this issue
|
@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? |
|
@AvSquirrel After sleeping on it, I'm having a conceptual problem and perhaps not understanding correctly. You said
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. |
|
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?) |
|
Info I got from FF tech support on how to collect ADS-B logs:
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. |
|
@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? |
|
@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. |
|
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? |
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.
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:
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:
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. |
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 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?":
Hmm.. maybe a test build with the following changes would answer these questions:
|
|
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? (Does not apply to me.) Last week I sent iFly your previous comment about them reduping targets This week there is a fix in the latest version that says 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. |
|
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. |
|
@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. |
|
@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.
|
|
I just looked at the sqlite log and see that N8163E was received from multiple sources but always with the correct ICAO address AB226C. |
|
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. |
|
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. |
|
@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.
|
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:
4480c9d
The text was updated successfully, but these errors were encountered: