Mode C / pressure altitude bug with IFD540
Printed From: Avidyne
Category: Avidyne General
Forum Name: AXP340/322 ADS-B Transponder
Forum Description: Topics on the Avidyne AXP340/322 ADS-B Transponder
URL: http://forums.avidyne.com/forum_posts.asp?TID=855
Printed Date: 22 Nov 2024 at 5:22pm
Software Version: Web Wiz Forums 12.01 - http://www.webwizforums.com
Topic: Mode C / pressure altitude bug with IFD540
Posted By: Royski
Subject: Mode C / pressure altitude bug with IFD540
Date 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? |
Replies:
Posted By: compasst
Date 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. |
Posted By: cajungene
Date 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?
|
Posted By: Royski
Date 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. |
Posted By: DavidBunin
Date 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. |
Posted By: cajungene
Date 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. |
Posted By: DavidBunin
Date 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. |
Posted By: roltman
Date Posted: 25 Nov 2015 at 10:20am
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. |
DavidBunin wrote:Posted By: Royski
Date 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 http://forums.avidyne.com/forum_posts.asp?TID=673&KW=&PID=8149&title=axp340-pressure-altitude-display-question#8149" rel="nofollow - August 1 . |
Posted By: PA20Pacer
Date Posted: 25 Nov 2015 at 3:53pm
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 |
Posted By: cajungene
Date 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. 😩 |
Posted By: roltman
Date Posted: 25 Nov 2015 at 9:00pm
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. |
Posted By: brou0040
Date Posted: 25 Nov 2015 at 10:37pm
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...
|
Posted By: Royski
Date Posted: 26 Nov 2015 at 8:16am
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
|
Posted By: PA20Pacer
Date 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 |
Posted By: oskrypuch
Date Posted: 26 Nov 2015 at 10:13am
... 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 |
Posted By: DavidBunin
Date Posted: 26 Nov 2015 at 12:38pm
|
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. 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 |
Posted By: cajungene
Date 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 |
Posted By: DavidBunin
Date 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 |