Voice UNICOM / CTAF

[Thimo Koolen]

In my opinion, it should not be made too difficult to use. So not tens of different frequencies you might need to tune. We're not professional pilots and have to do quite some stuff on our own already. Maybe a frequency for each country?

[Nathan Elliott 1278737]

@Cameron

 

You quoted the Vatsim terms of conditions and said "Members should be able to converse and/or provide air traffic control services in English"

 

Then you added your own opinion and said "not to mention a requirement to speak in order to join the network"

 

So which one is it , "should" or "requirement" because to me they're two different command words and have two different meanings.

[Ross Carlson]

In my opinion, it should not be made too difficult to use. So not tens of different frequencies you might need to tune. We're not professional pilots and have to do quite some stuff on our own already. Maybe a frequency for each country?

 

In my opinion, it should be realistic, which means, for the US at least, using the published CTAF frequency, and using the tower frequency for towered fields when the tower is not staffed.

[1275389]

I wonder, if to make things simpler, since many many users can't be bothered to look at a chart let alone look up a tower frequency, if there was some dual voice connection, so you could connect on both 122.8 and the tower frequency.

[Andy Ford 1203533]

With all due respect, this isn't something I can get behind as it seems impossible to police effectively and is likely to deter me from flying.

 

Someone act's like a twit on private message or unicom, great, we've got logged evidence to deal with it (logging recorded voice in any decent codec is going to use up a lot of space, real quick and transcription isn't always accurate). Voice requires not only that someone else *witnesses it* but is also able to identify who said it and make a statement about it.

 

If the current text unicom is anything to go by (and my previous experience on FSInn), this is going to be abused to the point that many pilots won't even bother - I certainly won't be entertaining it when I fly. I've got better things to be doing than listening to someone playing music down their microphone or screaming "mayday" in a voice high enough to break windows in a 20 miles radius.

 

To that sense. I thought the entire point of NOT doing this was because it excludes text pilots and people who can't use voice. In fact, I know some people who can't use voice for medical reasons. Doesn't sound "inclusive" in the slightest. So [Mod - Happy Thoughts]uming we keep text unicom for that case - two unicom channels at a large airport will in my estimation result in confusion and probably chaos.

 

Disclaimer: Personal opinion, but shared by many people I've spoken to today.

Edited July 31, 2017 at 06:30 PM by Guest

[Etai Charit 910845]

Wonderful news! I've been waiting for this for years. This can dramatically increase the realism of VATSIM in a split second.

 

Suggestion for operation:

Each FIR will have a CTAF for it's use at all times, that will show in any of the underlying aerodromes' NOTAMS and docomeentation, as well as simply an open ATC channel in the network.

 

In addition to obvious CTAF as UNICOM operation, Controllers can choose to refer pilots to the CTAF whenever they're unable to provide adequate control responsibility. Example: a huge amount of traffic to a major airport, one Center controller online, then another Cessna arriving to a deserted aerodrome. When the Cessna is reaching this airport's cl[Mod - Happy Thoughts] D airspace they can be handed off to CTAF, just like in real life.

 

When only GND is online, they can listen to the CTAF as well to better anticipate traffic. Same for higher posts.

 

As per training:

CTAF and UNICOM are real life communication channels and there's a lot of materials instructing how to conduct. The AIM explains it wonderfully, Youtube is full of "How To" videos with real pilots showing the proper CTAF callouts and conduct. The only thing I believe VATSIM should do training wise is to send out a NOTAM to all the pilot's emails, stating that the changes are in effect and valid, a link to read the required changes in the Code of Conduct, and a tutorial docomeent for typical CTAF terminology and announcements, simplified from the AIM. Anyone who logs into the network since then is expected to know what's going on.

 

Yes, people are going to make some mistakes. It's not a professional network, and not only it is fine, it is the beauty of it.

A few weeks later it will be the new order.

 

Chapeau for the decision guys.

[Calum Shepherd]

redacted

Edited February 18, 2021 at 06:24 PM by Calum Shepherd
redacted

[Bradley Grafelman]

With all due respect, this isn't something I can get behind as it seems impossible to police effectively and is likely to deter me from flying.

Just do what I (and I'm guessing others) plan to do - mute the radio when on CTAF and it's back to business as usual.

[Sean Harrison]

I wonder, if to make things simpler, since many many users can't be bothered to look at a chart let alone look up a tower frequency, if there was some dual voice connection, so you could connect on both 122.8 and the tower frequency.

 

FSInn

[Andy Ford 1203533]

Those who can't receive voice...well...um...tough?

 

There are members that have hearing issues or are deaf. You've also got people that can't use voice because they have sleeping children. You also have new members are who are just getting into the network and are nervous about using voice. I could go on.

 

So you're basically saying "you have a situation that you have no control over, therefore you have no way to find out what other pilots using voice unicom and not posting on text are doing, so get over it and tough luck sunshine". How far will this go to make people feel like they're part of the hobby? The reason always given for not doing this up until now was so that everybody could take part on Unicom - not having half on and half off.

 

Potential problem with 24hr voice records - DCRM cases can take days if not weeks to decide depending on how high it goes. Whilst I appreciate that required logs could be collected at the time, it sounds like a lot more work for SUPs.

[Cameron Bristol]

If you're going to quote me, quote me properly...

 

Correct what I quoted incorrectly. I'm honestly missing it... I'll change it in a heart beat if you point out what exactly I missed quoted. It's confusing me due to the fact I just hit "quote" on the top right and then hit "post".

 

and the good old saying when someone says "but" in there sentence it's best to ignore what is said after the but. so i will not read past the but in your sentence.

 

Allow me to rephrase. I honestly don’t see a problem with a UNICOM coming in a different language, and I think so long as EVERYONE on the frequency speaks it that’ll be fine. However much like in the real world, the second an English only pilot comes on frequency, English should be spoken solely. Sounds terrible, but English is the universal language of aviation, not to mention a requirement to speak in order to join the network.

 

Well i did read past the "but" in your sentence and as predicted it's incorrect information. There's no requirement for English to be spoken if a pilot starts speaking in English i'm not sure what real world organisation you're quoting.

 

Let me rephrase because that probably wasn't worded probably. Air Traffic Controllers and Pilots can speak whatever language they want on frequency, sort of. So long as there is no one else on frequency who can not understand the language. For example, controllers in China speak Mandarin to Chinese pilots, and English to out-of-towners. It’s amazing to fly into Beijing or Shanghai at rush hour and hear the controllers rattling off clearances in both languages. So yes you can speak other languages on frequency so long as you can also speak English. I worded this poorly previously but this is what I was trying to get across. This part really wasn't even supposed to be part of the debate but my poor wording made it a problem.

 

I also don't remember Vatsim saying you HAVE TO SPEAK ENGLISH TO JOIN? If that's true who's there to police it? i never had an language test to join Vatsim why's that?

 

VATSIM Code is Regulations Article I 1.01 A Requirements VATSIM.net is open for membership to all individuals who have reached the age of thirteen (13) years old or older. In addition, membership is available to all individuals regardless of race, creed, color or nationality. Members should be able to converse and/or provide air traffic control services in English, the internationally accepted official language for air traffic control. I'm not a lawyer, so maybe I'm reading this like a commoner, but when I read "I should be able to do this" under a section labeled "Membership", it would stand to reason you need to be able to speak the language in order to satisfy this regulation.

[Nathan Elliott 1278737]

@Cameron

 

Should means a different thing to requirement - end of. There's no requirement for English to be spoken on Vatsim . I don't know why i'm actually replying to you? Vatsim may say English "should" be spoken for ATC but with CTAF there's no atc... ( even if there's a person in the tower they can only recommend not control ).

 

 

@Cameron

Please read up about CTAF /A/G frequencies and the lot...

 

 

 

No one so far has said CTAF will be voice only, it will include text .

 

MESSAGE TO THE PEOPLE SAYING MONITORING A TEXT AND VOICE CTAF IS DIFFICULT

 

To the people complaining that CTAF will be to difficult to monitor voice and text you need to remind yourself about what CTAF actually is you don't need to readback and your messages are incredibly short and sweet - if you think it's difficult to monitor a text and voice CTAF frequency ( were readbacks are not required and you know your next move rather than following ATC instructions ) what do you call a frequency were ATC is vectoring you? impossible?

[Nathan Elliott 1278737]

Exclude the large airfields

 

- ATC numbers will drop. ( all that training for .... )

 

 

This should be implemented at some airfields that have a low ATC coverage on Vatsim .

[Alex Hartshorne 1130787]

I'm really looking forward to this new addition of realism to our network Joel!

 

Just one thing I would like to highlight:

Although pilots are advised to "monitor" unicom when clear of controlled airspace, I see countlessly members posting almost in real-time their latest position, altitude and current in-flight meal...

 

What parameters will be set up to prevent pilots unnecessarily clogging up the frequency, especially at busy airports and inside congested airspace?

[Joel Richters]

With all due respect, this isn't something I can get behind as it seems impossible to police effectively and is likely to deter me from flying.

 

Someone act's like a twit on private message or unicom, great, we've got logged evidence to deal with it (logging recorded voice in any decent codec is going to use up a lot of space, real quick and transcription isn't always accurate). Voice requires not only that someone else *witnesses it* but is also able to identify who said it and make a statement about it.

 

If the current text unicom is anything to go by (and my previous experience on FSInn), this is going to be abused to the point that many pilots won't even bother - I certainly won't be entertaining it when I fly. I've got better things to be doing than listening to someone playing music down their microphone or screaming "mayday" in a voice high enough to break windows in a 20 miles radius.

 

To that sense. I thought the entire point of NOT doing this was because it excludes text pilots and people who can't use voice. In fact, I know some people who can't use voice for medical reasons. Doesn't sound "inclusive" in the slightest. So [Mod - Happy Thoughts]uming we keep text unicom for that case - two unicom channels at a large airport will in my estimation result in confusion and probably chaos.

 

Disclaimer: Personal opinion, but shared by many people I've spoken to today.

Andy, I [Mod - Happy Thoughts]ure you the hearing and text only pilots have been considered and is part of the plan. Rant or not I value feedback so thank you

[Joel Richters]

I'm really looking forward to this new addition of realism to our network Joel!

 

Just one thing I would like to highlight:

Although pilots are advised to "monitor" unicom when clear of controlled airspace, I see countlessly members posting almost in real-time their latest position, altitude and current in-flight meal...

 

What parameters will be set up to prevent pilots unnecessarily clogging up the frequency, especially at busy airports and inside congested airspace?

Good question Alex. At this stage it is too early to say with any absolute certainty, we are conscious of the need to keep good airmanship on the network and there will be limitations that allow for greater control and flexibility at the same time. While we may implement some governance at a network wide level, it’s likely to be the Divisional staff who will make the bulk of the rules locally.

[Lindsey Wiebe 1101951]

This is great news. Lots of different things have been brought up... some good some bad, some legitimate concerns some not.

 

I'm not sure we'd even need to change the current Unicom freq... from what I've discovered it is range dependant on altitude? When flying near Vancouver CYVR I will often hear aircraft starting their STAR into Seattle KSEA = 111NM apart. But when I'm lower down around YVR I don't hear SEA traffic... might be coincidence or might be an altitude/reception algorithm. If so that could be maintained, at least at the outset until more data could be collected. I could see it being an issue in high density areas such as SoCal and NYC area which tend to have quite a bit of traffic regardless of ATC or not. Constant updates about LAX when flying into SNA and JFK into LGA etc. The enforcing part could be "interesting" to police...

[Simon Kelsey]

I'm not sure we'd even need to change the current Unicom freq... from what I've discovered it is range dependant on altitude? When flying near Vancouver CYVR I will often hear aircraft starting their STAR into Seattle KSEA = 111NM apart. But when I'm lower down around YVR I don't hear SEA traffic... might be coincidence or might be an altitude/reception algorithm.

 

As far as I know, text communication (all text communication -- not just Unicom, but on active ATC frequencies as well) is modelled based on the standard VHF line-of-sight propagation formula (i.e. 1.25*sqrt h1 + 1.25*sqrt h2). Thus, as you say, at high level you will receive stations over a range of a good couple of hundred miles, whereas at lower levels you will only receive from much closer stations. You can also notice on some occasions if you are flying in a very large chunk of airspace (e.g. in an oceanic area) you may be able to receive all text transmissions from the controller but not always the replies from pilots who are outside your reception range.

 

The problem is that voice rooms don't work like this -- the room is tied to the frequency and you are either in the room or you are not, wherever you are on the planet. I presume that this issue is part of what the network team will be looking at.

[Nick Warren]

This is a very welcome and long overdue addition to the network. I agree with Ross from and earlier post suggesting that it should be implemented as realistically as possible. I would love to see all CTAF freq's covered and range limited. This gives the user the least amount of confusion in my opinion. The frequency is defined on the chart, and frankly not having a chart is poor airmanship even on here. After all, are we supporting a realistic environment or catering to an arcade game? There is another network that accomplishes this quite effectively. While their product is likely proprietary, they may be open for providing suggestions. I will embrace a single frequency, but feel that it is a convenience that still cripples realism. Like others, I don't want to have my pattern calls compromised regularly by an individual announcing their decent from FL390 and 110nm out. I do think this is a positive step however, and again I thank the executive board for bringing it forth.

[Daniel Mckee]

For those who reside outside of Australia where we have for many years enjoyed the realism of CTAF voice, if you would like to see how CTAF voice comms have been successfully working for many years may I suggest that you join one of Vatpac's "World Discovery Flights" or "VFR Flights" or at least just listen in to the flights. The most successful program using voice comms has been FSInn however recently a number of our P3D users who cannot use FSInn have been using VPilot which now allows for manually selecting the relevant CTAF. To dispel one misunderstanding, I have never experienced a "heavy" transmitting on a CTAF; they use ATC (as opposed to CTAF's or MBZ's or the like) frequencies only. On another small point, we have had many Newbies join us on CTAF here in OZ and they have never been critised by us "oldies"; in fact we are always forgiving and helpful. Just my two cents worth.

[Johnny Coughlan]

What in all honestly is the big deal with adding voice to UNICOM?. Why is there so many in this thread against it?.

 

In reality it's nearly the exact same as a live controller frequency, some using voice, some using text and some using receive.

 

People blowing on about how it's unfair on people who only use text or receive because as I said it's nearly the exact same as a controller frequency.

 

I often have a mix of the above on my frequency when controlling, text only pilots not having a clue what I'm saying on voice to voice only pilots and it's never been an issue, so what's the big deal with having the same on a UNICOM frequency?.

 

I seriously doubt UNICOM will be voice only anyways, and just like what controllers have to do if there is a trouble maker just .wallop and why would adding voice be any different than text only, we've plenty of keyboard warriors in this community who can cause problems all the same using text.

 

And at the end of the day, what percentage of pilots flying honestly even use UNICOM?.

Edited August 2, 2017 at 07:44 PM by Guest

[Charan Kumar]

What in all honestly is the big deal with adding voice to UNICOM?. Why is there so many in this thread against it?.

 

In reality it's nearly the exact same as a live controller frequency, some using voice, some using text and some using receive.

 

People blowing on about how it's unfair on people who only use text or receive because as I said it's nearly the exact same as a controller frequency.

 

I often have a mix of the above on my frequency when controlling, text only pilots not having a clue what I'm saying on voice to voice only pilots and it's never been an issue, so what's the big deal with having the same on a UNICOM frequency?.

 

I seriously doubt UNICOM will be voice only anyways, and just like what controllers have to do if there is a trouble maker just .wallop and why would adding voice be any different than text only, we've plenty of keyboard warriors in this community who can cause problems all the same using text.

 

And at the end of the day, what percentage of pilots flying honestly even use UNICOM?.

When a controller is on, the controller ensures separation, the text pilot doesn't need to hear the vox convo, but in a self coordinated environment, they can get into an argument where the text pilot didn't notice (or hear) the vox announcements. Just what came into my mind.

 

Again, it's not all doom and gloom all over. Yes there are trolls, but the number is far outnumbered by the amount of pilots putting in the energy and doing countless hours of decent flying. I am glad the network is considering changes. Change is good. As VATPAC has said time and again, it works really well there so let's at least try it before we decide to pull the plug on it.

 

It's all workable as long as we don't get hung up on other's mistakes. Go around a couple of times if you run into issues. That's what real pilots do too!!

[Richard Quigley]

O frabjous day! Callooh! Callay!”

He chortled in his joy.

 

(Apologies to L.Carroll)

 

Next step: Speech to text & text to speech conversion in the pilot client.

[Christoph Reule 1379750]

When a controller is on, the controller ensures separation, the text pilot doesn't need to hear the vox convo, but in a self coordinated environment, they can get into an argument where the text pilot didn't notice (or hear) the vox announcements. Just what came into my mind.

 

Pretty easy to solve: let text pilots receive voice, too (I don't see a point against that). For voice (& text) pilots: even if you ticked off the option to display text messages on your simulator screen you could expect to frequently look on your client's interface when approaching your destination airport.

 

Just my 2 cents.

[Russell Diehl]

Just thought I might chime in. It has already been indicated that VATPAC has been implementing features of FSINN to undertake voice CTAF. Voice is preferred in many of the VFR GA events as the flying is by hand and typing calls in text is just unmanageable. It is also somewhat risky when in a TMA where the pilot is busy. It is obscenely easy to inadvertently type without realising the input focus in not in the chat window/frame. The keystrokes are then being captured by the simulator and something as innocuous as "YSSY" will potentially invoke slew mode, change view 2x before returning to flight mode for a typical FSX simmer. The converse to also true. Having input focus in a chat window will capture the "G" gear down key with the potential result being a wheels up landing into a major airport. So the option of having voice available to all is a relief to those of us who like to fly VATSIM seriously. Text is always there if someone prefers it.

 

As a participant in many of these activities there is some information to be gleaned from the years of experience accrued.

• Implementation should allow the pilot client to display the active voice room and all callsigns present in them at the time. Who wants to make calls when there is no one to listen. It is also a good way to confirm aircraft in the vicinity are able to receive broadcasts. Or more importantly, to identify those that are not able to receive. It is those that require the most attention.
  
• Implementation should be server side. FSINN requires the use of special voice files that map frequency at a location to a voice room. These FSINN files must be installed correctly before CTAF ops can be successfully undertaken. Many an hour has been spent setting this up with the many installations. The file needs regular updates to remain consistent with real world and having various versions is problematic. It is far more desirable to have all clients access mappings directly from a common source on the server.
  
• Major airports aren't typically included as a CTAF. Reasonable since they are typically ATC 24/7 in the real world. The merits of [Mod - Happy Thoughts]igning an independent voice room based on the tower freq should be left to each region to determine. In all instances however, the tower frequency for a major airport should be active even if it is simply mapped to the relevant UNICOM voice room.
  
• Voice UNICOM would benefit from some rationalisation. The present implementation of voice unicom in FSINN sees a single large UNICOM for a large region. This then creates a situation where an advisory call at one location can be heard 1000's of NM away. Smaller regions of unicom would be more useful and relevant.
  
• Close clusters of CTAF airports sharing a common frequency requires a common voice room. FSINN voice files isolates each airport to its own voice room. When those airports share the same freq, only calls at the closest airport can be heard. This can be awkward when a pilot wants to alert other aircraft of its arrival but can't reach the relevant voice room to make the transmission because the aircraft is closer to another airport using the same frequency. This needs to be identified and all airports within a common location included into a single voice room so that a broadcast at one airport can be heard at others nearby as would be the case in the real world.

The above points are some observations that have been made that affect CTAF operations as they have been implemented in the limited facilities offered by FSINN. These have been presented so that they can be considered when generating a more common and centralised implementation.

 

I invite other participants that have actively taken advantage of the present implementation of CTAF to add any additional thoughts they might have.

 

Russell Diehl

VATPAC VFR Events Coordinator.