Evan Reiter

Another successful Colorado Getaway is in the books as far as I'm concerned. Thanks for joining us at KASE, KCOS, and KDEN this past week. As enjoyable as the event was, however, it will certainly be a relief to get back to the East Coast where I don't have to worry about vectoring anybody into a mountain (I'm glad to say that didn't happen once this getaway). I'm sure controllers who have been waiting until we get to KBOS for their certifications are happy to hear that we'll be beginning that tomorrow as well. See you in Alaska later this year!

Thanks for the suggestions! Let me start with a brief explanation of our events. Running events at a virtual community like ours is a balancing act: we need to keep both pilots and controllers as happy as possible. Having too many events that favor one group over another isn't healthy in the long-run. Too many pilot-focused events and controllers won't want to sign up to control| pilots find some of the best ATC-focused events too short or unrealistic. We generally try to offer a range of events in different locations to keep things interesting and try to vary events between long and short, easy and challenging, pilot-focused and controller focused, etc. If you haven't had a chance to look through our Events page, I recommend you do so. Many of these events are coming up in the next month, so you should have a good chance to see what events at BVA are all about. When it comes to suggestions about events, I generally try to accept as many as possible if they seem feasible and will have the support of the community. For example, BVA recently voted that a foul-weather event would be interesting, so we will set up something in a future Regional Circuit to give that a try. Other suggestions are not always as practical (for example, suggesting a Regional Circuit that is 400nm long just won't work). The Domestic Journey, which often features longer routes, tends to be the least popular event (the Dj was 14% of members' favorite event| the Rc was 37%). The other complication is the Scenery Design Team: the group needs a few months' lead time in order to prepare the updates we value so highly during events. For that reason, I have a long list of Regional Circuit citypairs I provide Dan and his team with in advance so that they know what's coming. If someone has a suggestion for a citypair, I'll add it to the end of the list. Depending on the time of year, it can take up to a year to actually get to some of the suggestions. All that being said, I'll respond to your specific suggestions... We have featured every one of these airports except HDN, TEX, and CPR previously (sometimes the exact citypairs as well). Class E airports are not possible for Rc events because of the one-in one-out IFR rules (there can only be one IFR aircraft cleared for an instrument approach or with a departure release at a time, meaning everyone else has to wait in holds or elsewhere). Others (like KDEN to KRNO) are too long: Regional Circuit events longer than about 250nm tend not to work very well. I'm not entirely sure why, but events like KLAX/KLAS tend to be exciting only for radar controllers while _Cl and _G controllers are waiting for airplanes en-route. It may seem strange to do shorter Rc events (like last night's), but the more time airplanes spend with TRACON controllers (and the more time they spend moving on and around airports), the more exciting things are for controllers. I'm assuming that most pilots -- like me -- prefer interacting with busy controllers rather than saying "hello" to a Center controller and then waiting 45 minutes before their next instruction. This varies as well...some events are totally one-way (for example, if we do a KBOS-KACK event, most pilots spawn at KBOS and fly to KACK). Others, like last night, tend to be somewhat even. We've tried things like a "tri-city circuit" before where three airports were controlled. What tends to happen is that pilots fly to two of the airports and the third gets no traffic. Or, we see not enough traffic to support all three and, while there's steady traffic throughout the event, nobody is overly busy. We have also tried more major events. You just missed the Washington HTC where we featured KIAD, KCHO, KORF, KPHL, KACY, and KRIC, but we're featuring another HTC in Chicago on February 6 so you can get an idea how those work. Again, we saw that, while we had a fair bit of traffic, it was dispersed enough that, while steady, controllers weren't swamped consistently. That's why we've removed one airport from the list for the next HTC. I would welcome a few pilots flying out of other airports, towered or otherwise, during events. However, you have to remember that when you choose to do that, you lose out on interacting with three controllers waiting at a staffed airport. Again, it comes down to trade-offs. Great suggestions. We've done PHL to ISP, LGA, and HPN before, as well as LGA to ACK/MVY. However, I'll add a few of these to the list. I hope I've given you an idea of how events work and the range of possibilities that have tended to work in the past. That being said, I'm certainly not trying to 'shoot down' any of your ideas. If you have citypairs that are 50-200nm apart that you would like to see, please list them here. Alternatively, if you have other event ideas, please post them. Some may have been tried (successfully or unsuccessfully) but all of our new ideas come from somewhere. Feedback is always appreciated!

My mistake! Thanks for pointing it out -- I've corrected the page.

(Anyone who has already signed up for the HTC, unfortunately there was an issue with the page today| please add your name to the chart again)

It's pretty late to be making changes to the event| there has already been quite a bit of planning that has taken place. Pilot sign-up is open and controller staffing will begin shortly. I would rather not make major changes to the event at this point. Had you posted this before pilot sign-up and advertising had begun, it would have been much easier to make a change. That being said, we have already removed one airport from the list. We did 6 airports (inc. KIAD) for the Washington HTC| we're featuring 5 total airports this time. The concept of 25 pilots inbound and outbound was voted on by the community and approved by our controllers. Again, I'd rather not make that change unless another event proves that we need to make a change. Remember that we've really only held one event and it was not as well-attended as many of us had hoped. Before we start making wholesale changes let's see whether we're seeing a consistent issue or a one-off. I'd be happy to consider your changes if you and others feel that this next HTC is not particularly intense. Hope to see you in Chicago!

Right...well, based on the poll results, we'll have to give a weather-specific event another shot sometime this year.

I've merged the two topics related to a weather-specific event into this one. I was hoping the poll would remain but unfortunately not. However, users can continue to vote in the poll on BVA's homepage (I think the results are already quite similar).

I've never been a fan of creating weather (actually, I don't really know how to do it with FSX...I would use ActiveSky if I wanted to, but that's beside the point). As Brandon has suggested, this type of event creates several logistical issues. For one thing, the server would also have to be reset to real-world weather after the event| you can't change weather conditions without re-starting the server and ejecting all pilots. By the way, ATC does not see weather on radar screens, so there could be no creative vectoring. If the server is set to real-world weather, I'll sometimes use real-world weather imagery and try to vector pilots accordingly, but that's obviously not possible if we've set the weather to something custom. If you can get 10 responses, (not including those here already) that indicate that there's interest in a special-weather event, then we'll do it.

Consider it done.

The majority has spoken...and the SoCal Getaway has been extended through to October 22 (this Friday will be our last day in SoCal this year). I'm locking the topic because it's the only way I can find to actually stop allowing people to respond to the poll without deleting it altogether.

A few people have approached me about extending the SoCal Getaway so they can continue to enjoy the new airspace for a few extra days. Please let us know what you think about extending the getaway...the decision (based on this poll) will be made around 11pm ET. Happy voting!

This sounds exactly like the Domestic Journey but perhaps you were suggesting having the pilots fly two-way routes instead of the one-way trip. The difficulty with longer events is that, without a very large pilot turnout, they are incredibly boring for ATC (and some pilots too). For example, during our LAX/SFO event with about 24 pilots at the peak, all the controllers had very little traffic because most of the airplanes were actually in the air with the two Centers. In general, I have noticed a lower turnout for even the most popular longer-distance Regional Circuit routes. LAX/SFO had two Center controllers.

That's mostly (but not always) possible. For example, at KBOS, depending on the runway configuration, any of the LOGAN4, WYLYY7, or SSOXS1 might be used for someone departing to the south| this isn't something that would be known until the event starts because they vary based on the configuration of the airport. However, in most cases, there's one departure procedure that will be used, and in those cases, I will definitely add the SIDs/STARs to the textual preferred routes.

As a note for those who are unaware, you cannot call the tow plane in FSX's multiplayer mode -- it leads to glitches on the server.

Fixed... sorry, and thanks for letting me know!

I thought we left off that discussion saying you were going to contact Bill to see whether it was feasible. From my perspective, I think it's a good possibility.

Ok, so once again, correct training but incorrect delivery. The correct procedure is to have the aircraft advise clearance delivery when ready to push and subsequently have the aircraft monitor ground. If the "monitor ground" was given right after the correct readback, it was clearly wrong.

True, except many aircraft are not immediately ready to pushback after receiving their verbal clearance (they re-program the FMS, set up the airplane, etc.). When they are actually ready, they contact the clearance delivery controller to pushback (like they would after receipting a PDC) and are instructed to "monitor". Am I missing something?

I'd say don't report, unless you're specifically asked. If a controller says "report over MHT", then do so, but otherwise we're probably watching you on the live map (or maybe you're un-glitched) and it's probably not going to be worthwhile. If some controllers choose to try the 'without radar service procedure' (actually, there are still a few airports around without radar service in some less-developed parts of the world), they'll let you know what to do.

Thank you for listing some of your observations. Last night's event was a bit of an experiment from the controllers' perspective. For the past 2-3 events, we've had a lower turnout than usual (around 20 pilots), and I assumed with the KBOS-KBTV run last night, we'd have the same scenario. As a result, we had a lot of newer controllers online. Boston Clearance and Ground were working together for the first time, BTV_G was a brand new controller, and BTV_A was controlling his first Regional Circuit as Approach (I think). Our very capable ZBW_C had only controlled that position once before (but Center is an event is drastically different than on a regular night, because normally there won't be any aircraft flying to non-staffed fields during events). Even though each of our students was being listened to by a mentor, the pilots came out in full force and may have overwhelmed some of us. My normal rule is that we do not train during events. I thought I could break it, and we weren't going to be too busy. I was wrong. The pilots came out in full force last night, and you guys may have even scared off a few of our controllers (technical issues with a microphone may have contributed to that a little bit as well). That being said, let me answer a few of your specific points, because I believe they are not systemic errors (i.e. problems with the way we train or the procedures we follow) but rather specific examples of deviation from the norm. This is the real-world procedure for KBOS. Because most gates at the airport require aircraft to either pushback onto Taxiway "A" or into a small ramp area, the FAA allows Boston Ground controllers to act as a pseudo-ramp control and actually authorize almost all pushbacks (with the exception of the Delta company ramp, as well as the Signature/North GA/Cargo ramps, which have their own controllers). In order to avoid overwhelming the one Boston Ground controller, the real-world procedure at KBOS is for Clearance Delivery to tell aircraft to "monitor ground .9" when the are ready to pushback. If you listen to LiveATC, you'll hear it| you'll also hear Boston Ground issuing pushback instructions without having been called by the pilot. You can review the KBOS SOP on our Air Traffic Control page if you want to see BVA's official policy. Our controllers are trained to the real-world standard, and that's what SHOULD have happened. You probably fell through the cracks... someone forgot to edit the "Remarks" section of your flight progress strip and ground never got the message to instruct you to push. Actually, when I heard you call ground and ask him why you weren't contacted, I believe I spoke with both Ground and Clearance Delivery to try to figure out what happened. Despite being a "Pilot Tip of the Month" in a recent Logan Informer, several pilots still contact when they should monitor (last night on BTV_T, a few people called me when they should have just been monitoring... that contributed to the chaos that ensured when I had to quickly step up to BTV_A). That's probably why everyone else was calling instead of waiting for Ground to call them for push. As it turns out, they should not have done so. In other words, in this scenario, the correct, real-world procedure was delivered incorrectly by the controllers online last night. By the way, the correct procedure to follow (or at least, what I've heard real pilots do when it's busy) if you are instructed to monitor a frequency but receive no response is to go back to the previous frequency (on COM2 so you can hear if the controller you are monitoring does call you) to check with that previous controller. For example, in your case last night, you would have gone back to BOS_Cl, asked whether Ground knew you were ready to push, and the controllers would have sorted you out. What you did was totally fine as well because, at the time, BOS_G's frequency wasn't too congested. I WISH, I WISH, I WISH we knew what caused the glitching and what we could do to fix it. But I haven't found a solution just yet. It doesn't seem to happen more or less when it's busy, seems to affect some people but not others (and yet not be related to internet), can sometimes be corrected by temporarily pausing a session, but is (almost) always solved when another member leaves the session. In my opinion, what happens in a 'glitch' scenario is that the server stops sending out updates to the glitched aircraft's movement (either because of a bug on the server, or because for some reason the glitched client has stopped sending out this information... my money is on the server, explanation coming below). Thus, the glitched aircraft continues to do exactly what it was doing when these updates stopped. For example, if you are flying on heading 350 and climbing at 2,000' per minute when a glitch starts, you won't turn or change your rate of climb. I've seen people well over 1 million feet. Strangely, it seems some glitches only affect controllers -- other pilots see the aircraft fine while controllers do not -- and sometimes a plane will be glitched for everyone. When the glitch is resolved -- again, normally when a player leaves the session, but sometimes if the glitched player pauses -- the server starts once again sending out updates to the client. They jump back into position on our radar screen and continue as normal after. During a glitch scenario, however, the server never loses the aircraft. Check BVATC Live! -- that map is fed directly from the server, as are FlightDesk's tracking updates if FSX is closed. The tracking updates and live map show the aircraft correctly, but other FSX clients do not. That's why I think it's a server bug that causes the server to stop sending out the glitched pilot's updates, and not an issue on the client side. In other words, the data are getting through to the server, but aren't coming out the other end. Again, if we knew why, we might have a solution. That explains what a glitch IS. Since we can't say what causes it, it's difficult to place the blame on FlightDesk, easy or helpful as that may be. Furthermore, I understand that Bill has carefully designed and re-designed FlightDesk so as to take up very little bandwidth and CPU usage. He describes himself as a performance freak, and every letter of code he writes is influenced by keeping performance impacts minimal. I've seen glitches happen for AGES, starting before BVA even used FlightDesk. If it's any consolation, they seem to happen to a small group of people consistently but then stop and never come back. A few months ago, controllers would tell me that I'm glitched almost every session. I haven't heard it for a little while now. I wish I could tell you what to do when it happens, or how to avoid it. While restarting your router, re-installing FSX (and in fact the entire OS) from time-to-time, and making sure to run FSX in multiplayer mode such that it's not maxing out your CPU are going to help things anyway, there's no evidence to support the theory that you can resolve or stop glitches from happening by doing any of those things. One thing I have noticed is a considerably better connection to the server -- better voice, smaller chance of getting disconnected randomly -- when settings are not maxed out. There are some members that control for long periods of time but are disconnected after only short flights. I wonder if their settings and CPU usage is dramatically different when they are controlling vs. flying. I know I always tune down my visual settings when I'm doing ATC and the scenery/frames don't matter. I also lock my frames at the lowest possible level when controlling. So what is this glitch crap? I wish we knew, and I wish we had a solution. Since we don't, our controllers try to handle it as best we can, but it can be difficult and frustrating to deal with sometimes. Actually, we do have an informal procedure that controllers should use. In my case, I'll look at the BVATC Live! map right away. Since glitches never manifest themselves there, you can get basic information about the pilot's heading and altitude. Of course, it's impossible to vector someone for an approach using the map, but it's very possible to keep that aircraft separated from others using it. Normally, glitches resolve themselves before I need to start vectoring for an approach, but when they don't, I'll use the live map to maintain separation while I vector someone for delay, or even put them into a holding pattern (like I did to UAL340 last night, the only glitch I saw during the entire Rc). In the case of ZBW, perhaps he was looking at you on BVATC Live! or in FlightDesk, and thus didn't need the position reports. Perhaps BOS_A was not looking at those tools, or just preferred to have you report a waypoint because he was less busy. In every case, controllers hate the fact that glitches happen. Imagine looking at a radar target thinking you have plenty of time to turn/descend someone and then the aircraft suddenly jumps 40 miles and 8000'. Or to issue someone a climb but see them descending 5,000' below the ground. It's difficult to handle. It's worse when you have a no-radar scenario with an aircraft you need to vector to final. Recognizing that glitches are as confusing and frustrating for pilots as controllers, we try to avoid mentioning them as much as possible, and do our best to work with the pilots and provide them the ATC services they need without interruption. Nobody wants to be stuck on the ground holding short of a runway in FS because controllers can't see where they are. Sometimes, if you un-glitch right when you change to a new frequency (or if the previous controller is too busy to alert the next of a potential glitch), we won't remember or know to tell you that you are back on the screen. Normally I will "radar contact" someone a second time if they were previously glitched, but it's the last thing on our minds when it's busy. Normally, we're just thrilled we can see where you are again. The controller on BTV_A last night was (I think) controlling Approach for (one of the) first times during an event. I was going to try to listen in and help, but, as I said, I wasn't expecting him to be as busy as he was. Between the terrain restrictions, a small sector, and the traffic, BTV_A was a difficult position for anyone (even me, as I quickly found out when I had to take over roughly halfway through the event). For some reason -- I'm assuming a technical problem -- our BTV_A was unable to respond to pilots, and I had to take over and clean up the resulting mess. I ask you to give Josh (BWIA) the benefit of the doubt that there was something he couldn't deal with, and support his attempts to continue to control in the future. I will be working with him at the next chance I get to figure out what went wrong, and how we can prevent it in the future. I hope that helps, and thank you again for your comments. In most cases, I think we're dealing here with deviations from the standard rather than standardized deviations from what you might expect, perhaps excepting the glitch scenario, which isn't something you can deal with realistically at all. If you (or anyone else) has suggestions or comments as to how we can improve the standard procedures we follow, I would be glad to discuss them with you. Without the experience of actually controlling, and understanding how frustrating it is when glitch scenarios occur, it's difficult to understand the operational restrictions on some ideas... which is why discussing them with a base of controllers that experience that almost daily is an important step to finding a solution. Thanks again for flying -- and discussing -- last night's event. We'll be going down to Florida for KMCO & KMIA on Tuesday. I'll do my best to staff it with a more experienced crew... you (pilots) see if you can overwhelm us again!

I know that one of BVA's members (RangerTJSC, the President of Cape Air Virtual) went on a tour of the facility and spoke with a few of the real-world Cape Air's executives. They seemed excited about our VA version of Cape Air and, from what I understand, were very accommodating.

That's a very cool idea... I'd be (tentatively) interested.

When it has been requested before, I have requested that the people who are most interested in making the event happen become part of its administration. I don't know enough about Oshkosh, and am busy enough with other events. Is someone willing to take ownership of such an event? If so, I'll be more than happy to help with the PR, ATC staffing, etc.

... the .exe file will be available from the normal locations (Event Scenery and Regional Circuit Details pages) before the event on Tuesday. Thanks for your hard work Devon!

Per this request, our featured Texas Getaway will include KDFW & KIAH next week (Tuesday, June 1). Hope to see lots of traffic there... it's a long flight, so we'll need as many people as we can get to make it worthwhile!