Because the EHSI display is a nice, 2-dimensional display, it is very natural and convenient to look at it as simply cartesian coordinates and believing that calculating paths can be done via plane trigonometry methods. Such an approach breaks down very quickly as you get deeper into simulating the features of the FMS and compromising at this juncture would yield compromises in FMS accuracy and depth of features.

We must; therefore, use spherical trigonometry to calculate our lnav paths if we want to do it right. When going down this road, the relatively straightforward plane trigonometric relations go right out the window and not only do we have to use spherical trigonometry to calculate relations, but we also have to project the results onto the 2D EHSI display with minimal distortion, even at high latitudes. Here's an example. If you treat lat/lon as x, y values, then distortion would be least when taking lat/lon values near the equator so we'll use that as an example. If you were to calculate the true course to fly when flying from lon/lat: 10, 10 to lon/lat: 20, 13, then that comes out to a true course of 72.0 degrees from point 1 using spherical trig. If you treat lat/lon as x, y values though and use plane trigonometry, you would calculate that true course as 73.3 degrees. The distance between these two points are about 615nm apart and when you arrived, you'd be 13.6 nautical miles off course if you did not use the spherical relations. The problem gets even worse at higher latitudes and longer distances. This, of course, is for great circle navigation and not rhumb-line.

After making sure we have our angles and distances correct, we then have to use a projection algorithm to convert lat/lon to x, y values for display on the EHSI and no matter where the aircraft is on the earth, the EHSI display needs to always look "normal" where the x distances match the y distances. If the course to fly from point A to B is 72.0 degrees, as in the example above, then it needs to be drawn at 72 degrees on the EHSI display. This representation needs to be valid for higher latitudes and even the poles. By programming in a suitable projection algorithm, you can view a flight plan on the equator, step through the waypoints of a flight plan to a high latitude such as Norway and you will get a very "normal" looking representation of the plan on the EHSI all along the way.

Also, one of the more challenging spherical geometry problems to solve is determining when to begin a "fly-by" turn when transitioning from one leg to another. Given the known information in such a case, the quickest way to solve the problem is with what is called the "polar-cosine" formula. Such a formula can be solved in roughly 4 ways, 3 of which are analytical and cumbersome and one numerical. Of course since we are using computers, the numerical implementation is the way we go. We solve this by using what is called the "Newton-Rhapson" method. This is a very common method in programming when solving for the root of an equation where not only the equation is formulated in terms of one unknown, but also it's derivative function. With these two functions on hand, we then can utilize an iterative technique in code to converge on the solution very quickly.

So this is where our time is going at the moment. We are not stuck with bugs or problems, but simply dealing with a large volume of work. We are very happy we began with systems over most of the 3D as we are nearing the point of finishing all the majorly difficult tasks. Our hope is to run to the finish with lots of 3D work and progress imagery we can show. I would think it should be very nice to see progress shots and know that when the 3D is nearly finished, then the project is nearing completion.