A story from a pilot I know…
He bought one of Garmin’s new 345 ADS-B in+out transponders last week.
New to this breed of transponders is the addition of a heading input from another AHRS or HSI. The transponder has the ability to project a standby AHRS display over bluetooth to an iPad.
In his case he has Aspen panels, so hooked up the heading output of the Aspen 429 bus to the heading input of the transponder.
He noticed after taking off from the radio shop, which is on a field with runways 17 and 35, that the transponder had rebooted during my climb and initial turn. He thought that odd, but didn’t think much else of it, until he got the airplane on the ground at his home airport.
His hangar faces due north, and he always lines the airplane up so that the line service crew doesn’t have to move my airplane much, they just push it straight back. With the airplane sitting on the ground with the nose pointing due north in front of the hangar, the transponder was in an infinite reboot cycle. As soon as it synchronized with the GPS, it would reboot again. In searching around for what might cause this he found that he’s not the only one to have such a problem. The first GTX345 customer with Aspen panels in the U.S. found the same thing. His shop thought that the unit was overheating, so left it running overnight with a ground power unit attached to the airplane to see how hot it was getting, but found it cool and working fine the next morning.
Upon further investigation, they found the culprit. The GTX345’s heading input expects values from 1 to 360, because that’s what the entire aviation and maritime world agrees is the proper way to define a circle. Aspen disagrees. Their computer outputs heading encoding that represents values from 0 to 359. So when flying a heading of 360, the Aspen panel sends the transponder an invalid heading of zero, and the transponder either assumes an AHRS failure and reboots itself, or hits a divide by zero error and crashes.
In this case the fix is relatively simple: the GPS has an internal CDI that can output heading over its 429 bus to the transponder, and that should work fine. But anyone with Aspen displays and without a GNS480/CX80 or GTN as their GPS will not be able to use the 345’s AHRS function, unless they avoid flying north…
This shows how really stupid some avionics software programmers are. Clearly, not even the simplest range checking is being done.
Peter wrote:
The GTX345’s heading input expects values from 1 to 360, because that’s what the entire aviation and maritime world agrees is the proper way to define a circle.
Well, ARINC 429, which has been the standard for civil aviation since the 1970ies, describes circles from 0 to 359.xxx degrees (see for example page 13 of this document: http://read.pudn.com/downloads111/ebook/462196/429P1-17_Errata1.pdf ). So in this case, Garmin has it wrong.
But of course a simple plausibility check of input values should not be too much work for a programmer, one should think…
I replied to this forum’s other thread on the 345 but THANK YOU VERY MUCH!
I was going to start digging through paper to prove someone wrong and you’ve done it for me and saved me a few hours of trouble. This guy is trying to blame Aspen over on the United States based Beechcraft forums as if “oh yeah well we’ll push a software update to fix it, even though it’s not our fault we’re such nice people, blah blah blah”
Peter wrote:
Upon further investigation, they found the culprit. The GTX345’s heading input expects values from 1 to 360, because that’s what the entire aviation and maritime world agrees is the proper way to define a circle. Aspen disagrees. Their computer outputs heading encoding that represents values from 0 to 359. So when flying a heading of 360, the Aspen panel sends the transponder an invalid heading of zero, and the transponder either assumes an AHRS failure and reboots itself, or hits a divide by zero error and crashes.
It strange that people start with blaming Aspen, while the GTX345 is a new and newly installed product. The Aspen HDG output is used by GNS / GTN / Stormscope system, traffic systems etc without issues.
One would expect that there is filtering on false data, not rebooting the complete unit for incorrect data.
They are blaming Aspen because Garmin sends a rep to post on their forums and lie to them about what a great job Garmin is doing. Aspen doesn’t bother to have someone employed to post on forums all day.
Unfortunately for him, he’s been caught in one of those lies.
It is probably too early to know who is right and who is wrong. Reps on forums are not necessarily evidence of why something is right.
Interactions between various dissimilar systems are complicated but it is surprising this did not come out in testing and certification.
JasonC wrote:
Interactions between various dissimilar systems are complicated but it is surprising this did not come out in testing and certification.
Agreed. Though I once had issues to get something to work, when the product manufacterer finally said that they didn’t test every combination in the manual. This was a very small manufacturer, it seems some testing is replaced by looking at the specifications, which is understandable, but not the best option.
In this case, they used an unapproved interface, that’s why it came out without being tripped up in certification testing.
The interconnects between Aspen and the GPS are ARINC429, that’s an approved interface with a particular spec for each port and pin. The connection between the GPS and the transponder is plain RS232 serial which has a lot more leeway given to the OEM on the particulars of compatibility. So a better question is… “why is the FAA allowing Garmin, Aspen, and Avidyne to try and steal their new transponder spec by allowing them to certify devices with non-compliant interfaces?”
I’m told by someone else that the heading interface is optional and can be disconnected without affecting the rest. That may be the case and if it is I’ll do so and just keep the box until the software update fixes it, but that guy from Garmin is going to admit his lie in front of his flock over there, I’m not going to remove it on my own and not harass him about it.
That guy pushes “well if you had bought XYZ from us instead of those other people you wouldn’t have these problems” all the time over there.
The real issue here is “One would expect that there is filtering on false data, not rebooting the complete unit for incorrect data.” which shows really sloppy software practices. It is the very practice (not range checking data) which has resulted in thousands of updates to Windows to block all the buffer overflow (etc) back doors allowing remote code execution. Certification testing isn’t going to pick up crappy software because you cannot test every data combination.
BTW, RS232 is an interface, not a protocol. You can send anything over RS232 but you can also send (slightly less than) anything over ARINC429 too. If somebody is not validating ARINC429 data, what will happen if the source happens to include some new label in the data stream? Reboot?? And ARINC429 too is sometimes badly coded e.g. a Garmin GTX330 ARINC429 altitude output is not compatible with an Avidyne TAS605 altitude input (so that interface had to be wired using gray code i.e. 10 wires) and both blame the other without anybody giving details.
Sure XYZ works but it is used less and less, and being analog you get variations between receiving devices of up to 1-2 degrees. But also XYZ goes back to days (the Gemini space programme, 1960s) when coding and design generally were done by more competent people.
As regards mfg reps participating on forums, this is a whole other topic… most of them are scared of it, but then
Mfgs who participate intelligently can get a lot of business that way. I recall seeing this from the early days of CAD/EDA when Protel pretty well wrapped up the PCB design market, largely by participating on Compuserve and in Usenet.
Reminds me of a story from a controller at Copenhagen ACC:
They got a new computerized control central back in the 90’s. One morning the radar screens showed blank circles instead of the expected sqares with transponder code and other data. The cause: The radar screen computers had rejected all flight plans as February 29th was not a valid date.
