It definitely doesn’t see Flarm of P51 (? the Pilotaware format).
Sure; I would not expect an ADS-B IN box to see Flarm.
The suggestion, IIRC, was that the GTX345 sees all ADS-B emissions regardless of the GPS level. I vaguely recall that there were some “low cost” initiatives being discussed which were “ADS-B OUT” but not otherwise compliant.
I am not going to have an Ipad running just to show traffic. The stuff needs to be in the primary field of view. If one was happy to run a tablet for traffic warnings, then (a) the audio feed would need to mix into the headset and (b) this issue is moot since one can rig up a “portable” ADS-B IN receiver feeding it. But most of the time in flight I am not referring to any tablet (except on an OCAS flight in the UK when I am watching the CAA chart on a moving map, carefully 
).
The audio comes from the GTX345 to your audio panel, no need to connect your tablet. The tablet is useful to you only if your current screens can’t display the traffic.
FWIW I found the post by @AviSimpson stating that the ADS-B IN upgrade will also require ADS-B OUT – here.
As one can see reading up and down that thread, a lot of this stuff has been done before… The Avidyne guy also states that the KMD550 will work as it does at present, displaying traffic data from the upgraded TAS605, though I presume this has not actually been tested since the product doesn’t exist.
The above is my reading of what was posted. Why one would need a “W” GPS for ADS-B IN I have absolutely no idea and that was not answered.
The other aspect is that if/when Avidyne do produce that ADS-B IN upgrade, will that do more or less than the proposed GTX345 approach? Obviously it would be a lot less work. So Q2 in my original post is becoming more relevant: what “kinds” of ADS-B traffic will each approach display?
To answer your specific question about what traffic will be seem:
Any traffic sending a SIL=0 will not be shown on a certified traffic display. This is a specific requirement in FAA TSO C195
http://adsbforgeneralaviation.com/wp-content/uploads/2011/12/TSO-C195.pdf
Therefore anyone sending ADS-B OUT from a Trig/Becker etc transponder linked to a KLN94/GPS 150 or similar non-WAAS GPS will not appear on your certified KMD550 or SN3500 displays.
On the question of why you need a certified WAAS GPS for the ADS-B IN function of the TAS 605. Same rule applies as for ADS-B OUT – the own-ship position source data for your display needs to have an integrity level equal to at least SIL=1 or above per the TSO (see table 2-3)
Many thanks wigglyamp. That is an eye-opener!
So it sounds like the TAS605 needs a GPS input (well, that’s obvious for ADS-B based traffic warning) and refuses to generate the output data unless the GPS data is SIL=1 or higher, so a TAS605 -A cannot work with a KLN94 in the panel.
Whereas a GTX345 ought to work since it has its own WAAS GPS, so the KLN94 becomes irrelevant.
Is the above correct?
Is there likely to be any difference between the way the “Mode C/S TAS” and ADS-B traffic get merged, between the two approaches?
This post seems to imply that anybody radiating ADS-B OUT must have a Mode S transponder, because a Mode A/C (e.g. a KT76C) one won’t have the 24 bit ID etc.
To fill in some detail: I have a KEA130A altimeter outputting gray code pressure altitude and that feeds
I was hoping to use the ex-GTX330 ARINC429 pressure altitude for the TAS605 (to avoid running the 11 wires) but it doesn’t work, and neither party wanted to be involved. I wonder if the GTX345 changes this in any way.
Peter wrote:
So it sounds like the TAS605 needs a GPS input (well, that’s obvious for ADS-B based traffic warning) and refuses to generate the output data unless the GPS data is SIL=1 or higher, so a TAS605 -A cannot work with a KLN94 in the panel.
Not correct. It’s the display that needs the WAAS GPS source and it’s the display that will disregard SIL=0 traffic targets.
This post seems to imply that anybody radiating ADS-B OUT must have a Mode S transponder, because a Mode A/C (e.g. a KT76C) one won’t have the 24 bit ID etc.
In Europe ADS-B OUT is only certified on 1090 and per CS-ACNS section 4, the ADS-B OUT transmission must be a function of the transponder, so therefore it must be a Mode S unit. You can’t have separate transponder and ADS-B OUT systems in the same aircraft:
CS ACNS.D.ADSB.025 Provision of Data
(See AMC1 ACNS.D.ADSB.025(a)(c))
(a) All data provided by the ADS-B Out system comes from approved sources.
(b) The data transmitted by the ADS-B Out system originates from the same data source as used in the transponder replies to Mode S interrogations.
ADS-B TRANSMIT UNIT
CS ACNS.D.ADSB.030 ADS-B Transmit Unit Approval
(See AMC1 ACNS.D.ADSB. )
The ADS-B transmit unit is approved and it is integrated in the Mode S transponder.
On your GTX330 issue sending 429 altitude to the TAS, I have seen this problem before and in fact our PA28 uses grey code to our TAS620 for the same reason. However I have seen instances where another 429 altitude source does work! It may be a high/low speed selection issue at the GTX but I haven’t investigated this further and don’t know if it’ll be solved with the GTX345.
It’s the display that needs the WAAS GPS source and it’s the display that will disregard SIL=0 traffic targets.
That gets even more interesting then.
The Sandel EHSIs are relatively modern and yes they get the GPS data, currently in RS232, so it sounds like they will implement the ignoring of ADS-B IN data if the GPS is an old one.
But the KMD550 is from 1999 and its firmware was last updated c. 2010 (it lives on the same 20MB data card as the map database). However the ARINC429 input is an ancient add-in card which was sourced in the USA and looks at least 10-15 years old. Is that really going to implement this specific ADS-B IN functionality (ignoring some traffic data) and does it have the second ARINC429 input for a “W” GPS? (The ARINC429 adaptor KAC504 has multiple inputs).
The above questions are relevant whether I do ADS-B IN with the GTX345 or by upgrading the TAS605.
Doesn’t the TAS605 -A need “W” GPS input too?
Looking at the GTX3x5 install manual, the following table lists the traffic-compatible displays:
This table shows the compatible traffic sensors that it can use to merger traffic and ADS-B data:
It looks to me that you would probably be best served to do the previously discussed GTN upgrade to get a compatible display for ADS-B traffic and the GTX345 (without internal) GPS for ADS-B OUT/IN and merged TAS data. If Sandel can also display ADS-B traffic on the SN3500 then that’ll be a bonus as the display GPS source would be suitable from the GTN. However, certification of an ADS-B display on the SN3500 would fall outside Garmin’s GTX AML STC. There’s no way to display SIL-0 traffic on the fixed installation but you could then run a tablet with Garmin Pilot to display ALL traffic.
Many thanks wigglyamp.
Gosh, hmmm, that pretty well finishes it
The GTX345 probably won’t feed a KMD550. I wonder what would happen if it was connected up? It might display SIL=0 targets…?
The GTX345 “cannot legally” feed the Sandel EHSIs unless Sandel have FAA approval for that input source. If it is in the current SN3500 IM, it should be approved.
The -A TAS605 needs a “W” GPS.
If I upgraded the centre stack for a “W” GPS then the TAS605 -A upgrade will work because the KMD550 will be gone too, and Avidyne are sure to support both IFD and GTN displays. And the GTX345 route would also work. Except for the Sandel EHSI question…
So I can’t really do anything until I am in a position to tackle the “big job”.
Where does Garmin Pilot get the traffic data from? Does it get it from the GTX345 via bluetooth, and because it is uncertified it displays the whole lot? If so, that suggests a KMD550 would also display the whole lot.
Incidentally I would have considered replacing KLN94+KX155A with a GTX650 (which would also leave enough centre stack room for the TKS control panel) but there is that issue with a GNS/GTN feeding the KMD550. There is the mysterious OBS mode incompatibility. One old thread here.
Peter wrote:
Where does Garmin Pilot get the traffic data from? Does it get it from the GTX345 via bluetooth
Yes
Peter wrote:
because it is uncertified it displays the whole lot?
Don’t know and hard to test because so few SIL=0 targets live in the UK
Peter wrote:
that suggests a KMD550 would also display the whole lot
If it does display anything at all obviously :-)
Peter wrote:
here is that issue with a GNS/GTN feeding the KMD550
I know you don’t like the iPad but if you have one somewhere and haven’t yet tried the GTN750 simulator, it may help making a decision in what a few of us would consider the right decision, which is to get a GTN750 ;-)
