That Garmin rep is usually trying to be helpful but there is a limit to what a mfg rep can say in a forum.
One concern is that this may never be fixed, for commercial reasons. For example the GTX330-TAS605 ARINC429 pressure altitude incompatibility I mentioned has not been fixed for years and IMHO never will be because why should one encourage the sales of the other?
The other concern is that not every installer knows about this and what happens a lot is the “fait accompli” situation where your €40k avionics upgrade turns out to have a significant (well, significant to a pilot, not necessarily regarded as significant by the installer) issue but you are hardly going to have it all ripped out due to that. You will accept it and pay up. I have been in this situation a few times myself. It gets compounded by the discovery being made when you are over a barrel and with your back to a wall, having travelled a long way to collect the plane.
It worries me that a new product such as the Garmin GTX345 “handles” unexpected data by rebooting!
I can accept that there is a protocol mismatch between Aspen and the Garmin unit. That happens. But for a certified unit to not have any checking that the input data matches what they expect and that there does not seem to be any error-handling to speak of is a frightening. Having the unit endlessly rebooting while flying a heading of 360 is not what I would call having a robust design.
To add to my comment about stuff not getting fixed, the FAA-approved GTX330 IM shows a KLN94 interconnection (for auto GND/AIR switching based on GPS GS) but this never worked and both Garmin and King washed their hands of it. A UK avionics shop charged me £500 for wiring it up, which I had to pay anyway… A year or so ago Garmin rolled out an update which claims to contain a “KLN89” fix which may address this, but (if that fixes it) that took 10 years!
This is probably not relevant to the GTX345 which has its own GPS (IF you go for that option – needs the extra antenna etc) but it is IMHO a valid illustration in this inter-compatibility runaround. The fix for that particular issue (and it is really good to have auto switching – you never need to turn the txp on/off ever again) is an external switch of some sort (differential pressure, or landing gear) and that is a lot of work.
Peter wrote:
I have been in this situation a few times myself. It gets compounded by the discovery being made when you are over a barrel and with your back to a wall, having travelled a long way to collect the plane.
A friend I know who was in a similar situation (not to do with avionics, but other issues with a light twin) when discovering that the work had not been done satisfactorily cancelled the cheque. I don’t know how it got resolved in the end.
JasonC wrote:
These things happen more and more as avionics are more software and less hardware. Suggest we get used to it.
I don’t really understand why this would be the situation. In my experience most modern software written in modern languages by people who understand them are not prone to such errors. I have, however, seen loads of such issues with firmware, which is still mostly written by hardware specialists with some “special” understanding of software engineering. Of course, the choice of low performance hardware and nonstandard connectors in embedded applications often makes it necessary to code that way.
So, IMO, if avionics would actually be more software than hardware, i.e. they would use some general purpose CPU attached to a big touchscreen display, run an OS and treat all the special sensors / transmitters etc as external devices, most of such issues would disappear. Others would appear, of course, and the current certification regime would nullify almost all advantage of such a system.
(Btw, I write this as a software engineer, who also oversees the hardware development at a medtech company.)
Peter wrote:
That Garmin rep is usually trying to be helpful but there is a limit to what a mfg rep can say in a forum.One concern is that this may never be fixed, for commercial reasons. For example the GTX330-TAS605 ARINC429 pressure altitude incompatibility I mentioned has not been fixed for years and IMHO never will be because why should one encourage the sales of the other?
The other concern is that not every installer knows about this and what happens a lot is the “fait accompli” situation where your €40k avionics upgrade turns out to have a significant (well, significant to a pilot, not necessarily regarded as significant by the installer) issue but you are hardly going to have it all ripped out due to that. You will accept it and pay up. I have been in this situation a few times myself. It gets compounded by the discovery being made when you are over a barrel and with your back to a wall, having travelled a long way to collect the plane.
These are all very valid points, Peter.
Having gone through the same things you have, and having people come to me since then with advice for their airplanes, I’ve told them that quite simply the answer is to demand the installation manuals up front and either do their own research or pay someone else to advice/research compatibility for them beforehand.
I know that shop contracts with avionics OEMs surely preclude them from giving out manuals but you know what, I don’t care. I’m paying, I want to see a manual. If the manual says something works and it doesn’t, I have at least that much in favor of recourse should it come to that.
I am certain there is absolutely nothing in certification which requires manuals (including maintenance manuals) to be kept dealer-only.
It is purely to make it hard to compete with mfg authorised installation and repair shops.
Same with cars.
I have a huge collection of avionics manuals… Been collecting them since 2002.
I can see both sides of the argument but still prefer independence! OTOH this is moot for most glass G500 and above because you need dealer-only codes to configure the stuff… Which is why I would never install a G500. The IFD540 is ok; not sure about GTN750.
Garmin has gone further toward the proprietary route with the 750.
There is an ethernet interface for connectivity with other Garmin devices, which is why my and another person’s GTX345 exhibit the crash-on-north issue but 750 owners think it’s just peachy. 750/650 owners can plug the two up via ethernet and I cannot.
The Avidyne unit I think is great from a UI design standpoint, it’s an updated version of the GNS480/CX80 basically. The only catch with Avidyne is they chose to use an ARINC735 bus for traffic to maintain compatibility with a TCAS system they sold years ago, which will effectively make their ADS-B interface proprietary as well, because no one else is using the same thing. In their case I don’t think it was a nefarious plot toward proprietary interfaces, but rather just legacy support.
FreeFlight is making ADS-B hardware for Aspen. Navworx is making ADS-B hardware for Avidyne. Garmin is making their own.
I understand that install manuals are not regulatory, but they are evidence of false advertising. If something stated in one does not work I might not be able to get their STC/TSO pulled, but I can cause them enough grief to motivate them, at least. Sadly most owners believe the shady idea suggested to them by dealers that they should “not badmouth hardware they bought in public, lest they affect the value of their own airplane negatively.” Which is of course a farce, that 15,000 dollar GPS on the used aircraft market is worth 5,000, and can be easily replaced with another used unit for that value.
It’s never ceased to amaze me how people smart enough to earn the money required to buy an airplane are by and large such suckers for a salesman.
Update to my 345…
Confirmed the issue today. We somewhat fixed it by passing 429 bus heading to the 345. That stopped the constant reboots. Still a couple of random crashes, and if the connection to the 429 bus is lost it will revert back to the broken interface, but there is no more constant crashing on a north heading.
video of the unit on the proprietary interface in a crash/reboot loop…
video of the unit with 429 bus heading hooked up on the same 360 heading, with the GPS showing a 429 bus heading of ‘0’ that it is just fine with..
Garmin’s rep is still trying to push the line that this is Aspen’s fault in the Beechtalk thread on the issue. He’s got a tough sell on that considering it’s none of his business what sort of heading indicator I use, whether it be mechanical HSI or electronic AHRS, and none of his business who made it, either. All that matters is it’s compliant with the ARINC429 spec that it sends heading data out on.
All of this is also a lesson for the FAA in their grand mistake of allowing anyone certification of an ADS-B device with a proprietary interface.
RNCTX wrote:
Confirmed the issue today. We somewhat fixed it by passing 429 bus heading to the 345. That stopped the constant reboots. Still a couple of random crashes, and if the connection to the 429 bus is lost it will revert back to the broken interface, but there is no more constant crashing on a north heading.
I don’t get it. Which interface EXACTLY are you using? You where talking about RS232 when this hole thing started, now on 429. 429, from Aspen to GTX directly? Or Aspen data from Aspen trough your GPS to the GTX345?
I am also quite amazed that none of the involved parties took their RS232 or ARINC 429 analyzer, and just watched what happens, and simulated afterwards using their RS232 or ARINC 429 simulator to fake these labels and loads. Then it is SO easy to spot the problem this way, and exactly know what is going wrong. One can even do this comfortable from the bench / workshop.
We somewhat fixed it by passing 429 bus heading to the 345
This is a statement, which doesn’t tell me anything?
Still a couple of random crashes
Why are these other random crashes? They shouldn’t do that. What does happen, has this been analysed?
To me it seems you and/or your shop don’t understand troubleshooting. Measuring is ALWAYS the prefered method, over replacing components or switching datastreams. Don’t get me wrong, I don’t think their is anything wrong with the Aspen heading interface, as it is used on many situations, without issues, so is the Aspen heading acceptance on many Garmin products. I just would be interested to see the source of this issue. Which doesn’t seem to be to difficult to spot when I am honest. Talking in your rant to Garmin, first talking about RS232 and now on 429, without any exact details or settings, isn’t really helpfull, and for sure doesn’t help getting it fixed ASAP.
