Jump to content

SIDS/STARS not interpreted Correctly By FMS. maybe an explanation.


Tchou
 Share

Recommended Posts

Hello, I wanted to report this the first time but I thought that it might not be an IXEG issue.

But seeing that others are reporting when the plane doesn't follow SID/STAR, I guess I might add my 2 cents...  

Here it is : 

The SIDS from UMMS runway 31, most of them include a right turn once reached 1300ft, 

SID31umms.JPG

GOVIK1BSIDPT.PNG

Let's take GOVIK1B, as you see you have to turn right from 311° to 241°

The FMS will discard the right turn and intercept directly to the left. 

As you see we are on runway 31 and the ND shows the line to the left.

on runway IXEG.JPG

I checked with another plane (FF763) which has been said on various youtube videos to have a good interpretation of Nav data, but as you see it gets fooled exactly the same way.

On runway FF.JPG

 

This made me think that the culprit with the mis-interpretation of navdata might be the navdata itself given the same results on two different planes from two different editors.

I guess the other topics about bad STAR or SID following might have their origin in the navdata itself.

 

 

 

Link to comment
Share on other sites

The problem is that the description of the SID is giving most FMCs a hard time. The SID was clearly coded for overloaded Soviet prop airliners - they would fly a few mile ahead until reaching 1300´, then have ample of space to make a right turn back to MNS and then track the VOR outbound.

Most twin-engine jets will make 1300´ (which is only 600´above the aerodrome!) within 1NM of starting their take-off run. Then they will never be able to circle back to MNS - they are simply still too close (turn radius is too big).

Of course a pilot will "know" what to do. He will pass south of MNS and then just keep turning until intercepting the radial. But an FMC is not smart enough (yet) - it will simply figure out that it can´t make the turn, BYPASS (disregard) the waypoint in question (MNS) and then happily go with the next task at hand (intercept R-241).

So in conclusion - correct behaviour by IXEG and FF, just one those "weird" SID´s that modern FMS systems still have problems with...

Jan

Link to comment
Share on other sites

17 hours ago, Tchou said:

Hello, I wanted to report this the first time but I thought that it might not be an IXEG issue. But seeing that others are reporting when the plane doesn't follow SID/STAR, I guess I might add my 2 cents...  
[...]
This made me think that the culprit with the mis-interpretation of navdata might be the navdata itself given the same results on two different planes from two different editors.
[...]
I guess the other topics about bad STAR or SID following might have their origin in the navdata itself.

Well, yes and no. There are several cases where procedures won't draw correctly by the FMS, some of them a general problem with more or less all X-Plane aircrafts, some specific to one or another model, some even specific to the IXEG B733. Let's have a look at those:

  1. Freaky (i. e. not flyable in accordance with the chart) procedures just like the one you dug up. This is indeed a very rare case, but with great potential of hitting a lot of aircraft models.
  2. Real world limitations. If creators of a model did a good job (and IXEG did!), you will probably hit some limits with procedures you wouldn't be allowed flying with a B733 in real world. This applies mostly to procedures marked as "TURBOPROP ONLY", or RNAV with RNP limits (ok those will work since X-Plane doesn't simulate RNP, you are always on spot where you are...).
  3. Procedures where nav data do not properly describe the procedure as per chart. In my flight sim beginnings they were quite common since procedural data quality then was not at the level it is today. Today you encounter this with rather esoteric procedures; I just caught one yesterday, seeing that the LOWS RWY 33 RNAV-V procedure data (at least with NDP) are missing the two final waypoints (ok that one's not sooo esoteric, but also not that frequently used). Programmers stand no chance capturing these errors, even with a sophisticated plausibility test (which would probably deliver more false positives than real issues).
  4. Blotted or imprecise nav data. This again is a quite common issue; for instance I would categorize all those virtual waypoints with imprecise fly-by / fly-over tags under this umbrella. Here the nav data allows the programmer to interpret what could be meant. Most issues I dug up with the B733 belong into this category; for comparison I usually check also with the FF B763 - simply because they seemingly coded around this issue and determine correct turn direction in most cases where IXEG doesn't (yet).
  5. Incomplete FMS implementation - just have a look at all the payware aircrafts with a FMS out there and count how many of them correctly deal with radial or alt interception, bearing/distance or bearing/bearing intersections, etc. There are more than just a couple only understanding FIX, VOR and NDB waypoints. OK this one doesn't touch IXEG so much; they announced the FIX page will be delivered somewhat later, so no limits on procedure oddities from their side :D
  6. Implementation bugs. Yes, they exist, too. Usually they're hard to find and prove, since you first have to understand the nav data and their correct interpretation. IXEG has made this a lot easier by moving to a very explicit nav data format. Trade-off: you have to scroll a lot in those XML files, but the readability is much better than any other format I came across so far. I only spotted on potential candidate for this category with IXEG yet, where the draft route shows correct routing, but EXEC blows the thing...

So for me this boils down to three simple things:

  • Yes, IXEG has done an exceptionally good job on LNAV so far.
  • Nav data for simming purpose will most probably never reach the perfection they would need, so as an aircraft developer, you will hardly be able to avoid implementing some work-arounds for the most common flaws (e. g. the fly-by / fly-over tag issue)
  • For the same reason, as a pilot you have to check what the FMS draws before EXECing it or even (auto)-flying it. When in doubt, fly the procedure as per chart by hand or using other modes (i. e. HDG and/or LOC) for lateral navigation.
  • Upvote 2
Link to comment
Share on other sites

In reference to the Hand Flying comment...I think many a simpilot confuses the the hand fly with Navigation

Navigational mode and "hand flying" are mutually exclusive.

This example highlights that, this departure requires you to use Nav radios and not the GPS system to navigate to the point so that you are direct GOVIK on R241 MNS.

The fact that you "hand fly" or use your AP via heading mode then VOR LOC is inconsequential. That notwithstanding, one should be hand flying this dep really.

All the map really needs to display (similar to a Vectors Dept) is the route starting post GOVIK for us simmers, so to daemotrons point:

" Nav data for simming purpose will most probably never reach the perfection they would need, so as an aircraft developer, you will hardly be able to avoid implementing some work-arounds for the most common flaws "

This is very salient here. There is such a thing as the laws of diminishing return, how much time energy and effort will it take to draw a line that in all reality is not required for Sim pilots.

In my opinion...lets let them focus on larger systematic weakness such as in the VNAV.

Edited by stealthbob
Link to comment
Share on other sites

3 hours ago, stealthbob said:

In reference to the Hand Flying comment...I think many a simpilot confuses the the hand fly with Navigation

Navigational mode and "hand flying" are mutually exclusive.

No, they aren't. The lateral navigation mode only determines what the flight director bar indicates. It's up to the pilot to either have the autopilot follow the flight director automatically, or follow the FD by manual control inputs. Of course you can also ignore the FD or switch it off.

3 hours ago, stealthbob said:

This example highlights that, this departure requires you to use Nav radios and not the GPS system to navigate to the point so that you are direct GOVIK on R241 MNS.

<nitpick>
The B733 doesn't use GPS directly for navigation. You're probably referring to RNAV (which I agree is not appropriate since the procedure sampled by Tchou is not an RNAV one. RNAV uses the two inertial navigation systems as primary source, updating/correcting the position by GPS and radio navigation inputs
</nitpick>

But I don't get yet what you're up to, nobody suggested flying this procedure under RNAV conditions so far...

3 hours ago, stealthbob said:

The fact that you "hand fly" or use your AP via heading mode then VOR LOC is inconsequential. That notwithstanding, one should be hand flying this dep really.

Again, the AP (if engaged) will simply follow FD guidance, independently of whatever lateral navigation mode the FD is using. I agree that a procedure beginning with a 270° turn below acceleration altitude is something that would normally be flown with manual control inputs. Nobody disputed this. Just consider what Jan said: With a loaded aircraft just after takeoff, your minimum maneuvering speed will most probably not allow you to catch the relatively narrow radius drawn on the chart, but will force you to fly a circle that will have you intercept R241 MNS not exactly at MNS, but further south-west of the VOR. This has nothing to do with lateral navigation mode or autopilot engagement, but simply with physics.

3 hours ago, stealthbob said:

All the map really needs to display (similar to a Vectors Dept) is the route starting post GOVIK for us simmers, so to daemotrons point:

" Nav data for simming purpose will most probably never reach the perfection they would need, so as an aircraft developer, you will hardly be able to avoid implementing some work-arounds for the most common flaws "

This is very salient here. There is such a thing as the laws of diminishing return, how much time energy and effort will it take to draw a line that in all reality is not required for Sim pilots.

You probably want to read Tchou's and my previous post again - we were both referring to a whole bunch of reported LNAV issues, among them some referring to RNAV procedures, and not just the example given above. In reality, navigation data sets used in aircrafts are double- and triple-checked to ensure that data flaws don't mess with the FMS. However this quality doesn't sell for less than 40 US-$ per 12 cycles. So even this is not in line with reality, in virtual aviation the aircraft developers are left to deal with that problem. This doesn't mean one needs to program around any eventual problem with nav data. Capturing most common flaws however is something you want to take into consideration.

3 hours ago, stealthbob said:

In my opinion...lets let them focus on larger systematic weakness such as in the VNAV.

Hm, that's again a question of philosophy - seeking perfection in one feature and tackling others afterwards, or try reaching an acceptable level (whatever that means) for all features concurrently. And btw. since IXEG is a team seeking realism at a really great level, it's up to them to stop discussion about LNAV inaccuracies the moment they want it.

Link to comment
Share on other sites

On lundi 16 mai 2016 at 5:19 PM, Litjan said:

The problem is that the description of the SID is giving most FMCs a hard time. The SID was clearly coded for overloaded Soviet prop airliners - they would fly a few mile ahead until reaching 1300´, then have ample of space to make a right turn back to MNS and then track the VOR outbound.

Most twin-engine jets will make 1300´ (which is only 600´above the aerodrome!) within 1NM of starting their take-off run. Then they will never be able to circle back to MNS - they are simply still too close (turn radius is too big).

Of course a pilot will "know" what to do. He will pass south of MNS and then just keep turning until intercepting the radial. But an FMC is not smart enough (yet) - it will simply figure out that it can´t make the turn, BYPASS (disregard) the waypoint in question (MNS) and then happily go with the next task at hand (intercept R-241).

So in conclusion - correct behaviour by IXEG and FF, just one those "weird" SID´s that modern FMS systems still have problems with...

Jan

 

So that means that on a real 733 EHSI we could see this ?

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...