tkyler

Thx, specific experiences / routes vs expectations regarding these altitude restriction issues are very good data points for me. Thx for the input. -tkyler

This is a lengthy post, explaining our VNAV situation, or at the least, how we arrived where we are today, and where we're going from here. This is a tale of how being too ambitious and trying to be all things to all people bit us and our customers. In the beginning was nav data in XML format....whether other formats were avail in the beginning, I don't know, I only know this was my beginning because I inherited the FMS work and this was the dataset that landed on my plate. It was from Navigraph. The first thing I did when I started was to open up a few XML files to get the lay of the land. I noted several differing "types" of data like so: and decided I needed to know every single type in the dataset so I could design algorithms around it. So I wrote a program to go through all the files and log each unique occurence 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". ...and for a while things were good; however, we started seeing some issues related to the fact that Aerosoft had additional XML types that Navigraph didn't have...and for which I didn't have code to handle. So I started throwing up 'band-aids' to get the Aerosoft dataset integrated....which would lead to some anomalies for Navigraph users...OK...a few more band-aids ought to do it. And this went back and forth until I had all 10 fingers plugging up holes in the dike. But turns out I needed a few more fingers....OR a more robust dike (hint...that's where this is going). Over time, we'd see bug reports for navigraph users that aerosoft users weren't seeing and vice-versa. Without exception though, the most obvious problem spot was in "decent FMS entries", i.e. STARS, Star transitions, etc. Entering these procedures were frought with all sorts of bugs and gizmo crashes. For online users who frequently enter these procedures in the air, as they approach their destinations, this simply was a deal killer. So...fast forward to today when I'm revisiting the FMS code from a much higher level and seeing that these band-aids just didn't cover the wounds well enough. So..case in point. Here is how Aerosoft and Navigraph each represent STARs with runway transitions, specifically KBOS. Aerosoft uses a data type "RwyTransition" to denote a runway transition waypoint, whereas Navigraph does not. This is where things went south originally when we tried to support Aerosoft users late in our development process. Now when a user enteres 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. The good news, is I can see it better now and CAN write better structures; however, better than both these XML formats is the XP1100 dataset that we plan to migrate to in the future. But there is still more good news. 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 instantces of entering STARS / Transitions. 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". While Aerosoft has the necessary common points separated so as to load those without a runway selection, recall my code was not orginally written for it, and so for the moment, I am not going to create a fork to handle it just yet. Knowing we are switching to XP1100 navdata format, I'll have to gauge the effort of accomodating Aerosoft's transition points differently than the Navigraph data vs the effort of just focusing on the XP1100 integration. It could be, that accomodating Aerosoft's transition points is not so difficult...and in this case, a user could select a STAR and STAR transition without having an approach selected; however, Navigraph folks, we simply need to know the arrival runway before we can load up these "runway transition" STAR types. For STARS that are NOT associated with a specific runway, but serve all runways, this arrival runway selection is NOT required before STAR selection. Many times users don't notice that the STAR they are selecting are unique to a runway (and subject to the case described here) and so in the course of their simming would see inconsistent behavior with STAR selection as they flew differing flights around the globe. This "RWY SELECTION REQD" message will let them know. 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 calcualtions / representation completely useless. This is why some folks see good VNAV behavior and others do not. It is dependent on which route your are flying, which STAR type you select and whether or not you selected a transition. I believe this CDU message will fix a lot in the interim, but ultimately the swap to XP1100 nav data format, with its consistency and basis in ARINC 429, will be our final and most durable solution. Aside from the issue described here, the other glaring issue is the waypoint altitude restrictions. We will be attacking those soon enough and with clearer eyes, I expect to get this cleaned up also. -TomK

so digging a little deeper, I now recall why I had that line of code in there...and why we need to switch over to the XP1100. nav data format. The problem is the XML format we use does not represent "common" portions of STARs such as is found at KBOS. In this particular example above, the STAR serves 'all' runways, indeed that is the exact word the XML format uses for this star..."ALL". BUT at an airport like KBOS, a STAR will serve a bunch of runways and perhaps only the first few points of the STAR may be common before it diverges to specific runways. So if a runway was NOT selected, but a STAR was, then you would at least expect the common points to load; however, the XML format associates waypoints with runway identifiers in this case...and without a selected runway, I don't know which XML block to load. There is an extremely cumbersome workaround of trying to extract the common points, but it is not worth the effort IMO, and switching to a more realistic data format is the prudent solution....putting a giant band-aid on what we have is not the way to go. SO....what this means is when you select this type of STAR, that is associated with specific runways (as opposed to ALL runways), then we will pop a CDU message saying, SELECT RWY FIRST". When you do this, then you can select a STAR and it will load the STAR associated with the runway selected...inlcuding the "common points". Then, as mentioned above, you can select a new runway after you know which one you'll get, but at the least we'll avoid these gizmo erros ruining the flight. We avoided this message earlier because it simply wasn't like the real FMS, but neither is the nav data format and so its finally time to compromise. Unsure if we'll get this into the next patch...as we want ample time to test it. Certainly entering the runway first now before selecting stars is a good protection. -tkyler

Not necessarily. If you dig into your fmc_data > SidStar folder inside the IXEG folder and pull out the ENGM.xml and EDDU.xml files and post them here, I can try to reproduce this with your exact dataset. It is definitely worth trying to reproduce for me as I would not expect that bypass calculation. -tkyler

For the life of me, I have a line of code that says, "if the arrival runway is selected, append the star transition points". I remove that condition and everything snaps into place on this particular procedure (still a tweak to RTE page required though). I can't recall what kind of situation made me put that in all those years ago (though I'm sure some other user will find it). Transitions were particularly challenging given the XML dataset I originally started with, that I do remember...and one provider had runway transitions and another didn't. Things seem to have leveled out over the years, but this old code remained. I can only wonder how this may clean up other calculations on the descent side of things.

So I have recreated it....and will take a stab at it. This one rears its ugly head from time to time and I'd love to get it fixed (as would everyone else I'm sure!) -tkyler

This is one of the major areas that will be fixed by switching to the XP1100 navdata set. The XML data format does not delineate between the "runway transition" portions of a STAR vs the common portions very well at all. If you enter a STAR and the runway isn't entered yet, then ideally it should either 1) load the common part of the STAR, until the runway is selected or 2) let you know that a runway selection is required. (which does exist in some cases) The XML format we use is proably 15+ years old and just not the most flexible format. While this can be coded around, the code turns in to bloat very quickly with this XML format. I can't wait to move from it. Maybe I'll think of something clever or have some aha moment to get this to work with this format until then. -tkyler

Also....those who have the Gizmo Error when entering a PBD waypoint....FWIW, that message results when entering a PBD and the reference waypoint isn't in the Database for whatever reason. I have since fixed that for the next patch. Being as we're now dedicating development time to the FMS again, we will be endeavoring to organize our error handling much more gracefully. -tkyler

I don't know what P/GVA is, but that could have something to do with it...log file definitely shows it doing a lot regularly and it does precede our issue. All our GUI interface code is event driven and uses the same function to process clicks, only receiving differing "constants" depending on what is clicked. I have never seen our "widget code" attempt to index a nil value. I too, would be very interested to see if you could reproduce it. I haven't the slightest idea...I tried recreating your pref settings, then went to town clicking everything I could to no avail. -TomK

Definitely on the short list. I'm working on the remaining user waypoint code even now, to include the fix page. -TomK

ALS is the first point of the enroute portion, but looks like you have several points before that (being your on page 3). Did you select a SID? or insert the points manually? If you can give me all the individual waypoints up to ALS, that would be helpful. Those distances are large enough that I wouldn't expect a bypass...indeed do not get one with the dataset I'm using. (Navigraph 23 Apr 2020).

Certainly we'll look into this. FMS work is ramping up and focusing on these things is "front and center" for us. Thanks for your report -Tom

I need to organize my error checking messages better and also supress them better for sure. i apologize. I'll be working on this straightaway along with the other user created WPs, which are part of the whole process anyhow. -tkyler

GCRR/03 is not a valid format. PBD means "Place Bearing / Distance, i.e. "text number / number". You have Text / Number The error message, unfortunately arose from a debug message I use. When I test for 'invalid formats', I want the console to pop up, but I should display "invalid format" or "not found" on the CDU for you guys and suppress the message so you can keep using the CDU. I'll make that adjustment for next release, my debug code is in the "wrong spot" for final users and causing this error when a Waypoint isn't found or a user created waypoint is wrong format. -tkyler

so the 1.31 update has gone out, with the objective being to stabilize our "get back to where we left off with the new toolchain, but conformant to XPlane 11.5" update. Assuming we don't have really big show-stoppers, it is now time to start moving foward rather than just get stable. We have a few things we'll be working on simultaneosly from this point on. With an eye on X-Plane 12, we'll be working on swapping our sounds to the FMOD sound engine. This is a compatibility move, moreso than changing the way our sounds are played because we quite like our sounds. In addition, we'll be working on incorporating particle effects in spots. On the 3D front, the 3D changes will begin with the galleys, cabin and cabin doors and after that wing flex. On the FMS side, first up will be the remaining user-created waypoints, (PB/PB, ATD, LL), then probably VNAV work, including PROGRESS page predictions.. A better VNAV algorithm will make programming holds a bit more predictable and so HOLDS will be after our VNAV work. Once all that is working reasonably well, then we'll look at porting our navdata over to the XP1100 navdata format....which will probably be after the XP12 release and be a pretty heavy FMS rewrite. Thanks for the support and patience, its time to starting improving things again. -TomK

that wreaks of HDR processing not working....but can't speak as to why as of yet. -tkyler

So we got PBD user created waypoints in for 1.31....we'll set about getting the others, including LL for the next update. -tkyler

all fixed and covered elsewhere in the forums. They'll be included in the next update, which we're finalizing presently. -tkyler

It is more difficult than it appears yes. variation in winds alone change all predictions. If you have a 200kt headwind and are flying with thrust for 200kt, you'll go nowhere an burn all your fuel. . If you climb vertically while doing it, your fuel burn rates will change, complicating gthings more..and if the wind speed changes as you climb, it gets even tougher. The real FMS uses a "step integration method" for prediction.....and the only way that could ever be accurate in X-Plane is if we had access to the real performance database of the aircraft...which we don't as its proprietary. So we have to use a few heuristics and our own test data, that I'm sure we can improve upon, but its not as straightforward as it looks. We'll revisit that aspect of the FMS also -tkyler

They shouldn't.....none of the dataref names or 'state values' have changed...only the manner of manipulation in VR and with the mouse. Things should work fine with Smart-Copilot -tkyler

Looks like the scripts are choking on missing sounds , or so it thinks. Are the sound files indeed missing from the folder specified? -tkyler

this is FYI only, in case you're curious.....without a doubt, the speed is too great (bigger turn radius, earlier turn point, later rollout point) to finish the turn before passing KK371, but probably just barely.....and I suspect that our bypass code isn't being run since the next waypoint is a runway, which is a bit of a special case waypoint. I will revisit our bypass code to check it out and under what conditions it runs, but it does need to run and would fix this issue. -tkyler

What dataset is this? Aerosoft or Navigraph. and what cycle? Agree the loop shouldn't be there; however, it is probably a bypass situation, which the FMS is supposed to handle, indeed ours is normally very good about it. Those two waypoints are probably too close together to make KK371 at 170 knots when you shortcut to 'VAXOB', so lowering the speed is quite appropriate since you altered the published procedure. If you shortcut at KK501, you probably won't see the issue. Procedures are generally designed so that they can be flown without bypassed waypoints, so when you modify them, it is possible to get unexpected results (but not a circle...the FMS should bypass KK371. -tkyler

anyone who has this problem, pleast note in your post what FMS page you were on when you had the problem. It will speed our fixes. Thx.