Not Seeing My Neighbour

[Rob Killins 897126]

Last evening, I logged into my centre position responsible for controlling traffic for the entire FIR (sec_ctr). To my west, my neighbour had logged into his centre position responsible for his entire sector (ces_ctr). His callsign was displayed in my controller list, and me in his. The sector boundary illuminated indicating the neigbouring sector was online.

 

Within a few minutes, another controller logged on to control a bordering sector within my neighbour's FIR, ces_b_ctr, in essence dividing it up. The FIR to my west was now being controlled by two different controllers.

 

However, what struck me odd was ... although ces_b_ctr was actively controlling, he did not show up in my controller list, nor was I in his. Additionally, his boundry with me didn't light (mine was already lit only because of the ces_ctr position being online), but I think I know what the problem is with that (sectorline criteria not set up for this scenario). Considering we border each other, and our vis ranges are both 600NM, I don't undertsnad why we were unable to see each other in the controller list.

 

Being the sector file creator for both these FIRs, is their something I'm missing?

[Todor Atanasov 878664]

Was the new controller on active position, in other words, did he select the correct Facility and prim freq?

[Rob Killins 897126]

Hi Todor,

 

Yes, I believe he was. The other controller, ces_ctr, had him in his controller list. As well, vroute had identified the controller, although not the position.

[Miguel Frias]

Check if frequencies used match the ones in the sector file. If my frequency is 125.55 (in the sector file and official) but I use a different frequency that is not listed there, Euroscope will fail to detect the controller online. I may not see other controllers and they won't see me either.

 

Miguel

[Rob Killins 897126]

Thanks Miguel,

 

I was really hoping that was the solution. The frequencies in both sector files match.

[Miguel Frias]

Moving on... then it's most probably something in the SECTOR/SECTORLINE definitions in the .ese file.

 

Miguel

[Rob Killins 897126]

Hi Folks,

 

So ... with some further testing, we have been able now to see each other. The sectorline "illuminates" accordingly with both sectors (CZEG_AC_CTR and CZWG_CTR) online, but within 3 or 4 minutes, my neighbour's callsign turns white in the controller list, and within seconds, the connection is lost. He has not voluntarily selected to logoff. This is a neighbouring smaller sector within the FIR (CZEG). The other neighbouring subsectors do not behave like this.

 

Miguel ... does this still suggest an issue with the sector/sectorline definitions in the ese? What should I consider looking for in those modules of the ese?

 

 

SECTORLINE:E31a ;12a-YEG(AC)-ZWG(NL)
;boundary between CZEG(AC) and CZWG(NL)
DISPLAY:CZEG_AC_CTR:CZEG_AC_CTR:CZWG_NL_CTR
COORD:N062.45.00.000:W080.00.00.000
COORD:N064.24.03.000:W080.00.00.000
COORD:N063.19.14.050:W085.39.26.390
COORD:N062.20.00.070:W089.45.30.450
COORD:N061.06.08.370:W094.00.09.140
COORD:N059.57.07.800:W097.21.55.490

SECTORLINE:E31b ;12b-YEG(AC)-ZWG(VC)
;boundary between CZEG(AC) and CZWG(VC)
DISPLAY:CZEG_AC_CTR:CZEG_AC_CTR:CZWG_VC_CTR
COORD:N059.57.07.800:W097.21.55.490
COORD:N058.40.45.830:W100.35.58.570
COORD:N057.40.09.420:W102.52.46.300

 

SECTOR:CZEG_AC_CTR:0:65000
OWNER:EAC:EGC
BORDER:I03:E26:E27:E28:E29:E30:E31a:E31b
DEPAPT:CYZF
ARRAPT:CYZF

SECTOR:CZWG_NL_CTR:0:65000
OWNER:ZNL:ZGC
BORDER:E31a:ZWGNLGW

SECTOR:CZWG_VC_CTR:0:65000
OWNER:ZVC:ZGC 
BORDER:E31b:E32:E33a:ZWGVCGW

[Miguel Frias]

Try this:

 

DISPLAY:CZEG_AC_CTR:CZEG_AC_CTR:CZWG_NL_CTR

 

add:

 

DISPLAY:CZWG_NL_CTR:CZWG_NL_CTR:CZEG_AC_CTR

 

 

i.e., add a second line with the positions reversed. Not sure how your sector file is in full but this may be it. Some same-FIR positions require that if pos A is on but then pos B comes online, B takes the traffic. And then B sees that A is also online.

 

Miguel

[Rob Killins 897126]

Hi Miguel, thank you for your continued support.

 

We tested additionally with your recommendation by adding the second line to the Sectorline definition without any success. There is an initial connection, but within a few minutes it is dropped.

 

As mentioned, we do not have any issues with similar neighbouring subsectors, nor do we have any issue when its simply CZEG_CTR and CZWG_CTR connected as wide centres.

 

CZEG is a large FIR stretching to the far north of the globe. Could geography or ES's map projection be limiting it? I doubt it, as if it did, the wide sector relationship would fail as well as it covers the same sector in question.

 

The CZEG_AC_CTR is a very important sector for CZEG as it provides the best coverage with it's unique 4 visibility points providing coverage of the entire north that CZEG_CTR is unable to cover completely.

 

If there is any additional specific information that would be helpful in helping diagnose this issue further, let me know. I don't know what information to share as it relates to our sector file that will help others understand.

[Miguel Frias]

Check if the magnetic variation is set up correctly. Check for radio and radar ranges (which you referred as having 4 points). If a connection suddenly turns white and drops it's as if the controller simply signed off. If you change visibility centers (or if it is somehow changed) then ES will show the same thing.

 

If CZEG is rather big then maybe you have to open up as FSS (even if using the CTR callsign). FSS is radio-range hardcoded to 1500nm.

 

You said other subsectors are not a problem. As they as big / far up north as CZEG?

 

Miguel

[Rob Killins 897126]

Hi Miguel,

 

I feel like a pest with this nagging problem, but do appreciate your ongoing help.

 

Magnetic variation? That is set up in the [iNFO] module of the .sct2 file correct? How can I go about determining whether or not the value I have is correct? I never gave it any thought as to where the value is gathered from, so it could be way off.

 

Our latest sector rewrite included a redefinition of radio/visibility points in order to optimize coverage. Again, not sure what to look for in terms of being correct or incorrect. The progression of sector development over the past couple years went from one sector (wide centre) with 4 points chosen for visibility (at the expense of radio coverage) to our latest release having 4 subsectors with individual radio/visibility points for each to optimize radio coverage. We found if we can optimize our radio coverage at 400NM, the 600NM visibility range for CTR is a no brainer.

 

The remaining three sectors are significantly smaller in area and fall south of CZEG_AC_CTR. They are easily covered by one 400NM radio range, where as the problem sector has 4. When subsectors are not being used, CZEG_CTR relies on it's defined 4 points, with reduced radio/visibility coverage to the far north. CZEG_AC_CTR was created in an effort to optimize radio coverage.

 

Perhaps some pictures would be of help Miguel and friends? Let me know, and I will happily upload some images to [Mod - Happy Thoughts]ist in the visualization of this FIR.

 

At one point in our testing, we changed frequencies for CZEG_AC_CTR and made the appropriate changes to the [POSITIONS] module in both ese files (CZEG and it's neighbouring CZWG). We we able to connect, with both positions appearing in our respective controller lists, and hold a connection, however the sector definitions were not being recognized. The _AC_CTR sector did not darken up, nor did the boundary line change. Despite simply changing only the frequencies in the ese file, the position showed up in the controller list as the default "## ie 60" rather than the coded "EAC" designation from the position line. (with which the original frequency recognized).

 

Thanks ...

[Miguel Frias]

Frequencies and callsigns much match so that the letters show. Otherwise, an ordered number is shown. This will also make coordination lines work or not, respectively.

 

The magnetic variation is obtained from the charts/AIP/AIC. I'm not really sure about their configuration. Airspaces that are far from the equator have more sensitive values especially due to the distance between longitudes being different. 1nm=1 min long at Equator. One minute of latitude equals one nautical mile and degrees of latitude are 60 nm apart. The distance between degrees of longitude isn't constant because they converge towards the poles.

 

That might be it.

 

Miguel

[Rob Killins 897126]

Some great insight Miguel.

 

I'm at a loss as to what to do at this point. CZEG FIR extends from the 49th parallel north to the north pole. The difference in magnetic variation between the south and the north would be hard to define with only one value. For example, Inuvik NT (far north) has a magnetic variation of 31East, whereas Calgary in the south of the FIR has a published variation of 17East. The value in the sector file is -6. But, why does everything appear to work properly when it's just the one wide sector ... it covers the same area as the problem subsector?

 

[INFO]
CZEG_FIR V1111.6 AIRAC1111 20-10-11
YEG_CTR
CYEG
N053.18.35.000 
W113.34.47.000
30
19
-6
.5

CZEG_AC_CTR from CZEG ese position module:

CZEG_AC:Edmonton Arctic Centre:125.050:EAC:EA:ZEG:CTR:-:-:2130:2177:N064.16.00.580:W105.11.52.020:N071.11.19.060:W125.06.08.370:N076.49.20.960:W097.11.57.800:N069.04.21.070:W079.34.49.91

CZEG_AC_CTR from CZWG ese position module:

CZEG_AC:Edmonton Arctic Centre:125.050:EAC:EA:ZEG:CTR:-:-:-:-:-:-

http://imageshack.us/photo/my-images/854/czegfir.jpg/

[Miguel Frias]

Iceland sector has this:

 

BIRD Sector File - AIRAC 1108 Rev 01

BIRD_CTR

BIKF

N063.59.06.000

W022.36.20.000

30

13

21.6

0.5

 

 

One more tip. I'm always a bit confused with so many CY** and CZ** callsigns since I don't know the airspace that well. That suggests that there could be a typo in a letter where a Y was placed where a Z should be or something like that. Suggest a thorough scan in the ESE file regarding the related frequencies.

 

Miguel

[Rob Killins 897126]

Hi folks,

 

Just an update to anyone that may be following this.

 

I spent considerable time yesterday combing meticulously through both ese files looking for an ellusive typo which may be the culprit for this issue. As Mr. Frias had mentioned, it's a dizzying task with all the "y"s and "z"s.

 

I was unable to find any issue in the ZEG ese, but I made a few changes to it's neighbouring ZWG ese. I added the inverse sector line relationships as Miguel suggested in an earlier posts, and also found sector ownership priority errors. I had originally had zeg_ac_ctr (in the ZWG file) OWNER: EGC:EAC, prioritizing ZEG wide centre over the AC centre. So I reversed them, prioritizing ownership to EAC then EGC.

 

After these changes, did some additional testing.

 

Test 1: ZEG_AC_CTR and CZWG_CTR

ZEG_AC_CTR displayed in ZWG's controller list, but as a sequence number only, but ZWG not in AC

Sector line did not post

AC Centre did not highlight itself

 

We did several other tests with different combinations of subsectors and I wish I could recall their results. I do remember vaguely have a 50/50 success/failure rate.

[Gergely Csernak]

I think that if you do not see another controller in the controller list that is because ES does not receive information about him. And that depends on the servers not on the client. May be different range center positions work differently on the server. That is why sometimes you see sometimes not. If you do not see him in the controller list do not expect anything about sector updates and sectorline highlight.

[Mark Wolpert]

Wow, I never see my neighbor and even forgot about this feature that is highlighted in the manual. I am thinking I might have changed the colour of the border to match the default so that is why. Where do I go to change it back ?

 

 

 

Mark.

[Rob Killins 897126]

Thank you Gergely for your input into this scenario. If I'm understanding you correct, your stating that the issue stems around a server limitation rather than a Euroscope issue, and that the supporting .ese files are not likely the culprit.

 

Not being one to understand the complexities of how the servers work, I'm curious as to why our one position wouldn't be recognized, and what steps would be needed to have it recognized (if it's even possible). VATRUS I would imagine covers a lot of far north airspace ... does anyone know if they experience similar problems?

 

Other than perhaps testing on another server, can anyone offer any suggestions? As mentioned in my initial post, this is a valuable position that provides us great benefit to have operational.

[Gergely Csernak]

I suggest playing a bit with visibility center. Move it around to see any change. Or probably add some more visibility points - one close to the neighbor you can not see.

[Rob Killins 897126]

I will indeed give that a try Gergely. We're already maxed out with 4 vis points for that sector, so adding more isn't an option.