And chance of voice CTAF on vPilot?

[Ross Carlson]

Our current procedure works like this: each aerodrome is [Mod - Happy Thoughts]igned a frequency (this is done for us by the government). Nearing a non-towered aerodrome (read: there is literally no control tower), pilots tune said frequency and either manually (Squawkbox) or automatically (FSInn) tune the appropriate voice server/channel.

 

It is not a perfect solution and misses almost all of the edge cases (aerodromes near each other with the same frequency, voice server goes down, etc.) but it works 99% of the time.

 

Why do you say it doesn't work for adjacent airports with the same frequency?

[Ernesto Alvarez 818262]

it would probably be better to have something the pilots cant edit, instead the list is downloaded just like the server list from the servers. this will kinda prevent the issue of people being on different voice servers. FSINN's is editable, which means the minute anyone changes anything in that file, whether its the channel name, position, or server, its no longer guaranteed that someone else is going to be on the same server/channel

[Ross Carlson]

it would probably be better to have something the pilots cant edit

 

Yup ... have a look at this post of mine on the first page:

 

viewtopic.php?f=8&t=70437#p495961

 

If such a feature were adopted officially, then the mapping file would definitely need come from a VATSIM server and not be editable.

[Ross Carlson]

I'm going to write up a summary proposal for the BoG to see if there's a chance voice CTAF could get approved.

 

I'm thinking it would work like this:

 

• Pilot clients would download a voice CTAF mapping file from the VATSIM servers upon startup, similar to how they currently download the server list.
  
• Each entry in the mapping file would represent an airport with the following fields: airport ID, frequency, voice URL, range
  
• As the pilot flies around, the client is continually checking to see if the aircraft is within range of any entries in the mapping file, and tuned into the [Mod - Happy Thoughts]ociated frequency. If so, join the voice channel.
  
• If there is a controller in range on the same frequency, don't join the CTAF voice channel, join the controller's voice channel instead. (This is necessary for controlled airports where the tower frequency reverts to CTAF when the tower closes after hours.)
  
• It is possible for the client to be joined to more than one CTAF voice channel if the aircraft is within range of more than one airport and those airports share the same CTAF frequency. (Quite common, at least in the US.) The pilot would have no idea that he's on multiple voice channels ... he just knows that he's on the CTAF frequency.
  
• By way of VATSIM policy, if a user makes a text transmission on the CTAF frequency, all other pilots operating at the same airport must use text until the text-only pilot has left the area.
  
• The pilot client would have some way of quickly sending common CTAF transmissions on text ("KMPV traffic, turning final runway 35", etc.)

 

There is one issue that I'm not sure how to deal with. In the scenario where there's a text-only pilot in the area, how will other pilots know when it's safe to switch back to voice? Since the first text transmission means everyone needs to switch to text, if a new pilot arrives while everyone is on text, how will that new pilot know which pilot is the text only pilot, and thus know when that pilot has vacated the area, and that it's now safe to switch to text? Without a way of identifying the text-only pilot, it's possible that an airport's CTAF frequency could get converted to text-only and stay that way well after the text-only pilot has left the area, if the airport is busy enough.

 

One solution I was thinking of for this is to tag the text transmissions from text-only pilots with some sort of prefix such as "[text-only]". One benefit of this approach is that it would allow everyone to differentiate between text-only and voice-receive-only pilots. Full voice capable pilots would NOT need to switch to text if there's a voice-receive-only pilot in the area. (Such as a pilot that doesn't have a working mic, or doesn't want to disturb other people in the room by talking, but can still receive voice on headphones.)

 

Anyway, I'd like to get some feedback about this approach before I write up a summary proposal for the BoG. Would this type of set up work for non-US countries? Should we call it something other than voice CTAF? (I'm not sure what they call pilot coordination frequencies in countries other than the US and Australia.)

[Bruno Cote]

I am back into VATSIM after being away from it for not quite 10 years. Interesting to see that the same topics are being debated today.

 

Anyhow, I thought I would come back to this thread just to show my support for the idea. I was pleased to see that Ross had actually came up overnight with a tangible proposal that may work. That is just great!! I think it is important that VATSIM progresses with this feature, as other networks have the possibility for voice CTAF. When I got back into flight simming, I thought I would go to a network allowing voice CTAF, just for that single reason, but came tot the conclusion VATSIM has things other networks just cannot offer, ie. the dedication of the people who spend hours controlling on here just for the fun and experience of it. Still I think it is important that VATSIM tries to keep up in order to implement these feature long-awaited by many members.

 

I was wondering if there would be a benefit of VATSIM making an actual survey of members to see how many are really opposed to the idea of a voice CTAF, perhaps that would be the best way to get the pulse of the entire community.

 

I looked at the proposal, some thoughts...

 

If a pilot was in the range of a voice controller, say center... but there is an uncontrolled airport underneath his airspace... does the proposed protocol allow the pilot to join the voice frequency of the uncontrolled airport.... I re-read the proposal several times, maybe I do not grasp the technicalities, but the protocol seems to say that it would not be possible (I am sure I missed something here).

 

One person had recommended an opt-out option in a post above....I am thinking it may sound like a good idea perhaps ... as long as that does not make him a 'text-only' pilot and obliges everyone else to revert to text CTAF. I understood that the reasoning behind the proposal was that perhaps some of the pilots on voice unicom may not be so effective at their voice communications.

 

I am also wondering if there may be a benefit to have the pilots 'voice-CTAF-certified' to increase the chances that the pilots will be using more effective the CTAF. Perhaps it can even be included as part of one of the VATSIM pilot ratings (P2, P3???). That would give a tangible incentive for pilots to make the additional effort to go through the pilot training program as there would be a tremendous benefit for them to do so.

 

In the case that a pilot is not able to use voice for any reason (or not certified if that is requirement), I am wondering if a risk-management approach could be used instead of the traditional philosophy of 'if there is one pilot on text, all others should revert to text'. In practice, the level of traffic on the network does not often lead to actual conflicts between aircrafts. In the event that one pilot was on text only and that actually created a conflict, would there be a signficant consequence? (it is flight simming after all, not real world). Would the benefits of having the voice CTAF offset the drawbacks of that consequence? From my point of view, if I was challenged to avoid such conflict on the network while flying, it would give me a good opportunity to practice my go-arounds or to remember the traffic avoidance rules (turn to the right, yield to traffic to the right or lower traffic).

 

Just some thoughts that came to mind...Keep it up Ross!!

[Kirk Christie]

Its a good proposal Ross, however i am disappointed that the people who constantly complain in these forms about the lack of such a feature are quite happy to poke the dragon and let some one else fight it when it wakes up.

[Ross Carlson]

If a pilot was in the range of a voice controller, say center... but there is an uncontrolled airport underneath his airspace... does the proposed protocol allow the pilot to join the voice frequency of the uncontrolled airport.... I re-read the proposal several times, maybe I do not grasp the technicalities, but the protocol seems to say that it would not be possible (I am sure I missed something here).

 

Yes, that pilot would still be able to use the voice CTAF frequency for the uncontrolled airport. The thing you missed is that the voice CTAF would only be unavailable if there was a controller in range on the same frequency. In your example, the center controller would not be on the CTAF frequency.

 

One person had recommended an opt-out option in a post above....I am thinking it may sound like a good idea perhaps ... as long as that does not make him a 'text-only' pilot and obliges everyone else to revert to text CTAF. I understood that the reasoning behind the proposal was that perhaps some of the pilots on voice unicom may not be so effective at their voice communications.

 

In such a case, if that opt-out pilot could still receive on voice, then he would not be text-only. He would only be text-only if he could neither transmit nor receive on voice.

 

I am also wondering if there may be a benefit to have the pilots 'voice-CTAF-certified' to increase the chances that the pilots will be using more effective the CTAF. Perhaps it can even be included as part of one of the VATSIM pilot ratings (P2, P3???). That would give a tangible incentive for pilots to make the additional effort to go through the pilot training program as there would be a tremendous benefit for them to do so.

 

We would certainly want to include voice CTAF etiquette in any pilot training curriculum. I wouldn't want to have the voice CTAF certification be mandatory for using voice CTAF, though.

 

In the case that a pilot is not able to use voice for any reason (or not certified if that is requirement), I am wondering if a risk-management approach could be used instead of the traditional philosophy of 'if there is one pilot on text, all others should revert to text'. In practice, the level of traffic on the network does not often lead to actual conflicts between aircrafts. In the event that one pilot was on text only and that actually created a conflict, would there be a signficant consequence? (it is flight simming after all, not real world). Would the benefits of having the voice CTAF offset the drawbacks of that consequence?

 

In my bullet list above, I said that if there is a text-only pilot on the CTAF frequency, all other pilots operating at the same airport would need to switch to text. The idea being that only those pilots that potentially create a conflict with the text-only pilot need to switch to text. In practice I think the voice-capable pilots will make a judgement call about the potential for conflict with the text-only pilot, and make some or all of their calls on text if they feel it's necessary. Real pilots make similar judgement calls when operating at uncontrolled fields all the time. I also realize that many voice pilots will be lazy and not send relevant messages via text even when they know there is a text-only pilot at the same field. That's a problem that we already have today with text-only CTAF. However, I think the policy needs to be there so that text-only pilots aren't left out in the cold.

 

We could also just leave the policy as it is today ... as I understand it, there's currently no requirement for pilots to make text transmissions on 122.8 when operating at an uncontrolled field. I think the spirit of how it's written is that pilots need to use common sense and be courteous. That would not necessarily have to change with the advent of voice CTAF.

[Ernesto Alvarez 818262]

In my bullet list above, I said that if there is a text-only pilot on the CTAF frequency, all other pilots operating at the same airport would need to switch to text. The idea being that only those pilots that potentially create a conflict with the text-only pilot need to switch to text. In practice I think the voice-capable pilots will make a judgement call about the potential for conflict with the text-only pilot, and make some or all of their calls on text if they feel it's necessary.

 

this is probably the only hole in the voice unicom/ctaf idea. thats one of the "nice" ideas of what would/could happen in a perfect environment. but as we already know from some of the attitudes already shown in the community, this idea wouldnt happen in our community sadly. too many strung up on their own ways that theyll simply continue doing it their way and who cares about anyone else. this is already proven as people are supposed to send text if they are going to transmit at all whether its on voice or text, but they dont.

 

the big Q thats going to have to be answered is how to deal with those, if they are dealt with at all and just wait until an interruption occurs to deal with it

[Ross Carlson]

this is probably the only hole in the voice unicom/ctaf idea. thats one of the "nice" ideas of what would/could happen in a perfect environment. but as we already know from some of the attitudes already shown in the community, this idea wouldnt happen in our community sadly. too many strung up on their own ways that theyll simply continue doing it their way and who cares about anyone else. this is already proven as people are supposed to send text if they are going to transmit at all whether its on voice or text, but they dont.

 

Agreed ... though I do wonder if having voice CTAF will encourage more users to properly use CTAF, since using voice is so much easier and so much more realistic.

 

Obviously we'll still have pilots that just don't care ... no amount of convenient/realistic tooling will change that.

 

Of course, the ease of transmitting on voice (as compared to typing out text messages) is a double-edged sword. It will also make it easier for people to transmit superfluous/irrelevant/meaningless information on CTAF. One nice thing about text is that the frequency cannot be monopolized by one person transmitting a really long message. Not so with voice. Perhaps the client should limit voice CTAF transmission duration?

 

I was also thinking that maybe the frequency mapping file should include a field elevation for each airport, and the client would not join the CTAF voice channel if the aircraft was more than some preset height AGL. (Something like 5000 feet AGL.) This could help prevent transmissions that have no relevance for the aircraft operating at the field, such as an airliner announcing that he's vacating FL350.

[Evan Reiter]

On the text vs. voice issue, could the existing policy of requiring pilots to monitor text UNICOM not be applied? Rather than the rule of "once someone is on text we all use text", perhaps we could say that all pilots are required to monitor text, and can make reports on text or voice. If there is a conflict anticipated between a voice and text pilot, then the voice pilot would be required to use text. But if, in the opinion of the voice pilot, there is not a conflict, what would be the reason for forcing someone who wants realism to switch to text? If a text-only pilot wants more situational awareness, it should be on him/her to buy a set of headphones, not on the pilot who is trying to be realistic.

 

I recognize I'm going down the road toward a separate issue that's also highly contentious but I'll do it anyway. What are the chances of VATSIM revisiting the policies around text pilots? In particular, I would be interested in seeing a policy that permits /r/ freely for anyone, but that requires someone who wants to fly as /t/ to provide a rationale for doing so. I can understand why some people may not want to have a mic; perhaps they're in a public place like a dorm, others are sleeping nearby, they aren't comfortable on the radios, etc. But outside of circomestances where people have a legitimate disability, what's the benefit to the network of allowing /t/ regularly?

 

In other words, I'm envisioning a world in which the membership department reviews the cases for /t/ on an individual basis.

 

A variation on this might allow /t/ for anyone at cruise or in the enroute environment, but would require either /r/ or /v/ while on approach, unless specifically approved for one of the reasons I mentioned.

 

It's 2016. A pair of earbuds costs $2. We're flying around on hundred-dollar computers and simulators that cost up to $200. People who aren't willing to purchase a headset or at least earphones are, in my view, missing out on the most beneficial part of flying on VATSIM: realistic ATC interaction.

 

Ross, I'd like to help champion a proposal to the BoG around the use of voice CTAF/UNICOM. I've thought of doing the same thing myself. Since you brought up this idea, I'd defer to you if we want to save the battle about /t/ and /r/ for another day. However, if VATSIM were to revisit this issue now, it would solve some of the questions we have about Voice CTAF/UNICOM as well.

[Ross Carlson]

On the text vs. voice issue, could the existing policy of requiring pilots to monitor text UNICOM not be applied? Rather than the rule of "once someone is on text we all use text", perhaps we could say that all pilots are required to monitor text, and can make reports on text or voice. If there is a conflict anticipated between a voice and text pilot, then the voice pilot would be required to use text.

 

That's precisely what I think will happen in practice ... voice pilots will switch to text if they think there is a potential for conflict with a text-only pilot. However, I don't know if we can leave it to a subjective judgement call and still have an enforceable policy. That's why I say all voice pilots at the same airport should switch to text while the text-only pilot is operating there. That removes the judgement call as to whether or not there is potential for conflict. It's saying that any time two aircraft are operating at the same field there is potential for conflict. That's not far from the truth, in my opinion. And again, in practice, I think most pilots will only take the time to type out their message if they really think there's going to be a problem.

 

That being said, if the BoG goes for it, I'd obviously be totally fine with wording the policy such that it is left up to the pilot whether or not the text transmission is warranted, since that's what I think will happen anyway.

 

In other words, I'm envisioning a world in which the membership department reviews the cases for /t/ on an individual basis.

 

Interesting idea ... though I'm not sure it would actually solve anything. I can't see the VATSIM staff actually denying anyone the ability to use text only. And if someone is too cheap to buy headphones, they could just say they have a hard time hearing people and need to use text. The staff isn't going to say "nah, I don't believe you" and deny them.

 

Also, in order to enforce such a thing, we'd have to disable text transmissions for pilots not certified for text-only, right? Then we have a problem when the voice system breaks down and we need to fall back to text.

 

Or were you thinking this would just be a barrier for flying on VATSIM as text-only and there wouldn't really be a need to enforce it?

 

Another thing to consider is that other than disability, there is one significant legitimate need for /t ... some pilots are text only because English is not their first language and they can read text far easier than they can understand spoken English, especially given that many pilots/controllers speak too quickly, don't enunciate well, and/or have low quality microphones.

[Ernesto Alvarez 818262]

but that requires someone who wants to fly as /t/ to provide a rationale for doing so

 

wrong road to go down. would open up the door to discriminatory behavior, or what could be seen as such by various users. not a can of worms that the network need deal with

[Sean Harrison]

 

If such a feature were adopted officially, then the mapping file would definitely need come from a VATSIM server and not be editable.

 

Ross why would this be a requirement? We currently allow pof files to be freely downloaded and altered by anyone, so why could we not do same with pilot voice/frequency [Mod - Happy Thoughts]ignments?

 

My concern is that by having an uneditable file, means someone will have responsibility for maintaining a huge world wide file. Could be a huge job and easily p[Mod - Happy Thoughts]ed over. Currently VATPAC makes their regional file freely available and I don't believe we have ever had a problem.

[Norman Blackburn]

My understanding is that Ross means not editable by the end user. Divisions would be responsible.

[Ross Carlson]

Heh, yeah, I don't mean nobody can edit it ... obviously someone has to be able to update it.

[Trent Hopkinson]

Love the direction this thread has taken while I've been away

 

One suggestion - take it or leave it.

 

Any voice transmission on a Voice CTAF spawns it's own automated text message from the pilot transmitting as a kind of general heads up that a Voice transmission has been made (for those without access to voice anything). Some standard short message.

Perhaps a time set, so that only transmissions longer than, say, 3 seconds spawn the message. and Only if the client is connected to a CTAF voice room. If the client is connected to no voice room or a controller voice room, the message is not spawned.

 

That way the CTAF frequency may look something like

 

ABC123: [text only] C182 is 10 miles north of YWOL, positioning left downwind runway 34

XYZ789: [Voice Transmission]

ABC123: [text only] XYZ789 what is your position?

XYZ789: Hi ABC123 on ground at YWOL taxying 34.

ABC123: [text only] C182 turns base rwy 34

XYZ789: [Voice Transmission]

XYZ789: Holding short rwy 34

ABC123: Thanks XYZ, ABC123 final 34.

XYZ789: [Voice Transmission]

XYZ789: Enters rwy 34

ABC123: Vacated rwy 34

XYZ789: [Voice Transmission]

 

of course some days it will look like this:

VHABC: [Voice Transmission]

VHHTM: [Voice Transmission]

VHLBR: [Voice Transmission]

YMA2790: [Voice Transmission]

VHABC: [Voice Transmission]

VHHTM: [Voice Transmission]

VHLBR: [Voice Transmission]

 

I'd also go for a set of quick macros to send a basic set of messages with minimal fuss. Maybe even something like this:

ICAO code and runway (where you can type in an ICAO code for your next approach, and runway designator, YYYY - XXX for say, ICAO-36L)

 

Then you just have a set of standard messages

[iCAO] traffic [Callsign] Downwind rwy [Runway]

[iCAO] traffic [Callsign] Base rwy [Runway]

[iCAO] traffic [Callsign] Final rwy [Runway]

[iCAO] traffic [Callsign] taxying to rwy [Runway]

[iCAO] traffic [Callsign] holding short of rwy [Runway]

[iCAO] traffic [Callsign] entering rwy [Runway] for takeoff

 

Most other scenarios I can think up are usually less time sensitive. Your 10 mile cardinal direction call can be typed manually easily enough.

 

Maybe a dropdown menu, ability to set a key-bind etc at will.

 

This way, the Text-only pilots (or even voice capable pilots who weren't listening and/or have that firewall gateway problem that makes inbound voice stop at random) will be alerted of any voice transmission on the CTAF, and they will know someone is tuned to their frequency inside the CTAF distance (20 miles or whatever it is).

 

Also love the Max altitude idea.

[Trent Hopkinson]

So, looks like the answer to the original post is No! Not unless Ross get permission from VATSIM.

 

Have you tried FSInn?

 

Looks like the answer to the original post is "Not Yet!"

 

As mentioned before, there are now 2 Australians on the Board of Governors.

 

And it looks like there's no major technical hurdles holding it back (unless "waiting till voice range frequency instead of voiceroom architecture takes hold in the -it's not even a thing we're working on- timeframe in the future" is the only option.)

 

Waiting for this mythical range-based voice system would be like telling us to wait for the PMDG Airbus A360/A370 package (which will probably be released decades after the PMDG 797)

[Ross Carlson]

Any voice transmission on a Voice CTAF spawns it's own automated text message from the pilot transmitting as a kind of general heads up that a Voice transmission has been made (for those without access to voice anything).

 

I fear that might get terribly annoying for everyone on the frequency, including text-only pilots. What benefit do you see that it provides? Maybe I'm missing something, but it seems like all that this message would tell you is that there is a pilot on the frequency and he's transmitting on voice. It doesn't tell you where the pilot is, which airport the pilot is operating in to or out of, or what runway the pilot is using or planning to use.

 

I'm all for anything that would provide additional situational awareness for text-only pilots, and do so in an automated fashion that doesn't increase workload for the voice pilots, but I'm failing to see how this would add any situational awareness.

 

Allow me to springboard off of your idea and make a related suggestion:

 

What if the automated text message showed the distance and cardinal comp[Mod - Happy Thoughts] direction from the nearest airport with a matching CTAF frequency? Something like this:

 

ABC123: [Voice transmission - 3.5 NM southwest of KMPV at 3,245 feet AGL]

 

If the transmitting aircraft's altitude is at or near ground level, then it might say something like this:

 

ABC123: [Voice transmission - on the ground at KMPV]

 

And to prevent this from being annoying for voice pilots, we could implement it through a new network protocol extension, and the message would only be displayed by text-only pilots.

[Trent Hopkinson]

Any voice transmission on a Voice CTAF spawns it's own automated text message from the pilot transmitting as a kind of general heads up that a Voice transmission has been made (for those without access to voice anything).

 

I fear that might get terribly annoying for everyone on the frequency, including text-only pilots. What benefit do you see that it provides? Maybe I'm missing something, but it seems like all that this message would tell you is that there is a pilot on the frequency and he's transmitting on voice. It doesn't tell you where the pilot is, which airport the pilot is operating in to or out of, or what runway the pilot is using or planning to use.

 

I'm all for anything that would provide additional situational awareness for text-only pilots, and do so in an automated fashion that doesn't increase workload for the voice pilots, but I'm failing to see how this would add any situational awareness.

 

Allow me to springboard off of your idea and make a related suggestion:

 

What if the automated text message showed the distance and cardinal comp[Mod - Happy Thoughts] direction from the nearest airport with a matching CTAF frequency? Something like this:

 

ABC123: [Voice transmission - 3.5 NM southwest of KMPV at 3,245 feet AGL]

 

If the transmitting aircraft's altitude is at or near ground level, then it might say something like this:

 

ABC123: [Voice transmission - on the ground at KMPV]

 

And to prevent this from being annoying for voice pilots, we could implement it through a new network protocol extension, and the message would only be displayed by text-only pilots.

 

Even better. Can't argue with that!

 

IRL we have AFRU which:

If after (I think it's 5?) minutes without any transmissions will, upon receiving a transmission longer than 3 seconds, will "automatically Respond" on the frequency with an automated recording "[name of location] Aerodrome"

If further transmissions are received within the time-out time-frame, it will respond with just a "beep" noise. I was suggesting a text version of that.

 

Example:

 

Here we have 2 frequencies tuned at the same time.

Radio 1: on Melbourne Centre. Melbourne Centre is telling Rescue 21 about Us! in the C172 VH-JKN taxying at YORG.

Radio 2: on Orange CTAF, Arjun (PIC) transmits at 7:00 starting his Taxi call on CTAF. But drops the Push to Talk because he wanted to double check the frequency he was on.

At

the CTAF AFRU automated Frequency response unit makes it's "Haven't heard anything on frequency for 5 minutes" response.

 

You will notice that all subsequent transmissions on Orange CTAF are only responded to with "

"

 

of course no need for sound effects on voice, since we're trying to facilitate the text pilots here (and text on frequency already has an option to make a sound effect in client if the pilot wants in most of our current clients).

 

But your suggestion of adding in a location/altitude tag works even better for our purposes.

[Ross Carlson]

Correct me if I'm wrong, but AFRU isn't meant to provide any SA for other pilots ... it seems like it's there to help pilots know that they're on the right frequency. Is that right?

[Ernesto Alvarez 818262]

another option to consider, text to speech/speech to text might help get the message out with ease on both ends. this however was a project long on the wait list ever since SB2

 

the technology has advanced since though and compared to back then, tons better. its nothing easy to implement though, so im told, and getting a good codec to include with the clients probably wouldnt be cheap either.

 

windows does include the technology these days though with the system, its not too bad. this might be easier to do, just have to make the clients able to accept inputs from it. not sure if they can do that already, havent tried

[Trent Hopkinson]

Correct me if I'm wrong, but AFRU isn't meant to provide any SA for other pilots ... it seems like it's there to help pilots know that they're on the right frequency. Is that right?

 

This is true. I was just re-purposing the concept to help text pilots know that a voice user is on the frequency and said something.

 

That said, I like your idea better.

[Ross Carlson]

One thing that I'm sure will come up as this proposal is considered is what to do about aircraft that are operating in unstaffed airspace that normally has 24/7 radar service in the real world. As it is now, at least in the US, we've conditioned radar controllers on VATSIM to say something like "monitor UNICOM 122.8" when an aircraft leaves their airspace into unstaffed airspace that would normally have a radar controller in the real world.

 

Personally speaking, the idea of being on any sort of pilot coordination frequency when I'm not near an airport is just strange, I guess because it simply doesn't happen in the real world. With real flying, I'm either talking to a controller, or if I'm VFR and not getting flight following, I don't need to be on any particular frequency until I get close to an airport, at which point I'll tune the CTAF.

 

So my vote would be to get rid of "monitor UNICOM 122.8" when a flight leaves a radar controller's airspace into unstaffed airspace, and instead simply say "xxx center is offline, radar services terminated, good day." Perhaps adding "frequency change approved" or "change to advisory frequency approved" if we know the flight will soon be operating at an airfield with a CTAF.

 

Thoughts?

[Evan Reiter]

In other words, I'm envisioning a world in which the membership department reviews the cases for /t/ on an individual basis.

Or were you thinking this would just be a barrier for flying on VATSIM as text-only and there wouldn't really be a need to enforce it?

Doing it that way would certainly be a good starting point. Perhaps as a matter of policy rather than enforcement.

 

Another thing to consider is that other than disability, there is one significant legitimate need for /t ... some pilots are text only because English is not their first language and they can read text far easier than they can understand spoken English, especially given that many pilots/controllers speak too quickly, don't enunciate well, and/or have low quality microphones.

Agreed...and that's one of those places where I think some discretion could be applied. That being said, I'm curious as to whether (or how) people plan to improve without trying. Perhaps if it's busy or there's a controller with poor mic quality, you'd revert to /t/, but I certainly try to encourage folks on my frequency who self-identify as "new" or "ESL" to grab their mic and talk. The experience is just so much more immersive and realistic than the alternative.

[Ross Carlson]

I'm curious as to whether (or how) people plan to improve without trying.

 

I've always figured they improve by listening to voice transmissions on the frequency. Pilots that are /t due to not being comfortable with spoken English ATC are most likely still receiving voice.

 

Being a native English speaker, I can only speculate, but my guess is that non-English speaking pilots are reluctant to be "that guy" tying up the frequency by saying "repeat please" many times, or worse, misinterpreting an instruction, making a mistake flying the airplane, and getting a tongue lashing from the controller. Embarr[Mod - Happy Thoughts]ment is a significant demotivator here.

 

I've even had pilots request that I send my instructions via both voice and text, presumably in an effort to gain more familiarity with spoken English ATC. Perhaps we need a voice tag for that, such as /b for "both".