Jump to content
Sign in to follow this  
vonmar

Cycle 0704 KATL SIDs

Recommended Posts

Terry,At first I did not know where the problems were.With the SIDs and or Level-D's FMC or whatever?Each had to be sorted out.After sorting a few things with you and Dan, I wanted to use (INT)to program the conditional waypoint. I figured if one SID couldbe fixed they all could be fixed in the same way.I knew (.int) would fly any heading, capture the the fake radial, then fly to the waypoint "on the selected radial". I initally selected40 degree HDG to intercept to see what the Level-D's FMC would do with the new procedure instruction and values.I picked 40 degrees as at test. Assuming airport elevation is 1000' and the turn altitude was only 1500', RWY08L runway is 1.7 miles long. We would barly pass the end before reaching 1500' and starting the left turn on 072 HDG to HRSHL.So, I picked a 30 degree intercept angle (040) to fly to get onto the 072 HDG required heading (R-252 from HRSHL) to HRSHL.I assumed, what if:If the pilot flew RWY HDG too long before turning left to interceptthe 292 radial .... I figured 040 would get him back on track.Anyway, the FMC liked it and I knew we could work the SIDs now.*********************************************************************Later I went back and used 092 ... your initial value and it also worked to intercept the R-252. So, just using .INT was the solution with the Level-D's FMC and the SIDs.************************************************************************For BRAVS4 and other KATL SIDs:The speed restriction it is "until passing" HYZMN or ZALLE etc.ATC wants the departing flights on the "inner" route to BRAVS at <=250then they only have to assign speeds to pilots flying the "outer" routes so everyone does not arrive at BRAVS at the same time.Safety too, the inner tracks do not want to overshoot the departureheadings ... sharp turns ... lateral separation.**********************************************************************The speed is inserted where you have normally put it in the procedures:eg. HYZMN250It tells the Level-D's FMC not to go faster than this until past HYZMN. **********************************************************************


Best Regards,

Vaughan Martell - PP-ASEL KDTW

Share this post


Link to post
Share on other sites

Terry,I tried programming a .VRI radial interceptfor the procedure two ways. This is theone your program was using.1. Using HRSHL waypoint as the radial fixThis would not work ... crashes the FMC2. Using ATL (vor) as the radial fix insteadof the HRSHL fix waypoint.Using a real vor worked well but you haveto figure out the radial you want to cross andthe procedure does not specify using a vor.But, I told the procedure here to get the ATL 045 (3 digits to define bearing instead of two)radial the direct HRSHL.ATLVorRadialIntc33.629069-84.435069000at192 45AutoHRSHLNormal33.682769-84.279567000atFly-byAutoIt worked.3. Using the and using the 252 radialfrom the fake vor, waypoint HRSHL.It worked.Advantage here: It agrees with the procedure andyou do not have to figure out which real worldvor radial to cross.Note:Still have not got my taxes done, DARN!


Best Regards,

Vaughan Martell - PP-ASEL KDTW

Share this post


Link to post
Share on other sites

Although RNAV procedures often provide bearings between waypoints, in reality they are flow as RF (route to fix) legs and that's how I program them.In this case, BARVS4 Rys 8L/R, a track (092) is flown until altitude (1500) then direct HRSHL thence as charted. The significance of the altitude is only that that is the minimum safe altitude (~500 AGL) at which the turn to HRSHL should be commenced. Having some experience with how these are designed (TERPS procedures), I am confident that the intent is not to maintain 092 until intercepting 070-072 track to HRSL; rather: TRK 092 UNTIL 1500 FIX HRSHL FIX ESFOR FIX ESTWU FIX ESTUS is the correct PMDG instruction.I'm sure that the design of the departure is such that obstruction clearance and traffic separation is assured from the runway to HRSHL at any altitude above 1500, which must be achieved at the specified 500 ft/nm, thence standard minimum climb angle.RNAV procedures always seem to provide a waypoint where a change in track is intended, I have not seen one that requires a TF (track to fix) leg (but I haven't seen them all).


Dan Downs KCRP

Share this post


Link to post
Share on other sites

Ya,That is the easiest way to get the SID procedure done. I mentioned that in my original post.But, Terry is following the procedure which does give a turn to heading to the first fix, after that, then per the plate, by dipicted (direct) route. The advantage is, no matter when you reach the restricted altitude (early/late) you will always end up flying the plates HDG to the first fix.This method does require one more programming step to generate the SID. I flew it times and the aircraft will be right on the plate heading to the first fix. Accurate!When DIR to the first waypoint is used, the heading to the first waypoint is "different" each time.On these departures I would prefer Terry's method of getting there.


Best Regards,

Vaughan Martell - PP-ASEL KDTW

Share this post


Link to post
Share on other sites

Dan,It my understanding that from an ATC point of view they do not control the RNAV guys. They expect they will be on heading/altitude (per procedure) for the entire route. From departure to ILS.The non-Rnav flights must be constantly vectored HDH/ALT to keep the route safely separated.If a controller gives an Rnav pilot a direct to a fix, that just blew away the Rnav route/plan ... he is on vectors from now on and controlled from that point on.That is why the Rnav procedures must be "right on".


Best Regards,

Vaughan Martell - PP-ASEL KDTW

Share this post


Link to post
Share on other sites

<>I don't agree... but it's a moot point. If they are flying RNAV1 accuracy (per chart) they are allowed an RMS Error of +/- 1 nm.. I've seen comparison pictures of the vectors vs RNAV departures at DFW (in Aviation Week & Space Technology), and believe me the tracks have a scatter although the RNAV tracks are "tighter." Anyway, an allowable error of 1 nm means your TF vs RF tracks are equivalent in this case. Either works... why not keep it simple.By the way, the controllers are monitoring the RNAV flights, as you suggest, but I've never heard one admend the clearance to fly vectors for the reason you give. Usually it's a gently reminder such as, "are you on the braves four?" (I've been flying since 1974).


Dan Downs KCRP

Share this post


Link to post
Share on other sites
Guest staang

Good morning Vaughan,>1. Using HRSHL waypoint as the radial fix>This would not work ... crashes the FMCThis a interesting. I am looking at the ND now (plan mode) with the BRAVS4 with 08L programmed in and it perfectly displays the DP. Actually all the runways worked. The climb is there and the interception of "radial" 252 is there. I don't understand why the DP works on my 767 and not yours. I reloaded the aircraft I downloaded yesterday to insure I was fully up-to-date and I loaded the procedures that I downloaded from my site this morning.>2. Using ATL (vor) as the radial fix instead>of the HRSHL fix waypoint.Problem here is that the radial from the VOR to HRSHL most likely would not match the 072 course because the top of the climb is at an unknown location that probably would not fall on the VOR radial. Plus if it did match for one runway it wouldn't for the other. And for sure it would not work for all of the runways. I am rethinking my stance here. As displayed on the ND the top of climb and the radial interception point are very close. If the climb is less than what is calculated by the FMC it would be possible for the aircraft to fly beyond the interception point before reaching the TOC. It would then miss the interception entirely. I may just do what you want and use the direct to fix method at KATL but let me ask around some more.>Still have not got my taxes done, DARN!I hope they are simple for you. Hmmm, today is 14th and Sunday is 15th. I wonder if the deadline is extended to Monday. Oh well, an extension would work.....regardsTerry

Share this post


Link to post
Share on other sites
Guest staang

Hi Dan>Although RNAV procedures often provide bearings between>waypoints, in reality they are flow as RF (route to fix) legs>and that's how I program them.The TOC and interception point of the course to the fix is very, very close as displayed by the ND in plan mode. They are so close I can see that there may be a possibility that the TOC may go beyond the radial intercept point and therefore not be able to do an intercept. I am now leaning towards using , as suggested, a direct to fix. I'm thinking in this case that the resultant course would still be very close to the published one. I want to poke around a little more though.Thanks for your help.Terry

Share this post


Link to post
Share on other sites

Terry,You said , What is the ND?Are you using Level-D 767 aircraft for testing?On your procedure using Radial (HRSHL), when that loads into the Level-D, that waypoint displays like: x**%3@>&$ , basiclly really junk text to discribe the waypoint looks like on the FMC screen. Other waypoints display and plot on the screen just fine. This happens with each of those type radial entries.I have to say again, I am not a programmer. I can only tell you what I see when the procedure is loaded. Maybe there is a missing "thing" like a special character or whatever in the procedure ... I do not know.If you like you can e-mail me the begining of the procedure, end it after the first 08L part of the procedure, and I will test it and report back. vbmartell@comcast.netBetter yet, if you live in the US, I will call you and we could quickly finger poke a few things and I could tell you what I see.E-mail me and I will send my phone number if you would rather call me.Whatever I can do to help I will.


Best Regards,

Vaughan Martell - PP-ASEL KDTW

Share this post


Link to post
Share on other sites
Guest pwyll

Hey terry,I found that the THRSR4 depature has the THRSR waypoint north of the airport and in my FMC it says a heading of 017. Its suppose to be south of the airport. I thought this seem to be weird. So i removed it from my FMC and re-entered it and it popped up where it should be south of the airport with a 167 degree heading from ZALLE. I took a look at the XML file but i have no idea how to fix the problem. Looks like you need to update this slight problem or pilots will be getting yelled at by ATC as to why are they going north after ZALLE??. lolMatthew

Share this post


Link to post
Share on other sites
Guest staang

Hi Vaughan>You said , >What is the ND?Navigation Display which is referred to as the EHSI in the Level-D manual. >Are you using Level-D 767 aircraft for testing?Yes>On your procedure using Radial (HRSHL), when that loads into>the Level-D, that waypoint displays like: x**%3@>&$ Are you using the KATL update I put up yesterday late? I am not getting what you are.>If you like you can e-mail me the begining of the procedure,Just download the KATL update from my site and you will have what I am using.>Better yet, if you live in the US, Yup, in Teaxs.>E-mail me and I will send my phone number if you would rather>call me.I have free calling any time, anywhere in the US so unless you have the same I could call you but first lets see what happens when you verify you are using the update from my site, filename LDS_Update_A.zip . Just make sure it unzips to the navdata folder and overwrites the old KATL.xml file.Terry

Share this post


Link to post
Share on other sites

Terry,E-Mail me and I will give you my phone number.Good, you have level-D 763.My FMSCDU shows the following when the BRAVS4 SID is loaded:092 (1500) 092HRSHL250/9%'10@@@0p/ (until it runs off the display)HRSHLThe EHSI displays tries to display correctly:The correct route is there but the datatag info on the displaylooks like the above trash line above.I am using the 0704 revision (A) downloaded from planepath.comIs that the wrong one?Where do I go to get it? Then I will try it first.Now that I know you have the Level-D we could try a few few things on the phone looking at the same displays at the same location and get it fixed quickly.I have free calling USA also.


Best Regards,

Vaughan Martell - PP-ASEL KDTW

Share this post


Link to post
Share on other sites

Terry,I found the ZIP on your site.I will test it now.I took a quick look at BRAVS4I noticed you are using <.INT> instead of <.VRI>It should work.I try it right now.** My sister lives in Amarillo ... we are neighbors!** Got my taxes done ... free to do whatever you want.


Best Regards,

Vaughan Martell - PP-ASEL KDTW

Share this post


Link to post
Share on other sites

I looked at Bravs4No problems with the display or route using the <.INT> GREAT!No speed restrictions ... but ok .. they can be edited in with Notepad later.Actually, you cannot save the speed restrictions when programming from the FMC CDU anyway.Previous post here mention THRSR north of the airport ... Yep, the procedure LAT?LON does point north and the route tracks that-a-way.How do these wrong LAT/LONS find there way in?Side Note:It was my understanding that the conditional waypoint using <.INT> will intercept then also track the radial.Whereas <.VRI> would track commanded heading to intercept the radial and then proceed straight through it. I have always had to use a VOR as a non deleted anchor to get this one to work. Then it displays properly on the ND ...Anyway, need me to test, phone, whatever ok ... as always, no charge.


Best Regards,

Vaughan Martell - PP-ASEL KDTW

Share this post


Link to post
Share on other sites

I noticed some SIDs are using <.int> and some use direct to next wp.JOGOR needs two WP in the transition: GUNDE & MAPEE.


Best Regards,

Vaughan Martell - PP-ASEL KDTW

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...