NAT's, FlightAware and NavData

[Jgid 0]

Hi- If this topic is in the incorrect place, please move it.

 

I rarely fly across the north atlantic, and when I have in the past, I had no issues. I would like to attempt another in the T7, but I am having some problems. I understand how the NAT system works for the most part, with entries and exits, etc.

 

I am using PFPX, and the my first issue is the track messages only showing a single entry point, and not the pair that I have seen in the past on track messages. Has the procedure changed for flying the NAT's that now only requires flying to a single waypoint before entering the NAT?

 

Problem #2 comes with my charting. I am using a Navigraph charts subscription, and the north atlantic charts that come with that. I am finding that the NAT waypoings are not showing on the charts. When flying the NAT's in the past, they have always been there. (The charts are up to data) When I look on skyvector, the exact opposite is the problem. I see the waypoints for the NAT's, but not the ones on the navigraph chart.

 

Problem #3 deals with using flightaware for the route. I prefere to use flightaware to get the real world route for the flight I am flying, but I am seeing a difference in what NAT is filed, and the waypoints that are being flown. For example: NATV would be filed, but the waypoint directly before NATV would be the entry point for NATU.

 

Lastly, if I forget the chart and flightaware, and just fly the NAT, many of the waypoints for the NAT are not in the FMC database. I am using Navigraph 1313. Would updating the database solve this problem? Do the waypoings for NAT's change on a regular basis?

 

Thanks for the help, and once again, please move this if in the wrong location.

 

[scandinavian13 5,192]

 

 

I am using PFPX, and the my first issue is the track messages only showing a single entry point, and not the pair that I have seen in the past on track messages. Has the procedure changed for flying the NAT's that now only requires flying to a single waypoint before entering the NAT?

 

NATs only really have one entry point and one exit point, despite there being multiple transition fixes to those entry/exit points.  Could you be more specific?  I'm confused as to what the issue is on this one.

 

 

 

Problem #2 comes with my charting. I am using a Navigraph charts subscription, and the north atlantic charts that come with that. I am finding that the NAT waypoings are not showing on the charts. When flying the NAT's in the past, they have always been there. (The charts are up to data) When I look on skyvector, the exact opposite is the problem. I see the waypoints for the NAT's, but not the ones on the navigraph chart.

 

I'd take that up with Navigraph.  Are you sure it's not a formatting issue?  The NAT entry/exit fixes have names.  The rest are LAT/LON coordinates, usually, so if you're not formatting those properly (N50W030 versus 50/30 versus N5000.0W03000.0 versus N5030, and so on).

 

 

 

Problem #3 deals with using flightaware for the route. I prefere to use flightaware to get the real world route for the flight I am flying, but I am seeing a difference in what NAT is filed, and the waypoints that are being flown. For example: NATV would be filed, but the waypoint directly before NATV would be the entry point for NATU.

 

If you're looking on FlightAware, what are you looking at?  Remember that FlightAware is filed flight plans for that specific time.  The NATs change based on time of day to accommodate traffic flows and adjust for wind.  If you're looking at yesterday's flight plans, then you're looking at old NATs.  Additionally, if you're looking at a flight plan that has been filed for much later, it may be using data from the day before.  These flight plans are known as "intent" flight plans, where the operator is notifying the various agencies that it intends to fly through their airspace, but the NAT portion may be updated closer to departure time when the NATs are updated.

 

As an example, looking at the current NATs, a AAL100 is filed on NATV through VODOR, but NATV for tonight picks up at ELSIR.  I can nearly guarantee that if you check that flight plan out closer to departure time (three hours from now), you'll see the flight plan adjusted through ELSIR, as appropriate.

 

This is the same as if you look at some domestic flight plans.  Occasionally, you'll see domestic flight plans filed right through the middle of a frontal storm system.  As it gets closer to departure time, the flight path is updated to route around the system more accurately.

[Jgid 0]

 

 

NATs only really have one entry point and one exit point, despite there being multiple transition fixes to those entry/exit points. Could you be more specific? I'm confused as to what the issue is on this one.

In the past, the track messages have had 2 waypoints for the entry. An example from the beginning of this year: U COLOR RONPO 47/50 49/40 50/30 50/20 SOMAX ATSUR. Why are tracks only showing one waypoint and not the transition to the entry. If not listed on the track message, how do you know which transition you fly over for a given entry. As said in a NYC Aviation article: "If you fly over one of the points, you must fly to its buddy point, which is intended to line everyone up before going oceanic". Do I just guess based off of what the chart says?

 

Thanks for the quick response.

[scandinavian13 5,192]

 

 

In the past, the track messages have had 2 waypoints for the entry.

 

Two named waypoints (they're all technically waypoints) is no longer the case:

https://www.notams.faa.gov/common/nat.html

 

The article is technically correct, but the fact of the matter is that everyone needs to be sequenced onto the NAT in general.  It has nothing to do with how many named waypoints you see in the track message.  Granted, yes, there's only a certain amount of distance that the controllers can see before radar coverage drops, but that doesn't depend on you filing one named waypoint or two prior to the LAT/LON points.  If you plot the NATs out on a chart, you'll see that the first two points are relatively close, despite the second one being a LAT/LON and not a named point.

[Meese 5]

As stated, Gander OCA recently did some changing to their coastline, navigation-wise. The North American Routes still go to/from the OCA-boundary waypoints, and everyone's flying on top of everyone just the same. I'm probably repeating a bunch of what Kyle already said here, but the bottom line is that you only enter the OCA at one point, and at that point you're separated from same-level traffic by 10 minutes (some separation tricks are used for overtakers and slower-in-trail, but that's not the point). When you're issued an Oceanic Clearance, the ATC has ensured that you will maintain separation from any and all traffic throughout your entire crossing, within each of the OCAs. 60nm laterally, 10min in trail, or vertically. Ideally, you should be able to get your clearance, turn off your radios and still be safe all the way through, although one or two people might not take that all too well.

I'm not familiar with NaviGraph charts, so I can't comment on those. As you say, the SkyVector ones seems OK.

 

I'm gonna take the Track validity part and explain it from scratch, in case less familiar people want to learn a bit, and in my experience, taking it from the top might bring that one missing detail to light:

Now, as Kyle says, pay very close attention to your flights departure date and time when fetching Flightaware-plans. Being updated each and every day, NATs A thru H run West and Q thru Z run East, and they do this at different parts of the day. West is 1130z - 1900z, Easts fly from 0100z - 0800z. The track message of the day is designated with a TMI number, which is simply the day of the year (5th of Jan is TMI 5, 2nd of Feb is TMI 33, etc). Flightaware doesn't give you any info other than filed FP and Track Letter, so you have to check that entry and exit point. If the Entry/Exit matches the track message, you're good 99 times out of 100. If it doesn't match, verify time to departure and date of flight. Might be you're looking at yesterdays plan, which by now will be completely wrong. Also, Track Messages are posted typically 12-14 hours before its valid time, so you might also be looking at current flights flying at the proper TMI, while your updated track message displays info for the next day.

Also keep in mind, that NATs isn't the only way to cross the Atlantic. If you're flying from Western Europe to the East Coast, NATs make sense, that's what they're for. For everything else, Random Tracks (aka Random Routes) is what you want. Flying between West Asia or Northern/Eastern Europe and Central/Western America, the direct route takes you north of the NATs, due to the curvature of the Earth. What many sim pilots fail to realise, is that NATs are not mandatory. Random tracks is simply a set of coordinates that takes you from one side to the other. What they are, is up to you and your dispatcher, just try not to cross the NATs themselves. PFPX is a great tool here, as it provides you with an easy way to find tracks north or south of the NATs, optimized for wind and shortest routing possible. Many real flight plans can also be found. The format is still pretty much the same, the entry and exit is usually a named fix, as that's just how the OCAs are set up, then you filed a coordinate for each whole latitude across (The norm is to file 020W, 030W, 040W, 050W, and adding 015W and 060W if you're flying that far north/south within the OCAs.). These are also of course managable in your CDU as xxxxN-wpts (63N060W = 6360N, etc).

 

This should also answer your database question, Jacob. The coordiantes are coordinates, they won't change in forseeable future. In a flightplan (VATSIM or IVAO, f.ex), the ICAO correct format is 7- or 11-character (62N030W or 6200N03000W), but in your CDU/MCDU they still work best as 6230N. The OCA borders have named waypoints, and technically these might change with any cycle. However, it is rare that they do, and the recent change along the western Gander boundary is probably gonna stay that way for years.

Hope I didn't repeat Kyle too much here, keep throwing out questions if you have them.

[Jgid 0]

As stated, Gander OCA recently did some changing to their coastline, navigation-wise. The North American Routes still go to/from the OCA-boundary waypoints, and everyone's flying on top of everyone just the same. I'm probably repeating a bunch of what Kyle already said here, but the bottom line is that you only enter the OCA at one point, and at that point you're separated from same-level traffic by 10 minutes (some separation tricks are used for overtakers and slower-in-trail, but that's not the point). When you're issued an Oceanic Clearance, the ATC has ensured that you will maintain separation from any and all traffic throughout your entire crossing, within each of the OCAs. 60nm laterally, 10min in trail, or vertically. Ideally, you should be able to get your clearance, turn off your radios and still be safe all the way through, although one or two people might not take that all too well.

 

I'm not familiar with NaviGraph charts, so I can't comment on those. As you say, the SkyVector ones seems OK.

 

I'm gonna take the Track validity part and explain it from scratch, in case less familiar people want to learn a bit, and in my experience, taking it from the top might bring that one missing detail to light:

 

Now, as Kyle says, pay very close attention to your flights departure date and time when fetching Flightaware-plans. Being updated each and every day, NATs A thru H run West and Q thru Z run East, and they do this at different parts of the day. West is 1130z - 1900z, Easts fly from 0100z - 0800z. The track message of the day is designated with a TMI number, which is simply the day of the year (5th of Jan is TMI 5, 2nd of Feb is TMI 33, etc). Flightaware doesn't give you any info other than filed FP and Track Letter, so you have to check that entry and exit point. If the Entry/Exit matches the track message, you're good 99 times out of 100. If it doesn't match, verify time to departure and date of flight. Might be you're looking at yesterdays plan, which by now will be completely wrong. Also, Track Messages are posted typically 12-14 hours before its valid time, so you might also be looking at current flights flying at the proper TMI, while your updated track message displays info for the next day.

 

Also keep in mind, that NATs isn't the only way to cross the Atlantic. If you're flying from Western Europe to the East Coast, NATs make sense, that's what they're for. For everything else, Random Tracks (aka Random Routes) is what you want. Flying between West Asia or Northern/Eastern Europe and Central/Western America, the direct route takes you north of the NATs, due to the curvature of the Earth. What many sim pilots fail to realise, is that NATs are not mandatory. Random tracks is simply a set of coordinates that takes you from one side to the other. What they are, is up to you and your dispatcher, just try not to cross the NATs themselves. PFPX is a great tool here, as it provides you with an easy way to find tracks north or south of the NATs, optimized for wind and shortest routing possible. Many real flight plans can also be found. The format is still pretty much the same, the entry and exit is usually a named fix, as that's just how the OCAs are set up, then you filed a coordinate for each whole latitude across (The norm is to file 020W, 030W, 040W, 050W, and adding 015W and 060W if you're flying that far north/south within the OCAs.). These are also of course managable in your CDU as xxxxN-wpts (63N060W = 6360N, etc).

 

This should also answer your database question, Jacob. The coordiantes are coordinates, they won't change in forseeable future. In a flightplan (VATSIM or IVAO, f.ex), the ICAO correct format is 7- or 11-character (62N030W or 6200N03000W), but in your CDU/MCDU they still work best as 6230N. The OCA borders have named waypoints, and technically these might change with any cycle. However, it is rare that they do, and the recent change along the western Gander boundary is probably gonna stay that way for years.

 

Hope I didn't repeat Kyle too much here, keep throwing out questions if you have them.

Thanks for the great explanation! As Kyle said previously, the flight aware route would change closer to the departure time to update to the current track, and indeed it did. That was causing me a lot of confusion with the discrepancies between flight aware and the track messages. Thanks for the help!

[scandinavian13 5,192]

 

 

As Kyle said previously, the flight aware route would change closer to the departure time to update to the current track, and indeed it did. That was causing me a lot of confusion with the discrepancies between flight aware and the track messages. Thanks for the help!

 

haha - yep!  I actually made a mental note to come back in here and post the update, but completely forgot.  While the plane was cruising for hours on AP, I was running around my house getting ready for my brother's wedding this weekend.

 

Of course, the reason I gave you the example of AAL100 was due to my following its progress for my own reasons.  I figured I'd try and make the flight and follow it in real time (I departed a little behind it, though...can't remember what held me up...):

https://vatstats.net/flights/286433

[Eric_Parker 4]

Not sure if this is on topic, but I flew a NAT route today from ATL to AMS and while over the Atlantic I noticed Navigraph Simlink was plotting my aircraft north of the intended waypoints. Then I noticed that while I had filed for N5440 as a fix apparently Simlink was headed for H5440 instead. When I corrected the Navigraph flight plan to show H5440 instead on N5440 it showed me on course. Why would there be two fixes with the same coords but different coding?

 

Eric Parker

[downscc 1,327]

I'm not sure what H5440 is but N5440 is literally N 54 W 40, and this definition can be found in the navdata.  I don't get a hit on H5440.

I assume you have already posted in the Navigraph forum?  Be sure to if you have not already, there's not much PMDG can do about Navigraph issues.