VATUSA Forums
General => The Control Room Floor => Topic started by: Shane VanHoven on March 16, 2018, 10:14:04 PM
-
Sorry to everyone that flew to the FNO at MSP tonight who had to fly a 30 mile downwind, followed by a 5 mile base and a 30 mile final, only to be sent around because the guy departing on the runway didn't roll in a timely manner.
But nevermind that, I want to talk about how to meter airplanes on the network and start a discussion about how some other facilities manage volume during events. We spent most of tonight with the final out to 30-35, sometimes 40 miles, just barely keeping it all within the TRACON. The final spacing was about as consistent as what they hit at the real building, so at a glance, it seems clear that we stumbled along with more traffic per hour than they see IRL.
Every airport has an Airport Arrival Rate they can handle per hour, and it's always changing depending on weather. How does a facility on the network meter arrivals so that we never surpass, say, 80-85% of the real AAR (Less than 100% to account for voice latency issues, disruptive pilots, and and controller inconsistencies)?
We all know that there isn't any particular program design specifically for metering arrivals, so we have to improvise. I'd love to hear everyone's methods and opinions.
-
I just do holds. Lots of holds. Pilots complain about the wait? They shouldn’t, especially since realism is something pilots (and controllers) are always hoping to achieve. I’d say it’s pretty realistic to fly into a big airport on a Friday night and have massive delays for traffic flow.
-
Also just thought of another topic, what do you do for OTHER facilities' FNOs? When the ARTCC adjacent, a even the 2nd or 3rd tier, how do you help a controller 500, 700, or 1500 miles away?
-
Also just thought of another topic, what do you do for OTHER facilities' FNOs? When the ARTCC adjacent, a even the 2nd or 3rd tier, how do you help a controller 500, 700, or 1500 miles away?
Today I attempted to get our cab controllers to give an alternate routing, however they didn't follow it. Ideally, it would have alternating routes on departure, but we made it work. Usually it's speeds and turns/holds, or if you have friendly neighbors, who can help take some of the stuff if you can't get screwed.
-
I just do holds. Lots of holds. Pilots complain about the wait? They shouldn’t, especially since realism is something pilots (and controllers) are always hoping to achieve. I’d say it’s pretty realistic to fly into a big airport on a Friday night and have massive delays for traffic flow.
Holds are a short-term solution though. You're just placing an extra burden on your enroute controllers if you don't also implement flow control at origin airports too. At ZLA we do call for release going to the main featured airports for intra-ZLA traffic. It works quite well, and you don't have enroute suddenly trying to merge traffic coming out of L30 in with the ANJLL flow, which is easily our busiest arrival into LAX during events.
Also just thought of another topic, what do you do for OTHER facilities' FNOs? When the ARTCC adjacent, a even the 2nd or 3rd tier, how do you help a controller 500, 700, or 1500 miles away?
15 MIT, compatible speeds if it's a neighbor unless they want something else. At the ZOA FNO earlier last year when they were down to one runway for landing at SFO due to storms we had call for release for anything going to SFO outside of LAX. At LAX we were launching departures every 3-4 minutes. All of our tier 2/3s at ZLA are pretty far away so we generally don't have so much traffic going to event airports that we need to implement some sort of metering.
Today I attempted to get our cab controllers to give an alternate routing, however they didn't follow it. Ideally, it would have alternating routes on departure, but we made it work. Usually it's speeds and turns/holds, or if you have friendly neighbors, who can help take some of the stuff if you can't get screwed.
Letting your neighbors sort it out is highly dependent on how much space you have between your boundary and their arrival airport. In ZLA if ZLC/ZDV are handing me ties where the ANJLL merges (which isn't their fault - it's hard to see those things coming so far away, at least on VATSIM) I have 300 miles to sort it out and get a good stream going into SCT. If the KKILR is busy (which it always is during events, everyone loves the ORD-MSP flow) I have about 100 miles between the ZMP-ZAU boundary and the ZMP-M98 boundary to sort it out if things aren't spaced out well. If my neighbor isn't doing their job then I'm probably in for a rough time.
-
This is a useful resource (https://www.fly.faa.gov/ois/) for getting an idea how many arrivals an airport can handle per hour based of a certain configuration.
Here's San Francisco's for instance:
(https://i.imgur.com/jPEvkCX.png)
As you can see, our arrival rate drops by over half if we went up using a single runway in IMC (as we did during an FNO last year).
-
When I’m working a tier 2/3 center for an event, I put tons of space between aircraft bound for the event field 25+ MIT if I can do it.
That way tier one has plenty of holes to fit in their originators and hopefully allows for a bit of extra space to allow for voice lag, slow pilots, and the fact that many of our controllers are not real world professionals.
This happens so far out that most pilots don’t even realize they’re being metered or delayed.
The biggest problem with trying to meter VATSIM pilots is the disconnect button. If they don’t like the idea that they’re gonna have to sit on the ground for a half hour to fly from ORD-MSP, they’ll just disconnect and reconnect airborne. And that causes worse problems than had tower just let them go on a penalty vector where we then know he’s coming.
-
Sometimes what we do in New York is Call-for-Release (CFR). If I’m the TMU for the event, I’ll usually be asking ZBW—or at the very least, BOS—for CFR for all flights coming to the designated airport. That way, I can look for appropriate gaps in enroute/arrival flow to fit in aircraft. Downstream centers can do this too; for instance, often times we get a heavy arrival stream from ATL at some point during the event. ZTL is a tier 2 center and admittedly, we have very little infrastructure to communicate with them so we ask ZDC to have them either provide MIT, reroutes, or ideally, CFR to either our TRACON, Center, or just between them (ZTL to ZDC).
Additionally, we have implemented CFR for ZOB and CZY, where Toronto traffic is heavy.
CFR is pretty much as close as we can get to using all available arrival capacity efficiently without creating excessive delay through ground stops and holding. All that has to happen is the tower calls either an enroute controller or the TMU requesting CFR and asks for a release time. They have 2 minutes before the time and 1 minute after the time to release that aircraft or else they will have to ask for another time.
Alternatively, if you know the demand before an event (like through signups where you have a flight list), you can construct a ground delay program to schedule aircraft. This is the most effective method of controlling your arrival rate because it restricts it to a certain number. You break each hour into segments and schedule aircraft to each block leaving a certain number of slots empty to account for unscheduled traffic (pop ups). Unfortunately, while often being the most effective method of controlling your arrival rate, it is the most time consuming and relies on a high level of controller-controller and controller-pilot cooperation and rarely ever suits events in VATSIM due to the lack of that cooperation.
Finally, for short term periods of excess demand, a ground stop is usually sufficient. The scope is important here and must be determined before implementing the GS. If there is excess demand for MSP and much of the future traffic isn’t airborne yet and originated from ORD, MDW, and MCI, then a tier 1 ground stop would suffice. If you have a heavy arrival stream from DEN and there are 28 more departures not yet airborne, bound to MSP, then a single-airport (for DEN) is all that’s needed and anything more than that would generate excess delay. If there is excess demand from many ARTCCs, all scheduled into MSP and not yet airborne, then an ALL+Canada GS might be most effective.
Oh, and for reference, there have been times where 40 MIT for ZTL to ZDC wasn’t even enough for spacing LGA arrivals and we had to seek other solutions. One thing we did was implement a mandatory reroute from the FAA Playbook that swapped the arrivals to come through ZOB and this alleviated congestion some. ZDC also did a great job in creating space for us while that was happening. If I remember correctly, BOS didn’t have a whole lot of traffic coming in so nothing was necessary with them, though if it were a problem, I would’ve had them on CFR.
-
We like to use expectation management also. When we have a pilot or VA-organized event, we ask the coordinators to ensure pilots know that delays may be expected depending on traffic and weather conditions. We’re going to do our best, but you can only fit so many planes on a single route. Getting that relayed to the pilots helps clear up issues before they start.
To address pilots who disconnect and then pop up in the air: they’re going to get vectored out of the way. Sequencing a disconnect/pop-up aircraft into a existing stream in front of aircraft that waited their turn is providing a form of priority.
-
To address pilots who disconnect and then pop up in the air: they’re going to get vectored out of the way. Sequencing a disconnect/pop-up aircraft into a existing stream in front of aircraft that waited their turn is providing a form of priority.
Excellent answer. "Proceed direct Outtadaway VOR, advise when ready to copy holding instructions...."
-
Today I attempted to get our cab controllers to give an alternate routing, however they didn't follow it. Ideally, it would have alternating routes on departure, but we made it work.
This is where you need to start prodding your cab guys to do some work. By just accepting it as is, you aren't helping yourself. Alternatively, you issue the reroute in the air.
or if you have friendly neighbors, who can help take some of the stuff if you can't get screwed.
Any time!
-
Just going to add this in as this should pretty much be common knowledge for all of us.
This is where sequencing at the Ground/LCL lvel comes in. If given the MIT via TMU from adjacent sectors, the LCL controller, especially the Ground controller can create that MIT by sequencing flights not going to the sector hosting the FNO between those that do. if that can't be done at the GND level in time, intersection departures would create that as well. For example, if SFO hosts the FNO, and I have 6 flights that are heading up that way, instead of holding up the entire conga line, I'll pull a LAS or SLC-bound aircraft(s) out of the line, TIPH them at an intersection, launch them, then get the next SFO-bound aircraft out. That artificially creates that MIT, without having to manage it by airspeed further along the higher positions. That's one way to properly get that MIT spacing at least from 1 - 3 different airports.
Another suggestion: Could TMU be used for Call-for-Release procedures? I'm not talking in getting the release from the TRACON, but in particular for the featured airport for FNO, could the local controller not only get the release from the TRACON (for the TRACON's airspace), but for the release for the aircraft going to the FNO airport and get the window for their departure? Sorta like combining metering with calling up for oceanic clearance, and getting the expected window for when they should reach the sector in question.
I'm trying to brush up again on all of the call-for-release procedures, so my memory is a bit rusty there.
BL.
-
Another suggestion: Could TMU be used for Call-for-Release procedures? I'm not talking in getting the release from the TRACON, but in particular for the featured airport for FNO, could the local controller not only get the release from the TRACON (for the TRACON's airspace), but for the release for the aircraft going to the FNO airport and get the window for their departure? Sorta like combining metering with calling up for oceanic clearance, and getting the expected window for when they should reach the sector in question.
This is usually how we do it for ZNY. Either the EC or dedicated TMU will make sure the appropriate lines of communication are open for release time coordination. For example, during the Eastbound CTP, I was working with the ZBW TMU to coordinate releases that weren't initially scheduled through the official booking channels. ZBW had heavy enroute volume and departures from EWR or PHL bound to Europe were on CFR. EWR Tower would relay me flight info they were requesting to release and I would call ZBW TMU and ask them for a specific wheels-up time. EWR Tower would be responsible for getting that flight of the ground within 2 minutes prior to 1 minute after that time or a new release would have to be coordinated.
In the real world, CFR isn't always involving the ARTCC (or for N90, the TRACON) TMU; sometimes the tower only has to pick up the phone (unless they have a shout line or something) to the TRACON or ARTCC controller above them and request a specific release. However, other times TMU or specific TMU personnel are aware of the CFR procedures being in effect and participate in coordinating the releases so that controllers can focus on more immediate things.
-
Different winds & temps aloft. Simulator stutters and hiccups. XPlane running at a reduced rate without the pilots realizing it. There are a number of reasons why strategic metering doesn't work very effectively.
If we were to give metering a real try, I think VATUSA has to own it and do it week in & week out. We have no fancy software and the number of variables we deal with exceed those in the real world. Its going to take trial and error to build some proficiency. It's also going to require some people sitting out of the fun of actual controlling.
Having each ARTCC attempt to do it 3-4 times a year isn't going to cut it, in my opinion. I doubt anyone is going to volunteer to be the TMU for every event.
-
Different winds & temps aloft. Simulator stutters and hiccups. XPlane running at a reduced rate without the pilots realizing it. There are a number of reasons why strategic metering doesn't work very effectively.
Which is why you'd have to shoot for 20-30% less than what the airport could handle at max capacity.
I doubt anyone is going to volunteer to be the TMU for every event.
You'd be surprised.
-
Separation starts from the ground up. I've been seeing a lot of facilities lately (more than when I first join the network) put a dedicated C1 on TMU which is great. FNOs are tough because traffic comes from all different directions but I have seen facilities coordinate with other tower controllers in the adjacent ARTCC or even two ARTCCs over to slow guys down off the RY. In my opinion, that's where it needs to start so the centers and tracons don't get saturated. I agree with Dan Everman, holds should be a temporary 20 min fix, we shouldn't have 10 a/c stacked up waiting to descend! :D
-
... I think VATUSA has to own it and do it week in & week out. We have no fancy software and the number of variables we deal with exceed those in the real world. Its going to take trial and error to build some proficiency. It's also going to require some people sitting out of the fun of actual controlling.
Having each ARTCC attempt to do it 3-4 times a year isn't going to cut it, in my opinion. I doubt anyone is going to volunteer to be the TMU for every event.
I think it depends on the size and activity of the facility. As Jeremy has pointed out previously - we at ZNY already do this on our own. We talk to our neighbors and have found a good working relationship that in most cases work very well. You don't need to get VATUSA involved - just talk to your neighbors and create an agreement on how you want to deal with the issue.
Yeah, it's not going to solve the aircraft flying cross country from LAX to JFK for a JFK FNO, but those we can plan for, it's the short pop-up flights that typically cause an issue and those your neighbors can deal with.
-
It's important to remember that TMU is a process, not just a function. It takes planning, familiarity of airspace, open lines of communication, and collaboration. I remember for the PHL FNO a few months back, I was TMU for that event, I made sure to be cognizant of what could go wrong before it actually hit us.
The constraining factors for this event were staffing levels and high anticipated volume. I anticipated two possible scenarios and proposed workarounds to their constraints. Here's the first possible scenario:
(https://image.prntscr.com/image/sAC3ASrzQseEB1LXu6uM4A.png)
This scenario features heavy ZBW flow on J121 in combination with high DC Metro (PCT) volume. The solutions were pretty straightforward: (1) BOS ground stop for 1 hour and then a PCT ground stop about 15 minutes after, to end at the same time as the BOS one to stabilize demand; or (2) extensive MIT with ZNY, ZDC, and ZBW.
This is the 2nd scenario and it actually came to fruition:
(https://image.prntscr.com/image/MetdnCz1Q6e0JytQItKgjg.png)
Here, we have heavy ATL volume with little room to accommodate flows from ZOB or ZNY66 (flights from/through ZBW). Unfortunately, there is little coordination we do with ZTL (a major pitfall for ZNY since there's so much traffic between the 2 ARTCCs) so we would have to heavily rely on ZDC. The best possible action would have been an ATL ground stop for no more than an hour to clear the airspace and reaccommodate capacity to allow for that flow. Once it was released, we would implement MIT for ZDC overflights landing PHL (i.e., the ATL departures). Option 2 was to stop DC Metro departures and place ZBW on CFR with ZNY_TMU in order to optimize the arrival streams. The last option was to reroute aircraft through ZOB (which we ended up doing) to help out ZDC with the MIT. This required coordination with ZDC, ZTL, ZID, ZOB, and ZNY and was the least desirable option; we only used it because we were unable to get ATL to give us the ~40 MIT we needed to accommodate other arrival streams in time.
-
This is a great discussion.
I've seen TMU work well on multiple occasions here out west, and the only thing I'd like to add to that is a small wishlist.
1) As Nick said earlier in the thread, pilot outreach. It would be great to work with the organizations offering pilot ratings on the network information and education on how a virtual TMU might function during a high traffic even. During CalScream we use slots, and Cross the Pond does something similar, slot wise. It would behoove us to make prominent the concept of traffic management as an increase in realism and a net benefit to pilots.
2) The FAA uses software that puts all aircraft inbound to an airport (or an airspace) on a cool timeline that makes it easier on TMU and lets those controllers see immediately where aircraft are bunching up. It would be cool to have some sort of VATSIM approximation of this for events.
-
2) The FAA uses software that puts all aircraft inbound to an airport (or an airspace) on a cool timeline that makes it easier on TMU and lets those controllers see immediately where aircraft are bunching up. It would be cool to have some sort of VATSIM approximation of this for events.
Something along these lines are in the works. But I agree pilot education on this topic is a must, because TMIs only work with cooperation from the pilots.
-
2) The FAA uses software that puts all aircraft inbound to an airport (or an airspace) on a cool timeline that makes it easier on TMU and lets those controllers see immediately where aircraft are bunching up. It would be cool to have some sort of VATSIM approximation of this for events.
I've attempted this, but with such an unknown when it comes to wind aloft and who uses what, where does it change, etc. it was completely unreliable, so I scraped it.
-
2) The FAA uses software that puts all aircraft inbound to an airport (or an airspace) on a cool timeline that makes it easier on TMU and lets those controllers see immediately where aircraft are bunching up. It would be cool to have some sort of VATSIM approximation of this for events.
I've attempted this, but with such an unknown when it comes to wind aloft and who uses what, where does it change, etc. it was completely unreliable, so I scraped it.
True, there are a lot of variables with sims and weather, not to mention I doubt most pilots (and I'm guilty of this myself) file accurate true airspeed. I wonder how far off the accuracy would be, though, if we made basic assumptions about winds aloft and built in some sort of padding. As shane said, accounting for roughly 80% of the airport's actual capacity.
That, and just knowing the limitations of such a tool could just make it easier to visualize.
Forgive my ignorance on the subject, but what are some actionable steps we can take to start educating pilots on the network? Is VATSIM currently reworking training programs or is it still a hodgepodge of 3rd parties with the ability to assign pilot ratings?
-
Forgive my ignorance on the subject, but what are some actionable steps we can take to start educating pilots on the network? Is VATSIM currently reworking training programs or is it still a hodgepodge of 3rd parties with the ability to assign pilot ratings?
It is essentially that, yes, although a rather pessimistic way of looking at it in my opinion. But that's a discussion for another day.
What sort of pilot education are you and Shane suggesting is needed? Over and above what we already do -- such as helping people understand how to follow ATC instructions, how to fly holds, how to control their airplane when asked to divert from the programmed route, etcetera -- what exactly are pilots lacking in understanding that the Pilot Training organizations can help with?
The biggest limitation that the Pilot ATO program faces is not the decentralized aspect of it. It's the fact that none of it is mandatory in any way, shape, or form. Only 350 VATSIM pilots **worldwide** on the network hold the P4 rating. Anything we do to further pilot education about IFR traffic metering is going to be a drop in the bucket until that changes.
-
Forgive my ignorance on the subject, but what are some actionable steps we can take to start educating pilots on the network? Is VATSIM currently reworking training programs or is it still a hodgepodge of 3rd parties with the ability to assign pilot ratings?
what exactly are pilots lacking in understanding that the Pilot Training organizations can help with?
Although this has never seemed to be a big deal with the network (and a little off subject), preflight planning is fairly important. I'm not talking about clicking a few buttons and having simBrief spit out whatever fuel load either, I am talking about know what you're planning in simbrief/ PFPX and the decision making that goes into preflight planning.
In my experience when we are hosting a major event and inevitably get jammed up, we go to holds and start getting people worried about fuel. If you're flying into a major event, it's best to plan some hold fuel and maybe some contingency fuel for possible reroutes/ excessive vectoring etc. It seems like the majority go to simbrief or fire up PFPX and just plan the flight straight and have no idea what they planned. The reality is they're taking the bare minimum into a very fluid and busy event.
I'd be willing to help out if you needed it and I know there are a few other dispatchers on here as well that may or may not be interested in giving some pointers.
But getting back on subject, we came up with a faux sort of GDP thing with ZLA. We haven't used it in a full scale event, but in the few tests we did it seemed like it may work. Basically, since we can't give an EDCT and expect the pilots to know what to do with it, we control the delay on the ground via gate holds.
Once a clearance is issued we instruct all flights to call for push back, then the ground controller can meter the outbound taxiing aircraft. Either they get to push and taxi, or they are told they have to wait and are put into the queue. It gets a little facility specific at this point because we are limited on how many aircraft we can have waiting at our runways, but basically the ground controller will send the aircraft waiting the longest once they are able to based on various factors.
When they get to the runway we use time to create MIT when we have successive departures to the same airport that has a high arrival demand. It's fairly involved, but it was something worth trying.
-
The biggest limitation that the Pilot ATO program faces is not the decentralized aspect of it. It's the fact that none of it is mandatory in any way, shape, or form. Only 350 VATSIM pilots **worldwide** on the network hold the P4 rating. Anything we do to further pilot education about IFR traffic metering is going to be a drop in the bucket until that changes.
Totally agree. Forgive my pessimism, what I was driving at was more along the lines of "what does a new pilot on the network get as far as training, and what sort of outreach does the network do to existing pilots?"
Forgive my ignorance on the subject, but what are some actionable steps we can take to start educating pilots on the network? Is VATSIM currently reworking training programs or is it still a hodgepodge of 3rd parties with the ability to assign pilot ratings?
what exactly are pilots lacking in understanding that the Pilot Training organizations can help with?
Although this has never seemed to be a big deal with the network (and a little off subject), preflight planning is fairly important. I'm not talking about clicking a few buttons and having simBrief spit out whatever fuel load either, I am talking about know what you're planning in simbrief/ PFPX and the decision making that goes into preflight planning.
When they get to the runway we use time to create MIT when we have successive departures to the same airport that has a high arrival demand. It's fairly involved, but it was something worth trying.
I've seen the gate holds work at ZLA pretty well. Next event I plan to monitor the ground controllers a little more closely to see what sort of pilot friction (if any) there is. I know we got one or two negative feedback reports recently, but I suspect it was more about traffic over saturation for a single controller. We should work on formalizing some of these programs.
As for flight planning, I agree there, too. Not just fuel, but also what a good route looks like. Robert and I discussed it a bit during a VATSAR event we had at ZLA on Sunday.
-
This has always been something I wish most ARTCC's managed better was TMU. You see it over and over again traffic levels far outpace the controller capacity, network capacity (voice), airport capacity, etc...
A lot of people aren't mentioning this, what about staffing levels the event ARTCC has? If an ARTCC can only staff one guy on finals for a position that can fit 3 final controllers, what is his limit? I personally feel anytime you get more then 10 pilots on your frequency for a very busy sector (vectoring, finals, arrivals, etc..) due to voice and network limitations you can quickly lose control over sequencing. The pilots are NOT professional pilots and thus add to more radio calls being necessary also.
Many times when working ZTL (non events) I and a few other controllers would simulate re-routes due to weather in the ATL area. You would be surprised on how many pilots participated and LOVED the fact we were simulating that! We occasionally would get the pilot who did not want to participate and we would just send him on his normal route no questions asked. So while many in this thread are afraid pilots will not want to sit on the ground, or just disconnect, yes some will do that, however I think you will be surprised on how many would actually like that.
Also how many times have you seen a FNO where they have 4 center controllers online but only 1 is super busy why the other 3 are twiddling their thumbs??? ARTCC's need to be able to recognize this and take initiative on opening up further sectors, rerouting traffic, something. Again using ZTL as a example since I am the most familiar with it...They use 1, 2, 3, next to their position name when staffing a position. Why you may ask?? So that if you have 4 center controllers online they can very quickly switch frequencies to open/close different sectors without having to log off and change callsigns. To this day I really do not understand why other ARTCC's have not adapted this policy, it works wonders.
-
2) The FAA uses software that puts all aircraft inbound to an airport (or an airspace) on a cool timeline that makes it easier on TMU and lets those controllers see immediately where aircraft are bunching up. It would be cool to have some sort of VATSIM approximation of this for events.
You mean something like this? (http://minniecenter.org/tmu) This is something that I've been working on for the last little that will hopefully help us better manage traffic flow. We'll see how well this works for our next event.
-
2) The FAA uses software that puts all aircraft inbound to an airport (or an airspace) on a cool timeline that makes it easier on TMU and lets those controllers see immediately where aircraft are bunching up. It would be cool to have some sort of VATSIM approximation of this for events.
You mean something like this? (http://minniecenter.org/tmu) This is something that I've been working on for the last little that will hopefully help us better manage traffic flow. We'll see how well this works for our next event.
You are the hero this world needs. Exactly this. Looking forward to seeing this develop further.
-
I want to thank everyone for their input, I hope the discussion continues.
Maius has been an absolute boss at doing the website end for ZMP, and he decided this TMU project was something that was doable. Here's an idea of how deep of a discussion we went into about this:
I were looking at stats from our last event and found the busiest 30 minute period, which we all agreed was beyond our max (factoring in network lag and bad pilots). So we figured a max, took 20% off of it, and decided that it's the "AAR" than we can use to shoot for during events. We just have to figure out the different rates for the other runway configs.
Holy crap we're dorks.
-
I want to thank everyone for their input, I hope the discussion continues.
Maius has been an absolute boss at doing the website end for ZMP, and he decided this TMU project was something that was doable. Here's an idea of how deep of a discussion we went into about this:
I were looking at stats from our last event and found the busiest 30 minute period, which we all agreed was beyond our max (factoring in network lag and bad pilots). So we figured a max, took 20% off of it, and decided that it's the "AAR" than we can use to shoot for during events. We just have to figure out the different rates for the other runway configs.
Holy crap we're dorks.
MSP Rates:
http://www.fly.faa.gov/Information/west/zmp/msp/frames.htm (http://www.fly.faa.gov/Information/west/zmp/msp/frames.htm)
Also, I'm very interested in your TGUI you made for MSP! PM me please, I'd like to know more!
-
Wow, Maius! Wow! Awesome!
So we figured a max, took 20% off of it, and decided that it's the "AAR" than we can use to shoot for during events.
@SQ: I had to read your last post 4 times before I saw the word "off".... For some reason I thought you were saying 20% of it.... I was like, "I know more and more VATSIM pilots are "less than stellar" these days, but not that many! Then I finally saw the "off"... Phew... Need more coffee.... ;)
-
I would be interested in something like this for ZMA as well. Let me know how it plays out during the next event. Thanks.
-
I want to thank everyone for their input, I hope the discussion continues.
Maius has been an absolute boss at doing the website end for ZMP, and he decided this TMU project was something that was doable. Here's an idea of how deep of a discussion we went into about this:
I were looking at stats from our last event and found the busiest 30 minute period, which we all agreed was beyond our max (factoring in network lag and bad pilots). So we figured a max, took 20% off of it, and decided that it's the "AAR" than we can use to shoot for during events. We just have to figure out the different rates for the other runway configs.
Holy crap we're dorks.
MSP Rates:
http://www.fly.faa.gov/Information/west/zmp/msp/frames.htm (http://www.fly.faa.gov/Information/west/zmp/msp/frames.htm)
Also, I'm very interested in your TGUI you made for MSP! PM me please, I'd like to know more!
The thing is, is we can’t use real world numbers for the network simply because the real world doesn’t have some of the same limitations we do. For instance, they can give 3 instructions in the time it takes us to give 1 just because of voice lag and not being able to understand the controller half the time. Also,we aren’t professional controllers, so our spacing isn’t going to be as perfect as what they can hit in the real world, and not everyone can land on runway 35 in our 30/35 config on the network. So we’re probably going to end up running sweatboxes with arbitrarily increased separatation on final, and come up with our own numbers.
-
I’m excited to see how this will work in events!