|
Flight data transfer from IFD540 to Aspen |
Post Reply 
|
Page 12> |
| Author | |
Cruiser 
Senior Member 
Joined: 24 Feb 2017 Location: Ohio Status: Offline Points: 139 |
 Post Options
 Thanks(0)
 Quote Reply
 Topic: Flight data transfer from IFD540 to AspenPosted: 29 Jan 2019 at 7:07pm |
|
I have noticed that the flight path data is not being displayed on my Aspen PFD/MFD .
The flight plan route show correctly but the curved path course does not transfer from the IFD540 to the Aspen screen. I noticed that the HOLD depictions are also missing. The IFD540 shows the actual flight path for entry i.e. parallel, teardrop etc. on the screen but only the standard hold image is shown on the Aspen units. Anyone know why this data is not getting transferred? TomK
Edited by Cruiser - 29 Jan 2019 at 7:09pm |
|
 |
|
|
nrproces
Senior Member
Joined: 19 Sep 2016 Location: Marion, MT Status: Offline Points: 142 |
Post Options
Thanks(0)
Quote Reply
Posted: 30 Jan 2019 at 7:41am |
|
Is this a recent phenomenon, or did it just become noticed? Annual recently, or other equipment install since it started? Could be a stream or settings issue, but more information is required to troubleshoot.
Edited by nrproces - 30 Jan 2019 at 7:43am |
|
|
Sauce
|
|
|
|
|
Cruiser
Senior Member
Joined: 24 Feb 2017 Location: Ohio Status: Offline Points: 139 |
Post Options
Thanks(0)
Quote Reply
Posted: 30 Jan 2019 at 9:15am |
|
This condition was actually brought to my attention. I did not notice it so I can't say that it was a change or always this way.
The IFD 540 is wired to the Aspens via 429 data lines per the install instruction. I thought what was shown on the Avidyne would be shown on the Aspen.
|
|
|
|
|
nrproces
Senior Member
Joined: 19 Sep 2016 Location: Marion, MT Status: Offline Points: 142 |
Post Options
Thanks(0)
Quote Reply
Posted: 30 Jan 2019 at 12:38pm |
|
Well, I have a pro 1500 system that is driven by my 540, on the MFD, which is the second Aspen system that is what I get, a repeat of the 540 stuff, on the primary I do not get that information. What Aspen system do you have?
|
|
|
Sauce
|
|
|
|
|
Cruiser
Senior Member
Joined: 24 Feb 2017 Location: Ohio Status: Offline Points: 139 |
Post Options
Thanks(0)
Quote Reply
Posted: 30 Jan 2019 at 2:48pm |
|
here is an image
 |
|
|
|
|
nrproces
Senior Member
Joined: 19 Sep 2016 Location: Marion, MT Status: Offline Points: 142 |
Post Options
Thanks(0)
Quote Reply
Posted: 31 Jan 2019 at 8:35am |
|
Is auto course enabled? You are at the fix, what is the next fix on your 540? I can only see the Aspen, do you have this shot with the 540 in view?
|
|
|
Sauce
|
|
|
|
|
Cruiser
Senior Member
Joined: 24 Feb 2017 Location: Ohio Status: Offline Points: 139 |
Post Options
Thanks(0)
Quote Reply
Posted: 31 Jan 2019 at 1:40pm |
|
My IFD540 shows the HOLD racetrack with the parallel entry path and the message at the bottom of the screen Parallel entry.
 Edited by Cruiser - 02 Feb 2019 at 8:45am |
|
|
|
|
Tquigley
Newbie 
Joined: 01 Feb 2019 Location: Athens, GA Status: Offline Points: 10 |
Post Options
Thanks(0)
Quote Reply
Posted: 03 Feb 2019 at 12:02pm |
|
We’ve had the exact same issue. Approaching KAHN from the south, we specified the RNAV20 with procedure turn at UMMIL. 540 showed proper route, Aspen PFD showed the CDI properly but the MFD did not update magenta line to proper path. If you look at the top of the MFD it shows that we are on an active segment to KAHN heading 359 degrees and then to UMMIL. But 359 degrees is the heading to UMMIL and KAHN is more like 280 when this photo was taken. These photos were several minutes after activating the approach. Telling it to go direct UMMIL several times didn’t change anything. Eventually I added UMMIL manually as a waypoint and that fixed it. That was last weekend. Yesterday I specified the ILS 27 and things updated immediately. Very puzzling. Any ideas? Getting close to my month in and considering putting the 530 back in and returning the 540 if this keeps up.
  |
|
|
|
|
Cruiser
Senior Member
Joined: 24 Feb 2017 Location: Ohio Status: Offline Points: 139 |
Post Options
Thanks(0)
Quote Reply
Posted: 04 Feb 2019 at 9:55am |
|
looks like there was a gap in your flight plan. That might have something to do with it.
|
|
|
|
|
AviSteve
Admin Group 
Joined: 12 Feb 2018 Location: Melbourne, FL Status: Offline Points: 2304 |
Post Options
Thanks(1)
Quote Reply
Posted: 04 Feb 2019 at 11:46am |
The IFD map is drawn using every bit of information that the IFD has regarding the flight plan. The Aspen, however, is being driven by the ARINC 429 GAMA Graphics stream. The GAMA 429 stream doesn't have enough features or capacity to fully replicate what you'll see on the IFD. That's a function of the decades old spec, not the IFD. In the specific case you illustrated, the IFD will show a hold entry and the candy-stripe next leg, but the Aspen (or any other device using the GAMA Graphics) will only shown the basic hold.
|
|
|
Steve Lindsley
Avidyne Engineering |
|
|
|
|
AviSteve
Admin Group
Joined: 12 Feb 2018 Location: Melbourne, FL Status: Offline Points: 2304 |
Post Options
Thanks(0)
Quote Reply
Posted: 04 Feb 2019 at 11:53am |
I have noticed before that the Aspen is very slow to respond to changes in the ARINC-429 stream. I'm not sure exactly why that is. It actually appears to process some of the data quickly, but the active waypoint and the graphics are really slow. I did try your exact example using an Aspen PFD and it did ultimately update to UMMIL, but it was minutes before that happened. I was simultaneously running one of our Entegra MFDs and it responded to the same data stream almost immediately. It may have something to do with the preceding gap, as suggested. I'll try to run a few more informal tests here to see if I can do anything in the GAMA graphics stream to kick start the Aspen while not breaking any of the other devices that typically connect to that same stream.
|
|
|
Steve Lindsley
Avidyne Engineering |
|
|
|
|
Tquigley
Newbie
Joined: 01 Feb 2019 Location: Athens, GA Status: Offline Points: 10 |
Post Options
Thanks(0)
Quote Reply
Posted: 04 Feb 2019 at 12:19pm |
|
Thanks for the quick reply. Our experience is that sometimes it does update after several minutes, other times is simply doesn’t update. Still others it works normally. It was sometimes slow with the Garmin, but never more than 15-20 seconds. In the attached case, we let it go more than 10 mins with nothing. Most unsettling is that the Aspen did NOT behave this way with the Garmin 530w so we cant be blaming the Aspen. Either I screwed something up on the install or the 540 is doing something different and isn’t a perfect substitute for the Garmin.
I’m about to send an email with a few more examples (and some other bugs/questions) to your support email address. Happy to email them directly to you as well if you would like.
Edited by Tquigley - 04 Feb 2019 at 12:20pm |
|
|
|
|
AviSteve
Admin Group
Joined: 12 Feb 2018 Location: Melbourne, FL Status: Offline Points: 2304 |
Post Options
Thanks(0)
Quote Reply
Posted: 04 Feb 2019 at 4:50pm |
I'm not trying to shirk responsibility, but there is an aspect of the Aspen that could be in play here. I suspect they optimized their software for the Garmin stream and didn't necessarily strictly implement the GAMA 429 spec. So, anything in our stream that is not in the Garmin stream might not be handled so well. I believe that to be the case here since my best guess is that the cause of this behavior is the gap immediately preceding UMMIL. The 530 doesn't have the concept of gaps like the 540 does and gaps *are* represented in the GAMA stream. I did try a few quick software changes earlier today to see if I could kick-start the Aspen in this case, but to no avail. I'd have to break open a lot of stuff right now in order to do any more in depth testing and experimentation. I am curious, though, since there are plenty of users out there using Aspen. Is anyone else noticing this kind of behavior? If not, are other techniques being used for activating approaches that mask the behavior?
|
|
|
Steve Lindsley
Avidyne Engineering |
|
|
|
|
Bob H
Senior Member
Joined: 26 Jan 2018 Location: NH - KMHT Status: Offline Points: 290 |
Post Options
Thanks(0)
Quote Reply
Posted: 05 Feb 2019 at 12:50am |
|
Isn't it also fair to say that with the higher functionality of the IFD there is a lot more data being pumped out for the Aspen to process? Sort of like trying to run Windows 10 on an old PC. I wouldn't blame Windows 10 for the limitations of the hardware.
|
|
|
Bob
|
|
|
|
|
Tquigley
Newbie
Joined: 01 Feb 2019 Location: Athens, GA Status: Offline Points: 10 |
Post Options
Thanks(0)
Quote Reply
Posted: 05 Feb 2019 at 3:10am |
|
I’m not trying to pick a fight with anyone or cast blame. Given I see mainly happy reports of IFD540 users and just this (original post and mine) and a few other mentions of issues with aspen MFDs on this forum and no where else, my assumption is that I must have screwed something up. There must be hundreds of installs with 540s and and Aspen MFDs so,if this was an ongoing problem, I’d think you would have heard about it. But, if I didn’t scree something up, it’s kind of a problem that the aspen will draw a line to the wrong place with the 540 in a way that didn’t happen with the Garmin 530 which it replaced. If I was in IMC when that happened it wouldn’t have been fun.
Avidyne advertises this as a direct swap for the 530w. Maybe I’m being unreasonable here but that to me means it should just work with rather than break things that worked with the 530. I just went back and reviewed the self install checklist again and nowhere does it say I can’t do it if I also have other things the 530 was driving. I mean isn’t it a safety of flight issue to expect it to interface as the 530 did if it is meant to be a direct replacement? I also just found a compatibility list that does not include the Aspen MFD. If this is really a problem, and your testing seems to suggest it is, shouldn’t there be a limitation for self installs that one only has compatible equipment interfaces with the 530 and, thus, the 540? |
|
|
|
|
PA20Pacer
Senior Member
Joined: 07 Mar 2012 Location: Illinois (LL22) Status: Offline Points: 161 |
Post Options
Thanks(0)
Quote Reply
Posted: 05 Feb 2019 at 7:29am |
Hi Steve- I have observed the same behaviour with the Aspen. While it would be nice if the response was faster, it has not bothered me a great deal. This may be something on which you wish to work with Aspen, since many IFD540 users have opted for the Aspen PFD. Regards, Bob
|
|
|
Bob Siegfried, II
Brookeridge Airpark (LL22) Downers Grove, IL |
|
|
|
|
AviSteve
Admin Group
Joined: 12 Feb 2018 Location: Melbourne, FL Status: Offline Points: 2304 |
Post Options
Thanks(0)
Quote Reply
Posted: 05 Feb 2019 at 9:34am |
No offense taken, I truly am curious why we haven't heard about this before. We did plenty of testing with several pieces of equipment that consume the GAMA 429 stream, including Aspen, during development. We certainly noticed that the Aspen was slow to respond, but just never experienced a case that was as slow as this one. We'll be taking a look at this exact case to see what we can do to improve the performance.
|
|
|
Steve Lindsley
Avidyne Engineering |
|
|
|
|
Tquigley
Newbie
Joined: 01 Feb 2019 Location: Athens, GA Status: Offline Points: 10 |
Post Options
Thanks(0)
Quote Reply
Posted: 26 Feb 2019 at 10:44am |
|
For anyone following this thread, I think I’ve narrowed the long delay issue down to an issue with procedures that have course reversals. See below for a lengthy email I sent to tech reps for both Avidyne and Aspen with links to videos showing how we came to this conclusion. Of note is that it’s not just the MFD. While the CDI on the PFD works, the next waypoint and heading into on the PFD are also not updated.
Aspen has suggested switching the connection speeds to high speed. I tried that but it didn’t work at all (as in nothing worked) and besides it seems like a bad idea to just change settings in ways that are counter to the install manual. Aspen also seems to think paying them a few grand to upgrade to their new Max line will help. Sure. Why not. I’ve received no response from Avidyne.
——————- Dear , I’ve traded emails with both of you regarding an updating problem I’ve seen on my Aspen MFD since replacing my Garmin 530w with an Avidyne IFD540. I tried a few other scenarios this weekend that seems to isolate course reversals as the culprit. I’ve copied Mike with Gwinnett Aero and Jeff, my co-owner, on this email. You may recall we first saw this issue flying the RNAV 21 approach into KAHN via the UMMIL fix from the south. This procedure requires a course reversal from this direction. As shown in this video, you will see when going from “Direct KAHN” to selecting the approach, the IFD540 updates, the Aspen PFD 1000 updates with the proper heading and CDI guidance, but the MFD picture does not update. After a while we change the approach to use one of the feeder legs into the RNAV approach (specifically the same RNAV 20 but this time via THUDS, which does not require a course reversal). The Aspen updates the picture for this almost immediately. https://share.icloud.com/photos/003BiQGEWZLhnC6OXEYsacY-A To make sure this issue wasn’t approach specific, we then selected the RNAV 27 via IMAVE (we were west of this fix thus requiring a course reversal). Again, the IFD updates right away but not the Aspen MFD. We select the exact same approach a little bit later but this time we are slightly east of (outside of) IMAVE making the course reversal optional. The Aspen MFD updates immediately showing the picture of the course reversal. https://share.icloud.com/photos/0pJJ017nbltsUxCUcaF6Nd_vg In the next video we again specify RNAV 27 via IMAVE and we are west of (on the airport side) of the fix. This time it creates the image right away but doesn’t provide a magjeffenta line from the current position to IMAVE (though if you look close, the MFD does show the proper next waypoint on the top as IMAVE, which is not the case when the picture doesn’t update like in the prior videos). https://share.icloud.com/photos/0VOaXsUcvgObVvK7HHS9b2jpQ In the next video we select RNAV 27 via IMAVE again (we are inside the fix). The MFD does not update. However, if we delete the “gap” that shows up in the flight plan, the MFD updates the picture but seems to highlight the inbound leg to the airport rather than the course from our current location. https://share.icloud.com/photos/01i4MJxp-IhtTvb6La-v9T1CA In this next video, we are outside of IMAVE when we select the RNAV 27 approach via IMAVE. While the MFD updates the heading (at the top) to show IMAVE, the picture on the screen stays direct KAHN. We then remove the course reversal at IMAVE and the picture updates to what we’d expect to see. https://share.icloud.com/photos/097bYZP_HJ5TmBVxQiSgg-KxQ We then tried the RNAV 9 approach at KAHN via SALIN (which, from the east, requires a course reversal). Again, the MFD does not update. Deleting the course reversal allows the picture on the MFD to update. Next we try activating the same approach via one of the feeder legs (JODAS) and things update as we’d expect. At the very end of the video, we select the approach via SALIN again (around 3:30). At 4:54, the picture updates to show what we selected without any input by us – so it took 1:24 to draw the right picture). https://share.icloud.com/photos/05s7_TN-o55vO2zK0JCS3WUow In the final video, we go back to the RNAV 20 via UMMIL. In this case we are north of the fix thus the course reversal/hold is not required. The image does not draw on the MFD. We then delete the hold and the picture updates immediately. https://share.icloud.com/photos/0oIew7urYlmLOEIkO7-E-2Tzw Collectively, these examples seem to show that the problem is with approaches that have a course reversal aspect to them. Perhaps this can help uncover the underlying issue and maybe find a solution? If you would like me to try anything else, let me know. Tim Quigley N9024P |
|
|
|
|
PA30 TC
Newbie
Joined: 06 Jun 2012 Status: Offline Points: 4 |
Post Options
Thanks(0)
Quote Reply
Posted: 19 Mar 2019 at 8:22am |
|
I have a similar issue with my single Aspen Pro 1000 that originates on the ground after power up with the flight plan loaded in the Avidyne IFD540(software V10.2.0) in that the Aspen lower CDI is very slow to populate the flight plan data. Yesterday, from power up until the flight plan displayed took 9.5 minutes. Seems to operate normally after 429 data is displayed on the CDI.
The following is my query to Aspen Tech Support and their reply: Over the last 6 mos or so I have noticed that
my Aspen Pro 1000 p/n 910-00001-001, with software V2.7.2 has been very slow to populate the lower HSI with
the flight plan data generated by my Avidyne IFD540 GPS. It takes 8-10 minutes after power up to
finally accept the inputs and display the routing. Nothing has changed since the original
install in April 2015 and has operated normally as soon as the GPS is fully operational. Is there currently any known issues on this
anomaly/problem and or software upgrades that may alleviate this condition? Response: This has something to do with how the IFD transmits there
data via ARINC 429. The speed at which they are sending packets is faster than
Garmin, Bendix/King, etc. and this is causing the delay in our processor
computing the information when it is initially sent to us. It's possible that
when our new Max is available, this will not be an issue since the Max has a
much faster processor. We have not changed anything with our displays on how we
receive information and there is no issue with this with all other GNAV's on
the market. What is curious is there have been no changes to the hardware or software or settings in over 2 years and was not an issue before. I certainly will not be upgrading to the MAX unit in the future. Any suggestion greatly appreciated! CW |
|
|
CW
|
|
|
|
|
SocialFlight
Newbie
Joined: 02 Oct 2015 Location: Marlborough, MA Status: Offline Points: 6 |
Post Options
Thanks(0)
Quote Reply
Posted: 22 Mar 2019 at 12:47pm |
|
I'm having this issue and it's a significant frustration while flying approaches. I can live with the update delay of the flight path display to the Aspen Pro (although it's painful). To be clear - everything is displaying fine on the Avidyne. However, it's a real problem to be hand-flying a hold on an approach that is displayed on the Avidyne and not displayed on the Aspen in front of me.
This issue seems intermittent, but frequent enough to be a real problem. Is there any operator workaround to get it to display? I hate the idea of reloading an approach while flying it (and that doesn't work consistently). Suggestions?
Edited by SocialFlight - 22 Mar 2019 at 12:49pm |
|
|
- Jeff Simon
www.SocialFlight.com Get the FREE app with over 20,000 aviation events! |
|
|
|
|
Cruiser
Senior Member
Joined: 24 Feb 2017 Location: Ohio Status: Offline Points: 139 |
Post Options
Thanks(0)
Quote Reply
Posted: 22 Mar 2019 at 8:46pm |
|
Practice..................
Not to trivialize the issue but none of us should be dependent on these at a safety of flight level.
|
|
|
|
|
Tquigley
Newbie
Joined: 01 Feb 2019 Location: Athens, GA Status: Offline Points: 10 |
Post Options
Thanks(0)
Quote Reply
Posted: 22 Mar 2019 at 10:09pm |
|
on some level I agree. On the other hand, the whole point of spending the dollars on this equipment is to make things safer. If they are going to be certificated and priced as replacements for primary instruments, they should freaking work as expected.
|
|
|
|
|
SocialFlight
Newbie
Joined: 02 Oct 2015 Location: Marlborough, MA Status: Offline Points: 6 |
Post Options
Thanks(0)
Quote Reply
Posted: 22 Mar 2019 at 10:48pm |
|
I'd prefer to focus on finding a solution, or at least an interim workaround.
With all due respect, properly functioning navigation avionics during IFR flight are most definitely a safety of flight issue. Saying "Practice" isn't not a constructive contribution to the group on this topic searching for a solution so a very real and specific problem. Back on a constructive note: Has anyone identified if the issue is related to having a discontinuity in the flight plan?
|
|
|
- Jeff Simon
www.SocialFlight.com Get the FREE app with over 20,000 aviation events! |
|
|
|
|
Cruiser
Senior Member
Joined: 24 Feb 2017 Location: Ohio Status: Offline Points: 139 |
Post Options
Thanks(0)
Quote Reply
Posted: 23 Mar 2019 at 9:40am |
|
my suggestion to "Practice" was intended to be constructive.
As I said, not to trivialize this issue. We are too dependent on our equipment and need to practice flying the airplane more. It is the SAFE thing to do. Now, I have seen delays of a few seconds with my Aspen/IFD540 combo but not minutes. Aspen says it might be improved with the new computer chips in the MAX upgrade. I will let you know when my upgrade is completed.
|
|
|
|
|
SocialFlight
Newbie
Joined: 02 Oct 2015 Location: Marlborough, MA Status: Offline Points: 6 |
Post Options
Thanks(0)
Quote Reply
Posted: 23 Mar 2019 at 11:52am |
|
We may have separate symptoms here. I would be more comfortable if my issue were related to a delay drawing the course and hold on the Aspen. In my case, many approaches fail to draw at all on the Aspen.
|
|
|
- Jeff Simon
www.SocialFlight.com Get the FREE app with over 20,000 aviation events! |
|
|
|
|
AviSteve
Admin Group
Joined: 12 Feb 2018 Location: Melbourne, FL Status: Offline Points: 2304 |
Post Options
Thanks(0)
Quote Reply
Posted: 25 Mar 2019 at 12:07pm |
|
I'm trying to characterize this problem a little better. We have an EFD1000 Aspen in our lab that exhibits really slow behavior and another that doesn't. The bad one has Map version 2.3.1 and IP version 2.0.2. The good one has Map version 2.6.2 and IOP version 2.0.5.
Can you guys post the model/versions of your Aspens? I suspect that those of you having problems will be the most motivated to do so, but it would be interesting also to hear from those of you that aren't experiencing the problem as well.
|
|
|
Steve Lindsley
Avidyne Engineering |
|
|
|
|
SocialFlight
Newbie
Joined: 02 Oct 2015 Location: Marlborough, MA Status: Offline Points: 6 |
Post Options
Thanks(0)
Quote Reply
Posted: 25 Mar 2019 at 9:27pm |
|
I was experiencing the issue with Aspen software version: MAP:V2.9 IOP:V2.1.
I upgraded the Aspen today to MAP:V2.9.0.1 IOP:V2.1.1. A test flight with the unit after upgrade did not duplicate the issue (but it was slow to update FP display). It was not an exhaustive test flight, so I will send an update after more testing.
|
|
|
- Jeff Simon
www.SocialFlight.com Get the FREE app with over 20,000 aviation events! |
|
|
|
|
PA20Pacer
Senior Member
Joined: 07 Mar 2012 Location: Illinois (LL22) Status: Offline Points: 161 |
Post Options
Thanks(0)
Quote Reply
Posted: 26 Mar 2019 at 8:35am |
|
Hi Steve-
I experience the slow Aspen update phenomenon with MAP v2.8 and IOP vB2.0.5. Regards, Bob
|
|
|
Bob Siegfried, II
Brookeridge Airpark (LL22) Downers Grove, IL |
|
|
|
|
PA30 TC
Newbie
Joined: 06 Jun 2012 Status: Offline Points: 4 |
Post Options
Thanks(0)
Quote Reply
Posted: 08 Apr 2019 at 8:16am |
|
Hi Steve,
My Aspen Pro EFD 1000 is using Map Version 2.7.2 and IOP 2.0.5. Before departure for Sun N Fun on Thursday, it took about 12 minutes for the flight plan data populate to the Aspen. Before the data populated there was a GPS1(single GPS unit installed) yellow caution flag displayed with a red line through the caution flag. After the 12 minute period and just before the display populated, the Aspen showed the following: flashed about 3 times: RSM GPS Reversion, Emergency Use Only and then the Aspen displayed the flight plan data from the 540 with no problems for the remainder of the trip. The Aspen pilot guide states that this caution is presented when a configured GPS source's data is invalid or unavailable. I spoke with an Avidyne Tech Support Rep at the show and he ask that I forward my data logs. He was unaware of this issue. The Aspen Tech Rep was also unaware of this issue and had no explanation after I explained the entire sequence of events. On return from Sun N Fun on Sunday, the Aspen displayed the flight plan data after only about 1 minute, much quicker than I have experienced lately. Hope this info helps narrow down the possible causes. CW
|
|
|
CW
|
|
|
|
|
Cruiser
Senior Member
Joined: 24 Feb 2017 Location: Ohio Status: Offline Points: 139 |
Post Options
Thanks(0)
Quote Reply
Posted: 08 Apr 2019 at 2:42pm |
|
IF the Aspen does not have the GPS nav source the FltPlan will not transfer. (no nav info to identify a route)
Did the IFD 540 show any issues? I,e. failure to lock in GPS position, etc.? Edited by Cruiser - 08 Apr 2019 at 2:43pm |
|
|
|
|
PA30 TC
Newbie
Joined: 06 Jun 2012 Status: Offline Points: 4 |
Post Options
Thanks(0)
Quote Reply
Posted: 09 Apr 2019 at 9:27am |
|
The 540 was completely lock on with great GPS signal reception. The flight plan was installed, activated and fully operational on the 540. There were no other indications of a system failure or warning flags on the Avidyne unit. My next plan is to download the data logs from the 540 and foward to Avidyne Tech support.
CW
|
|
|
CW
|
|
|
|
|
Tquigley
Newbie
Joined: 01 Feb 2019 Location: Athens, GA Status: Offline Points: 10 |
Post Options
Thanks(0)
Quote Reply
Posted: 06 Sep 2019 at 11:17pm |
|
I’ve been away from this thread for months as my plane went down for an unexpected engine overhaul in March. Finally back in the air with new engine and we also had the Max upgrade done to our Aspen PFD and MFD 500. Unfortunately the delay issue is still present. Anyone make any headway on this?
|
|
|
|
|
AviSteve
Admin Group
Joined: 12 Feb 2018 Location: Melbourne, FL Status: Offline Points: 2304 |
Post Options
Thanks(0)
Quote Reply
Posted: 09 Sep 2019 at 3:19pm |
|
Sorry, no. Last time I tried it, I was unable to recreate the problem. If you have a sure fire way to induce it, please send me the recipe. A video would be helpful too, if possible.
|
|
|
Steve Lindsley
Avidyne Engineering |
|
|
|
|
Tquigley
Newbie
Joined: 01 Feb 2019 Location: Athens, GA Status: Offline Points: 10 |
Post Options
Thanks(0)
Quote Reply
Posted: 09 Sep 2019 at 11:44pm |
|
see my original post above from Feb 3. Your post from Feb 4 indicates you were able to recreate that scenario.
Here’s a more recent video of the same approach. I only let it go about 90 seconds before selecting the same approach again. After I did that, it worked after about 30 seconds. I believe the issue is related to approaches with procedure turns. I came across this thread from a few years ago and made the changes suggested in the final post (changing 429 out from 540 to high and corresponding inputs on Aspen to high as well) I couldn’t fly today but tried it out on the ground. It was super speedy (5-8 seconds). To compare, I set everything back to slow and tried again. It always updated within 15 seconds but was always slower than what I saw using high speed. I’d say it was typically 5-7 seconds on high speed and more like 8-15 on slow speed. Who knows what will happen in the air but I am hopeful that will solve it. I’ll let you know.
|
|
|
|
|
AviSteve
Admin Group
Joined: 12 Feb 2018 Location: Melbourne, FL Status: Offline Points: 2304 |
Post Options
Thanks(0)
Quote Reply
Posted: 10 Sep 2019 at 8:51am |
|
I know, that's what's so annoying. I remember being able to recreate it, but then when I was trying to demonstrate it for Aspen, I couldn't get it to occur.
|
|
|
Steve Lindsley
Avidyne Engineering |
|
|
|
|
comancheguy
Senior Member
Joined: 24 Aug 2011 Location: Maryland Status: Offline Points: 160 |
Post Options
Thanks(0)
Quote Reply
Posted: 10 Sep 2019 at 5:15pm |
|
I hate it when things don't stay broken! :)
I *may* have worked on software (and hardware) a bit too long... Ken
|
|
|
|
|
Tquigley
Newbie
Joined: 01 Feb 2019 Location: Athens, GA Status: Offline Points: 10 |
Post Options
Thanks(0)
Quote Reply
Posted: 11 Sep 2019 at 9:25pm |
|
I flew today with the fix from the other thread (switching some stuff to high speed) and the issue remained. On the ground things were fine. We just flew to the north out of Athens and rotated between RNAV20, RNAV27, and ILS27 and then back to Rnav20. Maybe by the 4th or 5th change, the Aspen stopped updating. For the rest of the flight it was generally slow to update if at all. Sometimes if I cleared the entire flight plan and selected an approach from scratch, it would update OK, other times not.
Now here’s the new problem. With the speed set to high per that other thread, the VLOC1 was not available on the Aspen. So we had to set it back to slow speed.
|
|
|
|
|
AviSteve
Admin Group
Joined: 12 Feb 2018 Location: Melbourne, FL Status: Offline Points: 2304 |
Post Options
Thanks(0)
Quote Reply
Posted: 12 Sep 2019 at 2:19pm |
|
OK, I'll have to go give it another try. It may take me a little while to get back to it, but I will.
|
|
|
Steve Lindsley
Avidyne Engineering |
|
|
|
|
Kentucky Captain
Senior Member
Joined: 21 Mar 2015 Location: KBRY Status: Offline Points: 234 |
Post Options
Thanks(0)
Quote Reply
Posted: 20 Oct 2019 at 3:57am |
I haven't seen any of these problems with my IFD/Aspen combo which measn either I haven't noticed it our it's not happening. Reading about these issues scare the crap out of me since my bird gets a makeover soon with the Max upgrade, a new autopilot, new ADS-B solution, and some JPI upgrades. Hope I don't see any of these issues with the upcoming changes.
|
|
|
Woo Hoo!!!
|
|
|
|
|
Cruiser
Senior Member
Joined: 24 Feb 2017 Location: Ohio Status: Offline Points: 139 |
Post Options
Thanks(0)
Quote Reply
Posted: 10 Dec 2019 at 3:34pm |
|
adding to this thread, I have the 3 panel Aspen Max connected to the Avidyne IFD 540/440 combo.
Using the IFD540 to select approaches for my IFR currency on Sunday I found that when selecting a different approach after the first one updated the Map screen on the Avidyne but it did not transfer the navdata to the Aspen PFD. Specifically it still had the IAF for the first approach loaded in the Aspen when the new approach data was displayed in the IFD 540. I flew from the airport to the new IAF of the second approach, about 10 nm and the Aspen PFD never updated to the new navdata. I then selected the approach again and reloaded it in the IFD, no change. I then selected Direct to the airport and the waypoint immediately changed. on the IFD and Aspen PFD both. I then selected the approach again and it load both units properly. This occurred each time I switched for one approach to the next for the rest of the flight. I called Aspen. Aspen said it must be a timing problem with sending data by the Avidyne unit. The Aspen acts as a dumb receiver and only displays the data that is sent to it. They suggested a talk with Avidyne. They also stated that they have heard this complaint before from other Avidyne owners and were very confident that the Aspen PFD was working properly. They also stated that they have never received a complaint about this from Garmin owners and they have many more units connected to Garmin GPS than to Avidyne. Any thoughts. ?
|
|
|
|
|
Tquigley
Newbie
Joined: 01 Feb 2019 Location: Athens, GA Status: Offline Points: 10 |
Post Options
Thanks(0)
Quote Reply
Posted: 11 Dec 2019 at 10:26am |
|
my thoughts are that I’m tired of the two companies pointing at each other. My gut says it’s an avidyne problem because it didn’t happen with my garmin 530 but did when I did the direct swap to the Ifd 540. I’ve heard from Aspen the exact thing you heard. avidyne tells me that my Aspen is a “legacy product” and maybe can’t keep up with all the data being sent from Avidyne. Yet, just like you, the problem persists even after the Aspen Max upgrade.
Regardless, It’s a flight safety issue and the two companies should get together and figure it out. |
|
|
|
|
ddgates
Senior Member
Joined: 12 Aug 2011 Location: Deer Valley Status: Offline Points: 1100 |
Post Options
Thanks(0)
Quote Reply
Posted: 11 Dec 2019 at 1:10pm |
Agree strongly! There are multiple issues which could be solved by some intracompany communication and cooperation. |
|
|
David Gates
|
|
|
|
|
Tquigley
Newbie
Joined: 01 Feb 2019 Location: Athens, GA Status: Offline Points: 10 |
Post Options
Thanks(0)
Quote Reply
Posted: 11 Dec 2019 at 3:39pm |
|
and I’ll add one more thing...I’m less concerned about my own safety than I am for the person who doesn’t know this problem exists and experiences it for the first time on a missed approach or deviation to an unfamiliar airport or something like that. Encountering this for the first time while trying to select a new approach under stress and possibly already diminished situational awareness is a major risk. Further, I thought avoiding these sorts of bugs was the exact reason why we pay so much for “certified” equipment.
|
|
|
|
|
skitheo
Senior Member
Joined: 02 Jan 2016 Location: KFNL Status: Offline Points: 165 |
Post Options
Thanks(0)
Quote Reply
Posted: 17 Dec 2019 at 4:28pm |
As an EE with 32 years of embedded software experience, I beg to differ with the underlined statement above. Is the 429 link a Garmin standard or an ARINC standard? Did Garmin fully adhere to the standard? Did Aspen implement optimal execution for all of the standard, not just Garmin's implementation? Does Aspen have a 429 source simulator to test all of the possible permutations of the standard when it's feeding their Dev/Test units? Making it work with the Garmin units is only half the job. Years ago, I implemented a USB Virtual Serial (CDC) endpoint for an instrument. It complied with the USB CDC standard. However, Microsoft's implementation of USB CDC was poor at the time and it didn't work correctly with Windows. Linux did adhere to the standard and the communication worked just fine. Was my device implementation at fault or was the problem with Windows? Interestingly enough, with Win10 (somewhat with Win7) the problems went away. Full disclosure: I just had my 6-pack removed and an Aspen EFD 2000 MAX installed and have been flying the IFD-540 for 3.5 years. I'll be examining my installation for this behavior, now that I am aware of it.
Edited by skitheo - 17 Dec 2019 at 4:36pm |
|
|
|
|
Stevemurray29
Newbie
Joined: 02 May 2020 Location: Ksdc Status: Offline Points: 1 |
Post Options
Thanks(0)
Quote Reply
Posted: 03 May 2020 at 7:59am |
|
i was led here via search, I have similar issue with Aspen Evolution 2000 and GNS-650.
This started when I noted I get all enroute and approach information transferred to the Aspen but not hold or missed. On Beechtalk I was told Aspen needs ARNIC 429 GAMA Format 3. I looked and I was configured to Format 1. I changed to Format 3 and the hold and miss now show up but only what I think is called the icon. They are not drawn to scale, you can’t “fly it”, they are not as they are on the GPS. I also have a GNC-530W. When it is selected as the nav source the miss and hold show up just fine. So I am beginning to suspect it’s a combination in something Garmin changed in the data stream and the Aspen which no longer can interpret that change correctly. You all are convincing me of this sore subject. I have no idea if this is fixed with MAX, I might bring it up with Aspen. Being one of those that also recently installed STEC-3100 only to put in Sandia airdata in due to Aspen foibles this does not surprise me. If this is case, only an upgrade to Max will fix it. Like my Aspen but all this high tech gear can be frustration when it’s mixed. As one of you said it could have been wrong in the 430/530W and Aspen just designed to that stream, hard to blame Aspen if that was the case, I’ll give them the benefit of the doubt. Hard to blame Avidyne, yes you got a slide in replacement but also a unit for the future. Did they insure the stream complied to standards, work just like new Garmins so you have other display options, kind of a pickle of decisions to make in the design.
Edited by Stevemurray29 - 03 May 2020 at 8:11am |
|
|
|
|
plizotte
Newbie
Joined: 07 Dec 2021 Location: 32137 Status: Offline Points: 2 |
Post Options
Thanks(0)
Quote Reply
Posted: 07 Dec 2021 at 11:45am |
|
Ressurecting this thread.
I have IFD550 & 440 connected to Aspen 2000 MAX I experience the same problems as mentioned above and have spoken with both Avidyne and Aspen to no avail. Has anyone had any success finding a solution to the (intermittant and inconsistent) delay in transferring the NAV DATA from the IFDs to the Aspens. Thanks Phil |
|
|
|
|
nrproces
Senior Member
Joined: 19 Sep 2016 Location: Marion, MT Status: Offline Points: 142 |
Post Options
Thanks(0)
Quote Reply
Posted: 07 Dec 2021 at 1:44pm |
|
Well, last summer I upgraded my Pro1500 system to the MAX version. I still get the same results, but the time it takes has decreased significantly, so I am inclined to say that Steve was correct about computer update cycles and the depiction...JMO though
Edited by nrproces - 07 Dec 2021 at 1:44pm |
|
|
Sauce
|
|
|
|
|
skitheo
Senior Member
Joined: 02 Jan 2016 Location: KFNL Status: Offline Points: 165 |
Post Options
Thanks(0)
Quote Reply
Posted: 07 Dec 2021 at 3:11pm |
|
Remember that the ARINC 429 Graphics labels are being transferred over a serial line which must transfer real-time flight data at high frequency intervals. Ergo, one would expect up to 60 seconds to transfer that information. Given that, I have never noticed that the flight path drawing on the MFD has taken more than a minute on my IFD540 / EFD2000MAX combo. FWIW... EDIT: > 200hrs over the last 2 years using that combo.
Edited by skitheo - 07 Dec 2021 at 3:12pm |
|
|
|
|
plizotte
Newbie
Joined: 07 Dec 2021 Location: 32137 Status: Offline Points: 2 |
Post Options
Thanks(0)
Quote Reply
Posted: 07 Dec 2021 at 3:57pm |
|
I have teh MAX upgrades and have switched the settings to HI Speed on IFDs and Aspens per both mfgrs.
Still doesn't help. However, the initial approach of the day usually (85%?) transfers within a minute. It's after a missed, going to the Alt and activating an approach that I see anywhere from 1.5min to 9min before the approach is displayes on the HSI and MFD along with the next waypoint, distance to and ETE.
|
|
|
|
|
skitheo
Senior Member
Joined: 02 Jan 2016 Location: KFNL Status: Offline Points: 165 |
Post Options
Thanks(0)
Quote Reply
Posted: 08 Dec 2021 at 4:12pm |
|
Gary Reeves recommends that you load up your entire flight plan including expected approach (you did look at the TAF for you destination, right?) and alternate approach prior to takeoff. That reduces the likelihood of the situation you describe. I haven't done the calculations for the entire timing, but considering the graphics are the lowest priority labels transferred and there will be many for an entire flight plan that is expanded with quite a few new waypoints, I can see it taking a long time. 9 minutes does seem a bit long.
|
|
|
|
|
Post Reply
|
Page 12> |
Tweet
|
| Forum Jump | Forum Permissions You cannot post new topics in this forum You cannot reply to topics in this forum You cannot delete your posts in this forum You cannot edit your posts in this forum You cannot create polls in this forum You cannot vote in polls in this forum |
Topic Options
Cruiser wrote: