Frequency isolation logic is going to change

[Keith Smith]

Given the volume of GA VFR/IFR requests, I don't think this would have a lot of operational impact just yet, but I absolutely see it as being valuable in the future. We'd need to make some server-side changes to support the notion of squawk code being assigned to an aircraft that isn't yet connected, otherwise, we have what we need to do this. We could even modify the pilot client to allow the result of the PDC request to be fetched. This would be a huge win for sim integrators who have configurable FMCs who might want to retrieve their clearance while in the cockpit via PDC. It's a great direction, but it's not the solution to the current problem.

[nigelmcelwee]

I think this is a great Idea Keith. I too find that too many pilots are stepping on each other. Two nights ago I was doing circuits at KSNA and the controller on the tower was also a departure clearance controller and so many people kept stepping on each other he was just asking for xpdr readback only. I was supposed to report midfield each time so my report went at about lightning speed to help him out.

[Steven Winslow]

...rather than waiting to hear the controller say "readback correct."

That's precisely what I have been doing all along. I know after the controller speaks there will be a pilot response. I try to gauge that pilot response time and then make my request. Obviously, even that doesn't always work.

[Jeff N]

This is great news. I've actually been listening to the PE receiver while on the network to accomplish the same thing.

[Nick Warren]

There are way more cold calls on ground then any other role in the system. The exchanges also tend to be longer. The combination of those two things can be sinister the way things are currently set up.

I am certainly not one to quarterback the business model or staffing pattern, and while I don't fly on PE often, I have noticed the same person working all cab positions. That person is just getting hammered sometimes so is it prudent to separate the cab positions as this service grows? I'm just wondering if it would in part help reduce some congestion in itself not so much separating GND and CLNC but certainly separating off TWR from the other two.

On a side note, and please feel free to move this half of the discussion. I realize there is a certain amount of errata when it comes to desiring flight following off the ground and I have been guilty of not requesting it initially before as well, but there seems to be a lot of information gathering prior to taxi that I wouldn't normally provide at Class D airfields. I do realize some fields such as SNA and PSP have provisions to contact CLNC prior for advisories and even advising those intentions with GND at other fields, but in other cases where advisories are not requested, should I not be able to just call location, request for taxi, current information/numbers? Then when contacting TWR state request of remaining in the pattern or departing to the (direction), etc. It just strikes me as another item that is consuming an already overloaded ground frequency.

Just thoughts, and I always appreciate the service and think the controllers do great even considering the expansive workload.

Nick

[Keith Smith]

Hi Nick,

We do run a dedicated ground during parts of the weekend. Check the weekend recordings at http://pilotedge.net/audio and you'll see the ZLA Ground position recordings. In those cases, the workload on tower is significantly reduced. However, ground still has problems because of the voice isloation. People make long initial calls and the blocks continue to be a problem. We do have the provision to split the load among 2 ground controllers (and even 2 separate clearance delivery controllers) but it's a not a configuration we have run because of staffing limitations.

Most ground controllers in the real world are going to ask for direction of flight or your intentions prior to issuing the taxi instruction. This information is then passed to the tower controller prior to you reaching the runway. I am not aware of anything we could do to shorten the interactions that currently take place on the ground frequency, other than asking pilots to be succinct, prepared, and provide all of the information needed (location on the airport, departure request, and a statement regarding them having the ATIS or current weather).

[Nick Warren]

Thank you for the detailed reply. I can certainly be more diligent in providing the information up front with ground. At my home airport IRL (Class D with Class E overlay), it is not common with ground control, unless of course requesting outbound advisories. I can certainly appreciate the intricacies of SOCAL airspace though.

Nick

[Keith Smith]

This change was deployed this morning. Expect to start hearing a lot more pilots whenever you're working with a controller who is also covering the ground positions.

[NyyDave]

I misunderstood what was changing exactly and I was surprised to hear -all- of the calls my controller was receiving and not just calls for clearance. If it turns out that the clearance calls are really all that's causing the problem will changing to clearance only be considered? I understand the intentions of the change it's just strange hearing Grand Canyon calls for departure sitting at the gate in LA even more so since I didn't think non clearance calls were the issue.

As a side note, I understand that this exact example from tonight is due to the controller covering tons of frequencies.

Thanks,
Dave H

[Keith Smith]

A significant percentage of the towered airports don't have a clearance frequency, so there isn't really a way to distinguish between a ground call vs a clearance call. Additionally, it's not just the IFR clearances that result in blocks. Requests for VFR departures also cause congestion on the ground frequencies. The clearance, ground and tower positions all have cold calls from pilots associated with them. With frequency isolation in a combined environment, the cold calls can result in blocks that result in less efficiency, slower perceived response time and increased controller fatigue.

My first post on this topic did state that you would be hearing all of the traffic being worked by the controller who was serving the ground role, and I did imply that the same controller might be working higher level positions as well. It's common for us to run in a 2 controller configuration, with one person covering clnc/gnd/tower for all the fields with the 2nd controller covering all the radar positions. With this new logic, you would hear all the pilots talking to a clearance, ground or tower frequency. If we start doing partial isolation for a given controller's domain, the code becomes considerably more complex for not much return.

Simply put...1 person working 100+ positions is going to require some kind of compromise, especially as it scales. The only case that would be completely realistic would be if we had 80 controllers online, each covering a clnc/gnd position or a tower position for each towered airport. I hope the day comes...the system is built to scale to that level and the radio system can handle it...but the finances of that case don't work without massive levels of sponsorship. You're well on the way to replicating the National AIrspace System at that point.