Jump to content
Sign in to follow this  
Richard McDonald Woods

Unable RTA

Recommended Posts

The limits set for RTA seem to be very tight.

 

I set the RTA for a waypoint which is 1900+ nms away as 18:09, but when it is calculated that I will cross at 18:09:50 I receive the Unable RTA message.

 

Is this realistic? If so, what are the limits to this?

 


Cheers, Richard

Intel Core i7-7700K @ 4.2 GHz, 16 GB memory, 1 TB SSD, GTX 1080 Ti, 28" 4K display

Win10-64, P3Dv5, PMDG 748 & 777, Milviz KA350i, ASP3D, vPilot, Navigraph, PFPX, ChasePlane, Orbx 

Share this post


Link to post
Share on other sites

Is this realistic? If so, what are the limits to this?

 

Was it calculated that you'll cross that waypoint at 18:09:50 prior to you setting the RTA, or after?

 

Remember that, while at altitude, your max and min speed aren't too far apart. That being said, if you're in the higher altitudes at which the aircraft can cruise, you can't speed up or slow down too much. Of course, with distance, a small change in airspeed can have a larger impact, but there's only so much that you can do.

 

For the sake of argument here, I'm going to use GS instead of airspeed. Since they're linked, it's not an unfair comparison. You min speed is 470 and your max is 500. You're cruising at 485. Your original Time Over Fix (1000nm away) is 0203.7Z (123.7 minutes), which means the current time is 0000Z.

 

If I tried to set an RTA of 0207Z (127 minutes), this would be okay. The resultant speed to cross that point in 127 minutes is about 472 knots, which is above the minimum. Setting it one minute more (to 0208Z), however, would result in 468 knots, resulting in an UNABLE RTA (and I believe the FMC would give you a closest-to-RTA value of 0207.7Z). The same thing would happen on the max side. So, depending on the situation, the "margin" might appear rather slim. A single minute is all that stands between an acceptable and unacceptable time value.

 

 

 

The thing to remember, here, is that RTAs aren't pilot-assigned. RTAs come from ATC, and the values are calculated out by the trajectory systems. It isn't some best guess metric that a lot of people are using in the sim here. In other words, how did you come up with your RTA value?


Kyle Rodgers

Share this post


Link to post
Share on other sites

Hi Kyle,

 

Many thanks for your usual comprehensive reply. Much appreciated!

 

No, to your first question. My flight plan, KJFK-CYVR, said that I would cross at 04:02 after takeoff, so I just did a little bit of advanced maths and got the expected crossing time for MLP of 18:09z.

 

I understand that RTA is used by ATC for aircraft sequencing, particularly on oceanic crossings. I was playing with RTA just to see how the commanded IAS would be set.

 

Thanks for your help.

 

Cheers, Richard


Cheers, Richard

Intel Core i7-7700K @ 4.2 GHz, 16 GB memory, 1 TB SSD, GTX 1080 Ti, 28" 4K display

Win10-64, P3Dv5, PMDG 748 & 777, Milviz KA350i, ASP3D, vPilot, Navigraph, PFPX, ChasePlane, Orbx 

Share this post


Link to post
Share on other sites

 

 


No, to your first question. My flight plan, KJFK-CYVR, said that I would cross at 04:02 after takeoff, so I just did a little bit of advanced maths and got the expected crossing time for MLP of 18:09z.

 

Gotcha. I'll take a look again tonight and see what I can find. I remember trying to break it in the Beta, but haven't used it since.


Kyle Rodgers

Share this post


Link to post
Share on other sites

Yeah, I tried to break it in beta and succeeded and commented but apparently got buried in all the other things we were focused on. I recall a typical KIAH-PHNL trip and I didn't set the RTA for DENNS, which joins the MAGGI arrival, until I was about two hours ETA at the fix.  I set the RTA for 10 min later than the ETA and the FMS responded accordingly by adjusting cruise. The problem didn't arise until the last airway fix before DENNS, where upon passing the UNABLE message appeared. As reported by Richard, there was a very tight margin for RTA and I cancelled by setting a 0.84M cruise and continued on to the fix crossing it within a minute of my original RTA.

 

I should have ran more tests, and I should have pushed my finding but I moved on to other things.  Bottom line, I could recreate same symptom Richard is reporting in a different scenario.  My workaround is to use RTA until close enough to make the fix 'manually.'


Dan Downs KCRP

Share this post


Link to post
Share on other sites

We used to get crossing restrictions in to YYC (Calgary) all the time due to the configuration of the runways (or lack thereof) and the amount of traffic (dinner rush).

Share this post


Link to post
Share on other sites

Gentlemen,

 

I can now report the experiences of setting RTA for crossing MLP (Mullan Pass) from my completed flight into CYVR from KJFK. I accept that RTAs are normally only used by ATC to improve traffic flow.

 

At around 16:30z, I set my RTA as 18:09z, and the RTA page of PROGRESS showed to achieve the restriction the A/P commanded RTA SPD as .842M, with a maximum speed of .850M.

 

At 17:40z, the commanded airspeed had increased to .85M to cross MLP at a calculated 18:08.2Z, presumably only for wind variations.

 

I crossed MLP at 18:08.6z!

 

Really rather good, don't you think?

 

Cheers, Richard


Cheers, Richard

Intel Core i7-7700K @ 4.2 GHz, 16 GB memory, 1 TB SSD, GTX 1080 Ti, 28" 4K display

Win10-64, P3Dv5, PMDG 748 & 777, Milviz KA350i, ASP3D, vPilot, Navigraph, PFPX, ChasePlane, Orbx 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

  • Tom Allensworth,
    Founder of AVSIM Online


  • Flight Simulation's Premier Resource!

    AVSIM is a free service to the flight simulation community. AVSIM is staffed completely by volunteers and all funds donated to AVSIM go directly back to supporting the community. Your donation here helps to pay our bandwidth costs, emergency funding, and other general costs that crop up from time to time. Thank you for your support!

    Click here for more information and to see all donations year to date.
×
×
  • Create New...