Coordination problem

[Eivind Fosse 818131]

Hi again,

 

I might have done something strange to my settings after the upgrade to ES 3.1...

 

For some reason I am unable to coordinate aircrafts with other ES users... I use the same ESE file that I used with ES 3.0 and then the coordination worked very well.

 

Here’s what happens: I would like to clear an aircraft direct VOR ABC that is inside the next controllers’ airspace. So I press the COPX item in either the tag, or Sector Exit List, and choose ABC. I would expect ABC to go pink colour (indicating coordination is in progress and green when the other controller accepts). This does not happen though. ABC is set as the current valid direct to point, and no coordination between me and the other controllers ES was done...

 

I've tested this towards several controllers today, and it did only work as expected with those that used VRC (!). Then I got the telephone icon indicating I need to make an oral coordination with that controller.

 

The last test I did was towards an approach controller. I tracked an aircraft towards point RILKO and he was [Mod - Happy Thoughts]igned runway 18 at ENZV.

 

I was really sure that I had programmed a LoA altitude for such a flight so I searched the ESE file and found this line:

 

COPX:*:*:RILKO:ENZV:18:ENSV SR:ENZV TMA:*:10000:RILKO

 

I was online as ENOR_CTR and owning the ENSV SR sector. ENZV_APP owns the ENZV TMA sector. Still the COPX altitude was not set to 100, but his RFL. When I entered FL100 manually I was suddenly able to request direct points after RILKO from ENZV APP, as I was with version 3.0...

 

Any ideas what might be wrong?

[Todor Atanasov 878664]

There is one option in General settings "Allow direct bwyond COPX pint" have you selected it?

[Eivind Fosse 818131]

Yes,

 

"Allow direct beyond COPX point" is selected on.

[Jonas Eberle]

Also v3.1a:

 

I had the same: selecting a direct via either the "open next points" or the "open COPX points" did not start a coordination with the next controller as happened in 3.0a.

 

I had "Allow direct beyond COPX point" off as I understood the Wiki ("Allow direct beyond COPX point - If set then no coordination is initiated if a point is selected beyound the actual COPX.") in such way that this would supress coordination in some circomestances. But I am not so clear about this.

[Eivind Fosse 818131]

Jonas, did you have this problem, or do you still have it?

[Todor Atanasov 878664]

I have to do some test...can you send me your sct/ese file at xumepoc(_at_)abv(dot)bg

[Eivind Fosse 818131]

Thank you. Mail have been sent.

[Todor Atanasov 878664]

I'll test it tonight.

[Jonas Eberle]

Jonas, did you have this problem, or do you still have it?

I still have it, but am a bit puzzled as to correctly reproduce it.

I think it changed its behaviour to 3.0a: I was able to open the "open next points list" and get a list with the (waypoint) + (sector to coordinate with). On selecting a coordinated direct coordination was initiated.

In 3.1a, I THINK (but am not sure yet) this only works with sectors directly adjacent to the active sector. I get the COPX list (via "open next points list" tag function) and no indication of the sector to coordinate with. Coordination sometimes gets initiated, sometimes not.

 

Also tried the "COPX point" tag function, but this shows the same list and has the same function.

[Eivind Fosse 818131]

The problem have been fixed:

 

In ES 3.0a "Allow direct beyond COPX point" was selected ON. In ES 3.1a however, the option must be OFF.

 

Eivind

[Gergely Csernak]

Actually I found that the "Allow direct beyond COPX" was simply not used in 3.0 at all. I enabled it again in 3.1. That is why the behavior is changed. The meaning of "Allow direct beyond COPX" is really that it allows you to set a direct beyond the COPX without coordination.

[Jonas Eberle]

Actually I found that the "Allow direct beyond COPX" was simply not used in 3.0 at all. I enabled it again in 3.1. That is why the behavior is changed. The meaning of "Allow direct beyond COPX" is really that it allows you to set a direct beyond the COPX without coordination.

Thanks for clarification! That is, indeed, exactly what is written in the Wiki

 

I found a difference if coordinating to an adjacent controller (worked today) or a direct into someone's airspace with no controllers in between but sectors without ownership. (e.g. APP to some neighbouring, but not covering CTR with no COPX's set). I remember from 3.0a that this worked and I did like it

[Gergely Csernak]

I do not remember changing anything in the code around this. When you set a direct ES checks the points along the route and starts coordinating with the first online controller along the direct straight line. If there is an uncontrolled area then there will be no coordination. If you really want to have then select the next controller manually. If you did so then all direct outside your sector will start a coordination with the selected controller.

[Jonas Eberle]

If there is an uncontrolled area then there will be no coordination. If you really want to have then select the next controller manually. If you did so then all direct outside your sector will start a coordination with the selected controller.

Thanks, will try and I am sure that will work

[Eivind Fosse 818131]

I have another coordination related issue...

 

I was online as APP with TWR below and CTR above me. In the tag I've selected one item to be the "Sector entry/exit altitude". In the ESE file the LoA states that TWR shall clear flights to me to 5000 feet. I shall clear flights to FL130. In the tag item 050 appeared on flights handed over by TWR, however this did not change when I tracked the aircraft...

 

I would expect 050 to change to 130 when I got the track?

 

Anyone else who has experienced this? Or is my expectations not correct?

 

Thank you.

[Stephan Boerner 945550]

Without the LoA-lines from the ESE and the routing of the aircraft, one could just start guessing ... And while you are collecting those data, check the route calculation of the aircraft, maybe something shows up there. And bring screenshots or/and a log-file

[Eivind Fosse 818131]

As I don't have access to my computer this weekend I'll post the relevant lines in the ESE on Monday.

 

But for now you agree with me that the inbound altitude of 050 should change to 130 if everything is correct in the FPL an ESE?

[Stephan Boerner 945550]

Well, it would not be the inbound altitude anymore as it would then be the outbound/sector exit altitude, but yes, as you are using the combined TAG item it should change.

[Eivind Fosse 818131]

This is the relevant parts of the ESE file:

 

COPX:ENCN:04:ARDAL:*:*:ENCN CTR:ENCN TMA:5000:*:ARDAL

COPX:ENCN:22:ARDAL:*:*:ENCN CTR:ENCN TMA:5000:*:ARDAL

COPX:ENCN:*:ARDAL:*:*:ENCN TMA:ENOS RR:13000:*:ARDAL

 

ARDAL is the TMA border between ENCN TMA and ENOS RR Sector. The FPL of the aircraft is

 

ARDAL DCT TOR

 

Eivind

[Eivind Fosse 818131]

I'm still hoping someone could help me with this coordination problem described above...

 

I've also experienced these three problems I'd love to have an explanation on:

 

1 - I was online as CTR with a flight inbound ENZV. I give the aircraft clearence direct ZV501 (a point on base inside the TMA). After a few minutes ENZV_APP is logging on and the tag shows that he will be the next controller of the aircraft. I would like to give him a heads up that the aircraft is inbound a fix that is not normally [Mod - Happy Thoughts]igned, so I change the COPX to the STAR start point and back again to ZV501. However no coordination happens (Allow direct beyond COPX point is off)

 

2 - I'm online as the same CTR and ENZV_APP is still on. On an airport about 300 NM north of ENZV two aircrafts have filed a flightplan to England, and they will fly over ZOL VOR located on the ENZV airport. After takeoff I notice that these aircrafts have their COPX altitude set to FL160... This is so even though they will p[Mod - Happy Thoughts] the VOR at FL340. Well above the FL155 high altitude of ENZV TMA... Why might this happen?

 

3 - I'm still online as the same CTR. In this problem flights are departing ENGM outbound for ESSA via SUTOK. Both when Sweden is, and is not, online the COPX altitude is FL300, regardless of the actual requested FL. The problem is that the LoA for that direction states:

 

FIR_COPX:ENGM:*:SUTOK:*:*:ENOS ER:ESOS 3:29000:*:SUTOK

 

The direction from Sweden to Norway however states:

 

FIR_COPX:*:*:SUTOK:*:*:ESOS 3:ENOS ER:30000:*:SUTOK

 

I would be happy if someone could download the Sectorfile and ESE from this link, and maybe help me a bit on the way here...

 

http://www.vaccsca.org/component/option,com_docman/Itemid,77/gid,144/task,doc_download/

 

Thank you

 

Eivind

[Juha Holopainen]

1 - I was online as CTR with a flight inbound ENZV. I give the aircraft clearence direct ZV501 (a point on base inside the TMA). After a few minutes ENZV_APP is logging on and the tag shows that he will be the next controller of the aircraft. I would like to give him a heads up that the aircraft is inbound a fix that is not normally [Mod - Happy Thoughts]igned, so I change the COPX to the STAR start point and back again to ZV501. However no coordination happens (Allow direct beyond COPX point is off)

Was APP shown as the controlling sector in the next points list for the point ZV501 when you changed it back to it? If not, did you check the COPX altitude when [Mod - Happy Thoughts]igning ZV501 again? If it was above APP's sector, and the distance to touchdown long enough at ZV501, ES could have thought that the aircraft would still be in your sector at ZV501 and hence no coordination would be required? I'm not familiar with ENZV TMA procedures or layout so it's just a guess.

 

2 - I'm online as the same CTR and ENZV_APP is still on. On an airport about 300 NM north of ENZV two aircrafts have filed a flightplan to England, and they will fly over ZOL VOR located on the ENZV airport. After takeoff I notice that these aircrafts have their COPX altitude set to FL160... This is so even though they will p[Mod - Happy Thoughts] the VOR at FL340. Well above the FL155 high altitude of ENZV TMA... Why might this happen?

Could have been any one of the below lines:

 

COPX:*:*:ZOL:*:*:ENSV SR:ENZV TMA:*:16000:ZOL

COPX:*:*:ZOL:*:*:ENSV NR:ENZV TMA:*:16000:ZOL

COPX:*:*:ZOL:*:*:ENSV WR:ENZV TMA:*:16000:ZOL

 

They all will cause a COPX altitude of 16000 (or RFL if lower) to be shown for all traffic p[Mod - Happy Thoughts]ing ZOL no matter what the route, origin or destination is, unless the two sectors defined in the line are controller by the same controller.

 

3 - I'm still online as the same CTR. In this problem flights are departing ENGM outbound for ESSA via SUTOK. Both when Sweden is, and is not, online the COPX altitude is FL300, regardless of the actual requested FL. The problem is that the LoA for that direction states:

 

FIR_COPX:ENGM:*:SUTOK:*:*:ENOS ER:ESOS 3:29000:*:SUTOK

 

The direction from Sweden to Norway however states:

 

FIR_COPX:*:*:SUTOK:*:*:ESOS 3:ENOS ER:30000:*:SUTOK

The direction of the flight doesn't make a difference in the copx definition lines, and the aircraft doesn't even need to fly in either sector during its flight. The only thing the sectors are checked for is that the same controller doesn't control both of them. In the second line the two sectors will never be controlled by the same controller (unless both are controlled by Eurocontrol when no local controllers online). As there are no other rules in the line this means that this COPX line will be used for all aircraft p[Mod - Happy Thoughts]ing SUTOK in both directions.

 

To enable the SUTOK COPX point rules for departing traffic including the first line above, they have to be earlier in the file, before the second line. Even then, the second line will be used for the other flights, even when they're flying from Norway to Sweden. To check for the direction of flight, you can specify the previous and/or next point from the COPX point, for example:

 

Sweden->Norway

FIR_COPX:POINT_IN_SWEDEN_BEFORE_SUTOK:*:SUTOK:*:*:ESOS 3:ENOS ER:30000:*:SUTOK

 

 

From the previous post:

 

COPX:ENCN:04:ARDAL:*:*:ENCN CTR:ENCN TMA:5000:*:ARDAL

COPX:ENCN:22:ARDAL:*:*:ENCN CTR:ENCN TMA:5000:*:ARDAL

COPX:ENCN:*:ARDAL:*:*:ENCN TMA:ENOS RR:13000:*:ARDAL

 

As above, the last line will not be chosen if either of the above two is found suitable. Something like the following might work but it will be difficult to cover all possible routes without creating problems with other COPX points:

 

COPX:ENCN:*:NEXT_POINT_AFTER_ARDAL:*:*:ENCN TMA:ENOS RR:13000:*:ARDAL

[Eivind Fosse 818131]

Thank you for a great heads up Juha!

 

Regarding the ENCN and SUMAK problem though - in the Wiki page it is said the following:

 

COPX:DEP APT or FIX BEFORE:DEP RWY:FIX:ARR APT or FIX AFTER:ARR RWY:FROM SECTOR:TO SECTOR2:CLIMB TO XFL:DESCEND TO XFL:XNAME

 

As I understand this a specific coordination (the SUMAK at FL300) is only valid if the aircraft is going from ESOS 3 to ENOS ER sector. But as you tell me this is not true?

 

Does this mean that these two lines sais exactly the same, and one of them is obsolete (not necessary)?

 

FIR_COPX:*:*:SUTOK:*:*:ESOS 3:ENOS ER:*:*:SUTOK

FIR_COPX:*:*:SUTOK:*:*:ENOS ER:ESOS 3:*:*:SUTOK

 

Eivind

[Juha Holopainen]

I can't be sure how ES interprets the COPX lines, only Gergely can give a completely correct answer here. The Wiki page would lead you to believe that the aircraft needs to fly from the first sector to the second but from what I can see by experimenting, it doesn't seem to be true. What is checked is that the two defined sectors are not controlled by the same controller. Based on what I've seen, the two SUTOK lines are exactly the same to ES.

[Gergely Csernak]

Does this mean that these two lines sais exactly the same, and one of them is obsolete (not necessary)?

 

FIR_COPX:*:*:SUTOK:*:*:ESOS 3:ENOS ER:*:*:SUTOK

FIR_COPX:*:*:SUTOK:*:*:ENOS ER:ESOS 3:*:*:SUTOK

 

Yes, they are the same. At the moment there is no check which sectir is the first and which is the next. Just the controllers are tested if they are online or not. The reason is that LOA lines are decided if they are active or not just when sector ownership is changed. The active state of the LOA line is global. When I check if a LOA is to be used for an AC profile then only the DEP APT or FIX BEFORE:DEP RWY:FIX:ARR APT or FIX AFTER:ARR RWY values are matched.

 

We already have a new idea how to change both the sector ownership, both the COPX interpretation. But that will take some to arrive to there.

[Eivind Fosse 818131]

Ok, thank you for the clarification, Gergely.

 

This gives some answers to some of the strange LoA behavior I've seen.

 

Eivind