My GTX330 indeed uses a differential (pitot-static) pressure switch; this also drives the TAS605. That was after I paid £500 to an avionics shop to make that ground speed connection 
Predictably both Avidyne and Garmin washed their hands of it – just like they did on the GTX330 → TAS605 ARINC429 pressure altitude connection which also doesn’t work (although there is a post here somewhere stating that after some firmware upgrade this now works).
The Q of whether to radiate uncertified ADS-B, on the grounds that it is better than nothing, is really here and how many people who you are likely to hit use one of these. Personally I don’t know a single such pilot.
If anyone has managed to get anything out of a KLN94-GTX330ES connection, I would be interested.
Peter wrote:
The GTX330 cannot even use the KLN94 ground speed for ground/air mode switching, even though this is shown in the GTX330 manual… some indications exist that this bug was quietly fixed recently, under the “KLN89” heading.
Using GS to switch between ground/air mode doesn’t seem reliable with our slow-speed aircraft. It must not switch to ground mode in the air even if you are flying near Vs0 in a strong headwind, while not switching to air mode during taxi.
The Trig TT31 we use in two aircraft needs both a GPS and an ADC to do the switching without the use of a squat switch (or separate pressure sensor).
OK; but the GPS has to be a WAAS box. So for me, KLN94, this would not work. I could get ADS-B OUT with a GTX345 which would be doing it in isolation from everything else, using its own internal WAAS GPS, and otherwise acting as a standalone GTX330 does.
It is possible that a KLN94 could feed a GTX330 ES and I would then be radiating ADS-B OUT with SIL=0 so only uncertified traffic detectors would see it, but I very much doubt the GTX330 ES would take in KLN94 GPS data. The GTX330 cannot even use the KLN94 ground speed for ground/air mode switching, even though this is shown in the GTX330 manual… some indications exist that this bug was quietly fixed recently, under the “KLN89” heading.
Incidentally I have not managed to establish that a GTX345 will feed traffic data to anything I have. So it’s traffic merging feature (TAS605 + ADS-B IN) is probably useless. Of more concern in the future is that it may be that the Sandel EHSIs cannot display any traffic data other than what is coming directly from a TAS6xx or similar active TAS box.
It’s funny to observe that until I actually want LPV, my best course is to do exactly nothing
After the “ES” hardware upgrade, the transponder can be connected to a GPS and configured to transmit Mode S extended squitter (aka ADSB-out). In my case the transponder was already connected to my GTN650, but you’ll need to establish a serial connection if not already present. Then you just tweak a couple of configuration settings as detailed in the manual.
How many active pilots have some kind of electronic traffic detector? I guess about 1,000, give or take a factor of 10. But one can at least say that most of these (relatively) cheap portable gizmos can receive 1090 MHz ADSB.
Conversely, ADSB-out might be seen by a few of the transponderless aircraft which Peter’s TAS can’t detect, but who nevertheless have PFLARM, PAW, Stratux, GDL39 or similar portable traffic detection gizmos – all of which can detect ES/ADSB-out, even with SIL=0.
That is possibly a good argument for implementing ADS-B OUT.
What I don’t know is how many people fly with those low cost gadgets. Reading some UK forums (which admittedly I rarely do these days) there seems to be a different gadget for every evangelical supporter of it. And I know that the highest volume posters do the least (or zero) flying.
I upgraded my GTX330 to ES last year. There’s practically no labour involved, and I think it’s worth doing even if the 1 AMU cost will never be fully reflected in the resale value of the transponder.
What does that actually do?
Jason wrote:
It is 3k vs over 1k to upgrade to ES – it is a much better deal IMHO and gives you more options with GTN devices in the future to display the ADS-B in traffic.
It’s hard to argue with that, but here goes:
1. Peter doesn’t really need ADSB-in (for now). He already has TAS, so ADSB-in would, at best, show a bit more accurately a very small percentage of the potentially conflicting traffic already displayed on his EHSI.
2. Conversely, ADSB-out might be seen by a few of the transponderless aircraft which Peter’s TAS can’t detect, but who nevertheless have PFLARM, PAW, Stratux, GDL39 or similar portable traffic detection gizmos – all of which can detect ES/ADSB-out, even with SIL=0.
3. It’s true that few light aircraft in Europe currently have ES transponders, but I don’t think that’s a good reason not to join us.
4. I upgraded my GTX330 to ES last year. There’s practically no labour involved, and I think it’s worth doing even if the 1 AMU cost will never be fully reflected in the resale value of the transponder.
I may be naive but I think we may get a carrot in the form of on-board weather and “TIS” traffic.
I have asked Sandel the very specific Q of whether TAS605 → GTX345 → SN3500 displays any traffic on the SN3500.
Presumably if it works, nobody will want to talk about it, unless the IM for the GTX345 or the IM for the SN3500 shows the connection 
If not, then changing the GTX330 to a GTX345 would just give me ADS-B OUT, at a cost of a few k, which almost nobody (of relevance) will see anyway, and is there any ADS-B OUT mandate for IFR below 5700kg on the horizon? There will never be one for VFR, as there will never be one for Mode C/S (in much of Europe).
Peter, to your question, I already had a GTN750 so the GTX345 is getting its WAAS GPS position from there, directly. I thought about putting the GTX345 to get some redundancy but that made things more complicated.
My disappointment with the GTX is the SynVizz is which is truly useless.
unless one also implements a full reversion capability (that is, the ability to select any given data source to feed any given data sink).
I think if one installed a GTN650+750 then one would have an antenna for each. And each of my two Sandel EHSIs can select GPS1/GPS2. So that’s done.
The one thing which cannot be done (legally; technically it is trivial) is to drive the autopilot from either EHSI’s autopilot output, switchable with a toggle switch, because that would need a new autopilot AFMS.
So if I install a GTX345, yes, currently with the KLN94 I would need to give it its own GPS antenna, and then I would have ADS-B OUT immediately.
I could connect the TAS605’s traffic output to it, so it merges that with its received ADS-B IN data, but the GTX345 won’t drive anything I have i.e.
Then we get back to this again
If the GTX345 cannot show traffic on the SN3500, that will be a huge retrograde step for me because I will lose TCAS, and when the GTNs go in I will see traffic only on them which is nothing like seeing it on the EHSIs, right in front of me.
So clearly I need to check out the traffic data stream compatibility GTX345 → SN3500 and not bother with any of this until this is 100% checked. I have already discussed this with Sandel and didn’t get a reply which I could understand clearly. Well, they said that ADS-B traffic will not show because it is sent via a different protocol (which seems bizzare since the GTX345 is supposed to be merging them transparently!).
It is very possible that a GTX345 would work for Mode C/S and ADS-B OUT and nothing else, and ADS-B IN would have to be done using the TAS605 “A” + ADS-B IN upgrade if they ever do it. Not sure I would want to spend a few k for this.
It is 3k vs over 1k to upgrade to ES – it is a much better deal IMHO and gives you more options with GTN devices in the future to display the ADS-B in traffic.
Indeed, but not if the Sandel EHSIs cannot display ex-GTX345 traffic…
