Issue with Direct To distance count down
Printed From: Avidyne
Category: Avidyne General
Forum Name: IFD 5 Series & IFD 4 Series Touch Screen GPS/NAV/COM
Forum Description: Topics on Avidyne's IFD 5 Series and IFD 4 Series Touch Screen GPS/NAV/COM
URL: http://forums.avidyne.com/forum_posts.asp?TID=515
Printed Date: 28 Apr 2024 at 2:46am
Software Version: Web Wiz Forums 12.01 - http://www.webwizforums.com
Topic: Issue with Direct To distance count down
Posted By: pburger
Subject: Issue with Direct To distance count down
Date Posted: 22 Dec 2014 at 12:04am
|
I had just departed my home airport (TS07) for a lunch run to 11R which is out to the west. A buddy called me up on the radio and asked if I could go to 1500' and 10 miles and call him from that spot so that he could adjust the sensitivity of our pilot-controlled-lighting. No problem. At that time I was on a Direct-to flight plan to 11R. I decided to do a 'direct to' TS07, so that I could see the distance in the upper right data block. (Yes, I'm sure there are many better ways to do this...) I hit the Direct key, typed in TS07, hit enter then enter again to activate the direct route. Keep in mind that TS07 is behind me. The "Dist" field showed 7.7nm. I reported 7.7, and told my buddy I'd let him know when I was at 10nm. I looked again, and the Dist field now showed 7.4nm. What the hell?? I was immediately discombobulated. I thought I was traveling west, away from the field, but the GPS distance was DECREASING!! Lucky for me it was VFR, and I knew the area very well. I looked down at the iPad, and it said 10 nm, so I circled there while my buddy made his adjustments. I then proceeded WESTBOUND away from TS07, and watched as the Dist to TS07 continue to DECREASE. I took a picture of the screen with the iPAD next to it. The iPad shows 14nm, while the IFD 540 shows 6.5nm!!! (The iPad was correct) I then did a Direct-to route to 11R, and continued on my way with nothing abnormal after that.  I tried duplicating this on the simulator but could not. The simulator worked just fine. However, I noticed that the Dist that is displayed in the TO Waypoint datablock is not the direct-line distance, but rather the distance to be flown. For example, when I did the Direct-to to TS07, it plotted the U-turn on the screen, and the Dist field actually included the distance to fly the turn, rather than the point-to-point distance. That was not expected, but perhaps that is mentioned in the manual? Anyway, no matter how you slice it, the distance to a waypoint cannot be less than the direct line distance, so I'm baffled as to what happened during the flight today. What's going on Steve?? |
Replies:
Posted By: AviJake
Date Posted: 22 Dec 2014 at 10:53am
|
We can't duplicate any of this on hardware after spending all morning trying. We tried with TS07 as the origin and when not an origin. We tried every combination we could think of and did not see the problem. In every case, the distance counted down when it should and counted up when it should. What did your IFD540 map do during this event? ------------- Steve Jacobson sjacobson@avidyne.com |
Posted By: pburger
Date Posted: 22 Dec 2014 at 2:08pm
|
Steve, If you look at the picture, you can see that my position is about 2nm outside of the Class B ring both on the iPad and the IFD-540 screen. So, the 540 knows where I am, but that data field showing the "Dist" to TS07 is INCORRECT. As I stated, based on my experience with the simulator, I am assuming that the 'Dist' field is the "distance to be flown" to the TO waypoint, not the point-to-point distance. (I guess it is supposed to be the distance along the magenta line -- I don't like that, but so be it). I'm going to assume that something went awry in that calculation. I will set up a Go-Pro in the cockpit with audio, re-fly the same scenario and see if I can get it to screw up again. I won't have time to do this until the weekend. But, the pictures don't lie. Strange things are afoot at the Circle-K...
|
Posted By: AviJake
Date Posted: 22 Dec 2014 at 2:32pm
|
Okay, we'll wait for the video to try and explain this. We've definitely never seen anything like it. Has anybody else had this kind of issue? ------------- Steve Jacobson sjacobson@avidyne.com |
Posted By: pburger
Date Posted: 22 Dec 2014 at 2:38pm
|
One theory -- Looking at my 540 display, I don't see the magenta line. I do see the magenta triangle showing the direction to the waypoint (TS07 in this case), but no magenta line. I think the 540 plotted the course reversal and path to TS07 and painted the magenta line, but I kept flying away from TS07 such that the magenta line went offscreen. Here's my theory of what happened (pure guesswork here): I did the "direct to" TS07, and activated it. The 540 plotted a button-hook turn back to TS07 and calculated the distance from my position, along that curved magenta line, to TS07 and displayed that in the 'Dist' field. Then, as I continued outbound, perhaps it was just subtracting the distance I was flying (in any direction) from the "distance to be flown" that was calculated when I activated the "direct to"? If so, that would mean that the 'Dist' field shown in the TO Waypoint datablock is now virtually meaningless. That's a guess. I can re-fly this to test my theory. Now I'm very curious. I'll try to fly this tonight, weather permitting. I might not have the go-pro set up, but I'll see if I can duplicate the problem. EDIT - I can't test this on the simulator, because the simulator follows the magenta line.
|
Posted By: pburger
Date Posted: 22 Dec 2014 at 10:29pm
|
Repeated the problem. Uploading the video to YouTube now. Will post link when it's done. |
Posted By: pburger
Date Posted: 23 Dec 2014 at 12:34am
|
Okay, here's the video: Note that when I put the iPad in front of the camera, the distance was out of the frame (sorry). But at 4:51, right after I removed the iPad, you can see that the 'Nearest' datablock in the lower right still has TS07 as the nearest airport, and it shows 6.3nm to TS07 - while at the same time the 'TO Waypoint' datablock was showing 4.9nm to TS07. Both on the same screen on the IFD-540! I really think it has to do with the 'TO waypoint' calculating the course distance, and not the direct-line distance. I'm going to amend my theory a bit: I now believe that when it first plots the magenta line with the course reversal turn it calculates the distance to fly along that route, including the turn. Then as I am flying out beyond that, it probably is figuring some kind of point where I would intercept the magenta line, and the distance shown in the Datablock is from that intercept point to the waypoint. This seems more likely. I still think this is very confusing, and I don't think this is explained in the pilot guide. At least I couldn't find it. Maybe this is normal for a FMS, but I don't like it at all. |
Posted By: tony
Date Posted: 23 Dec 2014 at 12:54am
| The video doesn't play, it says "playback on other websites has been disabled by the video owner". Since there is no link, I can't go to youtube to see it. |
Posted By: jhbehrens
Date Posted: 23 Dec 2014 at 2:21am
| https://www.youtube.com/watch?v=ayCOKFZcuQk&feature=player_embedded |
Posted By: pburger
Date Posted: 23 Dec 2014 at 7:18am
|
I modified the video to "allow embedding". (I'm not a YouTube guru, so I hope this helps) The more I study this issue, the more I am convinced it is a bug. The pilot guide clearly states on page 4-21 that the "To Waypoint Information" datablock should show "...distance to current waypoint from present position". Well, it ain't doing that. I think the "To Waypoint Information" datablock is calculating it's distance in a similar way as the "Next Waypoint Information" datablock:
I think the "TO Waypoint Information" datablock should show the distance to current waypoint from present position like it says in the pilot guide -- similar to the "Nearest Airport" datablock, which shows "distance to airport from ownship". |
Posted By: tony
Date Posted: 23 Dec 2014 at 8:28am
|
That's great data, I assume its repeatable since you had the camera all set up to capture it. To me it looks like nav was working fine. You had altitude, heading, and ground speed; but guidance pewked. If you notice in your video, when TS07 was the nearest airport and you continued to fly away, the distance was correctly updated until another airport became closer to your position. So when guidance pewked the 540 stopped figuring out where to go. I wonder what would of happened if you selected a direct to, to a different destination, let the IFD figure out new guidance, and then did another direct to TS07. I'll bet you that would have probably worked. I'm guessing that the guidance CSCI didn't like that you selected a direct to from the origin. This is normal stuff for a new FMS. We are fortunate to have a forum like this to get the data back to the design team, and management willing to fix it. This is going to be an awesome product.
|
Posted By: AviJake
Date Posted: 23 Dec 2014 at 8:45am
|
Copy. Will think harder about this one today and post an update when I have one (that might be a few days). ------------- Steve Jacobson sjacobson@avidyne.com |
Posted By: teeth6
Date Posted: 23 Dec 2014 at 9:09am
|
This is probably not totally related to your issue but when you first hit direct to it gave you the distance along the magenta line (not the point to point) as you already said. I agree this is confusing especially when wanting to know exactly how far you are from the airport. Along these same lines, I saw a similar issue when I was in a hold with 5 miles legs after a missed approach. I had intended to fly outbound 5 miles and then start my turn inbound to the fix when the 540 said I was 5 miles from XYZ. As I passed XYZ to start my outbound leg it said I was 15 miles from it and then starting counting DOWN so (as in the case above on this thread) the further I flew from XYZ, the distance got less. I am not sure I really like the logic in the box on this one but the explanation from Avidyne was: That datablock shows remaining leg distance. A hold is considered a single leg that looks a lot like a racetrack, so the leg distance represents an entire lap and the remaining distance counts down until you cross the hold fix. If you continue in the hold, then the distance will jump back up when you cross the fix and then start counting down again. The start of the issue here (with the magenta line and the turn back) sounds similar to what I saw. |
Posted By: brou0040
Date Posted: 23 Dec 2014 at 10:13am
|
teeth6, So you were already established in the hold, and the legs were set to 5 miles, and the distance reset to the total hold distance as you crossed the fix? To me, the behavior you described is what I would expect. Did the distance count to zero as you competed that lap? Perhaps the datablock title and pilots guide needs to be more clear regarding direct to or along the flight plan distances for these datablocks like they are for the destination block. The To and Next fields should be along the flight plan, not direct distances. Avidyne has stated they are going to add a datablock that is the straight line distance to an arbitrary point. This would be the block that would contain the data you were expecting. Without more information, I believe this is unrelated to the issue above.
|
Posted By: AviJake
Date Posted: 23 Dec 2014 at 12:18pm
|
I've changed the title of the post to be a little more descriptive of the squawk. Something does appear to be not-quite-right and we're actively looking at it some more in the lab right now. Will post an update when I have something. ------------- Steve Jacobson sjacobson@avidyne.com |
Posted By: pburger
Date Posted: 23 Dec 2014 at 12:21pm
|
teeth6, That is very interesting. I don't see the advantage in knowing what the total length of the hold racetrack pattern is. (well, the only thing might be to calculate fuel remaining, or some such). If I need to fly a hold with 5nm legs, then I need some reference that tells me how far I am from the fix, PERIOD. NO EXCEPTIONS. Not everyone has GPSS that will fly the magenta line for them. Some of us have to hand fly these things, and need to know when to turn. We shouldn't have to divide the total "leg distance" by two and then take a little more off for the turns to figure out how far we are from the fix. What real benefit is it to a pilot to know that he has flown 4 of the 15 miles of the racetrack? I just need to know how far away from the fix I am right now. Doesn't SA mean anything anymore? I'm new to the whole FMS world. So, maybe this is how it is. Maybe it's all about flying a magenta line, or more accurately, letting George fly the magenta line. I'm kinda sorta not liking this. What about timed legs? The distance really shouldn't matter, except for SA, which is not a small thing. It looks like I need some more sim time to see how this thing works.
|
Posted By: 94S
Date Posted: 23 Dec 2014 at 12:44pm
|
In reply to brou0040 post above, It seems to me that pburger's and teeth6's situations are very related. When pburger entered the "Direct To" into the IFD it computed the magenta line and distance, just like it would for the hold in teeth6's scenario. The problem arose when pburger didn't fly the magenta line as the IFD expected he would. It would be interesting to experiment with teeth6's hold by entering it in the IFD and then not flying it as shown to see how the IFD would handle that. It seems to me that the "Direct To" algorithm should repeatedly recalculate the direct to solution from the aircraft's current position rather than just calculating the solution once when the "Direct To" function is activated. Even if you overfly the direct to destination, it should continue to recalculate the solution until told otherwise. I agree with teeth6 that the straight-line distance to the fix is important as I am putting an IFD 540 in a round dial airplane with a less than stellar auto-pilot. The along-path distance would also be useful, but for the reasons teeth6 gave, the straight-line seems more important. David |
Posted By: teeth6
Date Posted: 23 Dec 2014 at 2:08pm
Yes, the distance did count to zero as I completed that lap but it was very weird to see the distance count DOWN as I flew away from the fix. For a hold, I really don't see the benefit of knowing the total distance around the racetrack. To me, this is different than a regular flight plan leg. I don't mean to compare the 540 to the 430 because it is light years ahead and infinitely better but I did like to be able to see how far from the fix I have flown outbound in a hold so I would know when to turn inbound. |
brou0040 wrote:Posted By: tony
Date Posted: 23 Dec 2014 at 4:31pm
| I think you guys are confusing the distance to go with the distance to the airport. Its different. As we start to move into the Next Gen environment, someday we will have to be ready to do time nav. This FMS was built around DO-236. It's not a Garmin. Its much more sophisticated. |
Posted By: brou0040
Date Posted: 23 Dec 2014 at 4:56pm
|
94S, the difference between teeth6 and pburger is that teeth6's machine did what I would have expected it to do from reading the documentation and pburger's did not. Sure it can be argued either way regarding what is "right" for teeth6's example. When flying shorter legs, do you want that thing constantly chiming - maybe? Would teeth6's readout have been in error had he flown away from the magenta line? Maybe, that would be tied to pburgers issue, but he was describing wishing a hold was broken into multiple sections rather than a single leg. It sounds like what you guys are asking for is to have a hold broken down into individual segments for each part of a hold - I think that would be an improvement, but I'm not sure I would have considered an issue until I read this post. Making that change may introduce new issues such as the next leg being a previous leg in the flight plan as you are about to begin another lap. What I would suggest is that when you are in a hold, that a pop up readout show up somewhere on the screen such as the bottom left where the continue/exit hold button is just above the weather label, that is the distance readout and the name of the hold fix. I know that there is a future datablock that will give straight line distance to a point, but I'm not sure I'm going to want that as one of my normal datablocks and I don't want to have to change my setup as I'm entering / exiting a hold. pburger, I'm jealous of you being new to the FMS world, someday I'll join you. Until then, I'm also without GPSS and am still doing SA the old fashioned way...
|
Posted By: TogaDriver
Date Posted: 31 Jan 2015 at 9:35pm
|
I just saw this video. It jibs with some weird behavior I noticed recently with my newly installed IFD540. I noted this incorrect distance also populates my Aspen's next waypoint data block too. In the soup I'm trained to use the Aspen info as primary. If I am on a flight plan and then am vectored by ATC for traffic, etc, I wonder if the distance would no longer be accurate until a leg was re-intercepted, or until a Direct-To was executed? Avi-Steve, what is the status of this issue with the development team? |
Posted By: AviJake
Date Posted: 01 Feb 2015 at 11:37am
I'm not sure I understand the issue/concern but if IFD540 datablocks are the question here, there are a few subtlety different datablocks. A snippet from the Pilot Guide:
------------- Steve Jacobson sjacobson@avidyne.com |
Posted By: brou0040
Date Posted: 01 Feb 2015 at 11:49am
|
I've been waiting to see this post updated. This seems like a primary navigation issue that should be a very high priority, yet it's been silent for over a month - disappointing, not even a status of we're still working it. It seems like this is something that anybody with a 540 could test in their airplane (unable to test on the sim since it follows the magenta line). It would be nice if others chimed in with this test case and reported their findings. After confirming the same behavior, I'd also try hitting direct to the same waypoint again and seeing if it updates the calculated distance to something reasonable again, then continues it's erroneous behavior. Also, what happens if you let it count down for awhile while flying away from the magenta line for a few miles, then turning inbound. Does it continue counting down from the value it had, does it update to a correct value? This would be useful troubleshooting the bug. --------------- AviJake, any thoughts on pop-up box with distance to the fix while in a hold so that you don't have to modify your datablocks when entering / exiting a hold similar to the continue / exit hold button?
|
Posted By: brou0040
Date Posted: 01 Feb 2015 at 11:52am
AviJake, Can you state which of the above boxes you believe could provide the information shown in the video? Maybe I'm completely confused, but I can't see any of them doing this.
|
Posted By: AviJake
Date Posted: 01 Feb 2015 at 11:59am
|
I'll pipe in to address those questions on Monday - I'm not able to do the appropriate level of homework on this until Monday, presuming the weather permits travel. ------------- Steve Jacobson sjacobson@avidyne.com |
Posted By: MysticCobra
Date Posted: 01 Feb 2015 at 6:35pm
The issue/concern is the same one you acknowledged on Dec 23:
|
Posted By: pburger
Date Posted: 02 Feb 2015 at 12:04am
|
....not sure you understand the issue/concern?? Seriously? I'm dissappointed, Steve. I'm the one who posted the video. Since that time I have pretty much figured out how the distance field in the "TO Waypoint" datablock operates, and it is NOT in line with what the manual says, and not in line with what I would expect. You clearly indicated that Avidyne was looking at this and would report back. Based on your recent post, it sounds like no one is even looking at this - is that correct? As you point out in your recent post, the manual says the "TO Datablock" shows distance to current waypoint from present position. THE IFD-540 IS NOT DOING THAT!!! I believe it is showing one of the following two things, depending on the plane's current position:
Once I get my plane back I will be happy to video a scenario where I am 10 or 20 nm from the current waypoint, and the IFD-540 will show me <1nm away in the "TO datablock". I would also be happy if Avidyne took this issue seriously, as we were all led to believe they did. Even if the issue of the off-course distance somehow gets changed, I really don't like the idea that the distance in the TO Datablock is "ALONG THE COURSELINE". The scenario presented about flying a holding pattern really illustrates to me that this information is pretty much useless to the pilot flying the holding pattern. As I stated in an earlier post, I need to know how far I am from the fix, not how far I have left to fly in the racetrack. I suspect that Avidyne may not ever change this, so I would like to request the following: FEATURE REQUEST: A datablock called "TO Waypoint Direct Info" that shows the following:
(3 lines)
|
Posted By: Royski
Date Posted: 02 Feb 2015 at 10:27am
I'm not sure if it's the same problem, but with my 540 I've seen the datablocks for Nearest and Destination airports show different distances to the same airport. I took a photo with them off by 0.1 miles but I've seem them off my as much as, I think, 0.4 miles. |
Posted By: pburger
Date Posted: 02 Feb 2015 at 11:09am
|
That's interesting, Royski. Looking at the Destination datablock on your screen, it is clearly the "Destination Direct Info" datablock as shown in the manual on page 4-22. I would ASSUME that would be the DIRECT distance. There is another "Dest. Along Track Info." datablock that shows distance along the flight legs, but you clearly have the "Destination Direct Info" block on your screen. Avidyne - please check into this!! This is GPS, it should be dead nuts on. There is no "close enough" Either fix the calcs, or explain what information is being displayed. |
Posted By: oskrypuch
Date Posted: 02 Feb 2015 at 1:21pm
|
I would guess that the difference is the precise destination point at the airport, the airport center versus the arrival end of the runway, or something like that. * Orest |
Posted By: tony
Date Posted: 02 Feb 2015 at 2:52pm
|
If I remember correctly, nav was working just fine. The airplane knew where it was, however the guidance stopped working. The distance to the next waypoint didn't update and so the datablock froze. I thought this was a rather interesting problem.
|
Posted By: pburger
Date Posted: 02 Feb 2015 at 4:50pm
I would doubt that. How the heck does the box know which runway you're going to? I would think it uses the reference point of the airport in all cases, but maybe not. In any event, an explanation is warranted.
|
Posted By: AviJake
Date Posted: 02 Feb 2015 at 4:52pm
|
An explanation will have to wait another day or two. No ability to get to lab and check out today due to snowstorm. ------------- Steve Jacobson sjacobson@avidyne.com |
Posted By: brou0040
Date Posted: 02 Feb 2015 at 7:58pm
| My guess at the difference between the Direct To and Nearest fields would be the update rate of the nearest field. I thought this was discussed earlier that the Nearest field is not updated at a very high rate. My guess is that anything used for nav is at a higher rate/priority and anything used for SA is at a lower rate/priority. |
Posted By: Royski
Date Posted: 03 Feb 2015 at 3:45pm
| Thanks, I'm pretty sure the different update rate explains what I observed. |
Posted By: AviJake
Date Posted: 04 Feb 2015 at 4:41pm
|
Still on my to-do list but haven't come up for air yet to hit this one. ------------- Steve Jacobson sjacobson@avidyne.com |
Posted By: pburger
Date Posted: 15 Feb 2015 at 9:21am
As promised, here is a video showing a scenario where I am approximately 10nm from the TO waypoint, but the "TO Waypoint" datablock shows me at 0.0nm from the waypoint. Yes, I am not on the magenta line, but I will re-state my point that when I am NOT on course is when I need to know where I am exactly! This data presentation is confusing and dangerous. The areas of interest on the video are the TO Waypoint datablock in the upper right (TS07), and the Destination Direct datablock, which is a little further down. Also, you can see the magenta line on the screen, with the actual position of the airplane about 10 miles north. At 00:35, you will see that I am 9.6 nm north of the TO waypoint, but the 'TO Waypoint' datablock shows 0.0nm!! The data displayed was exactly what I expected, because it is working as I described in my Feb 1 post of this thread. I believe that this presentation in the TO Waypoint datablock is dangerous and should be modified somehow to present better, less confusing information when off course. I really don't want someone to hit a mountain. I also want to repeat my request for a new datablock called the "TO Waypoint DIRECT" datablock which would show the TO waypoint, the Bearing TO, and the Direct distance to. No curved paths, or any of that, just the bearing and distance in a similar fashion to the Destintation Direct datablock. If I had that datablock, I would put it in the upper right corner and I would forget about the current "TO Waypoint" datablock altogether.
|
Posted By: brou0040
Date Posted: 15 Feb 2015 at 11:01am
|
Yup, absolutely broken. No misunderstanding of datafields should cause this. Nearing the 8 week mark from when this was recognized as an issue and still no explanation... A day or two has also passed. I think at this point, we should be able to expect an explanation of what is causing this and a plan to address it. I understand any software change will be down the road, but it should at least be getting some attention.
|
Posted By: oskrypuch
Date Posted: 15 Feb 2015 at 11:37am
|
Curious ... When you see this behavior, what happens if you recompute the "direct to" route? Does the TO value then correct? Does this ONLY occur in situations where you are using a "direct to" construct? It seems to be giving you the distance along the course line, from the course point, from which you are abeam the currently plotted route. The manual description should probably be updated to reflect this as being along the course line, if that is the intent. But the other observation I'd make is that it seems to be an unusual situation, and perhaps why this situation was not noticed. IOW, if you hit direct to somewhere, and then fly substantially off the plotted route, would you not hit direct to again if you wished to make use of guidance? If you didn't, then you are creating an ambivalent/undefined situation for the navigation computation-- assuming that the TO waypoint value is meant to be along the course line. * Orest |
Posted By: TogaDriver
Date Posted: 15 Feb 2015 at 11:56am
|
I believe the "classic" behavior of the Garmin 4/500 series is to calculate the distance to the next waypoint regardless of whether you are on the track or not. This is beneficial for situations when you approaching an airport, either on D-> or as a leg waypoint, and want to announce your distance to the airport. If I am maneuvering VFR to the 45, for instance, I am often one or more miles off from the original track. Glancing at the data block lets me announce my distance accurately. Having to mash the D->, ENT, ENT, sequence over and over again is an unsafe distraction down low in the airport environment. My opinion: This is a critical bug and needs to be escalated to the next release. Obviously, it goes below bugs that actually crash the box, of course. |
Posted By: oskrypuch
Date Posted: 15 Feb 2015 at 12:44pm
|
Sure, on approach using a lot of "direct to" is generally a bad idea, other than for the IAF/IF. And having to execute a "direct to" to find a distance alone, is obviously rather clumsy. But in the discussion above there was no approach involved, and the "direct to" was the method of navigating to the airport. On approach I am often referring to the "direct to destination" datablock. I really like it, and use it often. The range rings will help with this as well, what would really be nice is a FIX page that you could draw range rings and radials about arbitrary waypoints, including the destination -- that provides very powerful situational awareness. But, not to side track the discussion here. Based on the other posts here (I've not actually tried to test this in the air), once it is all confirmed it would seem reasonable that either the documentation needs to be amended and amplified, or perhaps a second type of (DIRECT) TO WAYPOINT data block needs be added, or in time, both. * Orest |
Posted By: brou0040
Date Posted: 15 Feb 2015 at 1:46pm
| They are going to add a direct to data block. That can solve part of this issue, but there is still an issue. The counter should never count to zero unless you are over the fix. It shouldn't matter if you hit direct to again, if it's calculating along the magenta line, or whatever. If the datablock is calculating along the flight path, then it should include the distance to reintercept the magenta line, then fly to the waypoint along the magenta line. If you fly perpendicular to the point (closest approach), the distance should never go to less than the direct to distance. |
Posted By: AviJake
Date Posted: 15 Feb 2015 at 1:54pm
|
I am currently airborne on JetBlue heading back to the office and will engage more directly this week. I will say that I absolutely dispute the assertions that this is a critical bug or causing dangerous conditions. I take solace in the passion that a lot of you have on this topic, the product, and aviation safety in general. I will provide a more thoughtful analysis of this issue in the coming days. (I am scheduled for jury duty on Tues so I might be NORDO then) ------------- Steve Jacobson sjacobson@avidyne.com |
Posted By: pburger
Date Posted: 15 Feb 2015 at 8:39pm
|
Although Avidyne may not want to hear this, I think this is a case of WWGD? A large percentage of us have been flying behind Garmins for the last 10 years or more. I had a GNC-300XL, but I checked with my 430 buddies, and they confirm that when they look at their distance to waypoint they see the direct distance, no matter if they are on the courseline or not. That's how my GNC-300XL worked, and it was INTUITIVE. If I've been vectored off the planned path, or if I've deviated for weather, or whatever, I would like to be able to look at the distance and see how far away I am from the waypoint. It seems pretty simple and straightforward to me. I shouldn't have to know some esoteric secret about what the distance really means (well, you see, this here unit is an Avidyne, and well, uh, if you're not on the magenta line, then the distance shown to the waypoint isn't really the distance to the waypoint per se, you see... ). To paraphrase a former president, "I guess it depends on what your definition of "distance" is." I do think this could lead to some serious confusion, and if you're in the clouds and aren't aware of the "secret" then I could see someone making a bad decision based on data they don't understand. This all started when my buddy asked me to fly 10 nm from the airport. I hit Direct-TO the airport so that I could monitor the distance, as I have done many, many times in similar situations in the past with my Garmin. This is when I noticed the distance counting down. Although it was a clear day, and I knew the area well, I was really freaked out for a minute or two. I was wondering how I got turned around 180 degrees. Once I looked at the ground and realized where I was, I realized quickly that the box was not acting as I expected it to. If I was in the clouds when this happened, I'm not sure how long it would've taken me to figure it out, especially if I didn't have a secondary GPS to cross-check against. Say what you will, I DO NOT WANT THE "TO Waypoint" DATABLOCK ON MY SCREEN. I would rather have the "TO Waypoint DIRECT" block which I have requested. That would be much more useful to me. I hope Avidyne will respond to that request one way or another. Orest - Yes, this was demonstrated with a Direct-TO, but I've got to assume it will behave the same way any time you depart the magenta line, whether or not the TO waypoint is the result of a Direct-To or just the next waypoint in the flight plan. Just telling someone to press direct-to repeatedly is not a solution. And to suggest changing the documentation as a solution to this confusing distance calculation? Really? I seriously hope Avidyne doesn't think that it's okay to show a 0 distance to a waypoint that you are 10 nm away from (or 100 nm, or whatever). That's just silly. No one I know who has seen this first-hand thinks it's right. |
Posted By: PA20Pacer
Date Posted: 16 Feb 2015 at 8:55am
|
It seems as though the issue described in this thread is not so much a bug as a necessary consequence of the fact that the datablock in question is intended to show the distance to the destination along the course line in the flight plan. If you are not on the course line, then some sort of decision must be made about how to calculate the distance displayed. It has been suggested a distance to intercept the course be added, but that begs the question of where the course is to be intercepted. When I have entered a flight plan for a long trip that includes some doglegs, I have often wished for a display that showed the distance to destination along the flight plan route. I have also used "Direct To" in the past on other GPS units to give me the distance to a point when maneuvering in an area, such as when practicing formation flying. Obviously, with the IFD540, using "Direct To" and monitoring the distance to the destination waypoint is not the correct way to get the desired information. I have not used the IFD540 enough to have a strong opinion, but this does not seem like a safety issue to me as long as the behaviour is clearly described and understood. Regards, Bob ------------- Bob Siegfried, II Brookeridge Airpark (LL22) Downers Grove, IL |
Posted By: pburger
Date Posted: 16 Feb 2015 at 9:47am
|
Bob, There is a datablock that shows distance to destination along the flight plan route. It's called the "Destination along track" datablock. That datablock is available and useful. It helps with overall flight planning for time and fuel management. |
Posted By: PA20Pacer
Date Posted: 16 Feb 2015 at 10:58am
|
I will anxiously await Steve's analysis of the motivation for this design element. As I said, I do not have much experience with the IFD540, so I do not have a strong personal opinion about this particular issue. Regards, Bob ------------- Bob Siegfried, II Brookeridge Airpark (LL22) Downers Grove, IL |
Posted By: AviJake
Date Posted: 16 Feb 2015 at 4:14pm
|
Had the chance to finally look at pburger's original post and subsequent updates in enough detail to formulate a real response. 1. I have an error in my Pilot Guide description of the distance field in the To Waypoint datablock description. I erroneously wrote it was "distance to current waypoint from present position" when really it's distance to current waypoint along track. More precisely, it's remaining distance along the path assuming the aircraft were on the path. I've updated the Release 10.1 version of the Pilot Guide to reflect that correction. 2. The system does not have a bug - it is operating per design. I'm sure there are those will argue they don't like the design or the design should change and that will be a fun debate to have. It is using big iron FMS logic. As implemented, the distance remaining is measured from a point called the "along track normal" (ATN) and that point represents where the aircraft is supposed to be on the flight plan. We've put together a set of slides with a bunch of annotated screenshots showing the behavior and how the ATN is computed. From a philosophical perspective, the system is expecting you to fly the path - it is not designed for you to create a FMS path, then intentionally not use it. Of course that happens in real life and then you have to think about all the cases which we have and still concluded to design it this way. For example, if we didn't design it this way, what distance would you present in the To Waypoint distance field when flying a DME arc as part of an approach? Etc, etc, etc. Use this link to check it out if interested: http://www.avidyne.com/downloads/products/ifd540/Issue-with-Direct-To-distance-count-down-explanation.pdf" rel="nofollow - http://www.avidyne.com/downloads/products/ifd540/Issue-with-Direct-To-distance-count-down-explanation.pdf 3. I agree that it is operationally very useful to have some easy means of knowing your direct distance (no button hook, no ATN, etc) to a waypoint. Towards those ends, we are going to create two new types of datablock options for folks to pick if they want. We will add the "Active Waypoint Direct Info" datablock which will contain the active waypoint identifier, present position bearing to that active waypoint, and present position direct distance to that waypoint. We will also add the "Direct Distance to Active Waypoint" datablock which will contain the active waypoint identifier and present position direct distance to that waypoint. Those two new datablock adds will come shortly after Release 10.1.0.0. ------------- Steve Jacobson sjacobson@avidyne.com |
Posted By: TogaDriver
Date Posted: 16 Feb 2015 at 6:53pm
|
Steve, thanks for the math. At least we all now know that the IFD is behaving as designed for this data-block calculation, and how, if not exactly why (DME Arc excepted). It does make sense that you'd want to calculate the time along the course and the box really can't know when the course is going to be abandoned. I only wish the ATC universe were ideal and we never got vectored. But, until then, I really do like to know how far I am (physically) from the next waypoint so AWDI and DDAW (sounds like a stuttering frenchman) will be much appreciated. Perhaps another way to skin that cat would be a LSK that could toggle the calculation from ATN to DWP (Direct Way Point). That way we could fly happily along the predicted path until ATC throws us a strange vector, or we need to vector ourselves for an alternate approach. That might not be as obvious as a unique data block but would be easier to use on the fly.
I, like many other IFD converts, am having to unlearn some of the oddness that Garmin inflicted on us with their trusty 4/500s. Perhaps the next webinar could be on this topic: 12 Steps to the Avidyne Way for recovering Garmin Users Topic 1: Which Way is Home and How Far Is It? ... |
Posted By: teeth6
Date Posted: 16 Feb 2015 at 7:03pm
|
The only thing I still don't understand is how pburger got a distance of 0.0 to the waypoint when he was 10 miles away. Under either scenario (distance direct to waypoint) or with the ATN that Steve described, I'm not sure how the IFD came up with a distance of zero. Would you explain that.? I'm not trying to push the issue or complain but rather just want to understand how the box presently is functioning. Thanks |
Posted By: oskrypuch
Date Posted: 16 Feb 2015 at 7:10pm
|
Teeth6, Let's say you had planned a direct to route/track, due east, to a certain airport.
You then flew off the track to the north, and are now offset by 10nm to the north from the original track. As you now turn, and continue to fly due east, that Along Track Normal (ATN) point continues to countdown to 0, as it nears that original destination. When directly north of the destination, the ATN point will be at the destination, and the distance will correctly show zero. But, you will still be 10nm north of the destination. If you then reselect direct to that original airport, presuming you want to go there, the distance will then change to show 10nm. * Orest (BTW Steve, great post above) |
Posted By: TogaDriver
Date Posted: 16 Feb 2015 at 7:23pm
|
I "think" if you parallel the plan course back toward the waypoint but, being parallel, though never intersecting, your track angle error becomes zero and cos(zero)=1 so it starts counting down 1:1 with your parallel travel until you can look 10 miles off your right wing at the waypoint and wave. Yeah, weird. I'm thinking of ATN as a little red ball in the magenta track that gets yanked along by a string tied to your airplane, but cannot leave the track.
|
Posted By: brou0040
Date Posted: 16 Feb 2015 at 8:55pm
Thank you very much for this response. I think this is very informative to understand what the system is doing. How would have I done it to include distance to the waypoint along a DME arc? I would have made it so it calculated the distance along the arc from current position to the waypoint (what it does currently if on the magenta line). If you are off the magenta line, it would calculate the distance to intercept the magenta line, then fly along it to the waypoint. You almost have this currently if you'd just add the distance from the current position to the red dot to the calculation. I'd think you'd do it a bit more elegant such as calculating the button hook distance to turn to an intercept and the turn from the intercept back onto the desired course. If you are off the magenta line while dodging storms and when it's most critical to have good information, you do not have a data block that will provide useful information. From how you are using this calculation, I'll go out on a limb and assume that this is the calculation you are using for fuel range as well. We all plan for fuel reserves, but we all know that the unknown is how much are we going to get vectored off course and how that will affect our fuel range. We've just seen how the distance to waypoint will provide non-useful data (even though as designed, I don't know if it can be argued that it is still useful when vectored off course) and direct to data does not account for turns or returning to the intended flight path. To me the most useful data would be the distance (and time) to intercept the magenta line then flying the flight plan from there. I don't see it as being that difficult to create straight forward intercept to calculate the missing information. Away from how I would have done it. I would suggest adding some of these figures to the pilots guide to capture this information in the formal reference material. I'd also suggest doing something as a reminder to pilots that this scenario is occurring. Maybe when the present position is a certain distance away from the course line, you could change the color of the time and distance in the datablock to red and add the red dot to the display similar to what you did in the .pdf. I think this would be a subtle reminder that you are not flying as the IFD is expecting you to and that calculated data is going to be affected. Again, thanks for the explanation, you did a very good job of illustrating and annotating the scenario.
|
Posted By: pburger
Date Posted: 17 Feb 2015 at 12:33am
|
Steve, I appreciate the explanation. I viewed the pdf file, and it explains exactly what I surmised and observed. While I don't like the design, and I still believe the "TO Waypoint" datablock will present very confusing and non-intuitive information in certain situations, I will not belabor the point any further. I look forward to the addition of the "Active Waypoint Direct Info" datablock (AWDI). I will put that one in the upper right corner just as soon as it becomes available. |
Posted By: teeth6
Date Posted: 17 Feb 2015 at 7:19am
|
Thanks for the detailed explanation with the PDF to illustrate. That makes it very understandable. I also will look forward to the release of the Direct To which will be released in the future. |
Posted By: bellanca1730a
Date Posted: 17 Feb 2015 at 8:16am
|
I admit that my limited FMS experience leaves me with a bit of a learning curve here, so forgive the rookie question -- but what is the real utility of the ATN distance? I looked over the slide presentation and re-read the explanations above, but must be too steeped in direct-to-waypoint tradition to wrap my head around it. ------------- Sean Andrews Bellanca Super Viking |
Posted By: 94S
Date Posted: 18 Feb 2015 at 3:08pm
|
Ditto bellanca1730a. I understand the math behind ATN, but fail to see the utility of it. I can think of many reasons why one might be flying off of the flight plan. Where, the TO Waypoint distance, as designed, would be confusing because it's not intuitive. Some scenarios would be; ATC vectors, diverting around weather, dealing with an emergency, going to look at that thing over there, etc. One particular use I have for direct distance and bearing is situational awareness at my home airport. I select "Direct To" before departing to go out in the practice area where I monitor the CTAF for other traffic coming and going. The direct bearing and distance to the airport help me understand my relationship to other traffic in the area as well as make position reports to same. The architecture of FMS might assume that you will always be on the magenta line where this won't be an issue, but if it simply showed direct bearing and distance to the waypoint it would be correct and intuitive when you are on the magenta line and when you are not. I don't see the value in knowing the distance your perpendicular intercept to the magenta line is from a way point. I want to know how far away my airplane is from a waypoint, on or off the magenta line. I understand that you are adding a couple of new data blocks that will provide the direct to information, but I am really puzzled why your keeping the original ATN logic. It seems to me that it could bite somebody already task saturated by the weather, atc, or other extenuating circumstance, not by leading them astray, but by taking valuable mental resources off the primary task of flying the airplane to try to understand why the "number" is not doing what it is intuitively supposed to do. I think pburger has brought up an issue that requires more attention than just saying "it works the way we want it to". Sincerely, David |
Posted By: oskrypuch
Date Posted: 18 Feb 2015 at 3:35pm
There are two great datablocks, which I use all the time, one shows just the distance to your destination, the other the distance, bearing, etc. They will do a better job of giving you that information, you could additionally create a user waypoint at the practice area, and set that as part of the plan, returning to homebase. As I understand it ATN logic is always required to keep track of where you are relative to the flight plan you set out, for sequencing in particular. Think of DME arcs or procedure turns. So it will always be used internally. With additional information datablocks added, you can have it both ways. There will be no reason you have to keep the original ATN related TO waypoint block. That said, now that I'm getting used to the current setup of the (only) TO waypoint datablock, I kind of like it. It adds another data point to SA. * Orest |
Posted By: 94S
Date Posted: 18 Feb 2015 at 5:14pm
|
Well ok, if it is needed internally for the program logic, keep it internal. I see no use for knowing the distance my perpendicular intercept of the magenta line is from a waypoint. Even on a DME arc, DME arcs are flown with the DME and a VOR, not the IFD (I believe any approach that has a DME arc is "GPS Overlay Not Authorized", which the IFD will tell you when you select it). The distance (or time) around the arc is of no use. The distance from and degrees flown around the VOR are. And has been discussed up-thread, the distance around a holding pattern is similarly not useful, the distance from the fix that defines the hold is (The time to the fix may be beneficial if departing the hold at a particular time, but I would think this could be displayed without the ATN distance and bearing info). And if I am flying off my route, what use is it to know when my perpendicular intercept is going to cross the waypoint since I am not going to cross the waypoint? The point of my previous post is not just that the information currently presented is not useful, it could be dangerous. I am an engineer, and like to keep things simple (KISS - keep it stupid simple), which for the most part the IFD is wonderful at. But this particular piece of it, I think strays from that philosophy. I know there will be options to do away with the "ATN TO" information when I set up my IFD and that I'm really not going to fly by the "ATN TO" information, but what about those who haven't followed this thread and don't know about the subtle but significant difference in the two? And what about those who have, and who in the heat of the moment in an emergency forget the difference, lose their SA because of the confusing information, and possibly their chances at a successful outcome? It would make more sense to have the Direct To info be the basic configuration and the ATN To information optional for those that want it, instead of the other way around. Just my 2 cents. David |
Posted By: bellanca1730a
Date Posted: 18 Feb 2015 at 5:55pm
|
To be clear, I was just hoping to better understand the utility of ATN and assuming that someone with more FMS experience would be able to weigh in and explain. Orest, as a primer, perhaps you might expound on "Think of DME arcs or procedure turns." ------------- Sean Andrews Bellanca Super Viking |
Posted By: Victor
Date Posted: 18 Feb 2015 at 6:42pm
Not true. As one example, it is very useful when determining your descent profile. We always use it during an arc approach and upon conducting other approaches in the airline industry regularly. You just need to know how to use it and I applaud Avidyne for including it in the IFD. In my opinion, it is a great bit of inclusion. Having said that we also can see our direct to distance on the flight plan page if needed. Please try to refrain from using emotional words like, 'it could be dangerous'. Any instrument or avionics equipment in an aircraft is dangerous if the user does not know the correct method as to how to use it or interpret the information provided. Victor Mooney M20J |
Posted By: brou0040
Date Posted: 18 Feb 2015 at 10:20pm
I'd equally say please don't shoot down others concerns. I wouldn't say this is emotional. When you read this thread, do you get the perception that most people understood how ATN was being implemented in the system, what it meant, how to use that information, when the measurement will give you a non-intuitive answer, etc? I agree that it is dangerous because it is misleading unless you have a greater understanding of the system than the baseline documentation provides. I do like knowing the time and distance along the flight path, but I fail to see the value of ATN beyond sequencing the waypoints. I still argue that it would be more useful to have a measurement based on getting back to the flight path and then along the flight path because that is a realistic estimate of the time to get to where I'm going. Even with the planned datablocks, this data is still not available when off the flight path because only ATN is being calculated that includes the flight path, but the ATN measurement without recapturing the flight path gives me zero useful information.
|
Posted By: Victor
Date Posted: 19 Feb 2015 at 12:49am
I apologise to anyone who interprets my post as shooting down others concerns. That certainly is not my intent. (Problem with emails and forums) As well as ourselves, there are potential buyers out there accessing these forums to help decide whether to purchase an IFD or a Garmin or BK. I think we are doing this great and very capable unit a big disservice by using words in our posts like 'dangerous' when we know otherwise. Some features of the IFD are misunderstood, but it is not dangerous. We all have differing opinions in our preferences. That is fine and respected by all of us and importantly Avidyne, who are endeavouring to rectify concerns raised. Re this particular matter, I am happy with the unit the way it displays distances. However, other poster's concerns have been acknowledged by Steve with a future rectification. We can't ask for more than that. Victor Mooney M20J |
Posted By: MysticCobra
Date Posted: 19 Feb 2015 at 7:05am
This is not true, so not a good argument for this debate. Certified GPS systems have been approved substitutes for DME since 1999. It is fully legal to fly DME arcs via certified GPS.
|
Posted By: pburger
Date Posted: 19 Feb 2015 at 7:26am
|
I said I wasn't going to belabor the point, but here I go. Victor, You say your intent is not to shoot down others' concerns, but that is exactly what you are doing when you say that "we know otherwise". No, WE don't. Let's agree to disagree. I used the word dangerous on my Feb 15 post, and David used it again yesterday, on Feb 19. Steve and you both are on record as disagreeing with that characterization. That's fine. We can have different opinions. I respect yours, and I believe you should respect ours. I stand by my opinion as stated on Feb 15:
I also think David's recent posts describe the concern much better than I have. This forum has been a free and open forum with complete transparency up until now, and I applaud Avidyne for that. That was a gutsy move, and I think it was the correct one. With all the transparency, it's still been a big love fest for the IFD-540, and that's understandable because it is a great unit. As I have said before, I want to sing its praises and I will be the biggest salesperson/advocate for the box because it is a great unit, and because I want it to be a success so that it will retain its value over the years. However, that doesn't mean I'm going in the tank for Avidyne for something that I think is a bad feature. I'm happy Avidyne will be adding a few more datablock options which will add some more useful information to my screen, but I must admit I was surprised that no change will be made to the existing TO Waypoint block. I do think this will turn out to be a thorn in Avidyne's side, but I might be wrong. The datablock in question shows a waypoint name, Dtk, and Dist, and ETE. To the uninitiated, "Dist" would imply "distance to the waypoint", and "ETE" would imply "estimated time enroute" to the waypoint. However, these two fields are not what they seem to be if you are off course. In fact, you have to read a two-page PowerPoint presentation to understand what these two fields mean. It's not intuitive, and I still have yet to hear how the data is useful -- it really has more to do with what is going on inside the box's calculations than with where the airplane is right now. I can just hear a lot of people telling their non-initiated friends, "oh that's just how Avidyne does it", or "well, it's not really the actual distance to the waypoint...", and other such excuses. This confusing off-course presentation may be infrequent enough so that this doesn't become a big issue, but time will tell. |
Posted By: SB Jim
Date Posted: 19 Feb 2015 at 9:02am
|
Hi Jake, How can the ATN distance make any sense (as calculated) if the pilot flies (or is vectored) further off track? |
Posted By: SB Jim
Date Posted: 19 Feb 2015 at 9:10am
|
PS. I'm in year 11 of flying behind a GNS 480, the first WAAS FMS type GPS/NAV/COM for general aviation. I don't recall ever seeing ATN distance. But I've used the direct to distance on every flight and I find it incredibly useful. If I can permanently hide the ATN datablock I am likely to do so when my 540 arrives. While it may make sense in an Engineering discipline I'm having a hard time wrapping my head around the usefulness of a distance measuring device that counts down as I get further from my To waypoint. At that time the ATN figure is theoretical, innacurate and meaningless; it's only valid if one is precisely on course. With the significant amount of radar vectoring we get out here on the west coast that data block would be useless. Regards, Jim |
Posted By: Victor
Date Posted: 19 Feb 2015 at 9:20am
I don't mind a robust discussion, but I will not tolerate being deliberately misquoted. Your comment about uninitiated saying that is just how Avidyne does it is equally as assinine. FMS units have been installed in jets and heavy turboprops throughout the world for many years. I fly professionally and have thousands of hours behind different manufacturer FMS's including Universal, Honeywell and Thales. I can tell you the info that is the subject of this discussion that is displayed on those units and the IFD is no different. You don't hear about hundreds of jets and turboprops slamming into mountains around the world because the crews aren't familiar with their FMS. We are very fortunate to have Avidyne design such a unit for us in the GA sector. By all means bring matters to their attention that are of concern, which are being addressed, but it is also encumbent upon you as a user to learn how to operate and understand its logic properly. If that is too much for you then ditch your IFD and go back to using a Garmin 100. Victor Mooney M20J |
Posted By: bellanca1730a
Date Posted: 19 Feb 2015 at 9:44am
How does one extract the utility of this ATN tool beyond the one example that Victor gave of determining descent profile on a DME-arc approach? It's a real question. I'm looking for real answers. I'm not looking to make a point. I just want to learn something to help maximize my use of the equipment. ------------- Sean Andrews Bellanca Super Viking |
Posted By: brou0040
Date Posted: 19 Feb 2015 at 10:33am
I can appreciate Avidyne trying to bring new technology to the GA world, but please acknowledge the target market of this unit. Most of us are not professional jet pilots with the associated training that comes with that job. This unit was advertised as being extremely user friendly, not requiring an ATP and FMS dedicated training courses. It is also not fair to say it is encumbent on the user to learn about ATN because ATN is NOT in any training material. Do you expect new users to read through every forum post and let them decide for themselves what posts they should learn and which are people posting who misunderstand the equipment? Nobody should be learning to fly from these forums. They can come to ask questions, but this should not be the official library of non-intuitive features of the unit. I think pburger's post was right on and I agree with the non-initiated comment. If someone were to ask me about that block, I would say I don't understand it's value and that it can give misleading information when you are off course - don't use it. People may blame me for speaking out of line for Avidyne, but that is currently my opinion. Since my unit is FINALLY being installed after numerous delays, I have an interest in not turning new customers away as well, but one of the great things about Avidyne is the transparency and ability to debate and potentially impact the design of the box. I think people reading these posts when tied with responsive posts by Avidyne goes a long way for positive advertisement - beyond any negative exposure by debating the issue in the first place.
|
Posted By: 94S
Date Posted: 19 Feb 2015 at 10:34am
|
Ok, ok! I stand corrected on my comments about DME arcs. However, the fact that GPS can be used to replace the DME for "measuring the distance to the fix that defines the arc" while flying the DME arc, and the fact that knowing the distance around and arc is useful for descent planning does not negate the fact that the presentation of ATN data in the TO Waypoint block is only valid when you are on the magenta line. Direct To data will be valid at all times. I think it is very short sited of Avidyne to assume that we, the end users will always be flying on the planned (or as modified) track. Mr. Burger has already demonstrated that off track flying does happen, and I thank him for bringing this to everyone's attention. I was initially hopeful that Avidyne was going to change things to present the direct to data instead of the ATN data. I'm a bit disappointed that their response was to provide a slide show that explained why the information displayed is not what one would expect and provide a couple of new optional data blocks that provide the information, but only after the user configures the unit accordingly. I'm thankful that the data blocks are being provided, but disappointed that they are not in the base "out of the box" configuration. There must be away that the unit can display direct-to data on straight segments and curved-to (which I'll lump together with direct-to from here on) data on curved segments, without presenting the ATN data. Like I've said before, the distance my perpendicular intercept to the magenta line is from the waypoint is of no use to me. I can see the day long after this thread has gone quiet (or maybe even before) when, if things are left as they are or will be after 10.1.0.0, that someone posts that they were "...out flying the other day and the information in TO Waypoint datablock was giving incorrect information" and this discussion will start all over again. Because as it is, the base configuration is not intuitive when you are off the track. I know Avidyne will be adding datablocks that will give the intuitive direct-to information, but my hope is that they will swap the priority of the information and make the direct-to information the base configuration and the ATN info optional so that the unit is as intuitive out of the box as it can be. I too very much appreciate this forum and Avidyne's willingness to let it all hang out. I have learned a lot about IFD from the forum, and hope that I can contribute to it as well. I too think the IFD is a amazing product and sing its praises to my fellow pilots, and I haven't even flown with one yet. I think the real power of this forum is our ability to share experiences with Avidyne and each other to try to help IFD be the absolute best it can be. And to that end, I would expect and appreciate that anyone who discovers something potentially "dangerous" or otherwise not ideal to share that info so we may all learn from it. That is part of the transparency of the forum. I would also think that most potential customers who research the forum for info on IFD would be glad to see how concerns of users are voiced and addressed. Kudos to Avidyne for this. I would hope that others will chime in on this issue, which ever side your on, so Avidyne can weigh the importance of it and act accordingly. If I'm only one of a few who wants the direct-to info, I will configure my IFD (hopefully someday to be IFDs) accordingly and fly on. Sincerely, David |
Posted By: pburger
Date Posted: 19 Feb 2015 at 11:25am
|
Victor, I didn't want to get into a personal debate, but apparently that is where we have landed. You implied that I misquoted you. Here is the full sentence from which I took the quote. This was from your post on this very thread on February 18, at 11:49pm. I'm not sure how I misquoted you, deliberately or otherwise.
I believe my comments were clear that I believe there is confusing information shown when off course, and I stand by that belief. On the other hand, you are "happy with the unit the way it displays distances." That's okay with me. We are all entitled to our opinions. Can we just leave it at that? pburger
|
Posted By: AviJake
Date Posted: 19 Feb 2015 at 11:53am
|
The topic is timely indeed - I'm sitting in a FAA sponsored session on Human Factors in aviation displays and distraction is a hot topic here. We take this very seriously and note that while we have no desire to stifle free speech and expression of your concerns, please act as responsibly as you can on this forum when it comes to declaring something as "dangerous". That is a phrase that is seized upon in our litigious society and twisted into all sorts of perverse and inappropriate uses. For this particular topic, and the unit in general, we and the FAA have combined thousands of hours into determining the units to be safe. As to the specific question about how ATN makes any sense as you get farther off track… The answer is, of course, that it doesn't. But there's a rhetorical corollary to that. As you get farther off track, how does the flight plan make any sense? You might as well not have one. Everything the FMS does is based on the existence of the flight plan and the assumption that there's actually an intent to fly that. I think that this whole issue started because the pilot used a technique that works for a GNS430 and that same technique doesn't work on an IFD540. It's not that the Garmin shows the remaining distance to the active waypoint. It's just that the data shown on the Garmin for this particular scenario is what the user wanted. Our data isn't wrong, it's just different than the Garmin. Garmin has no more idea of what the pilot's intent is than we do. He's entered a flight plan and is not flying it. So what's the remaining distance to the active waypoint? Who knows? There is no way to know whether the intent is to fly direct to that waypoint or whether the intent is to fly 10 mile S-turns. Or maybe, as in this case, there is no intent whatsoever to fly to that waypoint. You could just as easily make the case for displaying dashes for the distance to go. Nevertheless, it seems like everyone is used to seeing distance/bearing direct-to the active waypoint. We get that. It's a useful piece of information to have. So, in the short term, we're adding the new datablocks. We have related considerations to take into account like if someone was looking at that datablock and then switched over to look at the active leg stats on the plan page, they wouldn't match. In the long term, we can look across the board to determine how to handle all of this. As I said above, the flight plan is what the FMS uses to establish the intent of the pilot. All of the time and fuel predictions are based on that intent. Thus, the existence of the along track information that we are showing. So the real question is what should the FMS assume when the aircraft is significantly off of that path and what measurement is used to establish whether you're significantly off path. When the aircraft is significantly off path, should the FMS assume that the intent is to rejoin the active leg or should it assume that the intent is to fly direct to the active waypoint? In the case that started all of this, neither of those is true. So, what would we compute for remaining distance (which directly affects ETE and fuel burn)? So, there's much more to consider than just what distance should be shown in a datablock. We'll noodle on it for a while and see if we can come up with a comprehensive solution. ------------- Steve Jacobson sjacobson@avidyne.com |
Posted By: TogaDriver
Date Posted: 19 Feb 2015 at 12:17pm
|
Steve, thanks for the response. Since only ATC and the pilot know the intent of their current deviation from a flight plan, I suggest you give the pilot some control over toggling ATN/Direct calculation via an LSK or similar option that is immediately available to the pilot without a lot of messing around. On the upcoming 440 you will have limited screen real estate. Maybe just post a notice in the data block that you've gone on VECTORS instead of the standard calculation method. I've spent 30+ minutes getting vectored all around NorCal airspace even on IFR plans during a busy push - that's a long time to be off the flight plan. Even with the Garmin I did a good bit of D->,Ent,Ent. Steve, since you have more time than the rest of us combined with these IFDs, how do you handle extended vectors that take you off plan? How do you determine, and report, your location when VFR to an airport environment and the runway changed such that you had to maneuver. If you have some good tricks we'd love to use them while we wait for the update. Thanks! |
Posted By: AviJake
Date Posted: 19 Feb 2015 at 1:04pm
|
No magical tricks here. I typically use one of three basic techniques: 1. I use Destination Direct Info block which has the snap vector to my destination. Seems most helpful when flying a radar pattern or terminal area vectoring and want to maintain snap vector SA to the landing patch; 2. I use the range ring on moving map to provide close enough distance; 3. I keep the FMS flight plan representative of the route I'm trying to fly. ------------- Steve Jacobson sjacobson@avidyne.com |
Posted By: SB Jim
Date Posted: 19 Feb 2015 at 1:54pm
|
Most of my instrument flying is in California. Of course it's very busy out here. As a result radar vectors are the norm, not the exception. I can't remember the last time I flew an instrument approach as published, with or without procedure turns. On a simple IFR trip to Palm Springs (a 1 hour flight or less) I received four significant reroutes, one of which took me backwards towards Fillmore VOR after I had been cleared direct to Van Nuys. I think my record for being vectored back and forth across an ILS approach course is 4 times on a single approach (into Oakland, weather was worse than forecast, busy). Flying off flight plan is simply how they get us all from A to B with all the traffic. Perhaps the simple answer is to compute ATN as you have done until such time as the aircraft is clearly off course, then compute distance to the waypoint shown as "To" in the flight plan. If anyone's fuel planning is so tight that can't make a course reversal they have other problems they need to solve. I'm glad this forum exists, that would've been a "what is that box doing now?" moment had it happened in my cockpit. <g> Jim |
Posted By: NZFlyer
Date Posted: 19 Feb 2015 at 2:40pm
|
Flying the Litton 72 many years ago I seem to remember it had a function called 'remote range', which was instantaneous present position, range and bearing to a waypoint. This was very useful for spacial orientation around weather and when being vectored in the terminal area etc. If a similar function was used as an IFD Data Block it would be like Destination Direct, but more flexible in that any waypoint could be selected as the subject. Could this be a solution to those wanting more pertinent information when off flight plan? |
Posted By: AviJake
Date Posted: 19 Feb 2015 at 2:44pm
|
I think so. We're trying to create another datablock that allows you to create that kind of datablock for any waypoint, whether it is part of the flight plan or not. ------------- Steve Jacobson sjacobson@avidyne.com |
Posted By: teeth6
Date Posted: 19 Feb 2015 at 3:20pm
|
Steve, That would be awesome. When I had dual 430s, I had them setup to crossfill in ONLY 1 direction so I could use my bottom 430 for the "what if" scenario. I could enter direct to any waypoint to get bearing and distance direct without affecting my original flightplan. Since the 540s crossfill in both directions, that was no longer possible but having the ability to have a datablock for ANY waypoint would be very useful. |
Posted By: AviJake
Date Posted: 19 Feb 2015 at 3:23pm
|
roger ------------- Steve Jacobson sjacobson@avidyne.com |
Posted By: 94S
Date Posted: 19 Feb 2015 at 4:26pm
|
Steve, Thanks for the response. I'm glad to hear this issue is still being discussed on your end. As you talked about in your 10:53am post today, there is no way of knowing why a pilot has left the planed route. Or if, how or when he/she might rejoin the route. That's why in my simple way of looking at things it seems the most appropriate way to display the TO Waypoint data is with the direct-to info for the next down-plan waypoint. If you're on the course it's correct. If you're off the course, it's correct. Simple. As for the FMS calculations of distance, time and fuel; again using the direct-to info for the next down-plan waypoint followed by the along-track distances for subsequent down-plan waypoints gives the unit the information it needs to do the calculations. Just as I would if I was doing it with my map, plotter and E6B. If the pilot is flying to one side, perpendicular to or away from the next down-plan way point, base the calculations on the "if the pilot turns to the waypoint now" scenario. That is about all you can do, because as you said you can't predict if, how or when they might. But displaying information that indicates that the aircraft is AT the waypoint, when it is NOT, is confusing to put it lightly. I am all for having the option to select ATN info for those that want it. It was mentioned up-thread about using a LSK to select between ATN and Direct-To. I would offer another idea, tapping (or double tapping maybe more appropriate to avoid accidental selection) of the TO Waypoint datablock to "flip" it from one to the other. Not sure if that fits into IFD's architecture or not, but thought I'd through it out there. I understand that the beauty of the FMS is getting from point A to B along the planned route and most people will do just that, but human nature is in play here and we will not always do what we planned. I think making the unit as human proof as humanly possible is in everyone's best interest, Avidyne's and ours. The heavy iron airline folks might understand and appreciate the ATN philosophy, but it is my understanding that your target customer is GA. Nowhere in my GA flight training have I even heard the term "Along Track Normal". IFD is huge step forward for GA, but in regards to this particular aspect, baby steps may be in order. Sincerely, David |
Posted By: AviJake
Date Posted: 19 Feb 2015 at 4:29pm
|
roger ------------- Steve Jacobson sjacobson@avidyne.com |
Posted By: Gring
Date Posted: 19 Feb 2015 at 4:47pm
|
All this discussion is interesting, but in practice (and I think I've flown behind an IFD540 longer than any non Avidyne employee) it isn't an issue. I've used offset tracks, I've been vectored, I've used the FMS flight plan, I've been Direct To, I've created a user waypoint, and none of what has been discussed has ever been an issue in determining where I am relative to a waypoint. The IFD 540 has so many different ways to maintain SA and of the options Steve mentions above, I primarily use the range rings for distance calculations when flying off route. I've said it before, if you want an evolution of technology, then be prepared to accept an evolution of process and procedure too. The only thing I miss is the time/distance on a procedure turn/hold from the waypoint which was displayed in both time and distance on a 430 default nav page.
|
Posted By: MysticCobra
Date Posted: 19 Feb 2015 at 5:13pm
Except, that's not true. If you're flying a DME arc, the distance along the arc to the next waypoint and the straight-line distance to the next waypoint are not the same. If you're flying a course reversal, the along-track distance is not the same as the direct-to distance (to the next waypoint). As Steve has explained, it's not so simple. If it were, there would never have been a need for this discussion.
|
Posted By: 94S
Date Posted: 19 Feb 2015 at 5:52pm
|
Yes, but I'm sure that the IFD has a computer in it capable of calculating the actual curve distance to the down-path waypoints from the actual airplane position in both those scenarios, whether on or off the planned course. And in reality, by the time you're in those phases of an instrument approach, you'd better be pretty close to on the planned course. |