SECTOR - What am I doing wrong here?

[Ali Abou-Zeid]

Hi again,

 

SECTOR:CAIRO_CTLZ:0:3500
OWNER:CT:CA:CC
BORDER:HECA_TWR

SECTOR:CAIRO_TCA:3500:24500
OWNER:CA:CM:CC
BORDER:HECA_APP

SECTOR:CAIRO_FIR:0:65000
OWNER:CC
BORDER:HECC_CTR

 

This is what I have.

 

A quick explaination, Cairo Tower (CAIRO_CTLZ) controls the lateral limits specified by HECA_TWR (SECTORLINE) and vertical limits from GND to 3500'

 

Logically, Cairo Tower (CT) has higher priority on this position, then Cairo Director (CA), then Cairo Control (CC).

 

When I logged in as HECA_APP (CA), and a controller logged in as Cairo Tower (CT), nothing happened. I still had the whole area in the same colour, while the area outside the TMA was with the different inactive colour.

 

Same happened when I logged in as CTR lateral limits are defined by HECC_CTR and the sector CAIRO_FIR has vertical limits fro 0 to 65000' and it's got only CC to have priority over it. No other station can control the whole airspace.

 

Now, I had tested the DISPLAY option in the sector line here. Now when HECA_APP logged in, the sectorline was highlighted perfectly, however, the area inside it wasn't dimmed (changed to inactive colour).

 

Is there something I'm doing wrong here with priorities, or what?

 

Edit: Ah, if I may add, if I log on with each individual station alone, its area of responsibility is changed in colour for the active colour, and the area around is changed (stays) the inactive colour.

[Sami Ylismaki 878340]

You have to remember that the airspace above the tower is controlled by APP and the airspace above it is controlled by CTR, therefore making the airspace active. If TWR would create an inactive area in the middle of your CTR airspace, then that would mean nobody controls the airspace above 3500ft over the area of TWR.

 

Another problem here is caused by your attempt to cut a polygon from the middle. It simply doesn't work in EuroScope. If you really want to have a blank spot in the middle then you would have to define the inner borders as well, which however would cause EUS to complain about unconnected borders, which again means you'd have to split APP and CTR airspace in two halfs of sector to converge around the area of TWR and APP.

 

Eitherways, the airspace above is active and you own it when you control a position above TWR. Use highlighted airspace borders to mark the presence of a controller below your airspace. The active area in real life doesn't use inactive colour in the presence of a position below the airspace floor in the real life either.

 

Use inactive area only when you really don't control any vertical area of an airspace.

[Ali Abou-Zeid]

So, actually, there's nothing wrong that I'm doing here?

 

Cool!

 

Let me try something, then.

 

If I (for the sake of trial) increased the vertical limits for TWR to be 65000, then when I'm on CTR and TWR logs on, it'll colour it as inactive, correct?

 

If so, then, now I got what the whole thing is about!

[Gergely Csernak]

Ali,

 

Actually you will not have what you would like to. As Sami told the coloring of the active and inactive sectors are simply based on the sector polygon definition. EuroScope simply clears the whole screen with inactive color then in a loop draws all active sector polygon with active color. There is no polygon overlay, no polygon subtraction code behind. So the coloring will not be changed if you change the vertical limits of TWR.

 

On the other hand when EuroScope calculates the aircraft route, then it will work correctly. If TWR limit is 3500' and an AC crosses the sector at FL200 then it will not show the TWR sector as part of the route. But if you change to 65000' the it will sign that you have to p[Mod - Happy Thoughts] the tracking to the TWR position. But this logic is once again does not come from any complex polygon overlay. It just a precedence. If you define TWR sector first in the ESE then it will work, as it will find one point along the AC route is inside the TWR sector. But if you define TWR sector after CTR sector, then ES will never find it as it stops searching for sectors if finds one.

[Opher Ben Peretz 882232]

Servus Gergely,

just my humble opinion: .ese. file creation is not a straightforward task. Figuring the program out isn't either. Unless proper detailed instructions are available, I believe it will put off many potential users, resulting in their abandonment of EUS. The whole program lacks this kind of docomeentation helping understand its use for ATC services. I don't even know where the description is on how to select an aircraft, the use of multiple channel text window display, and actually most everything. I see here 3-4 people doing well, maybe many silent ones too, but I expect the majority of candidates to spend many many hours trying to figure the program out without such aid. I have been doing this for two weeks now and have not started using it for even the most basic ATC services.

[Ali Abou-Zeid]

Gergely, thanks for your support.

 

From what you said, the screenshot in the docomeentation is basically just multiple FIR boundaries that you are in control of as EuroControl FSS, and then when one came in, it's marked as inactive?

 

With that, then I'm doing quite well, and Egypt VACC's compatibility with ES would be ready in a few days. I wrote a tool that converts from ASRC ARTCC data to sectorlines in ES. I'll fine tune it and upload it.

 

Opher, I find ES very easy to use. I downloaded it just before an event, and during the event I was using ASRC, and reading the docomeentation for ES while exploring the program itself. After an hour, I was using ES easily and everything was really going smoothly.

[Gergely Csernak]

Ali,

 

Yes, exactly. In the EuroControl East ESE I defined a sector for each FIR. Of course I defined the local controller as first priority and the FSS position as second. So there the sectors are reallocated well.

 

But if you continue more down on this page (http://euroscope.hu/wiki/index.php?page=Sectors_And_Aircraft_States), you can see the first Hungarian ESE file. There you see that Wien Radar is online. There is a small area between GIGOR and LOWW. It is the so called GIGOR box. It is actually inside Hungary, but as really close to Wien, the lower airspace is controlled by Wien Approach. So it has a red border indicating an active handoff area, but still displayed as active are as I control the top levels. Just as in your case.

[Opher Ben Peretz 882232]

Opher, I find ES very easy to use. I downloaded it just before an event, and during the event I was using ASRC, and reading the docomeentation for ES while exploring the program itself. After an hour, I was using ES easily and everything was really going smoothly.

Marhaba ya Ali,

good for you! I read your original post on this. Is this the general case for users? I doubt it, I've been around, know well all division controllers and instructed and evaluated many of them and others in my division. Anyway, for me with my background, exeprience and rating, I'd describe the experience this way:

After the software went into public beta, I installed it, studied it and soon thereafter abandoned and uninstalled it.

Then came its official debut under Vatsim, so for the purposes of the division and then myself, went through it. On the one hand it is innovative and as close to the real thing that we ever had, but on the other, there is the Chinese wall between it and my smooth utilization. One example here: No way to get metar reports for most of the airports I tried, no matter how long the wait; EGLL replies in less than a second but LLBG and many others, KJFK included- never. Nevertheless I took upon myself to slowly develop an .ese. file for our division. I have yet to see an active sector light up and do not even know what to expect, as this is not specified in the docomeentation I have. I will keep trying hoping it won't be necessary to compile many similar letters by others, before literature is developed to make its use and mostly its file development reasonably easy. Ross did a marvelous job on both VRC and docomeentation, but even there I didn't find the extraction of mouse coordinate feature instructions, an important tool in sector file development. As experimental test pilot who flew anywhere on the globe, I met quite ingenious aircraft designs, except they were unsuitable for humans to pilot.

 

I congratulate Gergely and the people help him, their achievement is really a ground breaker. Let's try to make it easy to understand and use.