Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Brad Littlejohn

Pages: [1] 2 3 ... 9
A16 - many, many pilots using 122.800 as a chat line.  I remind folks and then I just wallop.

You're doing the right thing here in .wallop.

B8(a-c) - so many folks are unable to operate in the airspace with respect to following a /L or /Z flight plan.  Lots of wet nursing taking place on the part of the controllers.

Mandatory training for pilots please.

Ongoing issue on this one, as it has been an issue since RNAV was implemented over 20 years ago. Back then, those that filed RNAV were still waiting to be vectored, meaning that they had no clue about the concepts of RNAV or what was supposed to be done when it is filed. Now that RNAV is the norm, they still don't know..

Back then those who filed RNAV knew what they were doing and didn't need to be vectored. Now, those that do not file RNAV appear to be the ones that know what they are doing and respond properly when vectored.

Unfortunately, this may be an issue bigger than VATUSA can handle; the BoG has routinely stated that this is a learning environment, and as such, training for pilots has been optional, while training is required for controllers. This has resulted in some turnover of controllers which is a result/byproduct of being stuck in this position. I wish there were a solution for it, but until VATUSA and VATSIM come to an agreement for what should happen, this problem (pilot competency) will continue.


See subject.  Very draining on controllers.

It may be worth explaining what these issues are, as well as the context around them. This is very vague.


The Classroom (Controller Tips) / Re: Mac OS compatibility
« on: March 28, 2023, 08:03:39 PM »
Hi folks,

It's been quite a long time for me. I did do a cursory search of the forum but am wondering if there's been an updated process or suggestion.

In an effort to return back to this hobby, I'd much prefer to not go out and buy a windows laptop. Currently have a 14in MBP that I'd like insight from folks on how best to use it for VATSIM. Appreciate your time.


JH! yes, it's been a while!

Okay, here's the question.. Is your MBP an Intel Mac or an Apple Silicon Mac? If Apple Silicon, there is nothing you can really do that is native to the Mac for controlling. You may be able to get away with running a VM with Parallels and use Windows 10 for ARM, then you may be able to run something like vSTARs, vERAM, or CRC when it comes out. Ross would be able to chime in more on this to say which clients would work through that.

If you're running an Intel-based Mac, you could still use VRC via Crossover if you want to stay solely Mac Native. Otherwise, you can run anything like VMWare Fusion, VmWare Workstation, or use BootCamp and load Windows onto your Mac and use any client you'd like.


The Control Room Floor / Re: Pilot Expectations, cont...
« on: July 12, 2021, 02:04:47 PM »
This brings up another good idea. Pursuant to the Pilot Deviation idea above, one thing that the VATUSA brass could also implement is a "suspension" (again, lack of a better word) of an offending pilot's use of the network pending a slight variation of an Operation Raincheck

Unfortunately, this is not something VATUSA could do. VATUSA does not have the power to suspend users, only a SUP or DCRM can do so with the current Code of Conduct and CoR in place. From what I've been seeing from the BoG and the VATSIM meeting minutes, they are in no rush to change that policy.

Hence why I said that this would have to have buy-in from the BoG and every other division. Such a change like this would have to be done NETWORK wide, not just division-wide. Because of that, it needs to be seen if the same pilot issues we are having at VATUSA are also happening in the other divisions; as VATUK, VATSA, VATNZ, VATEUR, and VATEUD are seeing a lot of traffic, are the same piloting idiocies happening there as they are here. If they are, then there is our justification for taking this to the BoG and letting them talk it out.

I know RJ frequents this forum, doesn't live that far from me, and still has some pull at the BoG, as well as Don. I'm more than sure they are aware of this and also could take up the mantle and see how far it can go.


The Control Room Floor / Re: Pilot Expectations, cont...
« on: July 07, 2021, 06:06:31 PM »

Wow.. and with no hint of sarcasm or cynicism, I have to say that here we go again with this thread. Not that it is tedious or to gather a ton of groans, but that if it is being brought up again, it is important and something needs to be done. What that something is is the question.

A lot of what was mentioned in this thread and in the other thread was visited a number of times over the past 20 years. The PRC. VATSTAR. Training Academies. Opinions vary on the successes of those, but if the problem still persists to where 20 years on we are still talking about the same thing, the  the same things we are trying and expecting a different result is what is known as Einstein's Definition of Insanity.

Now, not all is doom and gloom, as I've seen some ideas here that should be taken into consideration. With that, let's dig in:

Possible Solutions:
- Pilot Deviation Reporting - No brainier and everyone above has indicated exactly how I'd go about it. Pilots need to be able to see it so they can learn and grow. Should be managed by the Facility with the ability to be elevated higher if further action needs to be taken.

I really like this idea, as what we should be able to do is if there is a problem, ATC should have a way to log that problem and submit it to the top brass (SUP and above), who should act as the moderators of that. They then send a "please explain" or similar type message to the pilot, either allowing the pilot to explain their side of things or a "these are the rules, you need to be reminded to follow them", etc. In short, SUP and above are the FSDO.

- Pilot Rating System similar to Pilotege - Their system works. What I like most about their system is you don't have to use it, but you better be good. If you are not good, use this program to get good. Oh by the way, no exam, just get on the network fly and prove that you can perform with a entire network of people around basically 24/7 to help you understand complex concepts/material.

Keith expanded on what we already had here at VATSIM at the time (Keith was the ATM of ZLA here), so he already knew what he wanted to do, but took it more commercially. We could do similar here and should. The issue here is that the ratings system was relative to what the pilot was learning at the PRC, but apparently, the PRC wasn't taken seriously among the rest of the network; it was a recommendation rather than a requirement, because there has been the longstanding ... well.. "common knowledge" (lack of a better word) that anyone should be able to join the network as a pilot, regardless of experience, as this is a learning environment. And while I get that, understand that, and agree with that, we need to hold that learning environment accountable. There needs to be a way to validate that that learning is indeed happening.

- Controller kill Pilot capability - Remove the problem child when they are a problem (even if not on purpose) and file the report. Maybe they didn't know, but now they do and everyone can learn and grow. The reality is SUP's (to no fault of their own) are poorly equipped to actually decide if a pilot is worthy of a kill as it relates directly to air traffic operations in a "timely" and fair manner. The best equipped people to decide that is the facility. Guy who's frame rates aren't cooperating, kill. Guy who spawns on runway, kill. Guy who leaves computer 20 miles from the field on final freq, kill. File the report. They learn, your scope is manageable again, everybody happy. I imagine the process of the ".kill" is probably more complex, but you get the idea.

I want to say that SUP and higher have that ability, but I can see where as a controller, that ability can be abused. For example, if you know of a certain person that is known to cause trouble on the network, hasn't done anything wrong, but you just don't want to deal with them, having the ability to boot someone off the network just because or out of spite can cause issues that VATUSA doesn't want to deal with, let alone VATSIM as a whole.

I see pros and cons to this, and why it is limited to those SUP and higher. In fact, I've only seen it used twice while controlling: once by Harv or Amy, and the other by GSM, when some idiot using FS2000 wanted to joke around and crash into the WTC.

I realize that in practice, this is a gross oversimplification of what would be required to establish such a system and VATSIM/VATUSA has come such an incredibly long way over the last year. Most of what needs to be said has already been said and I ultimately want to provide my +1 for this issue.

This wouldn't be that hard to do, as it basically requires a way at the controller client level to be able to log the session (this becomes "the tapes") so that if any pilot deviations occur, they can get sent to the SUPs to be handled. The only drawback with this is that that logged session wouldn't include any logging of voice comms, unless those could be logged at the voice server level (I haven't looked into AFV to see if that's possible). If it is, that's okay. Additionally, the handling of this would have to be at the division level, because a SUP at VATRUS, VATKOR, or VATSA wouldn't have a clue about what we are doing here.

Hey everyone,

*  Pilot fails to contact me in a timely manner.
* Pilot has a language barrier and is unable to contact me in English when the language of the air is English.
* Pilot fails to turn in a timely manner after requested to turn by a controller.
* Pilot fails to understand what "Hold for Release" means
* Pilot doesn't understand that PDC commands via PMs are NOT CPDLC systems and attempts to contact me via telex and uplink messages.

Daniel Kormendy

This brings up another good idea. Pursuant to the Pilot Deviation idea above, one thing that the VATUSA brass could also implement is a "suspension" (again, lack of a better word) of an offending pilot's use of the network pending a slight variation of an Operation Raincheck.

Seeing that all pilots have the OBS controller rating, should they commit an offense more than a couple of times (those offenses being reported; see above), they can not fly on the network until they've visited the ARTCC they've had the problem in, if not the staffed airport in particular to see what the SOPs are for that airport and seen them in action on the network, on the scopes. Yes, this would require them to have a simplistic ATC client installed (shout out to VRC for simplicity) so they can observe the controller and what they should be doing that conforms to SOPs and pilot expectations on the network. This could even be a Sweatbox session or something similar; it just has to be something where the pilot gets a crash course in the area they are having trouble in, and also so they can see how whatever problem they are creating cascades down to others having a problem, which in turn makes everyone's enjoyment of the network turn belly up.

Now, language barriers we may not be able to handle, and quite honestly, that isn't our fault, nor the fault of the network. I've controlled pilots from Japan and Malaysia who could understand English better than they could speak it, so I couldn't fault them for if they couldn't understand what I wanted them to do. All that could help that is patience and giving them the time to set up for what they need.

However, the others fall back onto training and being able to look over the controller's shoulder to see what should happen when it is done right versus what they are doing wrong. They can take that into account, apply it, and they are on the network again. Again, that's logged on a private part of their record (only SUP and higher would have access to that), so should they commit an offense again, they get a sterner warning from the brass; after that, suspension or sacking from the network.

Now, finally, the only other thing any of these (not just my) suggestions need to take into consideration, is that some of these changes would be global, across the entire network. So every division let alone the BoG would need to have buy-in on it, and that is even if their region isn't having such a problem. So it's a big undertaking for us here, but any suggestions would need to be run up to the BoG for those to occur.


The Classroom (Controller Tips) / Re: Runway RVR
« on: November 18, 2020, 12:15:22 PM »
The Detroit Metro ATTC SOP states that one of the factors that should be taken in to consideration while conducting LUAW procedures is RVR.

Could you shed some light on how RVR could effect LUAW?  Thanks.

Here's two different situations to consider. If visibility is low enough and RVRs are poor (If I remember right, ceiling has to be 800 or less, or 3SM visibility or less) ATC has to protect the ILS critical area when an arrival on an ILS approach is inside the outer marker or FAF for the approach. That would put the ILS hold bars for the critical into play so you may have to have an aircraft hold short of that critical area. Depending on RVRs for that runway, you may not even see that holding point until you're close or on top of it. That will affect a longer time for LUAW, as you are not completely holding short of the runway itself.

Another example. Say the soup has come in, you have VV001, and you've been given LUAW on the runway whose full length is 7300ft, but the RVR is less than 1000. You now have to take into account your speeds and when to rotate, and remind yourself of the full length of the runway as you won't see the end of the runway until you are 6300ft or more down the runway.

With that, bear in mind that RVRs are always fluid and changing, as they are not static for the entire hour that the METAR gets updated. You could have RVRs change between readings without having a new METAR report come out. However, since we can not change that here, we are limited to having the RVRs for the entire hour that the METAR reading is current.


The Classroom (Controller Tips) / Re: AIRAC File Corrupted?
« on: September 18, 2020, 11:59:28 AM »

Is the sector file located at ZDC's site? I still have Crossover running on my Mac (OS X Sierra), so I can give it a try and see if it is what you are doing, or the file that is the problem.


The Flight Deck / Re: What's the point - point 8, point 9...
« on: June 25, 2020, 08:32:32 PM »
Hi Gez,

It's in the FAA's governing document for ATC comunication, the 7110.65 under section 2-1-17

Transfer radio communications before an aircraft enters the receiving controller's area of jurisdiction unless otherwise coordinated or specified by a letter of agreement or a facility directive.
Transfer radio communications by specifying the following:

The facility name or location name and terminal function to be contacted. [...]
Frequency to use except the following may be omitted:
FSS frequency.
Departure frequency if previously given or published on a SID chart for the procedure issued.
Ground or local control frequency if in your opinion the pilot knows which frequency is in use.
The numbers preceding the decimal point if the ground control frequency is in the 121 MHz bandwidth.

I also thought it was funny that for how specifically particular the FAA is with what we are and are not allowed to say, the .65 still that this paragraph in it. It sure is fun to "legally" take shortcuts lol!

Think about it this way.. if there is only one ground frequency, you don't even need to specify even part of the frequency when you hand them off!

Well, they want us to use minimal time on the frequency, right!?!?  ;D


Really good post here, Shane!

One thing I will say, however, and this is completely tongue in cheek, is that at ORD, you have it easy!  :P Let me explain.

With how ORD has changed so much to keep nearly every runway parallel in an east/west configuration (I think barely the 14/32s and 4/22s are still there), you've increased effeciency for the number of arrivals and departures that can come in, as they are all based in a single flow. The downside to that, as you've mentioned, is the in-trail separation needed for departures with the same SID.

When you have simultaneous converging runway operations with parallel runways, you can get that separation implicitly applied, while splitting the cramming of so many arrivals down the same runway by offloading them to the other set. For example, KLAS.

When in configuration #1 (landing 26L, departing 26L/R and 19L/R; we have 4 different setups there) there is one particular SID that only departs 26R and requires a right turnout (STAAV8), whereas everything else departing 26R requires a left turnout. That means you can implicitly get that in-trail separation for two STAAV8 departures by having a departure launch from the 19s after the first STAAV8 departure is airborne. It takes sequencing this at the ground level for this to be accomplished, otherwise every other aircraft would be waiting for that same in-trail separation to take off, creating that delay. So the sequencing at that level is very important. Also, the good part about that, is that while that departure off the 19s is on its takeoff roll, any arrivals that just landed on 26L can safely cross 26R, so they aren't waiting either. Now, this isn't to say to just send all departures except STAAV8 to 26R and all other departures to the 19s, as you'll still have in-trail separation on the other SIDs, wake turbulence, arrivals crossing, etc., to deal with.

Another example. In Configuration #3 (landing 1L/R, 26L, departing 1L/1R; 26R is closed/taxi only, owned by GND), we're limited the most by the airport layout for most taxi instructions. If you're on the GA side of the field (west of 1L), you'll have easy access to the runways, but the main terminals are east of 1R, so they will all have nearly the same taxi instructions, including crossing 26R. But because of this configuration, you're going to have more in-trail separation to deal with, as well as the parallel runway ops we see at JFK, ORD, LAX, and the like. So what we can do in this case is separate the departures by the turnout they have off of the departure end. For example, all of our southwest/northwest departures (BOACH,SHEAD,MCCRN) can be given 1L for departures, while everything southeast/northeast/east (TRALR, HOOVR,COWBY/LAS) can be given 1R, and both 1L and 1R departures (especially if RNAV) can be simultaneously launched. This way, you're maximizing runway efficiency for both arrivals and departures, instead of having only one runway for arrivals and one  for departures.

It's in a setup like this that I'm actually happy that LAS isn't going to a single flow setup for traffic, because we wouldn't have all of these different ways to organize traffic (I'll save Configs #2 and #4 for another post).


General Discussion / Re: ARTCC Anchorage FIR Division??
« on: June 16, 2020, 12:08:51 PM »

Curious. Does PCF also handle ZAK? I ask, because I don't know if what you are doing there is cancelling the Pacific Oceanic Partnership between VATUSA, VATNZ, and VATPAC. Their site still exists, but their forum doesn't anymore, as it relied on the old VATSIM forum that was updated.

Is the Pacific Oceanic Partnership still in effect?



Will anyone mind if I grin evilly while stroking the back of the purring cat sitting in my lap and remind everyone of the time that we completely closed KLAX (left it unmanned and completely unstaffed) during California Screamin' II? We actually outdid our numbers between ZOA, ZLA, and ZAB compared to the first CalScream held the year prior, and since everyone only thought it was a huge LAX fly-in, we closed it, and denied any services to/from the field. Pilots treated LAX as closed (with full on CTAF), canceled their flight plans with us in the air or on the ground, and picked up IFR in the air with us should they have needed it. Anyone wanting IFR practice approaches or services went to the next closest Class C or D airport.

Ahh yes... Good times there indeed... now.. can someone put a cucumber on the floor behind this cat so it can get the heck off my lap?  ;D


The Control Room Floor / Re: Direct Requests
« on: March 30, 2020, 12:33:03 PM »
Not real sure what the GNSS capability of a/c performance has to do with clearing (or filing) to fixes or en-route waypoints.  Remember, for continental operations (not remote or oceanic) aircraft operate on RNP-2, so the GNSS component for this discussion comes to play only on arrival and approach operations.

I doubt most (if not all) Vatsim artcc's have LOA restrictions or discussions regarding en-route directs.  With that in mind, I try to apply what makes sense.  I do not believe in clearing someone 1000nm downrange to a long distance fix, and rarely have I seen this IRL. Clearing aircraft (on vatsim) to a known fix in the next artcc or subsequent following artcc is far enough.  Additionally, a C1 should have a little knowledge of major airspace around the country and the en-route structure.  In other words, if heading to the west coast, you should know there are fixes/vor where airways or arrivals begin and avoid restricted/military airspace (don't clear direct to LAX!).  Same applies to the NE airspace, etc.  There is a difference when the destination is MSP, ATL, MIA, JFK, SFO, vs OMA, AMA, BOI, etc.   

It is an interesting discussion though...

And  that's the funny part.. I was on a OMA-LAS flight once where right over LNK, the pilot put in a request for direct KSINO and got it. I've also heard flights overhead on my scanner where a pilot put in a request direct LENDY and got it. I'm in Sacramento. So I've definitely witnessed where they get approved those requests well and truly much farther out than their sector's boundary, but there is no real standard or correlation to how far, or how much coordination goes on between multiple sectors for it.


The Control Room Floor / Re: Direct Requests
« on: March 27, 2020, 11:52:34 AM »
Very good topic! I was taught that an APREQ is required if you amend an aircraft's flight plan and it affects the next controller. I look forward to hear if this is actually the case since I haven't been able to find any official rule.

This brings up another question: does APREQ for a shortcut really modify an aircraft's flight plan? For example, let's say I have the following plan from KOMA-KONT:


If the aircraft is already on J60 (which they will be when they cross LNK), would sending them direct NATEE amend their flight plan? NATEE is on J60. I ask, because a shortcut could be sending them directly to a fix that is already on their flight plan, or covered by an airway that is in their flight plan. That is different from say, needing to send them to a new transition to a new arrival to a field that is different from what they filed. That would require an amendment.


The Control Room Floor / Re: FAA Digital ATIS Text
« on: January 14, 2020, 06:31:16 PM »
Thanks again for this, JS!

FWIW, I support the decision not to integrate it into vATIS, and I’d be cautious in rushing to duplicate the r/w ATIS to a fault for VATSIM use. We don’t need non-pertinent NOTAMs about cranes, construction equipment, laser strikes, etc. in the VATSIM ATIS unnecessarily. This is useful for reference to duplicate the framework for your own vATIS profiles, but I think it’s important to respect the barrier between simulation and reality.

But on the other hand, it would help (to a degree). For example, for those airports that have a particular set of noise abatement procedures, especially those with runway configuration changes, or density altitude or performance due to weather, having that info in the ATIS especially if an airport is unstaffed could add to the realism.

That said, having an ATIS running at an unstaffed airport is an issue in and of itself, but there you have it.


Just like in real-world when airports close, have the ATIS become an AWOS with remarks. Be great to have AWOS at a lot of airports. Surprised that not even PilotEdge has done that yet. Be a nice thing for VATSIM to claim to have done first.

Good point! Obviously, if we could change the remarks, I could definitely see the benefits of that as well as use on the network. For example, when KVGT closes, they have a running AWOS with the weather, then the remarks about when they close and open (obviously, not beneficial to us), additional weather available at the PRC FSS (again, not beneficial to us), CTAF, for clearances out of the field into Class B Airspace, contact LAS APP on 125.9 or 124.0 if on the ground.

If we could change the remarks to make it VATSIM specific, then we'd have a great AWOS function at every airport that has D-ATIS, which would alleviate the issue of the CTR controller only being able to publish ATIS info for one airport when running in a top-down setup.


The Control Room Floor / Re: FAA Digital ATIS Text
« on: January 13, 2020, 06:21:11 PM »
Thanks again for this, JS!

FWIW, I support the decision not to integrate it into vATIS, and I’d be cautious in rushing to duplicate the r/w ATIS to a fault for VATSIM use. We don’t need non-pertinent NOTAMs about cranes, construction equipment, laser strikes, etc. in the VATSIM ATIS unnecessarily. This is useful for reference to duplicate the framework for your own vATIS profiles, but I think it’s important to respect the barrier between simulation and reality.

But on the other hand, it would help (to a degree). For example, for those airports that have a particular set of noise abatement procedures, especially those with runway configuration changes, or density altitude or performance due to weather, having that info in the ATIS especially if an airport is unstaffed could add to the realism.

That said, having an ATIS running at an unstaffed airport is an issue in and of itself, but there you have it.


Pages: [1] 2 3 ... 9