Mode C / pressure altitude bug with IFD540

This has been brought up before without a response so I thought I would start a new thread.

Myself and others (jwjenks here) have found that when the 540 is set to receive pressure altitude from the 340, the 340 no longer sends proper mode C altitude.  I discovered this after having my shop wire pressure altitude from my Aspen instead of from the old encoder.

Someone in Avidyne must be aware of this problem as their technical people advised my shop of this fix to get my mode C working again.  Will this be resolved somehow?

Same issue here.  I think that it might be an issue with the MLB-100.  I've had my IFD-540 and AXP-340 running fine till May.  On Nov 7th did an MLB-100 install and when I took off ATC said that I was showing that I was at 64,000 feet.  That is what the AXP-340 was showing as a PA. Left the plane at the shop and they said all was fine, but same thing happend on Nov 15th.  Could not troubleshoot on the ground so that shop disabled the MLP-100 serial port.  That seemed to fix the problem, but when I flew back to my home base, ATC lost my transponder signal for 3-4 mins.  When I checked the flight on Flight-Aware it did not show any ADS-B data like it has on all previous flights.

I don't see how the MLB-100 is involved in this problem at all.  It is just a receiver.

The only tie-in is that something happened to your setup while the avionics shop was installing the MLB-100.

Well technically, the IFD-540 is made by Avidyne, the MLB-100 is made by NavWorx, and the AXP-340 is made by Trig, but still you are correct that they should all work together.

There are a few different ways that these pieces of equipment can be wired together, and without knowing the details of your installation, it is hard to say what is affecting what, and where the fault may lie.  Overall, the MLB-100 is a side-system to the other two.  It shouldn't have any detrimental input to the altitude reporting capability of the transponder.

They do test their own stuff, as I'm sure you knew.  They have more than one airplane with the 540/340/100 combo installed.  But like I said, each piece of equipment has more than one way of being connected, and the details can matter.

I must have a different problem since I have no MLB100 and the AXP340 would output bad mode C at positive pressure altitudes.

Granted it's not a huge deal since the fix only involves me losing high resolution pressure altitude from the Aspen to the 540 (via the 340), but it would be nice to get some acknowledgement of the problem from Avidyne.  I  first reported this back on August 1.

David-Find it hard to believe that since I have an complete Avidyne stack that there is more than one way to hook it up. Looked at the install documentation and it is pretty clear what hooks up to what. Bottom line was that it appears Avidyne didn't do very much or very through integration testing with their own stuff. It's not like there are thousands of options out there in the Avionics world given that there are 10 manufactures or less. When you OEM stuff and put your label on it you are the stuckee. Since I'm an IT systems engineer I know the issues of heterogeneous integration, that is one reason I bit the bullet and did a complete Avidyne stack. The shop wanted me to go Garmin and now I see why. Seems like I'm really a Beta tester. 😩

roltman wrote: Now why the IFD is listening to MLB for anything altitude related is beyond me, but it is for some reason it is.

Hi Roy-

cajungene wrote: Find it hard to believe that since I have an complete Avidyne stack that there is more than one way to hook it up.

Let me say first, and foremost that I am sorry you're having trouble with your equipment.  I know how frustrating that is.  I also know that there is not much I can do to address the issue for you.

That said, there certainly are multiple ways to hook things up, just as I see in the thread above.  For example:

a) The IFD can act as a data concentrator, passing along altitude information from one source (Aspen) to others.

b) The AXP can act as a data concentrator, passing along altitude information from one source (encoder) to others.

The MLB100 alone has three different ways to accept altitude data (with variations within each category) because it is designed to be able to interface with so many different aircraft types and equipment types.  For example:

1) It can accept serial data from a digital altitude encoder.
2) It can accept serial data from a transponder that uses a grey code encoder.
3) It can use a TransMON to process the Mode C replies of the transponder directly.

So I stand by my statement that there is more than one way to hook things up.  There is a lot of variation in avionics interconnection design, and to be frank it is not practical to expect a manufacturer to test every possible interface in a live environment (think how many test planes they would need).  Even big, bad, brand-G doesn't do that.

David Bunin

Oh my gosh, I just realized who "CajunGene from Virginia" is.  Long time, buddy.  I'm sorry for the circumstances, but it's great to hear from you.  Tell Greg I said hello.

The 4.0.9 software update does work. Not sure what you mean about the TSO, because the unit is produced to a TSO standard.

I spoke to the people at NavWorx, and the altitude data output was one of the software feature differences between the MLB-100 and the ADS600-B products.  It was a feature that Avidyne requested during the development of the MLB/MLX series.  The bug described here was the fault of NavWorx, and they have taken the responsibility to fix it.  A new software (4.0.9) is in testing and certification now.

NavWorx was surprised (as was I) to learn that Avidyne does use the MLB-100 as the altitude source for all of the equipment in the panel, even if that equipment has access to other altitude data on another port.

Hang in there, the fix is on the way.  Lots of people surprised by this one.

David Bunin