They did it again.

[Andreas Fuchs]

Lemonade

 

On VATSIM I ignore the NORDOs, I tell pilots in my airspace to ignore them as well. So far I have had no complaints from pilots yet.

 

And in the real world nobody gets shot out of the sky for being unresponsive. Normally ATC will try to get in touch with pilots for about 15 minutes through the various channels: main frequency, relay through other pilots on main frequency, emergency frequency (121.50, "guard"), the company/airline that the plane belongs to: they can send them a message through ACARS or call them through SATCOM. The last resort will then be a pair of interceptors, who are going to try to wake up the pilots by one of the interceptors flying parallel to the plane at close distance, the other one trailing the plane in question at some distance (for better aiming, should it be necessary).

 

At VATSIM I sometimes wish we could send up some interceptors as well and wake up pilots: while they may not be able to see them, their TCAS will sure start shouting at them!

[Erik Wachters]

Probably the last thing I say in this topic:

Unfortunately I do not have a flight attendant at home!

You definitely have to do something about that

 

Next time a pilot that finally responds after trying for a while will think he has a microphone problem

 

Erik

Edited August 30, 2016 at 07:19 PM by Guest

[Kyle Ramsey 810181]

If you were in the other seat you'd be eating chicken.

[Andreas Fuchs]

Or first the cake

[Gunnar Lindahl]

I'm surprised a SUP would leave a pilot who is unresponsive in controlled airspace for 30 minutes - let's be clear that B(3) requires pilots to check for ATC coverage and contact the controller immediately on request, so there's no time lag which the SUP has to wait to elapse before he/she takes action.

 

That said, common sense applies and it's here that the SUP asking "is the pilot currently in conflict?" is a crucial question. If they're not, I'll give them a few minutes, maybe up to 10, to wake up and contact the controller. Then I'll disconnect them. If they are in clear conflict, I'll remove them straight away (after giving them a couple of minutes to respond) because that's going to inhibit the enjoyment of both the pilot and controller.

 

As for some people in this thread claiming feedback via email gets you nowhere... I see no emails in my inbox about this. Why not try me?

[Ernesto Alvarez 818262]

as far as other pilots complaining about another aircraft being "NORDO" or unresponsive. does it surprise me? no, far too many VATSIM pilots spend way too much time worrying how someone else is playing "the game". then they also complain that the "other" pilot caused them to not remember to put their gear down or cause them to crash in some way. my response is always the same to these users, nooooo you spent too much time trying to be a backseat pilot instead of worrying about your own flight.

 

ive also had pilots complain because i had them separated by the standard 10nm, its like some freak out the minute they actually see another aircraft in the air near them.

 

my point is, there will always be someone complaining or whining about this or that, especially online. i dont take them that seriously. if someone wants to complain, i guarantee you they will find something to complain about, especially like i said before, those that are much too caught up on what someone else is doing

[Jonathan Fong]

Well, there is a possible conflict between CoC clauses A9 and B3 - a situation where the pilot leaves their computer, ATC logs on while they are gone, and their plane enters controlled airspace with the pilot still AFK - HOWEVER, the pilot returns within the allotted 30 minutes and contacts ATC. Surely the pilot cannot be at fault in such a situation? After all, no one can sense when enroute coverage will come on just as you go to make some coffee or heat up some food.

[Bradley Grafelman]

the pilot returns within the allotted 30 minutes and contacts ATC.

There's no conflict, because the quoted part of your post is inventing something that isn't in the CoC - an "allotted" amount of time. A9 says you are not allowed to exceed 30 minutes of unattended time. It does not say anything about minutes 0 through 29. For those minutes, A9 doesn't have any relevant language and thus isn't applicable. If a SUP decides to give you (30 - x) minutes to respond, that's his/her prerogative. It's not required or guaranteed, though (at least, not on a CoC/CoR basis).

[Simon Kelsey]

As Bradley says, the CoC says...

 

a member is not permitted to leave his or her connection unattended for a period in excess of thirty (30) minutes.

 

30 minutes is a maximum, not a minimum, and my own interpretation has always been that in controlled airspace all bets are off (whether it was controlled or not at the time I left).

 

Personally, my house isn't so large that putting the dinner on and keeping half an eye on the connection are mutually exclusive -- I make sure the vPilot sounds are coming through the speakers so that if I get a PM I (hopefully) will hear it from the kitchen and I just pop up and cast an eye over it at regular intervals, especially if I'm flying through a region where ATC coverage is fairly regular, and doubly so if it's a time of day when ATC is likely to be logging on. If I'm in any doubt about being able to be on hand to reply to a message, I just disconnect and rest easy!

[Deon Mathews]

Ran into a similar situation some time ago when I still did controlling and admittedly got somewhat annoyed at the sup for allowing a situation in the airspace I was controlling. In his defense he quoted the VATSIM CoR 6.04 "Sole Discretion: It is within the sole discretion of the individual authorized by this rule to determine whether the conduct of a member warrants removal or temporary suspension of said member.". That was the end of that conversation.

 

I suppose therefor that the outcome of any non responsive call depends on the sup that responds within the 30 minute window.

 

Deon Mathews

[Adam Trzcinski]

Most supervisors I had the pleasure to work with are fairly good with that discretion they can use. If the traffic will impact someone else's flightpath and fun, they are usually more in favor of B03... if I just logged on and have been connected for less than 30min as ATC... they usually are more in favor or A09. But in the end, the sups deal with the situation.

[Don Desfosse]

As Brad and Simon correctly say, A9 allows for a maximum of 30 minutes away. B3 trumps A9, however. Technically, going to an extreme for example purposes only, once you enter controlled airspace (or once a controller logs on), you are allowed exactly zero seconds away from your connection.

 

Like I say, that's taken to the extreme for the purposes of an example. In most cases (though not all, sadly) most controllers will allow a reasonable amount of time (e.g. 5 minutes) before trying to hail the pilot, and will allow even more reasonable time before hailing a Supervisor. We all know that it's possible that a pilot, seeing no ATC ahead, may step away for a bathroom break, to grab a bite to eat or something to drink, shut the garden water faucet off, etc., and Murphy's Law being what it is, a controller will pop on seconds after the pilot steps away. That's why being reasonable is so important. But, all too often, that's not how it truly is -- it's someone who has been away for a very long time and is likely to be away for a very long time....

 

One note that we should all appreciate -- a draft of changes to the CoC is currently in review at the BoG level, and amongst those changes is clarification to the applicability of A9/B3 in uncontrolled vs. controlled airspace. Cliff's Notes: B3 trumps A9 in controlled airspace.

 

As a Supervisor, I try to ensure with a NORDO pilot report that I know a few facts before taking action.

- If there's an immediate conflict, I sent a quick note to the pilot and disconnect him to prevent against a negative experience for the controller and the other pilots nearby.

- If the controller just logged on (yes, amazingly some controllers will .wallop within only a few minutes of logging on -- and I really wish controllers would stop doing that unless an immediate conflict is brewing, and I wish all instructors reinforced not to do that!), I give the pilot the benefit of the doubt.

- If there's not an immediate conflict, I attempt to find out how long the controller has been attempting to reach the pilot, and I try to spend a reasonable time attempting to reach the pilot. How long I let it go depends on a number of variables, including potential conflicts, how long ATC has already been trying to reach the pilot, if the pilot has a history of unattended connections, how busy the airspace is, how busy the Supervisor is with other cases, etc. As was mentioned, most Supervisors try to use good judgment and good balance, taking those variables into account, and hopefully (workload permitting) most Supervisors actually communicate with the controller to let them know their approximate plan.

 

As a controller, one thing that I generally do, when I log on and see that there are people in my airspace that may not be aware that I just logged on, is send a text message on unicom that says something to the effect of: "XXX_CTR is now online, 1xx.xxx" This gets, on average, about 65% of the pilots out there who are dutifully monitoring unicom to call me. The others, I generally send another message, on unicom, directed at their callsign, that says Contact XXX_CTR on 1xx.xxx For those controllers/Facility Engineers that choose to add it to their facility's standard alias file, it could look like

.cme Contact $callsign on $com1

 

I use the .contactme as a last resort. It it the least realistic option; the hailing attempts on unicom mirror what the RW would do on guard.

 

Too harsh and we lose people. Too loose and we lose people. That sweet spot in the middle where everyone gets better/smarter and has more fun is a tough place to find, but a great place to be. Let's all look for that sweet spot that maximizes the enjoyment of the network for everyone....

[Andrew Morkunas]

I generally send another message, on unicom, directed at their callsign, that says Contact XXX_CTR on 1xx.xxx For those controllers/Facility Engineers that choose to add it to their facility's standard alias file, it could look like

 

As a controller, how do you send a message on UNICOM? How do you set 122.8 in the controller client?

[Ernesto Alvarez 818262]

same way you set any other frequency, nothing special about 122.80

[Robert Fersch]

This is an interesting discussion and I understand both sides of it. Perhaps we should add to the Code of Conduct a requirement that a pilot who, when ATC is absent steps away temporarily for those reasons already mentioned, place a message in remarks or other suitable place explaining the absence. Like: "No ATC observed ahead, grabbing a snack, back in :15."

 

I believe most members follow the CofC and want to do the right thing. This would help everyone to quickly understand the situation and resolve it.

 

Best Regards,

Bob

[1275389]

Like: "No ATC observed ahead, grabbing a snack, back in :15."

If this were to be implemented, should be in zulu, since no one knows when you updated. "Back at 2223Z."

[Robert Fersch]

If this were to be implemented, should be in zulu, since no one knows when you updated. "Back at 2223Z."

 

Yes. that's even better.

[Andreas Fuchs]

There's just one problem: once ATC has modified your flightplan (squawk [Mod - Happy Thoughts]igned, SID [Mod - Happy Thoughts]igned etc..), then it is locked. As a pilot you cannot change it anymore. We would rather need a new function in our pilots clients, where we could set this "time away".

[Camden Bruno]

We would rather need a new function in our pilots clients, where we could set this "time away".

 

As a controller, if I step away from the scope for a couple minutes, I always set .busyall [Optional Message]. This restricts private messages from pilots, other controllers, etc. In the optional message portion, I state that I am away for whatever reason and will be back shortly.

 

I am not suggesting we allow pilots to restrict/not accept private messages from controllers with a similar command, however, perhaps something similar could be setup so that when a pilot receives a private message (i.e. Contact Me) the pilot client could auto-respond to whoever sent the message with a message the pilot has set regarding their "time away." I'm sure Ross could incorporate this to vPilot fairly easily.

[Nicholas Cavacini]

Any such message or communication does not relieve the pilot of the responsibility to contact ATC.

[Ernesto Alvarez 818262]

there would have to be policy changes in order to accommodate such a feature. even on the ATC side the .busy doesnt relieve the controller of their responsibilities online.

 

like any feature though, if it gives the opportunity for someone to take advantage of it, youll be guaranteed they will (plenty already try to find ways around the unattended connection clause)

[Robert Fersch]

I expected that there could be issues with the "how to" and valid concerns about the possibility of people abusing the system and ignoring their responsibilities.

 

I'm no technical expert. If it is something we decide to implement, hopefully there is a way to enter this information. A pilot's responsibilities to contact ATC would not change. And for those inclined to take advantage, they are probably already part of the problem.

 

When I look at at who's online, the majority of pilots fly in uncontrolled airspace. Are all these pilots at the controls every minute, I doubt it. Also, are all these pilots irresponsible people unconcerned with the Code of Conduct, I really doubt that.

 

So, unresponsive pilots are one of, if not the most, common problem for ATC and supervisors. Erik had some in his airspace and called a supervisor. Erik did his job, the supervisor did his. Nobody did anything wrong but the problem persisted. It seems to me we need to give Erik, ATC and supervisors a better way to identify, understand and resolve these issues.

 

Respectfully,

Bob

[Nicholas Cavacini]

Supervisors already have ways of identifying these types of issues and others.

[Robert Fersch]

Supervisors already have ways of identifying these types of issues and others.

 

Okay. I understand. It was not my intention to upset the apple cart.

 

Regards,

Bob