stratux
stratux copied to clipboard
cyoung
Policy discussion: Traffic target update preferences
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
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 [email protected] 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 .
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 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.
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.
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.
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.
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.
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 [email protected] 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 .
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 [email protected] 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 .
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)
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).
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:
08a6629f2eb62d63aed61c2a001e2c801809e5bba8e6c40678a08200001c60000000
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. 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.
Oh, one thing that changed in the test above is that I'm running Stratux v1.2r1.
@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.
@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
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.
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:
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.
@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.