And chance of voice CTAF on vPilot?

[Trent Hopkinson]

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?

 

Ever heard of TIBA?

It's a horrible thing that happens when the Air Traffic Control agency can't afford to have a big enough staff to actually keep all of their radar sectors open.

 

Usually only a feature of locations in Africa and remote areas of Asia, Australia had (has?) a long-term issue with staffing levels at Brisbane and Melbourne centres which could occasionally turn large swathes of Centre level airspace into uncontrolled airspace implimenting TIBA (Traffic Information Broadcast by Aircraft) procedures across large-ish portions of the nations airspace.

 

Here's some news articles about it:

http://www.civilair.asn.au/latest-news-1/370-fix-controller-shortage-casa

 

http://www.crikey.com.au/2008/07/08/australian-skies-are-like-the-backblocks-of-africa/?wpmp_switcher=mobile

 

https://www.flightglobal.com/news/articles/australian-government-issues-sharp-criticism-of-air-388311/

 

http://www.wsws.org/en/articles/2008/08/airt-a18.html

And a quote from that article

Only days before the Learjet incident, CASA insisted that there was no risk to p[Mod - Happy Thoughts]engers when pilots relied on TIBA, while at the same time admitting the situation was “less than perfect”. Air traffic controllers, however, contend that some pilots fail to broadcast their presence on the correct frequencies, and many overseas pilots are unfamiliar with the system and do not sufficiently understand the collision avoidance procedures.

 

Now you might think "That's probably only out in the desert somewhere that nobody is flying over". Think again... I remember seeing a TV show at around 2008 showing what areas were running TIBA over a certain period. Some nights traffic from Melbourne to Sydney were having to make a fairly significant easterly diversion to avoid TIBA areas, and several international carriers could either divert several THOUSAND nautical miles off course, or spend a good hour or 3 in TIBA while crossing Australia's centre to get from Asia to Australia's East coast airports like Sydney and Melbourne. Not exactly "out of the way" places.

 

Couldn't find the video of the news article about it, but the map is here (Yellow is "Combined sectors" where 1 controller is running multiple sectors at once, Red is "Centre airspace where 0 controllers are running the sectors")

 

And from a more legitimate news service

https://www.youtube.com/watch?v=nLV6AhuoBk4

 

Anyway, here's a list of procedures from the GEN (25 NOV 04) AIP

 

GEN (25 NOV 04)

5. TRAFFIC INFORMATION BROADCAST BY AIRCRAFT

(TIBA)

5.1 TIBA Procedures

5.1.1 TIBA procedures are intended to permit reports and relevant supplementary information of an advisory nature to be transmitted by pilots for the information of other aircraft in the vicinity.

5.3 Listening Watch

5.3.1 A listening watch must be maintained on the TIBA frequency 10inutes before entering the designated airspace until leaving this airspace. For an aircraft taking off from an aerodrome located within 10 minutes flying time of that airspace, listening watch must start as soon as practicable after take-off.

5.4 Time of Broadcasts

5.4.1 Broadcasts must be made:

a. 10 minutes before entering the designated airspace or, for an aircraft taking off from an aerodrome located with 10 minutes flying time of the airspace, as soon as practicable after take-off;

b. 10 minutes prior to crossing a reporting point;

c. 10 minutes prior to crossing or joining an ATS contingency route;

d. at 20 minute intervals between distant reporting points;

e. 2 to 5 minutes, where possible, before a change in flight level;

f. at the time of a change in flight level; and

g. at any other time considered necessary by the pilot.

5.5 Acknowledgement of Broadcasts

5.5.1 Broadcasts should not be acknowledged unless a potential collision risk exists.

Index ENR TOC AD TOC GEN TOC

GEN (25 NOV 04)

5.6 Changes of Cruising Level

5.6.1 Cruising level changes should not be made within the designated

airspace, unless considered necessary by pilots to avoid traffic

conflicts, for weather avoidance or for other valid operational

reasons.

5.6.2 When changes to cruising level are unavoidable, all available aircraft lighting which would improve the visual detection of the aircraft must be displayed while changing levels.

5.6.3 When a change of level is anticipated or initiated, a change of level report must be made. When the new level is reached, a report advising that the aircraft is maintaining the new level must be made.

5.7 Collision Avoidance

5.7.1 If, on receipt of a traffic information broadcast from another aircraft, a pilot decides that immediate action is necessary to avoid an imminent collision risk to the aircraft, and this cannot be achieved in accordance with the right of way provisions or TCAS resolution, the pilot should:

a. unless an alternative manoeuvre appears more appropriate,

immediately descend 1000FT if above FL290, or 500FT if at or below FL290;

b. display all available aircraft lighting which would improve the visual detection of the aircraft;

c. as soon as possible, reply to the broadcast advising action being taken;

d. notify the action taken on the appropriate TIBA frequency; and

e. as soon as practicable, resume normal flight level, notifying the action on the appropriate TIBA frequency.

5.8 Position Reporting

5.8.1 Normal position reporting procedures should be continued at all times, regardless of any action taken to initiate or acknowledge a traffic information broadcast.

5.8.2 A position report must be made on the next CTA/FIA frequency 15 minutes prior to leaving airspace in which TIBA procedures apply to obtain a clearance or re-establish SARWATCH on the appropriate ATS frequency.

 

 

Not suggesting we apply this on Vatsim by any means, Just showing a real world procedure that covers a similar concept to High Altitude Airliner Cruise common frequency without ATC.

Edited February 10, 2016 at 07:28 AM by Guest

[Trent Hopkinson]

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.

 

These days I literally read back "Frequency change approved" when switched to 'unicom'.

 

To be pendetic, Radar services aren't Control services... in the case of Oceanic or similar remote areas, "Radar Services Terminated" doesn't mean you're controller isn't controlling you anymore

 

"Control services terminated" yes.

 

Quick and dirty change of phraseology to "xxx centre is offline, Control services terminated, Frequency change to 122.8 approved" or some variation thereof.

[Ross Carlson]

Quick and dirty change of phraseology to "xxx centre is offline, Control services terminated, Frequency change to 122.8 approved" or some variation thereof.

 

Why even mention a specific frequency at all? Is 122.8 what they use for TIBA? Would you advocate for a global simulation of TIBA on VATSIM for areas that are normally covered real world?

[Trent Hopkinson]

Quick and dirty change of phraseology to "xxx centre is offline, Control services terminated, Frequency change to 122.8 approved" or some variation thereof.

 

Why even mention a specific frequency at all? Is 122.8 what they use for TIBA? Would you advocate for a global simulation of TIBA on VATSIM for areas that are normally covered real world?

 

I'd probably not really... and I'd deftinately not suggest any Voice TIBA. Usually "Sitting on autopilot at FL350" isn't exactly a busy part of flight where typing is inconvenient. The reason that Australia employed TIBA is because even though the risk of a collision is small, it isn't as small as it is when ATC is actually controlling traffic, and as Dick Smith said in the video (I just edited into my prior post after you posted your reply) The result of that small risk of the worst case scenario coming to fruition is hundreds of deaths.

 

Here on Vatsim, traffic levels are even smaller and the worst case scenario is some angry keyboard action after the fact.

 

Possibly the best way to deal with "Unicom at Flight Level cruise outside ATC" is - maintain the status quo:

Text Only, 122.8 or other frequency that any given division chooses (Brazil and South Africa use different 'unicom' frequencies already), and CTAF as we have already been discussing for aircraft in range (and low enough) on the right frequencies.

 

The other option is to do what is done with the CTAF's, using the frequency usually used by the sector anyway, and having huge thousand nm sq areas which tune the Common frequency for TIBA but only if in cl[Mod - Happy Thoughts] A airspace ie FL245 or above.

 

Personally I don't see much of a point in that though. Leave it as text, utilization the same as the current "Unicom 122.8[except Brazil/South Africa]" text only minus the actual CTAFs.

 

If there's any feeling of needing to pursue that further though, TIBA might be a good real world "inspiration" to construct a framework from. It's a thing that happens in the real world, and it fits the function of "What happens when there's no ATC online and I'm flying a Jet on Autopilot in cruise"

[David Zhong]

1 step and 24 hours ahead of me, Ross!

 

Your proposal is near identical to the existing procedure that we use at VATPAC. With our existing procedure, pilots only join a single voice channel, thus creating a difficultly when nearby aerodromes share a frequency. The main difference between your proposal and our existing policy is that your proposal has the pilot client join multiple voice channels in the case of multiple aerodromes sharing the same frequency.

 

I would also go further to support voice TIBA. As with text Unicom, broadcasts would not be mandatory, but recommended and I would be surprised if many people made all of the broadcasts under the ICAO TIBA procedure. However, certain broadcasts, such as change of level, particularly when commencing descent into major airports, are no less beneficial than CTAF broadcasts at airports with little traffic.

[Richard McDonald Woods]

Very interesting!

If/when we get CPDLC capability as a part of swift, it would be possible to have it provide simulated control when beyond manned FIRs. Then we would be 'controlled' by text anyway everywhere when flying high.

[Jackson Harding]

Ross,

This is a great proposal. In VATOCE we have encouraged realistic use of CTAF for some time now, and both VATPAC and VATNZ have many years experience in doing this. VATPAC even have a CTAF mapping file for another client that moves people into an appropriate voice room when they tune the CTAF frequency when they are in range of it. The voice room is based on the ICAO of the airport concerned.

 

We do have issues with people on the network not using it. The greatest take up is by those with real life experience. Those who do not fly in the real world seem hesitant to use it correctly. We also have significant issues with visitors from outside the Region not being aware that we do try and simulate correct CTAF use.

 

I would like to see the ability in pilot clients of having two frequencies/voice rooms. This lets you monitor both an area frequency and a CTAF, which is what I do in real life every time I fly. I'm talking to ML CTR getting my squawk code and traffic information, and also on the YBDG CTAF as I taxi and takeoff. It would be great to see that in VATSIM as an everyday part of our operations.

 

The cons are obvious. It imposes a training liability, and it makes an issue for text only pilots. Other than significant hearing impairment (and we do have members with those) the true text only pilot is an interesting concept. Many years ago there were bandwidth issues. That was in the days of dial up and I think they are now well and truly behind us. Those who use their computer in spaces with other people obviously have issues, one has to ask to what extent should they be allowed to hold the rest of us back? They can, as has already been pointed out, listen via headphones, even if they can't/won't speak.

 

Training is something best addressed at the divisional level.

 

Finally I think the holy grail is a text-to-speech/speech-to-text interface. I don't see that any time soon.

 

You can expect my support at an EC level for this proposal.

 

Jackson

[Jackson Harding]

 

Soon enough the people at regional airports (including the 3rd largest city in NSW, Wollongong, and the 3rd largest city in Victoria, Ballarat) realize that there's no point in flying to regional airports in Australia. IFR or VFR.

Even with "Every single ATC position in the country manned to excess" - 285 airports in Australia are literally silent.

 

 

Sorry Trent. Bendigo is now the third biggest city in Victoria, we overtook Ballarat a few years go . Same all still applies though, two runways, lots of traffic, firespotting, air ambulance, IFR, VFR, all on CTAF.

 

Jackson

[Ross Carlson]

Possibly the best way to deal with "Unicom at Flight Level cruise outside ATC" is - maintain the status quo:

Text Only, 122.8 or other frequency that any given division chooses (Brazil and South Africa use different 'unicom' frequencies already), and CTAF as we have already been discussing for aircraft in range (and low enough) on the right frequencies.

 

This sounds good to me.

 

Regarding voice TIBA, there is a way I think that could work. This goes back to an idea I had for voice UNICOM years ago. Essentially it involves creating a lat/lon grid, with each square in the grid being something like 50 NM on a side. Each grid square has its own voice channel, named after the lat/lon extents of the square. All squares in a region share the same frequency. (E.g. all the squares in the USA would be on 122.8, but other regions could choose a different frequency.) As a plane flies along, the client would connect to the voice channel for the grid square the aircraft is currently in, plus the 8 surrounding squares. That way you have smooth transitions between grid squares and pilots in adjacent squares can hear each other.

 

This is essentially (I think) the FSInn method, but with finer granularity and the ability to be connected to multiple grid squares at once, essentially a "poor man's range limiting."

 

One thing that I'd be concerned about if we did BOTH voice CTAF and voice TIBA/UNICOM (I'm going to refer to it as voice UNICOM from here on) is that many pilots will just think it's okay to stay on voice UNICOM as they descend and approach an airport, not realizing that there is (or may be) a different voice CTAF frequency for their arrival airport. This is obviously a training issue, but with no controller on frequency to do a handoff from voice UNICOM to voice CTAF, it could be a problem. There may be a technology solution ... we might be able to have some sort of audible and/or visual signal in the pilot client that tells the pilot that he has entered the range of a voice CTAF frequency. Something like "You are now within range of the KBML Berlin Regional CTAF on 122.7."

 

If the regional UNICOM frequency and the CTAF frequency are the same (as is often the case with 122.8 in the US) then the pilot client would automatically switch to the CTAF voice channel for that airport, and disconnect from the voice UNICOM channels for the 9 surrounding grid squares. In other words, when an airport's CTAF frequency is the same as the regional UNICOM frequency, the CTAF voice channel takes precedence over the UNICOM voice channels.

 

I would like to see the ability in pilot clients of having two frequencies/voice rooms. This lets you monitor both an area frequency and a CTAF, which is what I do in real life every time I fly.

 

Yeah, we can already do that with multiple controllers, or with one controller and one ATIS. That wouldn't need to change with voice CTAF/UNICOM/TIBA.

[Trent Hopkinson]

I wouldn't mind not bothering with Voice TIBA "Unicom". it kind of helps cement the idea that the 2 concepts are, indeed, different.

 

Text only unicom for "cruise"

Voice/Text as proposed for CTAF in vicinity of airports.

 

Perhaps slightly out of scope, but..

... now we just need to convince someone to upgrade xsquawkbox, and any of the other strange clients for sims that aren't P3D or FSX, and/or retire clients that can't be bought up to standard

 

 

What sims do we have clients for that Vpilot isn't compatible with?

 

Xplane

Aerowinx PSX 747 (in some cases users can use their visual P3D stuff?)

FS9?

FS2002??

Other things?

 

Are any of those development teams active?

[Wim Sjoholm 1133704]

I wouldn't mind not bothering with Voice TIBA "Unicom". it kind of helps cement the idea that the 2 concepts are, indeed, different.

 

Text only unicom for "cruise"

Voice/Text as proposed for CTAF in vicinity of airports.

 

Perhaps slightly out of scope, but..

... now we just need to convince someone to upgrade xsquawkbox, and any of the other strange clients for sims that aren't P3D or FSX, and/or retire clients that can't be bought up to standard

 

 

What sims do we have clients for that Vpilot isn't compatible with?

 

Xplane

Aerowinx PSX 747 (in some cases users can use their visual P3D stuff?)

FS9?

FS2002??

Other things?

 

Are any of those development teams active?

Most of all you need to convince the vatsim br[Mod - Happy Thoughts] that there's a wish for change. I don't think it's going to be easy tho, they seem quite conservative about their network

[Trent Hopkinson]

Ross,

This is a great proposal. In VATOCE we have encouraged realistic use of CTAF for some time now, and both VATPAC and VATNZ have many years experience in doing this. VATPAC even have a CTAF mapping file for another client that moves people into an appropriate voice room when they tune the CTAF frequency when they are in range of it. The voice room is based on the ICAO of the airport concerned.

 

We do have issues with people on the network not using it. The greatest take up is by those with real life experience. Those who do not fly in the real world seem hesitant to use it correctly. We also have significant issues with visitors from outside the Region not being aware that we do try and simulate correct CTAF use.

 

I would like to see the ability in pilot clients of having two frequencies/voice rooms. This lets you monitor both an area frequency and a CTAF, which is what I do in real life every time I fly. I'm talking to ML CTR getting my squawk code and traffic information, and also on the YBDG CTAF as I taxi and takeoff. It would be great to see that in VATSIM as an everyday part of our operations.

 

The cons are obvious. It imposes a training liability, and it makes an issue for text only pilots. Other than significant hearing impairment (and we do have members with those) the true text only pilot is an interesting concept. Many years ago there were bandwidth issues. That was in the days of dial up and I think they are now well and truly behind us. Those who use their computer in spaces with other people obviously have issues, one has to ask to what extent should they be allowed to hold the rest of us back? They can, as has already been pointed out, listen via headphones, even if they can't/won't speak.

 

Training is something best addressed at the divisional level.

 

Finally I think the holy grail is a text-to-speech/speech-to-text interface. I don't see that any time soon.

 

You can expect my support at an EC level for this proposal.

 

Jackson

 

All (most?) of the clients available are capable of tuning 2 VHF frequencies at the same time via the Radio 1/Radio 2 concept. Certainly both Squawkbox 3/4 and FSinn can, along with the current iteration of vPilot.

 

It's pretty standard fare to run both frequencies IRL to speak to Centre on one and monitor the CTAF on the other, and then switch between them as required.

Example:

 

The main reason I believe that other regions don't use Voice CTAF files is... because Vatsim doesn't support it (yet). If it was officially endorsed, more divisions might use CTAF's in their events more often. Though I know Australia has lots of 737's and A320's operating into CTAFs IRL (examples include Bundaberg, Ballina, Ayres Rock... the odd

) I'm sure other parts of the world get RPT services into CTAF.

Lack of support from the BOG, and subsequent lack of the feature in some pilot clients, effectively means we can't host Fully staffed ATC events at CTAFs at all, without chaining some poor soul to YBNA_TWR without a michrophone and telling him to keep quiet till the event is finished. (Check the server stats for WOL_TWR and weep.. Also "because" I knew I was too busy to fly that night, I logged in as QFA747 and parked just outside HARS as the VFR event flew past - But that's one for the Orbx/FTX forum lol).

 

While speech-to-text is likely a bit much for now. Ross' idea of auto-text distance/direction/altitude for any time someone on a CTAF presses the push to talk button is cool.

IF: CTAF is tuned in

AND: Is in range

WHEN: Push to talk button is activated

FOR: longer than 2 seconds

THEN: Send text

"[Callsign] transmitted from [Distance]nm [Cardinal Direction] of [LOCATION ICAO] [altitude]ft"

 

 

Cap the altitude and range the CTAF can be tuned in. And now everyone is transmitting on text when in a CTAF simply by hitting their PTT.

 

Rest of the rules regarding "unicom" need not change.

Edited February 11, 2016 at 01:49 AM by Guest

[Trent Hopkinson]

There may be a technology solution ... we might be able to have some sort of audible and/or visual signal in the pilot client that tells the pilot that he has entered the range of a voice CTAF frequency. Something like "You are now within range of the KBML Berlin Regional CTAF on 122.7."

 

 

Quick concept edit in microsoft paint...

[Greg Barber]

Hi All,

 

I have been reading this thread with interest and it seems as though there is some very good discussion of the technical and procedural aspects of the issue. From a VATPAC perspective (where we have been somewhat successful in implementing voice CTAF/UNICOM with FSInn) I think I can provide some valuable experience in how this implementation may actually work.

 

Policy on usage of advisory frequencies...

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.

Is this talking about creating a new policy? Just want to be clear that there's not already some policy I am unaware of that states this is already the case.

 

Issue of pilot uptake...

This is why I say "somewhat successful"above. This has been a major challenge in our region not because it's too difficult for pilots but because it was difficult for us as a division to get the message out that this was available, especially to international visitors. Also because there was really only one pilot client that fully supported it (in SB3 you could tune manually but in FSInn your voice room would tune automatically). This meant that there were 3 types of pilot:

• The pilot that used the feature fully, tuning to the appropriate CTAF and using voice to broadcast their position intentions.
  
• The pilot that was aware of the CTAF procedures but was not using voice so would tune the desired frequency and make text broadcasts.
  
• The pilot who was unaware of CTAF procedures or features in their client and remained on UNICOM or the relevant CTR(Area) frequency.

 

For the most part these 3 types of pilot worked quite well together to achieve an acceptable result. The full voice pilot would make the odd broadcast on text just in case there was a text pilot listening. The second pilot's messages would be seen by anyone on the CTAF frequency and the third pilots messages would normally be seen by everyone as the guy on the CTAF was often tuned to the UNICOM, Area or Centre frequency on Comm2.

 

I guess what I am trying to say is, provide the functionality and pilots will work out the best way to use it.

 

The issue of RL 24/7 airports that are unstaffed on VATSIM...

Our policy here has been that any major airport that normally has a 24/7 tower requires that the pilot remain on the UNICOM frequency. Granted we also implemented a voice UNICOM channel but once again this often involved a voice pilot making the main broadcast calls on text as well, to accommodate those pilots. Remember that voice transmissions go out to anyone who is on that voice room, whereas text transmissions are limited by range.

 

The technical requirements...

I do like Trent's proposal above. I think that's a very elegant way to display the info. Perhaps even make it possible to minimise the CTAF window when you are not expecting to use it. If the client is looking for nearby CTAF's (only has to look a certain distance away, say within 50nm) then displaying the CTAFs it finds shouldn't be too onerous a task. Another handy tool is being able to show other aircraft callsigns that are in the same voice room. This helps you to decide whether it's worth reporting on voice at all.

 

Ross, if you have any questions about our experience with the local policies you can get in touch with me via PM or via director(at)vatpac(dot)org.

[Ross Carlson]

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.

Is this talking about creating a new policy? Just want to be clear that there's not already some policy I am unaware of that states this is already the case.

 

This would be a new policy as part of official support for voice CTAF network-wide.

 

The issue of RL 24/7 airports that are unstaffed on VATSIM...

Our policy here has been that any major airport that normally has a 24/7 tower requires that the pilot remain on the UNICOM frequency.

 

My thinking on this is that if the airport is staffed 24/7 real world, then an overlying approach or center controller would be providing tower services there anyway. If there is no overlying approach or center controller, then the regular tower frequency for that airport would become the CTAF frequency. That's how it works at many (all?) airports in the US that close during the night.

 

I do like Trent's proposal above. I think that's a very elegant way to display the info. Perhaps even make it possible to minimise the CTAF window when you are not expecting to use it. If the client is looking for nearby CTAF's (only has to look a certain distance away, say within 50nm) then displaying the CTAFs it finds shouldn't be too onerous a task.

 

I can't say I like the idea of dedicating so much screen real estate to a CTAF list. The way I see it, pilots should already be aware of CTAF frequencies for the airports where they're operating. (It's on the chart!) My suggestion about having the client alert you when you are near a CTAF is meant as a way of helping people get used to the new feature. I wouldn't want it to become a crutch that saves the pilot from having to "be a pilot" and read the charts. I'm picturing something more like an alert noise with a message in the main message area that says you're approaching (or have entered) a CTAF area.

 

If we really think a list is necessary, I would just show the closest two or three that are within 20 or 30 miles, perhaps at the top of the existing list of controllers.

 

Another handy tool is being able to show other aircraft callsigns that are in the same voice room. This helps you to decide whether it's worth reporting on voice at all.

 

I'd rather encourage pilots to make the appropriate transmissions whether there are any other aircraft in the area or not. It's good practice, and more realistic that way.

[Trent Hopkinson]

 

I do like Trent's proposal above. I think that's a very elegant way to display the info. Perhaps even make it possible to minimise the CTAF window when you are not expecting to use it. If the client is looking for nearby CTAF's (only has to look a certain distance away, say within 50nm) then displaying the CTAFs it finds shouldn't be too onerous a task.

 

I can't say I like the idea of dedicating so much screen real estate to a CTAF list. The way I see it, pilots should already be aware of CTAF frequencies for the airports where they're operating. (It's on the chart!) My suggestion about having the client alert you when you are near a CTAF is meant as a way of helping people get used to the new feature. I wouldn't want it to become a crutch that saves the pilot from having to "be a pilot" and read the charts. I'm picturing something more like an alert noise with a message in the main message area that says you're approaching (or have entered) a CTAF area.

 

If we really think a list is necessary, I would just show the closest two or three that are within 20 or 30 miles, perhaps at the top of the existing list of controllers.

 

Another handy tool is being able to show other aircraft callsigns that are in the same voice room. This helps you to decide whether it's worth reporting on voice at all.

 

I'd rather encourage pilots to make the appropriate transmissions whether there are any other aircraft in the area or not. It's good practice, and more realistic that way.

 

Adding it to the Controller list is fine too. Range limiting to 20-30nm is beneficial too, since it will reduce clutter, and there's no reason to tune a CTAF from 50+ nm away.

 

My suggestion would be at the Bottom of the controller list, as the current list is from top down, largest and highest altitude on top.

FSS

CTR

APP/DEP

TWR

GND

DEL

CTAF

 

I'm [Mod - Happy Thoughts]uming if no APP, TWR GND etc is online those categories remove themselves, so it is likely that, when only CTR and maybe a distant APP is online, the CTAF list will be close enough to the top to be seen easily. And given the range limitation 20-30nm will be small enough to not be silly.

 

Ross' idea of linking the Push to Talk button to an automated text message when (and only when) tuned to a (range limited) CTAF is a very good idea. That way text and voice users both will see anyone using the CTAF in any way, voice or text, and know it's time to start co-ordinating if needed.

 

Adding Location (Distance/Bearing from field) and Altitude info to this automated text helps even more for the text pilot to determine if they need to start co-ordinating, or if they can continue making just their standard broadcasts.

 

So if you're on Text only, inbound to YWOL from the North West and am 8nm from the field at 3000ft and tuned to the YWOL CTAF frequency, you might see

VH-XTZ made voice transmission 11nm NorthWest of YWOL at 3,704ft

and decide to start typing.

 

Or you might be the same text pilot, already be on final for rwy 16 for a full stop landing, and decide not to respond to that, because you already made your base and final call a few minutes ago, and there's no chance XTZ can cover 11nm and land in the time it takes you to land, vacate, and taxi to parking. Instead just concentrate on landing, and then make a standard CTAF broadcast once vacating the runway.

 

What's the list so far?

 

• Server hosted CTAF list updated only by staff from the divisions
  
• Range limited CTAF tuneability
  
• Altitude limited CTAF tuneability
  
• Automated text notification broadcast on activating PTT when tuned to CTAF (With range/location info derived from point 2 & 3)
  
• A way of notifying the user pilot that they are inside CTAF range
  
• possibly by including it in the "Controllers in range" window by airport ICAO designator, likely derived from the same tech in point 2 and point 3.

 

Anything missing?

[Sean Harrison]

Love the way this is going.

 

As a matter of consideration could I mention my belief that we need to publish the voice rooms in order that other clients can all be standardised. Specifically, as way of example, I'd hate to see FSInn users tuning to different voice rooms to other clients.

 

I'm sure that this would be considered, but couldn't go without mentioning it in case!

[Greg Barber]

Hi Ross,

 

All reasonable and measured responses. They all look good to me.

 

The 24/7 tower solution works as well. This is indeed how our non-24H towers work (the TWR frequency becomes the CTAF).

 

If you need any further perspective let me know.

[Trent Hopkinson]

Love the way this is going.

 

As a matter of consideration could I mention my belief that we need to publish the voice rooms in order that other clients can all be standardised. Specifically, as way of example, I'd hate to see FSInn users tuning to different voice rooms to other clients.

 

I'm sure that this would be considered, but couldn't go without mentioning it in case!

 

 

That [Mod - Happy Thoughts]umes FSinn remains in the list of supported clients

Even as an exclusively FSinn user, the only reason I haven't jumped ship on that client is the CTAF voicerooms in Australia.

 

Nevertheless, [Mod - Happy Thoughts]uming such a proposal is accepted, I'd guess a variation of the "vPilot CTAF list" file could be distributed for other clients while they remain supported on the Network. unfortunately as the developer of FSinn is no longer around, there's no real way to ensure all FSinn users have the same data source... other than retiring the client.

[Ross Carlson]

My suggestion would be at the Bottom of the controller list, as the current list is from top down, largest and highest altitude on top.

 

I'm thinking it should be at the top because if you're approaching a CTAF zone, then it is very likely you'll need to tune it in. If we put them at the bottom, then if the user has the client window reduced to the minimum size (as many do) then the CTAF item(s) could be off screen. Consider an event where you've got multiple centers, maybe multiple approaches, some ATISes. It's entirely possible that a pilot would be entering a CTAF zone and still be well within the range of all of those center/approach/atis controllers. Maybe even a tower controller or two.

 

The CTAF item(s) would only appear if you were within (or near) their range and at or below their altitude ceiling, so it's not like you're going to see them unless there's a high likelihood that you'll be needing to tune them in. That's why I'm thinking they should get special placement in the list, at the top.

 

I'm actually not convinced we even need to show them in the list ... I think an audible alert with a message that says that you're approaching the CTAF is sufficient. Many pilots, myself included, don't even have the vPilot window visible through most of the flight.

 

Perhaps we could do both and let the user decide if they want an audible alert, a message, or an entry in the controller list, or any combination of the three. Once pilots become aware of the voice CTAF capability on the network, they'll hopefully turn this feature off and just tune the CTAF after looking at the chart, just like real world. This is really intended as a learning aid after all.

 

In fact, now that I think about this a bit more, I'm wondering if the alert should only happen AFTER you've entered the CTAF zone and haven't yet tuned the frequency. I think if voice CTAF becomes a reality network-wide, the VATSIM staff will want to send out a NOTAM to the membership with a link to a page describing how CTAF works, when it is used, and on which charts you can find the right frequency. So any sort of notification in the client would really just be a nudge for pilots that didn't get the NOTAM, didn't bother to read the summary of CTAF usage, or just lost situational awareness and didn't realize they'd blundered into a CTAF zone.

 

I'm [Mod - Happy Thoughts]uming if no APP, TWR GND etc is online those categories remove themselves

 

They don't currently, but I'll probably change that ... there's certainly no need to have empty group labels shown.

[Ernesto Alvarez 818262]

the sooner FSINN and Squawkbox are put to bed, the better it is for everyone. its time to face it, theyve long been put to rest by their own developers. its the main thing that has been holding the network back. the only way for change is to simply put these older clients to rest, which i believe will come about once Swift is released. this is the one client that promises to be multi platform, so chances are it may even replace Xsquawkbox if that ones not being updated any longer. network cant make too much technical headway, like we all want them to, until thats accomplished.

[Ross Carlson]

Agreed, once swift is out, there should be no good reason to keep supporting the legacy clients.

[Sean Harrison]

the sooner FSINN and Squawkbox are put to bed, the better it is for everyone. its time to face it, theyve long been put to rest by their own developers. its the main thing that has been holding the network back. the only way for change is to simply put these older clients to rest, which i believe will come about once Swift is released. this is the one client that promises to be multi platform, so chances are it may even replace Xsquawkbox if that ones not being updated any longer. network cant make too much technical headway, like we all want them to, until thats accomplished.

 

That is a bold statement. I can't see any reason at all why putting FSInn to bed would be better for me. It works superbly for me, and I can't see one reason why I want to stop using it.

 

I can fully understand if VATSIM staff don't want to support it anymore; not sure how much effort goes into currently supporting it; but banning it or not allowing it to be used would be soooooo wrong.

[Christopher Collins]

Perhaps slightly out of scope, but..

... now we just need to convince someone to upgrade xsquawkbox, and any of the other strange clients for sims that aren't P3D or FSX, and/or retire clients that can't be bought up to standard

 

I really don't need convincing - what I need is (development) time, which I'm quite short on right now.

 

I'm all for voice CTAF, but as there's no standard, it involves a lot of making stuff up - and that's actually quite a lot of work to be doing without support from the network as a whole. (that said, I want it badly enough for AU that I was already planning on doing it). If somebody wants to throw a standard together, I'm all ears.

 

If somebody wants me to throw a standard together... well... we can discuss that...

[Trent Hopkinson]

I can fully understand if VATSIM staff don't want to support it anymore; not sure how much effort goes into currently supporting it...

 

The guys that developed FSinn literally haven't responded to emails about their client, written a post on a forum, or connected to Vatsim for over 5 years. The support forum is run by a guy who had literally nothing to do with coding it and learned the ins and outs of using FSinn the same way most of us did. By experimenting and learning by trial and effort. (And I'm [Mod - Happy Thoughts]uming it was a lot of effort!)