Avidyne Homepage
Forum Home Forum Home > Avidyne General > AXP340/322 ADS-B Transponder
  New Posts New Posts RSS Feed - Mode C / pressure altitude bug with IFD540
  FAQ FAQ  Forum Search   Register Register  Login Login

Mode C / pressure altitude bug with IFD540

 Post Reply Post Reply
Author
Message
Royski View Drop Down
Groupie
Groupie
Avatar

Joined: 26 Feb 2013
Status: Offline
Points: 87
Post Options Post Options   Thanks (0) Thanks(0)   Quote Royski Quote  Post ReplyReply Direct Link To This Post Topic: Mode C / pressure altitude bug with IFD540
    Posted: 26 Oct 2015 at 10:21am
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?
Back to Top
compasst View Drop Down
Senior Member
Senior Member


Joined: 22 Feb 2015
Location: Akron, OH
Status: Offline
Points: 169
Post Options Post Options   Thanks (0) Thanks(0)   Quote compasst Quote  Post ReplyReply Direct Link To This Post Posted: 31 Oct 2015 at 7:59am
I will check for this bug in my installation. I actually didn't know that the IFD540 could receive PA from the 340. 
Back to Top
cajungene View Drop Down
Newbie
Newbie
Avatar

Joined: 16 Apr 2015
Location: Virginia
Status: Offline
Points: 17
Post Options Post Options   Thanks (0) Thanks(0)   Quote cajungene Quote  Post ReplyReply Direct Link To This Post Posted: 19 Nov 2015 at 12:39pm
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.

 Will check again on a flight next week.  

Some questions:

Did ADS-B get disabled somehow? 
Is this an issue a patch for the MLB-100 or the AXP-340 or both?
If the ADS-B is disabled, what is the workaround?
When is the patch coming out?  
Back to Top
Royski View Drop Down
Groupie
Groupie
Avatar

Joined: 26 Feb 2013
Status: Offline
Points: 87
Post Options Post Options   Thanks (0) Thanks(0)   Quote Royski Quote  Post ReplyReply Direct Link To This Post Posted: 19 Nov 2015 at 1:17pm
FWIW, in my case there's no MLB-100.  The nature of the problem makes me think there is some sort of unwanted feedback loop between the 540 and 340 whenever the 540 was set to receive altitude from the 340.
Back to Top
DavidBunin View Drop Down
Senior Member
Senior Member
Avatar

Joined: 20 May 2015
Location: Rockwall, TX
Status: Offline
Points: 742
Post Options Post Options   Thanks (0) Thanks(0)   Quote DavidBunin Quote  Post ReplyReply Direct Link To This Post Posted: 24 Nov 2015 at 5:41pm

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.

Back to Top
cajungene View Drop Down
Newbie
Newbie
Avatar

Joined: 16 Apr 2015
Location: Virginia
Status: Offline
Points: 17
Post Options Post Options   Thanks (0) Thanks(0)   Quote cajungene Quote  Post ReplyReply Direct Link To This Post Posted: 24 Nov 2015 at 6:42pm
Flew today with the MLB-100 circuit breaker pulled. ATC could see me, but I think the shop disabled altitude input so I didn't have ADS-B service. I blows my mind how Avidyne shovels this stuff out the door and it doesn't work. This is not a Brand-X interface issue since I have an all Avidyne stack (IFD-540, MLB100, AXP-340). One would think that they would test their own stuff. The Pressure Altitude glitch is really galling.
Back to Top
DavidBunin View Drop Down
Senior Member
Senior Member
Avatar

Joined: 20 May 2015
Location: Rockwall, TX
Status: Offline
Points: 742
Post Options Post Options   Thanks (0) Thanks(0)   Quote DavidBunin Quote  Post ReplyReply Direct Link To This Post Posted: 25 Nov 2015 at 9:28am

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.

Back to Top
roltman View Drop Down
Senior Member
Senior Member


Joined: 04 Aug 2011
Status: Offline
Points: 173
Post Options Post Options   Thanks (0) Thanks(0)   Quote roltman Quote  Post ReplyReply Direct Link To This Post Posted: 25 Nov 2015 at 10:20am
Originally posted by DavidBunin DavidBunin wrote:

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.

David, what very little time I've managed to dig into it, it appears to be a simple signed integer being memcpy into an different sized integer.  Where this happens I don't know, but it does look like in the MLB100 code and is only an issue with negative pressure altitudes.

Looking at a reported pressure altitude value of -50 has a hex value of 0xFFCE in a 4byte signed integer.  Now taking that hex value and dumping it into an 8byte signed integer, 0x0000FFCE results in 65486. Now if you use positive numbers they'll translate without error. 50 = 0x0032 which if 0x00000032 is used in an 8byte integer also equals 50.

Since this only happens when pressure altitude goes negative and it appears the resulting values from the MLB to the IFD are dorked up. Now why the IFD is listening to MLB for anything altitude related is beyond me, but it is for some reason it is. It then through the IFDs connection to the APX340, its pressure altitude values become messed up.  Removing the MLB from the loop via a switch or breaker fixes everything on both the IFD and the APX.

What I've been able to determine it is not the encoder causing the issue.

Finally it wouldn't be the first time a trivial programming error made it out in production code in the MLB100 for one of its core features.  I'm referencing the traffic issue which was clearly a +/- issue on heading/track.

Finally, I should say the is all a "W.A.G.N.E.R." at this point and my theory.



Edited by roltman - 25 Nov 2015 at 10:22am
Back to Top
Royski View Drop Down
Groupie
Groupie
Avatar

Joined: 26 Feb 2013
Status: Offline
Points: 87
Post Options Post Options   Thanks (0) Thanks(0)   Quote Royski Quote  Post ReplyReply Direct Link To This Post Posted: 25 Nov 2015 at 11:07am
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.
Back to Top
PA20Pacer View Drop Down
Senior Member
Senior Member


Joined: 07 Mar 2012
Location: Illinois (LL22)
Status: Offline
Points: 161
Post Options Post Options   Thanks (0) Thanks(0)   Quote PA20Pacer Quote  Post ReplyReply Direct Link To This Post Posted: 25 Nov 2015 at 3:53pm
Originally posted by Royski Royski wrote:

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.

Hi Royski-

I thought that the IFD540 would be receiving altitude information (both pressure and baro-corrected) from the Aspen via the ARINC 429 bus, so why would there be any need for a serial pressure altitude input to the 540 from the 340? I have the AXP340 serial repeater output connected to my #2 GPS (Trimble 2000 Approach Plus) and it seems to work fine.

I probably lost an accurate understanding of your problem somewhere along the line. I apologize if I have confused the issue.

Regards,

Bob
Bob Siegfried, II
Brookeridge Airpark (LL22)
Downers Grove, IL
Back to Top
cajungene View Drop Down
Newbie
Newbie
Avatar

Joined: 16 Apr 2015
Location: Virginia
Status: Offline
Points: 17
Post Options Post Options   Thanks (0) Thanks(0)   Quote cajungene Quote  Post ReplyReply Direct Link To This Post Posted: 25 Nov 2015 at 8:44pm
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. 😩
Back to Top
roltman View Drop Down
Senior Member
Senior Member


Joined: 04 Aug 2011
Status: Offline
Points: 173
Post Options Post Options   Thanks (0) Thanks(0)   Quote roltman Quote  Post ReplyReply Direct Link To This Post Posted: 25 Nov 2015 at 9:00pm
Originally posted by cajungene cajungene wrote:

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. 😩


Cajungene,
They found the problem, it's in the MLB100. The fix is in flight testing to be released "after Thanksgiving".
I feel your pain, trying to focus on the good. You could have the Garmin software update eating $100 TSO''d SD cards right now.
Back to Top
brou0040 View Drop Down
Senior Member
Senior Member


Joined: 13 Dec 2012
Location: KIYK
Status: Offline
Points: 720
Post Options Post Options   Thanks (0) Thanks(0)   Quote brou0040 Quote  Post ReplyReply Direct Link To This Post Posted: 25 Nov 2015 at 10:37pm
Originally posted by roltman 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.

It would be nice to get the altimeter setting over ADSB.  Every time I change controllers, they tell me the setting in their sector and do the same for every other pilot.  Seems like that could be avoided by having the equipment pull the AS from the ADSB link.  That would also provide baro-corrected altitude into the system...
Back to Top
Royski View Drop Down
Groupie
Groupie
Avatar

Joined: 26 Feb 2013
Status: Offline
Points: 87
Post Options Post Options   Thanks (0) Thanks(0)   Quote Royski Quote  Post ReplyReply Direct Link To This Post Posted: 26 Nov 2015 at 8:16am
Originally posted by PA20Pacer PA20Pacer wrote:

[
I thought that the IFD540 would be receiving altitude information (both pressure and baro-corrected) from the Aspen via the ARINC 429 bus, so why would there be any need for a serial pressure altitude input to the 540 from the 340? 

Hi Bob,

In my case, when I had the work done this summer, I don't think it was yet approved to split the output of the Aspen such that I could affordably get the air data from it into the 540.  So I have the Aspen working as an altitude encoder, providing altitude in 10 foot increments, as I was starting to lose confidence in my old encoder.

Roy
Back to Top
PA20Pacer View Drop Down
Senior Member
Senior Member


Joined: 07 Mar 2012
Location: Illinois (LL22)
Status: Offline
Points: 161
Post Options Post Options   Thanks (0) Thanks(0)   Quote PA20Pacer Quote  Post ReplyReply Direct Link To This Post Posted: 26 Nov 2015 at 8:51am
Hi Roy-

That makes sense; I had forgotten that the air data may not have been readily available without the Aspen ACU2. To address you particular issue, I think I would go ahead and connect the ARINC 429 output of the Aspen to the IFD540 and leave the serial output of the Aspen driving the AXP340. You could then disconnect the repeater serial output of the AXP340 from the IFD540. Of course, this does nothing to explain the issue that you identified.

I like the functionality of having the Aspen air data available to the IFD540. I also use the Aspen serial altitude output as the altitude source for the AXP340. The only disadvantage of this is that if I turn off the Aspen for partial panel practice, I lose my altitude encoder.

Regards,

Bob
Bob Siegfried, II
Brookeridge Airpark (LL22)
Downers Grove, IL
Back to Top
oskrypuch View Drop Down
Senior Member
Senior Member


Joined: 09 Nov 2012
Location: CYFD
Status: Offline
Points: 3057
Post Options Post Options   Thanks (0) Thanks(0)   Quote oskrypuch Quote  Post ReplyReply Direct Link To This Post Posted: 26 Nov 2015 at 10:13am
Originally posted by PA20Pacer PA20Pacer wrote:

... The only disadvantage of this is that if I turn off the Aspen for partial panel practice, I lose my altitude encoder.

Regards,

Bob

... or if you get the big red X's, or if the ASPEN otherwise goes TU's. I installed a Nano encoder, yes losing the 10ft accuracy, but keeping more independence.

ASPEN units seem too quick to give up the ghost with confusing inputs, and jump to the X's removing all information.

It would be nice if the 340 could be set to use a hierarchy of encoder inputs, then I'd be happy to connect the ASPEN as priority #1, with the Nano as backup.

* Orest

Back to Top
DavidBunin View Drop Down
Senior Member
Senior Member
Avatar

Joined: 20 May 2015
Location: Rockwall, TX
Status: Offline
Points: 742
Post Options Post Options   Thanks (0) Thanks(0)   Quote DavidBunin Quote  Post ReplyReply Direct Link To This Post Posted: 26 Nov 2015 at 12:38pm

Originally posted by cajungene 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

Back to Top
cajungene View Drop Down
Newbie
Newbie
Avatar

Joined: 16 Apr 2015
Location: Virginia
Status: Offline
Points: 17
Post Options Post Options   Thanks (1) Thanks(1)   Quote cajungene Quote  Post ReplyReply Direct Link To This Post Posted: 28 Nov 2015 at 7:34pm
Given that It costs me more than a $100 to fly to get the update that may or may not work, a TSO'd update that does work would be a bargain.

Gene
Back to Top
DavidBunin View Drop Down
Senior Member
Senior Member
Avatar

Joined: 20 May 2015
Location: Rockwall, TX
Status: Offline
Points: 742
Post Options Post Options   Thanks (0) Thanks(0)   Quote DavidBunin Quote  Post ReplyReply Direct Link To This Post Posted: 29 Nov 2015 at 7:40am

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

Back to Top
 Post Reply Post Reply
  Share Topic   

Forum Jump Forum Permissions View Drop Down

Forum Software by Web Wiz Forums® version 12.01
Copyright ©2001-2018 Web Wiz Ltd.

This page was generated in 0.098 seconds.