I believe it is time to change the VATSIM CTAF/UNICOM rule.
Since the release of Audio for VATSIM, the growth of general aviation flying on the VATSIM network has been exponential. To continue that growth and enhance realism on the network further, it’s time to allow real world CTAF frequencies to be used in ALL situations.The current rule of having everyone on 122.800 when there is no ATC available is outdated.
If a full change is considered too much then this could be a possible alternative:
Change the rule to allow real world CTAF frequencies at uncontrolled airports to be used within 25 miles.
For controlled airports without ATC present and anything outside of the 25 mile range of a field, 122.800 can remain the standard.
Additionally, if it would be easier to allow VATSIM’s regional bodies (such as VATUSA) to develop their own rules on this matter, then maybe that could be considered as well. I admit that my knowledge of CTAF outside of the US is limited at best.
I believe the change would not only benefit those of us in the general aviation community, but would enhance the overall realism and immersion of the network. With all the efforts being made to that end, I now see this as the right time to make it happen.
I would love to hear everyone’s thoughts about this further. I hope that if enough people feel it would be a good idea, then we can advocate for the rule to be changed moving forward.
Been waiting for real-world CTAF for a while. Tired of getting weather AWOS/ASOS etc…when monitoring 122.8 for unicom. Mike brought this up as a lot of us who fly general aviation have questioned this policy for a while.
I completely agree with you. The usage of 122.800 is outdated at best at this stage in the technological game. Now to implement this plan from a technology standpoint may not be as easy but with my limited knowledge of VHF I would think it would be easier than dealing with ATC Transmitter locations. As pilots are talking to each other everyone’s radio is essentially the station where line of sight applies. Now I am unsure how VATSIM does 122.8 if it’s just one giant transmitter station that makes it work, but I’m guessing it isn’t because we would hear more pilots way outside of standard range.
Now talking real world as you know, there are days at MJX that I can hear traffic at PTW. On IFR days I can’t. That cannot be simulated to my knowledge but creating stations for each uncontrolled airport with a specific radius may be possible just a heavy lift of work, not to mention bandwidth.
I think the technical lift is heavy to get it done, but so was Velocity. I think the conversation needed to be started and I’m glad it did. Granted now us controllers get the pilots who don’t know what CTAF is and how to find the CTAF on a sectional chart but that’s more of a Training Issue. I would love to see usage of real world frequencies for CTAF implemented moving forward as other comparable products have done this.
I would love to see RW frequencies being used at VATSIM, however it is not as simple as saying “Let’s do it”. From the latest Navigraph Survey 2022 you may notice, that almost 25% of flightsimmers still use older simulator platforms such as FS2002, FS2004 and FSX, which are not able to use the 8.33kHz spacing used in e.g. Europe, so RW frequencies can’t be used there - UNLESS VATSIM demands the use via e.g. vPilot or tell the pilots to change to newer simulators, who are able to handle the 8.33kHz spacing. Perhaps other solutions can be found, but tuning your radios directly in these older paltforms is not possible ASAIK. So that would potentially mean “goodbye” to a relative high number of members.
This has been something that has been on my personal radar for some time now. Utilizing real world CTAFs would certainly improve the training value of network.
There would certainly be some items to resolve, however I believe that most of them would be procedural and training based vs technical. This would include developing procedures for airports which are never uncontrolled in the real world. Typically we can follow protocol for part-time towers and use the tower frequency, but this changes with larger airports such as JFK which have multiple published tower frequencies. I believe the solution here would be to utilize the VATSIM AIP (which already supports this) to designate the appropriate frequency to use and offer an endpoint for pilot clients to query the information for quick and easy display. This would also resolve the 8.33kHz issues. I do not believe that any transmitter or station definitions would be required to accomplish this.
With a change like this, there would be some drawbacks as well. Just like in the real world, we do have have some problems with aircraft callouts on CTAF/UNICOM. While there are no provisions in the CoC for aircraft without radios (as is permitted at some uncontrolled airports in the real world), the end result will likely still be that some are off CTAF for one reason or another. While CTAF usage is still something we should expect, there has to be an understanding as well that see and avoid is critical in VMC (whether under positive control or not).
The discussion of what to utilize outside of the airport vicinity is also a good discussion point that would need to be had. My personal opinion is that, within a TRACON-like area when flying into a large airport (think JFK, LAX, etc) you’d monitor published CTAF. Outside of that area, and within the flight levels, designating a CTAF (unless defined in the real world such as the Anchorage area) would likely not be very useful.
These are my personal opinions, but I do understand both the desire and benefits of implementing RW CTAF frequencies.
FWIW, the issues concerning CTAF call outs, as you say, are already an issue on 122.8. I’m not trying to be glib, but pilots can just as easily not listen or talk on the published CTAF frequency as easily as they aren’t listening or talking on 122.8 so the overall issue of pilot awareness/training around untowered fields would remain unchanged, imho.
Just like real world, the use of CTAF is optional but encouraged. Some pilots know what to say and other don’t. But I think opening up the option for members to use the real world frequencies can add to the overall realism. It would be a huge benefit to the general aviation community on the network that is growing.
I never understood why the FAA crams so many uncontrolled airports onto one CTAF frequency. In the area where I fly IRL, traffic is so congested that people are keyed over almost all of the time. However, in order to maintain a further sense of realism on VATSIM, I feel that implementing real world CTAF frequencies on the network would be an overall benefit. Not necessarily because voice traffic on the 122.8 frequency is so congested, but moreover for pilots who wish to enhance their real world procedures. I fly using ForeFlight mobile and would really enjoy being able to tune the published CTAF frequency to state or clarify my intentions in the area. HOWEVER, none of the radio communications should replace the due diligence of the pilot to be observant and look out the window for other traffic. Be it the VATSIM UNICOM of 122.8, or a real world CTAF frequency…there’s always a chance that a NORDO aircraft is in the area, possibly inbound to land without you knowing. I am all for using the published CTAF frequency at uncontrolled airports, provided you’re also doing the smart thing and looking out the window at the same time.
Oh my gosh yes please. 122.8 for all CTAF hurts my soul. It makes sense to have a standard common air-to-air frequency for self-announcing position in places that realistically should be covered by ATC, but when there are charted traffic frequencies for places, why in the world can’t we use those…
Pilots flying through uncontrolled airspace shall monitor VHF radio frequency 122.800 or other designated “UNICOM” frequency until they come under air traffic control coverage. Where another pilot may benefit, a pilot shall transmit their intentions on the designated unicom frequency.
You can use the published CTAF, e.g. if you’re in a group VFR flight to/from an uncontrolled airport. You just have to monitor 122.800 (e.g. on COM2) and transmit on that frequency where it would benefit another pilot who isn’t in your group.
I think one of the issues is the artificial 15nm limit on UNICOM transmissions. If you’re flying a jet into an airport with no ATC and there’s another coming into the same airport from the opposite direction 50nm away, the other pilot will not benefit from you broadcasting on UNICOM. There are also a few uncontrolled airports around the world where 122.800 is the CTAF.
My suggestion would be for the VATSIM Board to consider two things.
As a trial increase the artificial 15nm limit on UNICOM transmissions to, say, 30nm.
Allow each division to come up with its own policy on transmissions in uncontrolled airspace, e.g. using a published CTAF where one exists or some other common frequency.
Now a question. Should the second suggestion be adopted, is it technically possible for a pilot to be sent an automated text message with a link to the the local policy when they cross an FIR boundary? Or where a vACC has nominated a particular frequency for an airport which in the real world would be controlled 24/7/365, if you have filed a flight plan with that airport as your destination you would get an automated text message when you are within, say, 50nm of your destination advising of the frequency to use.
My personal thought is an APP frequency would be the most useful for large airports but it should be up to each vACC to decide.
A final thought is 122.800 should probably remain the standard in oceanic airspace where there is no ATC, provided the range is increased as suggested above.
a bit of a stretch on that correlation, because at no point in the survey there is a link between pilots on older sims and pilots flying online, so using that survey for that argument, is just plain incomplete.
A couple of people at VATSIM were recording those stats accurately though, and they have info on it. If 8.33 wasn’t a possibility, it wouldn’t have been stated that is coming by the president, nor so often on the BoG agenda
VATPAC has for maybe 8yrs used CTAF as per real world. It works extremely well. Not sure if the latest voice system still allows the same freedom. Simply meant that if the airport was a CTAF (has a CTAF freq on the charts) then we used that frequency, and still monitored 122.800 on C2. This obviously changed if ATC was online. Highly effective and beneficial.
Off cause there is no one-to-one correlation between the numbers of persons using older sims and who are flying online. Nevertheless it is an indication that a not insiginificant number of persons might have a problem on doing such a conversion to 8.33kHz spacing. The exact numbers are unknown to me. You state that a couple of persons on VATSIM have infos on this issue. But then let’s have the numbers out in the open. Do you know how many persons flying on VATSIM, who are using older sims?
I have a hardware cockpit with the ability of using 8.33kHz spacing and thus realworld freq. would be nice. But I wouldn’t like to exclude a number of persons from the network just so that you can have a better immersion in the sim. I don’t mind to tune 122.8 instead of some “random” CTAF freq. There are lot of other problems which will occur, if turning to RW freq. How to handle top-down controlling will be a lot bigger issue if RW freq are to be used.
One of the advantages of using RW frequencies, especially at Class D and C airports is that when a tower controller comes online, everyone in the pattern will already be on the appropriate frequency since the tower frequency tends to double as CTAF when those towers are closed. For Class B airports, because they all tend to publish multiple tower frequencies, 122.95 is a good choice since that’s technically the published UNICOM frequency for most–if not all of them. It also avoids potential interference from and with nearby non-towered airports with an actual CTAF of 122.8.
As far as top-down is concerned, I don’t see any change in how things are done right now. When I open up a sector, I assume everyone’s on 122.8 and send them contactme messages. I think the bigger issue is how to handle sims without 8.33 kHz capability.
Then there’s also the question of whether or not using RW frequencies increases the workload of the AFV servers significantly more than using 122.8. I’d really like to hear from a member of the tech team as to how this proposal would affect the server side of the network.
At KSEG Penn Valley one picks up Unicom from KRLV a mountain and valley away, KZER, several mountains away, Danville, PA, Bloomsburg, PA, and Northumberland County. And this is Susquehanna Valley/Anthracite Country Pennsylvania with mountains and ridges. I can imagine what it’s like in Peidmont land or the Mid-West.
I’d like to see 122.800 binned off (and POSCON’s “solution” of replacing it with 122.950 is very much not the answer!), but there’s a few things I think need discussing:
1.) In countries where 122.800 is an operational frequency at one or more controlled airports, how would this rule be implemented?
2.) In countries where CTAF frequencies do not exist in the same way as the USA, how would this rule be implemented?
3.) How do we make sure that less experienced pilots know which frequency to be on?
Personally, I’d be in favour of replacing 122.800 with 121.500 which (as far as I’m aware) is reserved globally and never operational.
Let each vACC/country decide what works best for them and publish it in a standard format where possible.
See if there is a technical solution to send a text message to each pilot with a link to the policy for that FIR when they first connect or transit an FIR boundary.
As I said earlier, I think increasing the range of 122.8 would help. Keeping this for all oceanic airspace would be useful if the range was increased.
Agree. It would be quite welcoming change, especially if it will support regional differences. I think it’s good not to develop bad habits. On the other hand we heavily rely in the Vatsim network on Topdown System, which itself introduce some shortcuts in how we work with ATC, so perhaps the balance needed to be maintained with this update.