Some observations on KBTV-KBOS RC

[Guest Yun Chase]

Overall, the event was great just as all other BVA events are... so don't get the wrong idea about this feedback... I just wanted to list out some mental notes that I made during my single run from KBOS to KBTV.

 

1) BOS_Clearance advised to "Monitor" BOS_GND after having given my push back clearance. However, once switching/monitoring... no GND controller contacted me but rather all of the other guys behind me made initial contact with GND and were given taxi instructions completely skipping over, yours truly, who were trying to follow the "Monitoring" instructions that were given to me by Clearance... We may all need to be on the same page... Do we "monitor" or "contact" GND? |)

 

2) I was glitched as I was climbing through about 1500' on initial climb out of KBOS... What causes this glitch crap? I've been on BVA since March and never had this problem until FD 1.1 release date (coincidence probably)... I did try to close out FD 1.1 but didn't help. Fortunately though, I was unglitched as I was being vectored for the ILS33 Approach... which I will get into in #3A/B below...

 

3A) If I am glitched and if the ATC decides to let me continue the flight while glitched, then sort of an informal or perhaps a formal "Glitched Procedure" might be nice to have for both ATC/Pilots. BOS_Dep clearly advised me to make a position report over MHT as he handed me off to BOS_Center. Once switched over, I made position reports over the following VORs: MHT, CON, and LEB. However, the BOS_Center himself did not explicitly request for that. Now I don't know what his intentions were but I made those position reports purely out of courtesy to perhaps help him out... but on couple of those occasions, it almost sounded as if those reports were of annoyance for the guy but I kept making them hoping to be helpful... Now, I don't know if I read him wrong or not but he clearly didn't sound too happy about the glitch... In situations like this, would it make sense to have a "Glitched Flight Procedure" in place? Like what real pilots have as in "Lost Comm" procedure???

 

3B) The story continues... as I was approaching KBTV airspace, apparently I became un-glitched as I was being vectored around... I was completely unaware of that since the BTV_App did not mention that I was unglitched (I had to ask him)... In a single pilot IFR situation, lots of stuff happens in the cockpit as being vectored around for the ILS approach... My state of mind last night as I was being vectored around is: 50% on instruments and the other 50% on being aware of where I am at, so that I can possibly advise the Approach of my position if he were to ask me where I was... that's 50% of my mind I am taking away from the instruments as I'm setting up for the approach... Well, it turned out that I blew past the localizer as soon as he gave me the intercept heading and by then I was too high, fast and needed extreme maneuvering... but managed to get the plane down for landing anyways... I actually called for the "Missed Approach" but the controller responded by giving me a new heading to intercept and so I proceeded to join the Loc for the approach... Besides, I had to go watch my Boston Celtics in Game 6, which they lost the game anyways... :x

 

Well once again, I want to reiterate that BVA events are extremely fun for me... no matter what some of these isolated incidences bring. :D I thought I would take a moment to jot some notes down for anyone who might be interested in improving our immersive experience! :D

 

Safe Flying boys!

Chase

[Evan Reiter]

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.

 

1) BOS_Clearance advised to "Monitor" BOS_GND after having given my push back clearance. However, once switching/monitoring... no GND controller contacted me but rather all of the other guys behind me made initial contact with GND and were given taxi instructions completely skipping over, yours truly, who were trying to follow the "Monitoring" instructions that were given to me by Clearance... We may all need to be on the same page... Do we "monitor" or "contact" GND? |)

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.

 

2) I was glitched as I was climbing through about 1500' on initial climb out of KBOS... What causes this glitch crap? I've been on BVA since March and never had this problem until FD 1.1 release date (coincidence probably)... I did try to close out FD 1.1 but didn't help. Fortunately though, I was unglitched as I was being vectored for the ILS33 Approach... which I will get into in #3A/B below...

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.

 

3A) If I am glitched and if the ATC decides to let me continue the flight while glitched, then sort of an informal or perhaps a formal "Glitched Procedure" might be nice to have for both ATC/Pilots. BOS_Dep clearly advised me to make a position report over MHT as he handed me off to BOS_Center. Once switched over, I made position reports over the following VORs: MHT, CON, and LEB. However, the BOS_Center himself did not explicitly request for that. Now I don't know what his intentions were but I made those position reports purely out of courtesy to perhaps help him out... but on couple of those occasions, it almost sounded as if those reports were of annoyance for the guy but I kept making them hoping to be helpful... Now, I don't know if I read him wrong or not but he clearly didn't sound too happy about the glitch... In situations like this, would it make sense to have a "Glitched Flight Procedure" in place? Like what real pilots have as in "Lost Comm" procedure???

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.

 

3B) The story continues... as I was approaching KBTV airspace, apparently I became un-glitched as I was being vectored around... I was completely unaware of that since the BTV_App did not mention that I was unglitched (I had to ask him)... In a single pilot IFR situation, lots of stuff happens in the cockpit as being vectored around for the ILS approach... My state of mind last night as I was being vectored around is: 50% on instruments and the other 50% on being aware of where I am at, so that I can possibly advise the Approach of my position if he were to ask me where I was... that's 50% of my mind I am taking away from the instruments as I'm setting up for the approach... Well, it turned out that I blew past the localizer as soon as he gave me the intercept heading and by then I was too high, fast and needed extreme maneuvering... but managed to get the plane down for landing anyways... I actually called for the "Missed Approach" but the controller responded by giving me a new heading to intercept and so I proceeded to join the Loc for the approach... Besides, I had to go watch my Boston Celtics in Game 6, which they lost the game anyways... :x

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.

 

Well once again, I want to reiterate that BVA events are extremely fun for me... no matter what some of these isolated incidences bring. :D I thought I would take a moment to jot some notes down for anyone who might be interested in improving our immersive experience! :D

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!

[Guest Yun Chase]

Hi Evan,

 

Thank you so much for your detailed reply. I learned something here... but very importantly, I am not complaining about any of the controllers at all. Not one bit, no sir. I have the utmost respect for each and every one of you guys for taking the time to learn this job and to participate as a controller for all of our enjoyment. So for Josh and everyone else who are working the radars, towers, grounds and clearances, my hats off to you all! :) And the day you guys all quit is the day that I will be forced to quit, flying on BVA... reluctantly... :cry:

 

In any case, I learned that I might have screwed up when I pushed without permission from Ground...

 

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....

 

... this is good to know and I'll keep this in mind next time. I might have been in a hurry to launch since I was trying to get back to the Celtics basketball game. :lol: But Thanks for this info.

 

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.

 

... another good info. Thanks for this.

 

Actually, we do have an informal procedure that controllers should use. In my case, I'll look at the BVATC Live! map right away....

 

My only request I have about the procedure is... do I report or not report? Do I just shut up and fly or help him out? That's all. Another thought on the procedure is... many many many years ago... people used to fly without Radar service even in the early days of ATC... they made position reports and ATC kept track of them using little boats on a enroute chart... I'm not asking for that kind of service but perhaps we can formalize a few ops procedures for both ATC and pilots in case of glitches... something like, pilots should report over all compulsory and non-compulsory reporting points on enroute chart when glitched... state heading, Alt, and approx time to next reporting point... otherwise, just tell us to shut up and just fly! And I'm happy with that too! :lol:

 

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.

 

Again, I have the utmost respect for all of you guys. I am NOT complaining here at all.... but rather giving some of my own thoughts in hopes of helping them progress through the ranks as the premier controllers on BVATC. :)

 

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!

 

And thank you again for your detailed reply. Please use any level of staff that you see appropriate. Even in real flying, I've had a newbie TWR controller giving me the wrong Runway numbers for a landing clearance on short final... (back in Syracuse where I got my Private ticket) things do happen and we all learn. That's the number one benefit that I get out of flying on BVATC... the fact that I get to learn for free! (or a small donation, which I will make another one soon) :) Learning from BVATC has been tremendous for me and I could not have this experience without you, Josh and other members of your fine staff. Thank you, thank you and THANK YOU! :D

[Evan Reiter]

My only request I have about the procedure is... do I report or not report? Do I just shut up and fly or help him out? That's all. Another thought on the procedure is... many many many years ago... people used to fly without Radar service even in the early days of ATC... they made position reports and ATC kept track of them using little boats on a enroute chart... I'm not asking for that kind of service but perhaps we can formalize a few ops procedures for both ATC and pilots in case of glitches... something like, pilots should report over all compulsory and non-compulsory reporting points on enroute chart when glitched... state heading, Alt, and approx time to next reporting point... otherwise, just tell us to shut up and just fly! And I'm happy with that too! :lol:

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.

[Guest Robert Williams]

Regarding monitoring ground, really we shouldn't be doing that here, because all the clearances are given verbally. In the real world the airliners get them electronically (PDC) and contact clearance when they're ready to taxi or pushback. Otherwise if they have to request a clearance verbally, it's usually 15-20 minutes or so before they're actually ready. Ground can't know when they're ready to go, so they need to be contacted first.

 

The longer term option might be to implement PDC's in Flight Desk, although the clearance position really wouldn't have much to do except press buttons.

[Evan Reiter]

Regarding monitoring ground, really we shouldn't be doing that here, because all the clearances are given verbally. In the real world the airliners get them electronically (PDC) and contact clearance when they're ready to taxi or pushback. Otherwise if they have to request a clearance verbally, it's usually 15-20 minutes or so before they're actually ready. Ground can't know when they're ready to go, so they need to be contacted first.

 

The longer term option might be to implement PDC's in Flight Desk, although the clearance position really wouldn't have much to do except press buttons.

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?

[Guest Robert Williams]

That's correct in real life, but what happened here (and happened to me too in this event) was I received my clearance verbally, then was told to "monitor ground" even though I was not ready to pushback. I had to call him first because there was no way for him to know when I was ready. If aircraft get their clearances verbally then they should be told to contact ground when ready to push/taxi. If they get them automatically then they'll call when they're ready.

[Evan Reiter]

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.

[Guest Robert Williams]

RIght, that would work if it's busy. If it's not all that busy (maybe less than 10 aircraft on freq) they could probably just have them contact ground when ready, which would save a bunch of "roger, contact ground" transmissions.

 

And for the record, I thought the controllers at the event did a nice job, especially the ones training. I sent feedback on that already, I believe. I admit was sort of tough with the one guy at BTV approach but only because they play games like that in real life. If you restrict somebody (I was vectored through the localizer and vectored perpendicular about 10 miles the other way, without explanation), and you also show hesitation on frequency, pilots will pounce on you with "where's the traffic" or "what's this vector for," or suggest alternatives to "help." Trainees need to learn to sound confident like they know exactly what they're doing, even if they don't, to keep control of the freq.

[Domenic Ruscitti]

Thats great advise Bob And I have to admit when ever I see you comin I get just a touch of nervousness. Hopefully it doesn't show up too often in my voice. :)

[Guest Kevin Wojtanek]

Hey Evan I was wondering if the PDC function thru flightdesk we were talking about a few months ago is still a possibility?

[Evan Reiter]

Hey Evan I was wondering if the PDC function thru flightdesk we were talking about a few months ago is still a possibility?

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.

[Guest Kevin Wojtanek]

If I'm remembering correctly I sent him an email and never heard anything back, so he probably didn't get it. And I wasn't sure if you had talked with him about it and you guys were working out the details. But now I'll put the idea in the FD Development Forum forum and see what he says.