Over on the X-Pilot forums, IXEG developer, Tom Kyler has released a lengthy post on the issues facing the VNAV profiles on the IXEG 737 Classic. Kyler then goes on to address how the issues are planned to be fixed in the short and long term in the future.

VNAV Issues have long plagued the IXEG 737 with issues surrounding the ways Navigraph and Aerosoft Nav Data represent departure and arrival data. To try and bridge these issues many covering patches have been put in place, but the development team has announced today that they are going to completely redo the coding for the respective SIDs and STARs VNAV systems.

The post opened with Kyler discussing the background history of the issues and how they came about, before continuing to discuss what is currently in place to try and patch the issues.

The developer went on to detail how he had to write an algorithm to collect information on all the different types of occurrences of data types in SIDs, STARs, Transitions and Approaches:

“I wrote a program to go through all the files and log each unique occurrence of a data type, i.e. "Star"  "Sid". "Sid_Transition", "Approach", etc.  After I had that list (because I couldn't find any spec), I set about programming the FMS....for a few years.  All was pretty well.  THEN....somewhere towards the end, we loaded up the same XML format dataset...but this time by Aerosoft, thinking "hey, lets support both providers, since there are plenty users of each"”

When nearing the end of the development of SIDs and STARs support, Kyler tested SIDs and STARs with Aerosoft Nav Data, but was faced with the issue that the format of Aerosoft Nav Data is of a slightly different format to that of Navigraphs offering, producing errors.

These errors resulted in Kyler coding in, what he called “band-aids”, to try and cover the flaws with the original coding, originally not designed with Aerosoft Nav Data in mind. Many of these so-called “band-aids” were put in place until Aerosoft data was compatible.

These band-aids did not cover all the flaws, as to the reasoning for the announcement for a complete re-coding of the system today.

The complete differences in the two data sets were demonstrated in the below screenshot of code written to originally deal with SIDs.

Further issues with differences between the two data types were explained below:

“Aerosoft uses a data type "RwyTransition" to denote a runway transition waypoint, whereas Navigraph does not.”

The developer continued to state that this is where many more issues started occurring when trying to support Aerosoft Nav data users.

Kyler explained further:

“Now when a user enters a STAR, and no arrival runway has been selected, then you'd expect to load those waypoints in the STAR that are not unique to runways, i.e. "common points".  If you're using NAVIGRAPH, you will note that each XML "block" is associated with a runway.  So if no runway is selected, we have no way of knowing which block of code to load for navigraph users.  If you're using Aerosoft, then I can load the STAR waypoints only (and not the transition waypoints)....except all my code was written for the navigraph formats....and trying to make this work "last second" ended up causing more code confusion and debugging difficult.  If I had a bigger picture of all these types from day 1, I would have written better structured algorithms.”

It is not all doom and gloom for IXEG users though, as Kyler went on to state that he can, and will, write better structures to deal with the differences.

Also mentioned was that the team are planning a possible move to the XP1100 dataset, claimed to be a lot better than their currently used XML formats.

“Looking at the code with clearer eyes and hindsight, I can see a few trouble spots that I can fix that should make this whole VNAV decent business improve significantly.   Indeed one or two poor lines of code can bring down the house and does for a few instances of entering STARS / Transitions.”

A temporary solution before the panned swap to the new Nav Data was explained below:
“We are going to add a new message to the CDU, which is NOT realistic, but required in our opinion to avoid confusion.  If you select a STAR that is associated with a runway, or has runway transitions, we will display a message "RWY SELECTION REQD".”

After lots of talk on SIDs, issues surrounding STARs were finally mentioned in the following statement:

“And finally....my code handling STAR transitions for these "runway transition" STARS was completely borked (by a poor band-aid), messing up the waypoint table and rendering any VNAV calculations / representation completely useless.   This is why some folks see good VNAV behaviour and others do not.   It is dependent on which route you are flying, which STAR type you select and whether or not you selected a transition. “

The developer concluded explaining that the CDU Message will fix the issue in the short term, but the ultimate swap to XP1100 Nav data will be the most durable plan for the long term.

The forum post can be read in its entirety in a post on the X-Pilot Forum.

For users who do not own the IXEG 737 Classic, it can be purchased for $74.95 from X-Aviation.