Well, the GPS was working properly after all on the flight from the previous post (Normally when a pilot had a depiction of 3.9 nautical DME miles from a Class D airport and hadn’t talked with the tower on a practical test, I would have failed them….but…). After some more digging, we found it was doing exactly what it was programmed to do. It just isn’t programmed to do quite what I might think I would like it to do in such a situation.
The GPS wasn’t actually telling us the distance to the station that we had put into the FMS, it wasn’t “distance to the desired waypoint” from the present position of the aircraft to that what was programmed into the FMS that was being shown, it was in fact “distance to current waypoint along a track.” More precisely, it’s the remaining distance along the path assuming the aircraft were on the path. It doesn’t’ matter if you are on the actual track that was programmed, or parallel to it. On it, 5 miles to one side, or 1000 miles to one side, it is going to track the distance along the parallel track to the perpendicular point of the originally set FMS point.
So was I. So we made the system do it again.
It’s not an error if it does the same thing each time do the same thing right?
On a subsequent flight we started by putting a direct to KBTL into the system then abandoning our course and dog-legging away from it. I took pictures throughout our testing process and you can see the first part of it below.
You can see that as we flew away from the path perpendicular that the ToDtk and the Dest BTL “DME”, numbers begin to diverge, although not drastically. What is happening is that the the destination calculation is tracking the actual DME to the destination of KBTL while the ToDtk is just tracking the distance travelled closer to the perpendicular point along a parallel path that would have lead us to KBTL if we followed our original course.
As we then turned to follow the “course line”, but not the particular actual course (we were to the west of it) the ToDtk then also counts down while the Dest BTL DME is continuing to reference the actual DME from the KBTL airport, not the distance travelled along the course.
Continuing forward to the point that would be parallel along the path and perpendicular in a horizontal plane from KBTL, we actually find that the ToDtk “DME” counts down to an eventual zero point (although I grabbed a picture at .3 miles) and we find ourselves at 7.8 actual nautical miles from the real airport, but at the zero point as travelled along the parallel to the course that was set.
I have to say this is not what my old school pilot brain would “expect” would be depicted. My brain things a DME is always a DME from the point that I have as the next fix, not some imaginary distance travelled along a parallel in any distance do a course that was set whether it is 1 mile or 10,000 miles. The reason we didn’t notice the difference in our first instance of this depiction was that there was previously set ultimate destination in the FMS that didn’t allow us to see the second point as we do on this screen shot set.
I can’t honestly for the life of me say I know when this would be an actual function I would use.
As WMU’s Chief Flight Instructor emailed me in the process of figuring this out,
“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.”
In reality, we probably don’t do this very often as we fly. If we get off of a course, we will most often reprogram a new “direct-to” and set a new course. If we are IFR, there is no way we should ever be this far off of a course and somehow still navigating. We would be well beyond a full scale deflection. But in a few cases, we may find ourselves vectored or wandering aimlessly on our own off of a course, and come up with a very difference “distance” (I won’t call it DME now) measurement that isn’t exactly what we thought we were going to be presented and could lead to some serious confusion.
So in the end, systems will do what they are programmed to do. It is up to the pilot to know what to expect in certain situations.
Many times we think we “know” an avionics system, but the reality is that there are a great many situations that can arise and we may have never experienced what each situation will depict and how it will react on our advanced avionics systems. A few hours of transition is a good start, but a few hundred hours in a particular system may really be needed to completely understand all the potential conditions that may be experienced – if even that is enough.
This isn’t to say that the systems are flawless as you can see from the picture below. This was another example of an “anomaly experienced” in flight where the right IFR pretty much lost all data, loc ked up, and the flight was scrubbed early to return on the left IFD and try to figure out what had happened. The picture below is a screen shot of the video. Click on it nad download the video to see it all (the video wasn’t in a format that worked in a blog but should readily play on your computer – I promise it is clear of viruses to download this quick example of a screen lockup).