Mentor and Student ID's

[Eivind Fosse 818131]

Hi,

 

When I log on as CTR during a training session at a TMA below I often see that the mentor is given the Controller ID that is usually owned by the sector the student is controlling.

 

For example ENGM_APP uses the ID AR. However very often AR is given to the mentor while the student is stuck with a number.

 

This makes some problem if there are a lot of traffic as the handoff will have to be done manually.

 

I understand the ID is given based on what frequency the controller uses so I've tried to add another ID to ENGM_APP further down in the ESE - ID AM. I would expect this order to give the first ID, AR, to the controller connecting to the primary frequency corresponding to AR first, and then the next controller (the mentor) will be given AM. Unfortunately this is not how it works... Initially the student is given AR, but as soon as the mentor tunes in to the primary frequency he is given AR and the student AM.

 

The only solution seems to be that the mentor does not tune into the primary frequency at all, but then he will not see the departure, exit and inbound lists.

 

Is there a way for me to fix the ESE file so that the mentor (ENGM_M_APP) is given a unique ID and still is able to see all aircrafts in the lists?

 

Thanks

[Johan Grauers]

What we've been doing during my ESSA training is that I sign in as ESSA_app and my mentor as ESSA_E_APP. Since E is the primary sector (we only drop the E when there's just one sector online) we both get the same airspace and see identical data.

 

This works where there's split TMA's though (ESSA and ESGG for example, or ENGM).

[Eivind Fosse 818131]

Yes, I see your point Johan. However that will not work in Norway as most sectors trained on is not split. And those who are are controlling different airspaces. If you log in as ENGM_E_APP you will not be controlling the same airspace as ENGM_W_APP and therefore your lists will be completely different.

[Stephan Boerner 945550]

The mentor is not supposed to have a primary frequency at all. The student is online as ESSA_APP, so he is the one with the primary frequency set. Even if the mentor joins the frequency, he must not set the same primary frequency as the mentor, because by network design the primary frequency is supposed to be unique (so it is not even an ES issue. As far as I know, doubled primary frequencies can confuse pilot clients as well).

[Eivind Fosse 818131]

I see.

 

So then the mentor will not be able to see the aircraft lists at all when he is mentoring? Or will they appear in his lists if he tunes in on the same freq as the student, but without marking it as primary?

[Stephan Boerner 945550]

The mentor will see the pilots on the frequency, because he is on the frequency. That is not linked to the primary frequency.

 

The lists are based on airport/runway settings and sector ownership. So the mentor needs to manually set the owned sector and/or the active airports/runways. Unfortunately at present there is no really comfortable way to match trainer and trainee.

[Eivind Fosse 818131]

I see...

 

Ok, thanks for the answer anyway!

[Jonas Eberle]

I experienced no problem if two stations are set to the same PRIM if THEY SET THE EXACT SAME VOICE SERVER/-CHANNEL.

 

I asked our Trainingsdepartment if there are any official rules that stand against it.

 

That your student does not get identified as the "primary" controller (e.g. having the number, while the mentor has the correct sector indicator) for this sector by other controllers (ES and VRC alike) is kind of random. From what I found out, the controller that LAST set his PRIM will be identified as the active one by other controllers. From the mentor's side, your student will always be "unidentified" which is exactly what you want because this way ES sets the mentor as active for the sector and shows handoff borders, departure lists etc. on the mentor's machine.

 

Controllers are "identified" (given a sector indicator from the .ese) based on

1) frequency

2) prefix

3) suffix

solely. That means that with a line similar to this:

EDDS_TWR:Stuttgart Tower:118.800:DST:T:EDDS:TWR:::2140:2157:N048.41.22.800:E009.13.18.830

any station with freq 118.800 and login like EDDS*TWR will be recognized as "DST". If a second station meets the same requirements, a number will be given. As I said, how to FORCE one as the "primary" station is not completely clear to me.

[Eivind Fosse 818131]

I experienced no problem if two stations are set to the same PRIM if THEY SET THE EXACT SAME VOICE SERVER/-CHANNEL.

 

That is exactly the same as I see. Since both are in the same voice channel the pilot will not know if it is the student or mentor he has connected to. And the whole point is that the student and mentor is on the same servers and channel. Why would they not be?

 

From what I found out, the controller that LAST set his PRIM will be identified as the active one by other controllers.

 

Unfortunately this is not correct... However I can not understand why it does not work like this... I've tested a lot regarding this issue and every time it seems completely random. However, for some reason, it seems like it is airport specific as well... For example at ENCN_APP the student will be given the correct ID - CN, while the mentor will be given C1:

 

Kjevik TMA:Kjevik Tower:119.950:CN:A:ENCN:APP:-:-:4200:4277:N055.11.56.917:E008.39.10.919

Kjevik TMA:Kjevik Tower:119.950:C1:A:ENCN:APP:-:-:4200:4277:N055.11.56.917:E008.39.10.919

 

However the Tower positions are reversed. CNT is the correct one, for some reason given to the mentor, while CX is the mentor ID given to the student:

 

Kjevik TWR:Kjevik Tower:118.100:CNT:T:ENCN:TWR:-:-:4200:4277:N058.28.26.214:E006.23.24.243

Kjevik TWR:Kjevik Tower:118.100:CX:T:ENCN:TWR:-:-:4200:4277:N058.28.26.214:E006.23.24.243

 

Just to clarify - the same happens if the two mentor ID’s are removed from the ESE and are replaced with numbers instead. I’ve also tested to ask the mentor to set his Prim freq after the student has done so. What happens is that initially the student has the correct ID:

 

ENCN_TWR – CNT

ENCN_M_TWR – 61

 

Then I ask the mentor to tune into the same Prim freq with this result:

 

ENCN_TWR – CX or 61

ENCN_M_TWR – CNT

 

any station with freq 118.800 and login like EDDS*TWR will be recognized as "DST". If a second station meets the same requirements, a number will be given.

 

Yes, this is also what I would expect. It works this way all over the ESE – the first line that matches is used as the correct one. But as I’ve shown above that is not the case. So why does it not work this way regarding the ID’s?

[Wycliffe Barrett]

Hello

 

I have read this post with interest, and I thought what we did here in the UK was a universal thing when it comes to mentoring. There has been a lot of debate in the UK about mentors controlling when mentoring.

 

The general consensus being that this is an aunfair situation because if a mentor who is say controlling an adjacent position gets busy then surely they can't be giving all their attention top the mentoree.

 

What we do for example is really quite simple

 

The mentoree will have a designation of EGFF_T_APP

 

The mentor will be EGFF_M_APP

 

T for training M for Mentor the mentor does not have a primary frequency set but can see all aircraft and can if required take over the session by using the facilities within Euroscope or VRC.

 

Wycliffe

[Eivind Fosse 818131]

the mentor does not have a primary frequency set but can see all aircraft and can if required take over the session by using the facilities within Euroscope or VRC.

 

Hi Wycliffe,

 

Unfortunately that will not solve the problem fully... Since the mentor is not using a primary freq he will not be given the ID intended for the student, so that problem is fixed this way. However it will not show airplanes in the various lists (Departure, Exit and Inbound lists) (since the mentor now does not have a primary freq i.e. he does not own an airspace and no aircrafts will enter the mentors airspace) and that is drawback. The mentor should be able to see the contents in the lists as well, and if he is not tuned into a primary freq that does not seem to be possible...

 

Eivind

[Wycliffe Barrett]

Works for me, can't explain how it just does.

 

Wycliffe

[Eivind Fosse 818131]

Strange...

 

So you get the lists as well when you've not selected a primary freq? Maybe because you use the _T_ in the student callsign?

 

I would not know... I'll check it out.

[Ross Bristo 1010003]

Works for me, can't explain how it just does.

 

Wycliffe

 

Maybe you're just doing it for APP? If so then you can just tick the arrival and departure airports.

 

From what i gather, the mentoring is happening on CTR, so the mentor wont get anything in the sector inbound list because he is not the owner of that sector. He could get the arrivals in to airports within the students airspace but any overflights wont be received by the mentor.

 

I only skim read the post so i maybe wrong on the scenario.

[Gergely Csernak]

Edvin,

 

If the mentor manually allocates owned sectors then he should see the same lists as he had the ID allocated.

About random ID allocation: I always loop over the controllers to allocate ID for them in the order they first time appeared. But that is somehow really random. Every controller sends his position data in about every 15-20 seconds. When you log in it is really random where the other controllers are in their delay time.

[Eivind Fosse 818131]

If the mentor manually allocates owned sectors then he should see the same lists as he had the ID allocated.

 

But you won't be able to set the owned sectors unless you have set a primary frq...

 

When you log in it is really random where the other controllers are in their delay time

 

Does this mean that if the mentor tunes into the prim freq more than those 15-20 seconds after the student, he should be given a "mentor" ID since the student already is given the primary one? Or is this loop going constantly so that won't help either?

 

Eivind

[Jonas Eberle]

About random ID allocation: I always loop over the controllers to allocate ID for them in the order they first time appeared. But that is somehow really random. Every controller sends his position data in about every 15-20 seconds. When you log in it is really random where the other controllers are in their delay time.

Hi Gergely,

 

can this somehow be influenced by setting the PRIM in a specific order, e.g. "student sets it, then after 30 seconds mentor sets it"?

The advantages of mentoring with PRIM are immanent, would be great if we could find out a scheme how handoffs will work as usual for other stations.

[Eivind Fosse 818131]

can this somehow be influenced by setting the PRIM in a specific order, e.g. "student sets it, then after 30 seconds mentor sets it"?

The advantages of mentoring with PRIM are immanent, would be great if we could find out a scheme how handoffs will work as usual for other stations.

 

Exactly as I would have said it

[Jonas Eberle]

Thanks Elvind

 

Just on a sidenote:

But you won't be able to set the owned sectors unless you have set a primary frq...

This was reported to be on the beta-forums already as a feature request

[Eivind Fosse 818131]

This was reported to be on the beta-forums already as a feature request

 

 

As you can imagine I have no access to the beta forums...

 

Eivind

[Gergely Csernak]

But you won't be able to set the owned sectors unless you have set a primary frq...

 

That is true. But when you select the sectors manually you can have any kind of frequency. You can create a dummy position for the mentor then you can allocate sectors for yourself.

 

There is no way to change the order how the IDs are allocated. As it does not depend on the sequence of the login and primary frequency allocation, but purely on when the others log in. If the student logs in, selects a primary frequency, then mentor logs in and selects the same frequency then it will be correct for all who already logged in. But will not necessarily work for the ones who will log in later.