Multiple enroute sectors online

[jackharpenden]

Hello,

 

Thanks for the update, mostly seems very good so far.

 

I am currently still enroute (on VATSIM) and have noticed that where EGTT is listed on the frequency bar it only shows one listing of the sector. For example at the moment there is EGVV (Shanwick Millitary) LON_S and LON_C online showing on Vatspy. A moment ago there were three listings of LON_S on the EFB, rather than the three different sectors, and now it just shows Shanwick Millitary. - Which is no use to me when flying Civil! So it seems that it is getting confused when more than one frequency is online within a single CTR.

 

I am now however, with EURI (Eurocontrol) and it is being listed and showing on the map nicely.

 

Thanks once again, and I hope that this can be rectified.

 

Jack

[bravolima]

Hello Jack,

 

the data for the Aivlasoft EFB are actualisized from VATSIM Server but sometimes there are local agreements done by the controllers and this agreements are not listed by VATSIM server. For instance combining subzones in LONDON FIR together to be staffed by one controller. Between Copenhagen and Stockholm once I had the same problem. Langen Radar in Germany can be somtimes tricky too. In general EFB gives you a proposal of frequences, but they have to be verifyed anyway. If you monitor the communications on your frequencies formost when preceding aircraft are handled to another frequency as proposed by EFB very quickly you realisze these pitfalls.

 

hope this helps

 

regards

 

Bernhard (LSZH)

[dts]

The data for Servinfo comes from each ATC division and to be honest is updated once in a blue moon, The UK were changing there upper airspace structure during the last update so all the upper airspace in the UK will never show correctly on Servinfo/Vatspy or EFB until the data is updated.

[aivlasoft]

Dave,

 

thanks for this info. I always thought that the update of these files is well organized and regular. Isn't it?

[dts]

to be blunt NO

 

the last update was the 1st worldwide update that I can remember in about 7 years, local ATC division tended to make there own up when changes were made. This only comes an issue with Upper Airspace, as the twr and app shouldnt be a problem.

[jackharpenden]

Hello Jack,

 

the data for the Aivlasoft EFB are actualisized from VATSIM Server but sometimes there are local agreements done by the controllers and this agreements are not listed by VATSIM server. For instance combining subzones in LONDON FIR together to be staffed by one controller. Between Copenhagen and Stockholm once I had the same problem. Langen Radar in Germany can be somtimes tricky too. In general EFB gives you a proposal of frequences, but they have to be verifyed anyway. If you monitor the communications on your frequencies formost when preceding aircraft are handled to another frequency as proposed by EFB very quickly you realisze these pitfalls.

 

hope this helps

 

regards

 

Bernhard (LSZH)

Hello,

 

I believe it understands the simple structure perfectly (I am not worried about it knowing which sector covers which area within the FIR, as I am aware that ServInfo does not accommodate this feature), but the problem is seen at the top of the screenshot below:

 

It seems to know that four stations within the London FIR are currently online: LON_N, LON_S, LON_C and LON_W. However, instead of listing all four different stations it seems to list the station which has most recently logged on, being LON_W in this case and lists that individual frequency four times.

 

I think that it is just a simple programming error.

 

Jack

[aivlasoft]

Hi Jack,

 

thanks for this screenshot.

You're right, there must be something wrong here. I will have to do some investigation on that.

[jackharpenden]

Hello,

 

Something else I have noticed:

 

It shows NY_KND_CTR twice with a UNICOM in between. Also most CTR positions cover top-down on airfields within their airspace, and in this particular case this is so. - Under KEWR in the screenshot it shows Newark airport as being Unicom, whereas it is covered by NY Center.

 

These are all minor problems, as everything else within this new version seems great!

 

Thanks,

Jack

[dts]

jack maybe a picture of the NY area that is online to show the route part that you are flying

[aivlasoft]

Hi Jack,

 

thanks again. The issue with London Control I could reproduce and I could also fix it.

Do you still have this flight plan LFPG-KEWR?

[jackharpenden]

Hi Urs,

 

Here is the copied ATS routing from the EFB:

 

LFPO LGL1P LGL UN502 JSY UN160 LEDGO DOGAL 5420N 5330N 5340N 5250N CRONO DOTTY N162B TOPPS HANAA ALB V213 SAX FLOSI1.HANAA KEWR

 

After looking at this I thought in more depth, and saw "HANAA ALB V213 SAX FLOSI1.HANAA KEWR". - It seems that the FLOSI1 Arrival also includes the waypoints "HANAA ALB SAX" so it was shown twice due to duplicated waypoints. This was why there were two instances of NY_CTR with a Unicom inbetween. So this was more my mistake.

 

There is however a screenshot below if you wish to see what I have explained above:

 

Also you may now note that NY_KND_CTR has loaded up an ATIS for KEWR so it no longer shows as UNICOM rather with the ATIS frequency.

 

Jack

 

P.S. Just noticed something else, it seems that whenever a NY_CTR is online, the EFB fills in the NY oceanic sector in as well. These are shown separately in ServInfo, so this problem only exists with the EFB. - In terms of callsign differential for the two, the oceanic sector is usually 'NY_JBC_FSS', whereas the NY area control being 'NY_KND_CTR'. The main difference being the ending of either FSS or CTR.

[aivlasoft]

Hi Jack,

 

thanks for pointing at the "NY_" situation. From the information given in the two files "fir.dat" and "servinfo.dat" it is not possible to exactly determine whether the oceanic area is staffed or not. I will try to explain how.

 

Let's assume that the following two controllers ("callsigns") are logged in:

NY_KND_CTR

NY_JBC_FSS

 

The two letters "NY" are the key for the area. I assume that "KND" means "Kennedy", I don't know what "JBC" means. "CTR" means "Center", "FSS" is somehow similar to a "Center".

 

Because the endings of two callsigns are CTR/FSS, the service must be a control area (not an airport). In the file "servinfo.dat" we must now look for a "control area" with a key "NY" or an alias "NY". There is one area in the [Controls] section which has an "NY" alias and "KZNY" as a 4-letter ICAO key:

 

[Controls]

KZNY/New York/NY/

 

It seems that this is the area that we searched for. Now the 4-letter ICAO code points to the FIR/ARTCC boundaries which are listed in the file "fir.dat". Unfortunately there are two boundaries and each of them has "KZNY" as a key:

 

[FIRs]

KZNY,32,18.000000,-77.000000,45.000000,-40.000000,K+ oo,31.500000,-58.500000

KZNY,72,37.227500,-78.127778,42.941667,-67.000000,KZ255dd,41.000000,-75.500000

 

 

If it were clearly defined in some papers I could "hard-code" that "NY_JBC_FSS" means the oceanic sector whereas "NY_KND_CTR" means the New York area, but as always "hard coded" items are dangerous and not really flexible .

 

Any other ideas?

Are there other "secret" definitions that we must be aware of?

[dts]

FSS - Flight Service Station

 

This is only selected so online controllers can see excessive distances.

 

Good luck on this task Urs, this is mammoth.

[jackharpenden]

If it were clearly defined in some papers I could "hard-code" that "NY_JBC_FSS" means the oceanic sector whereas "NY_KND_CTR" means the New York area, but as always "hard coded" items are dangerous and not really flexible .

 

Any other ideas?

Are there other "secret" definitions that we must be aware of?

I am sure there will be many other callsigns for NY Area other than just 'KND' and I reckon that they'll also be more for the Oceanic (Flight Service Station) Sector. - Also when shift changing, a controller may use '_1_ ' or an extra underscore in their callsign, meaning that hard-coding those would mean that fairly often it would not appear at all as online in the EFB.

 

From glancing over Servinfo, it would seem that the same problem would apply to the Miami ARTCC, where the oceanic sector also uses the 'MIA' prefix. It seems that all the areas on Servinfo that are shown with Oceanic at the end, e.g. SUEO (being the area control) and SUEO Oceanic, both use the same prefix. An example is below:

 

{Note that there is KZHU along with KZHU Oceanic and KZMA along with KZMA oceanic}

 

Along with other airspaces the problem affects Gander (CZQX and CZQX Oceanic) in the same way, but does not affect Shanwick (EGGX) even though it is an oceanic sector; because it only has one instance and therefore is only listed as EGGX in Servinfo (rather than EGGX Oceanic) due to there being no separate EGGX radar service within another location.

 

I would imagine that it will affect all airspaces that use the same callsign prefix for both the Area and Oceanic sectors and which are only differentiated from the ending of either _FSS or _CTR.

 

So I am really not sure of as to what can be done to fix this problem, except for implementing something in the coding relating to the use of _CTR or _FSS.

 

Hope this helps,

Jack