JasonC wrote:
but for light GA you get nothing
Wasn’t always that way – the Auster pilot’s manual doesn’t just include the typical V-speeds and preflight checklists, but about 80% of it is devoted to how to completely disassemble and reassemble the entire aircraft :-)
alioth wrote:
If input data can crash a device, the crusade is worth it. External input data should never cause a system crash. It’s a bug if it does, no ifs no buts. Failure to validate inputs is a schoolboy error.I can understand things getting “worryingly personal” when you’ve spent several thousand on an installation that keeps crashing due to a software bug, and when manufacturers of said products don’t publish installation manuals openly and tries to wash their hands of a very obvious software defect in their product.
Of course it shouldn’t crash. But I stand by my views on the tone and style of the poster’s approach.
And I am with you on the manuals point. It is funny that for the C510 you get everything down to NDT manuals and wiring diagrams but for light GA you get nothing. I expect it is based on what the customer base demands. But this of course is not-Garmin specific.
JasonC wrote:
So far we have not been shown enough to know if that crusade is justified. Seems worryingly personal
If input data can crash a device, the crusade is worth it. External input data should never cause a system crash. It’s a bug if it does, no ifs no buts. Failure to validate inputs is a schoolboy error.
I can understand things getting “worryingly personal” when you’ve spent several thousand on an installation that keeps crashing due to a software bug, and when manufacturers of said products don’t publish installation manuals openly and tries to wash their hands of a very obvious software defect in their product. Personally I like Garmin stuff but I’ll only buy their gear if I can get the installation manual first – fortunately this has been possible so far thanks to people leaking the manuals online where Google can find them. But Garmin should publish them openly. Even if I’m not doing the installation myself I still want to know what’s going to be involved and what level of complexity it will be, which the manual will tell me.
It is one thing to discuss a problem with an installation. This seems a bit of a crusade against Garmin. So far we have not been shown enough to know if that crusade is justified. Seems worryingly personal…
RNCTX wrote:
It took me awhile to get my hands on the manuals, that’s the other problem we could wax intellectual about (approved devices should have publicly available manuals).
Is your installer a Garmin dealer? They should have acces to all manuals. They also should now how they wired your aircraft, and how they did the configuration.
I can understand the manual issue from both sides. For equipment which is openly available, I get in quite some installations for troubleshooting. Many installation are done incorrect due to lacking knowledge or understanding of the installation and the lack of knowledge and/or availablity of test equipment. These poorly done installations can harm a manufacturers name, in cases where you can’t blame them.
RNCTX wrote:
The ambiguity from my shop about what interface was actually being used is a result of this being proprietary and poorly documented, again another political debate of sorts. They couldn’t give me a straight answer on what was coming from what because Garmin doesn’t tell them what’s on the proprietary port. The short answer is they didn’t know either until yesterday. We had to figure it out by trial and error.
As NCYankee also said, ARINC busses and protocols are industrie standards. With an ARINC analyzer one can have a look at all the labels and dataload. With a good analyzer you can also inject labels and data, to facilitate troubleshooting.
RNCTX wrote:
1) The RS232 interface from the GPS to the transponder is in use, because it carries the GPS position data, it has to be in use. It also carries other undocumented data, which is causing this problem. Garmin does not divulge what exactly is on that interconnect other than GPS position.
The installation manual list what GPS information is used.
RNCTX wrote:
At the very least, heading from the GPS, because that’s causing the repeatable crashes.
Where does this heading come from. A GPS alone has no heading information (only track) and uses other sensors to know heading. Does your GPS have an heading source, which source is being used?
RNCTX wrote:
The Garmin manual does say that ARINC429 true heading input will override any other heading source. So we ran that from my Aspen panels, and as long as the ARINC429 input is not lost, the box works on a 360 heading.
Ok, but you will always have your Aspen on, so this works fine, there is no problem with the Aspen to GTX interface. When switched off this shouldn’t be a problem, so you will have to troubelshoot another issue.
RNCTX wrote:
If the ARINC429 heading input is lost it reverts back to the proprietary RS232 heading data and the crashes begin again on a 360 heading.
So what is the source of the heading information on RS232? As said before, it can not be the GPS itself.
RNCTX wrote:
We got other random single reboots but not a repeatable pattern.
You must find the source of this as well. This is not ok.
RNCTX wrote:
We know what’s on the ARINC429 interconnects between the AHRS and the GPS, those are well documented and verifiable between the two boxes without any test equipment. One talks to the other and the data matches up.
Is this AHRS the Aspen? If so the Aspen delivers heading data to the GPS, however when you switch of the Aspen data you also loose heading data sourced from the Aspen. What happens to the HDG datablock on the GPS when you switch of the Aspen?
I am not sure what you mean by RNCTX wrote:
The ambiguity from my shop about what interface was actually being used is a result of this being proprietary and poorly documented, again another political debate of sorts. They couldn’t give me a straight answer on what was coming from what because Garmin doesn’t tell them what’s on the proprietary port.
ARINC 429 ports are not proprietary and the STC that Garmin provides includes using the Aspen heading via ARINC 429 in appendix C.5 Heading Source. So this would have been part of the testing to demonstrate that all of the connections to all of the devices worked. Something may have gotten past the process or some combination not included in the STC could be in play, but that is a totally different issue than proprietary interfaces which are not involved.
Edit: If your installer does something outside of the STC, it still may be approved, but not on the basis of the STC.
It took me awhile to get my hands on the manuals, that’s the other problem we could wax intellectual about (approved devices should have publicly available manuals).
The ambiguity from my shop about what interface was actually being used is a result of this being proprietary and poorly documented, again another political debate of sorts. They couldn’t give me a straight answer on what was coming from what because Garmin doesn’t tell them what’s on the proprietary port. The short answer is they didn’t know either until yesterday. We had to figure it out by trial and error.
So I went out there to observe yesterday as everything was pulled and re-interfaced.
1) The RS232 interface from the GPS to the transponder is in use, because it carries the GPS position data, it has to be in use. It also carries other undocumented data, which is causing this problem. Garmin does not divulge what exactly is on that interconnect other than GPS position. At the very least, heading from the GPS, because that’s causing the repeatable crashes.
2) The Garmin manual does say that ARINC429 true heading input will override any other heading source. So we ran that from my Aspen panels, and as long as the ARINC429 input is not lost, the box works on a 360 heading. If the ARINC429 heading input is lost it reverts back to the proprietary RS232 heading data and the crashes begin again on a 360 heading. We verified this by rebooting the Aspen panels with everything else running. We got other random single reboots but not a repeatable pattern.
3) We know what’s on the ARINC429 interconnects between the AHRS and the GPS, those are well documented and verifiable between the two boxes without any test equipment. One talks to the other and the data matches up. It’s the undocumented interconnect between the GPS and the transponder that is causing the issues.
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.
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.
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.
