Observation - Experience so far with using the SIDSTARS

[J Jason Vodnansky 810003]

Just wanted to share an observation so far from a total noob to Euroscope...

 

So far my experience has been that the STARs work very well as far as the routing IN the star is concerned. Great Job!

 

I experimented a bit by leaving the runway OUT of the section, and instead use a double colon. The routing still shows correctly, but are there any problems with this method?

 

STAR:KORD::PAITN1:ASP BOHIC OBSTR CSTLO GRR DITCA WLTER RHIVR PAITN WYNDE FIYER ERNNY PAPPI ORD

 

What am I not thinking of if I use this method for Chicago? We do not have any STARs to a runway at ORD.

 

Thanks Gergely, et al, great product, just wish the learning curve wasn't so high, but once over it, truly a great product!

 

Jason Vodnansky

vZAU ATM

[J Jason Vodnansky 810003]

OH, wanted to ask as well...

 

Regarding the stars, what is the purpose of the hierarchy for the stars? Can someone illustrate the example, or have I misunderstood the stars section in that it does NOT care about the order the stars are put into the ESE file?

 

Thanks,

Jason Vodnansky

vZAU ATM

[Gergely Csernak]

Jason,

 

Originally the RWY element was mandatory, but later I changed to optional for a request from the States. At the moment it is allowed to omit the RWY name from the line and both SIDs and STARs will match you FP independently from what RWY is set to active.

 

I would not say hierarchy. It is just a pure list of the SIDs and STARs. ES just looks after them in a loop and selects the first one that matches all the criteria. If it finds one the rest of the list is simply ignored.

It can be used as hierarchy. Eg. you define some STAR with RWY specifications and finally one without RWY. If a RWY is active from the first definitions then that STAR is selected. But if none of them is active the one without RWY definition will be used.

[J Jason Vodnansky 810003]

gotcha!

 

That helps quite a bit.

 

Thank you,

Jason Vodnansky

[J Jason Vodnansky 810003]

Gergely and anyone else with knowledge on this,

 

After spending some time using ES, I wanted to take a moment to follow up with this topic.

 

It seems, that as my experience has increased in using ES, that I am running into issues with aircraft on STARs into various airports.

 

Now, I know you are working an a new release in the short term, so feel free to tell me to standby, but feel this may simply be a "user" problem, as opposed to a "program" problem.

 

 

Karl, Tyler and I have been working a bit together on building our ESE files for our mutual facilities here in VATUSA. What we have found, and Karl has spoken about, is that aircraft inbound to an airport, on a STAR, that has multiple transitions, does not always show the correct flight path. There are times that an aircraft's location, that is, say, midway through the arrival, when its flight path is displayed, goes backward or to another transition, and THEN, it follows the STAR's flightpath as described in the ESE file.

 

I am not in a location right down to throw the SIDSSTARS section up in the thread, but, perhaps Karl, may be able to better describe this issue.

 

Is this due to NOT having runways in the STARS description?

 

For us in Chicago, there are a great many STARs, but can think of only one of them that contains routes to independent runways.

 

Help?

[Gergely Csernak]

Jason,

 

I am afraid that your description is far too general to be able to answer it. If you go a bit into details how the STAR is defined, weather you selected the START or not via the popup menu, and of course what did you exactly see (especially using the route display).

[J Jason Vodnansky 810003]

Thanks, I knew it was general, I will come back to this after the holidays. Perhaps, there will be a "present" from you and you fellow beta testers for me to open, and I may find this issue solved!!

 

Thanks again, and Merry Christmas!

 

JV

[J Jason Vodnansky 810003]

Perhaps before the holidays...

 

I had a chance to get on this evening, and remembered to take a few screen shots of what I am attempting to describe...

 

 

 

STAR:KORD::PAITN1:SSM JODEE BOHIC OBSTR CSTLO GRR DITCA WLTER RHIVR PAITN WYNDE FIYER ERNNY PAPPI ORD
STAR:KORD::PAITN1:ASP BOHIC OBSTR CSTLO GRR DITCA WLTER RHIVR PAITN WYNDE FIYER ERNNY PAPPI ORD
STAR:KORD::PAITN1:TVC PECOK UFDUH BITTR WLTER RHIVR PAITN WYNDE FIYER ERNNY PAPPI ORD
STAR:KORD::PAITN1:FNT EMMMA LTOUR GRR DITCA WLTER RHIVR PAITN WYNDE FIYER ERNNY PAPPI ORD
STAR:KORD::PAITN1:PMM PAITN WYNDE FIYER ERNNY PAPPI ORD
STAR:KORD::OXI4:VWV KULHY SPANN WATSN OXI STYLE
STAR:KORD::OXI4:DJB KULHY SPANN WATSN OXI STYLE
STAR:KORD::OXI4:BSV KUKEY KULHY SPANN WATSN OXI STYLE
STAR:KORD::OXI4:FWA SPANN WATSN OXI STYLE
STAR:KORD::BDF5:IRK LOAMY KEOKK BDF BENKY NEWRK ORD
STAR:KORD::BDF5:BAYLI MAGOO WIMPI BDF BENKY NEWRK ORD
STAR:KORD::BDF5:FTZ GROOV BDF BENKY NEWRK ORD
STAR:KORD::BDF5:STL GROOV BDF BENKY NEWRK ORD
STAR:KORD::JVL5:JVL BULLZ TEDDY KRENA ORD
STAR:KORD::JVL5:MSN GARTT JVL BULLZ TEDDY KRENA ORD
STAR:KORD::JVL5:MCW SUZYQ VIKNG LARVA JIBOR BRIBE MYTCH JVL BULLZ TEDDY KRENA ORD
STAR:KORD::ROYKO3:MZZ FRIDG ROYKO VEECK BOONE LOOTH CLUSO KAYTO PINKK MONKZ JORJO POSSM LENDR
STAR:KORD::ROYKO3:FWA CARVR ROYKO VEECK BOONE LOOTH CLUSO KAYTO PINKK MONKZ JORJO POSSM LENDR
STAR:KORD::WATSN1:MZZ FRIDG WATSN HAUPO MKITA PRISE HULLS STYLE DWEEB VOGLR CENAK
STAR:KORD::WATSN1:ROD FWA SPANN DAIFE WATSN HAUPO MKITA PRISE HULLS STYLE DWEEB VOGLR CENAK
STAR:KORD::WATSN1:ZANLA SPANN DAIFE WATSN HAUPO MKITA PRISE HULLS STYLE DWEEB VOGLR CENAK

 

I have just accpeted the handoff from Cleveland Center, and the aircraft is on the FNT transition for the PAITN1 STAR. As I understand it, the course SHOULD be drawing a line from its current position and along the STAR into KORD. Instead, it SEEMS to be drawing the line backwards to FNT, then up to SSM, then following the STAR into KORD.

 

I do not recall if this happens for all aircraft on all STARs, but it seems to me that it does. There are times that aircraft routes ARE plotted corectly however. I will try to find an example of this in short order.

 

Thoughts?

JV

[J Jason Vodnansky 810003]

 

In the above shot...

 

EGF3755 is along the same route, meaning FNT.PAITN1, same problem as above post

SWA6124 is on the FWA.GSH4, and all looks good...

COA907 is on the ROYKO3 arrival, and all looks good...

 

Just wanted to show you

 

Thanks,

JV

[J Jason Vodnansky 810003]

OK, a bit more info...

 

 

 

In the above image, the route is correct. The ONLY line for the PAITN1 in the ESE file is as follows...

STAR:KORD::PAITN1:FNT EMMMA LTOUR GRR DITCA WLTER RHIVR PAITN WYNDE FIYER ERNNY PAPPI ORD

 

So, I want to add another transition, the ASP transition, thus adding a second line...

STAR:KORD::PAITN1:ASP BOHIC OBSTR CSTLO GRR DITCA WLTER RHIVR PAITN WYNDE FIYER ERNNY PAPPI ORD

 

This means that I now have two lines for the PAITN1...

STAR:KORD::PAITN1:ASP BOHIC OBSTR CSTLO GRR DITCA WLTER RHIVR PAITN WYNDE FIYER ERNNY PAPPI ORD
STAR:KORD::PAITN1:FNT EMMMA LTOUR GRR DITCA WLTER RHIVR PAITN WYNDE FIYER ERNNY PAPPI ORD

 

Now, I close down Euroscope. Re-open it, and when I display the same aircraft's route...

 

 

Finally, this picture displays ALL transitions on the PAITN1...

 

 

Hope this helps a bit.

 

Thanks,

JV

[Stephan Boerner 945550]

Karl, Tyler and I have been working a bit together on building our ESE files for our mutual facilities here in VATUSA. What we have found, and Karl has spoken about, is that aircraft inbound to an airport, on a STAR, that has multiple transitions, does not always show the correct flight path. There are times that an aircraft's location, that is, say, midway through the arrival, when its flight path is displayed, goes backward or to another transition, and THEN, it follows the STAR's flightpath as described in the ESE file.

If "midway through the arrival" means, that the aircraft is already on the STAR when you [Mod - Happy Thoughts]ign the STAR, then it is normal behaviour of ES and has nothing to do with SIDs and STARs in specific. ES does not know if an aircraft has already p[Mod - Happy Thoughts]ed waypoints on a routing you [Mod - Happy Thoughts]ign, until it p[Mod - Happy Thoughts]es the first matching waypoint. So, sticking to the example, if you [Mod - Happy Thoughts]ign PAITN1.FNT while the aircraft has already p[Mod - Happy Thoughts]ed FNT, it is still the first waypoint of the STAR and ES expects the aircraft to be inbound to that waypoint, until the next waypoint on the STAR will be p[Mod - Happy Thoughts]ed.

 

I have a theory why your STAR matching probably does not work. Your STAR names are identical (PAITN1), so they are not unique and ES can not determine the STAR based on the name. Your STAR also does not contain the last waypoint before entering the STAR. How should ES know which STAR is depicted by PAITN1 in the route section? To give you an example from EDDF, the routes end at PSA. There is a PSA2W STAR, which is PSA CHA. So the endpoint of the route is the startpoint of the STAR. ES can use that to match the STAR. Your STARs start after the endpoint of the route. Again, no way for ES to find a match. So ES will always use the first line in the ESE, as there is simply no difference between the STARs in the matching progress.

[Todor Atanasov 878664]

LOL Stephan, you beat me by the second

 

J Jason, do a simple test, just make them PAINT1, PAINT2 and so on and make you tests again.

[J Jason Vodnansky 810003]

Not sure I understand what you mean here...

 

There is only 1 arrival, it is the PAITN1. That arrival has multiple transitions.

 

Perhaps looking at the chart will help illustrate what I mean here.

http://naco.faa.gov/d-tpp/0913/00166PAITN.PDF

 

Can you please tell me which fixes I may be missing in the following code. As best as I can understand, I have the beginning fix, all the way through to ORD VOR.

 

STAR:KORD::PAITN1:ASP BOHIC OBSTR CSTLO GRR DITCA WLTER RHIVR PAITN WYNDE FIYER ERNNY PAPPI ORD
STAR:KORD::PAITN1:FNT EMMMA LTOUR GRR DITCA WLTER RHIVR PAITN WYNDE FIYER ERNNY PAPPI ORD
STAR:KORD::PAITN1:PMM PAITN WYNDE FIYER ERNNY PAPPI ORD
STAR:KORD::PAITN1:SSM JODEE BOHIC OBSTR CSTLO GRR DITCA WLTER RHIVR PAITN WYNDE FIYER ERNNY PAPPI ORD
STAR:KORD::PAITN1:TVC PECOK UFDUH BITTR WLTER RHIVR PAITN WYNDE FIYER ERNNY PAPPI ORD

 

Thanks folks!

 

Merry Christmas,

Jason Vodnansky

Edited December 23, 2009 at 04:53 PM by Guest

[Michael Pike]

Is there any reason why the STARs can't be uniquely identified? For example PAITN1.FND PAITN1.ASP etc. In other words, treat the transition name as part of the STAR name so they are unique.

[J Jason Vodnansky 810003]

Is there any reason why the STARs can't be uniquely identified? For example PAITN1.FND PAITN1.ASP etc. In other words, treat the transition name as part of the STAR name so they are unique.

 

 

Not sure who the question is for...

 

Michael, if it is for me, I am not sure if that can be done or not.

 

To tell you the truth, I am not sure I am presenting what the problem is correctly...

 

JV

[J Jason Vodnansky 810003]

If "midway through the arrival" means, that the aircraft is already on the STAR when you [Mod - Happy Thoughts]ign the STAR, then it is normal behaviour of ES and has nothing to do with SIDs and STARs in specific. ES does not know if an aircraft has already p[Mod - Happy Thoughts]ed waypoints on a routing you [Mod - Happy Thoughts]ign, until it p[Mod - Happy Thoughts]es the first matching waypoint. So, sticking to the example, if you [Mod - Happy Thoughts]ign PAITN1.FNT while the aircraft has already p[Mod - Happy Thoughts]ed FNT, it is still the first waypoint of the STAR and ES expects the aircraft to be inbound to that waypoint, until the next waypoint on the STAR will be p[Mod - Happy Thoughts]ed.

 

Stephan, if this is true, then wouldn't the route from SWA6124 in the earlier post be drawn back to the first fix on the STAR. There are two transitions for the GSH4 STAR into the Chicago Airspace. One is FWA, the other is LFD.

 

STAR:KMDW::GSH4:FWA BAGEL GSH DRIVR AWSUM IROCK HALIE CGT
STAR:KMDW::GSH4:LFD BAGEL GSH DRIVR AWSUM IROCK HALIE CGT

 

In the picture showing SWA6124, it appears to be working correctly.

 

I just can't seem to figure this one out,

JV

[Earl Miller]

STAR:KMDW::GSH4:FWA BAGEL GSH DRIVR AWSUM IROCK HALIE CGT
STAR:KMDW::GSH4:LFD BAGEL GSH DRIVR AWSUM IROCK HALIE CGT

I had to make all our STARs and SIDs unique. Several STARs have 6 arrival runways. I had to use the runways instead of the ::. Even with the use of Runways, as your arrivals, they all merged along the route then separated for the runway in use.

***To make the STAR work I combined the "Entrance" way point, ie, MLF BCE before the STAR DELTA3. Called DELTA.DELTA3. DELTA3 has 6 runways

STAR:KSLC:16R:MLFDELTA3:MLF BEVRR DTA JAMMN DRAPR SPIEK HEIRY PITTT MAGNE

STAR:KSLC:16R:BCEDELTA3:BCE SLINA DTA JAMMN DRAPR SPIEK HEIRY PITTT MAGNE

***To make the SID work I combined the "Exit" way point, ie, DTA , MLF, BCE, HVE after the SID FFU6. Called FFU6.FFU. FFU6.FFU has 12 runways.

SID:KSLC:16L:FFU6DTA:FFU LODUY DTA

SID:KSLC:16L:FFU6MLF:FFU LODUY URNUW MLF

SID:KSLC:16L:FFU6BCE:FFU LODUY URNUW BCE

SID:KSLC:16L:FFU6HVE:FFU OHQES HVE

***Many of our SIDSTARs have multiple runway [Mod - Happy Thoughts]ignments. I tried every combination I could think of and this was the only way to get Euroscope to display properly every time. ES comes to the first 16L:FFU6 and stops you have to use the drop down on the approaching AC and select the proper route. We have to educate our controllers to think "STAR is entrance VOR, fix, NDB, etc, then STAR. SID is SID then exit VOR, NDB, Fix, etc." I hope I haven't confused you. I [Mod - Happy Thoughts]ume that once a AC reaches CGT that controllers direct AC to the "Runway in use". Try the example below of your STAR.

STAR:KMDW::FWAGSH4:FWA BAGEL GSH DRIVR AWSUM IROCK HALIE CGT

STAR:KMDW::LFDGSH4:LFD BAGEL GSH DRIVR AWSUM IROCK HALIE CGT

 

Hope this helps,

Merry Christmas

[Stephan Boerner 945550]

Stephan, if this is true, then wouldn't the route from SWA6124 in the earlier post be drawn back to the first fix on the STAR. There are two transitions for the GSH4 STAR into the Chicago Airspace. One is FWA, the other is LFD.

EuroScope currently does not know transitions. There are SIDs and there are STARs. SIDs are in the beginning of the route, and STARs are at the end. So if you have a PAITN1 arrival, that is the STAR. The transition does not matter, and EuroScope does not know anything about transitions.

 

EuroScope first looks at the name of the STAR in the flightplan, which in this case would be PAITN1. Then it looks for matching waypoints, so if the last waypoint of the route is FNT and the first waypoint of the STAR is FNT, then this would be a match (hopefully, I am actually not 100% sure if this matching still happens if there is already a match by name and there are several STARs with the same name, but it should. Can't test it currently as I have no running ES right now). Those are the only two ways how ES currently can handle the matching process.

 

It doesn't matter that in reality the STAR has a transition following, as long as ES does not support that, which it currently does not, and it will not in v3.1 either. We are aware that it works different mainly in the US currently (but I think there are also some changes in Europe that implement transitions following to a STAR), so it will be implemented at some point. But for now you will have to work around that either by using different names or extending the STAR waypoints to create a match bei last/first waypoint.

[Michael Pike]

Jason, what Stephan has posted is the point I was trying to make. In the UK, we have the same type of approach routes where the final part of several routes is the same but they aren't called "transitions". Instead, the STARs are identified uniquely by adding a single letter suffix to each route that ends at the same point.

 

See for example this chart. I believe it shows a similar situation to what you are trying to depict. But they aren't called transitions, they are 4 separate STARs even though they follow the same route from MCT VOR.

 

I don't know how many characters are allowed in the STAR-name field in ES but it seems to me that you may be able to make them unique by including the transition name.

[Karl Kornel 964857]

Jason asked me a while ago to add my thoughts to this thread, but it looks like everything that I wanted to say has already been said! In fact, I actually have a complete summary, with my thoughts and suggestions, as a post in a separate thread. To summarize...

 

• The problem is because the difference between SIDs/STARs in the US and SIDs/STARs in Europe, not just in terms of the number of transitions per SID/STAR but also because of the fact that, in the US, any point on a SID/STAR can be a transition point.
   
  
• In my opinion, there is no usable workaround to this problem. Simply giving each STAR/transition combination a unique name (like "ABCFFF" for the ABC STAR FFF transition) is not, in my opinion, a valid workaround, because of the amount of extra work required. Using "FFF.ABC" (or "ABC.FFF") as the name does not work either. The problem in this is that the tests to discover and confirm these problems are not easy to arrange with live traffic. The problem may not appear one day, but then traffic changes and you see it. Turning off RAM alerts is also not a good workaround, because RAM alerts are so extremely useful and nice to have!
   
  
• In my opinion, I can not suggest that controllers in the US use EuroScope until the problem is fixed. Of course, if people ask, I will help, that is certain, but if anyone asks my opinion, I will tell them "I do not think you should use EuroScope on Center, because of this problem". It may not be a big problem, but the number of RAM alerts that could be caused can be very high, so for a new CTR controller (attempting to transition from VRC) that is not good at all.

 

There are solutions, I think. I do not know how hard the solution would be to implement, and I can not even claim to know the correct solution (although I suggest one in my post). That information can not be provided by me. I also can not tell you what will happen in future versions, or even that something will happen at all, as I am not involved in that. Instead, we will have to continue to wait. While we wait, S3 controllers like me can start to learn the new features, S2s can start to learn EuroScope (as the bug blocking S1s and S2s has been fixed), EuroScope C1s & C3s can continue to live with the problem, and VRC C1s & C3s can continue to use VRC!