Jump to content

Alex Ying

Members
  • Content Count

    39
  • Joined

  • Last visited

Posts posted by Alex Ying

  1. Rob already gave some great answers, so I"ll just add on some additional context

    1. SimBrief sometimes generates some non-sense routes. In the US, many ARTCCs have Preferred Route Databases (PRDs) that you can search. ZNY and ZBW for example. You'll see on there that it also shows altitude and aircraft type restrictions for each route as well. Another source for routes is the FAA's Preferred Route Database. For some longer routes, there may not be a preferred route. In that case, you can serach FlightAware for real-world routes.
    2. In the US, SIDs have a short code depicted on the chart. The Westchester 7's is "HPN7" so you could file HPN7 MERIT ORW WOONS2 to request the HPN7 departure. Some airports have runway-dependent SIDs so you may get assigned a different departure procedure even if you request one and it's good to be prepared for a route amendment.
    3. Yes, you are expected to follow all parts of the departure procedure unless ATC instructs you to do otherwise. For context, the airspace design around HPN has LGA arrivals flying east of the airport. Flying to the west gives ATC room to climb and vector you around arrival traffic and then send you towards MERIT.
    4. Depending on the traffic situation and workload of the controller, they may let you continue or they may vector you wround to the correct place. If I'm not too busy, I like to send a private message to gently point out their error and provide guidance on how to correct it in the future. In gcongested airspace like New York's, it's really critical that procedures are followed to avoid conflicts in the air.
  2. I'll echo what Evan said and emphasize that it's highly situation dependent. If it's just another day on the network then there probably isn't likely to be a need. However, if it's an FNO or some other massive event? There's a lot of traffic management and flow planning going on the background that is not readily apparent to pilots. In the real world, sequencing and flow management for LGA or JFK can start as far west as Chicago and Minneapolis. VATUSA's FNO events in particular can regularly exceed real-world demand, so it's very common to see flow management even hundreds of miles away from the event airport.

  3. This is a bit of a feature request: For airspace and sector boundary development, it'd be useful to be able to have a Dev Mode where we could load a custom datafeed file in order to test how different boundaries light up when controllers are online without having to actually log on to VATSIM and wait for the datafeed to update. It would also enable testing and debugging of multi-sector interactions without having to find multiple people to log on.

  4. FYI, I'm not even trying to argue one way or another whether NY should be combined. My last post was all about providing some information about the setup at NY and elsewhere in the US and asking questions I had.

     

    I'd like to hear from Mark or whoever actually operates the programs/scripts that compile this on how exactly hours get combined. I skimmed through "The Rules" thread which seems to be the closest thing to docomeentation on how the contests work and it doesn't quite address what I was asking in my previous post. I'm all for consistency, but it's not clear that we have consistency even in the current iteration of the weekly awards (where the 3 major N90 airports are counted separately). Counting SCT_APP hours to San Diego for example or NCT_APP hours to San Francisco or Oakland. Does that happen? It's not clear from what's publicly available.

     

    As for the general use of subsectors, it's also not clear to me why the philosophy on sub-sectors is different between en-route facilities and terminal facilities. They're more similar to each other than towers. They're (mostly radar) facilities that cover larger areas and multiple airports vs. towers which are explicitly tied to a single airport at a time. We count en-route facilities as one for counting hours. Why do we have to tie terminal facilities to a single airport when there are many terminal facilities that are not designed like that (both in real life and on VATSIM)?

     

    I guess if I had to boil it down to a single question, then it's this: Are we trying to count service availability at terminal facilities, or are we trying to count terminal services available at airports? Those are similar but not the same thing and I don't see an answer to that anywhere on the forums. Until there's an answer for what the real goal of the contest is, it's kind of silly to be debating the minutiae of how to count the hours because we could be talking about two *different* contests and we don't know which one is the actual one being run.

  5. Here's a question about an analogous situation: How are hours for London Control (the en-route facility, not the terminal facility) counted? From what I know about their setup, they regularly open sub-sectors of their airspace on their own. Are hours only counted when the entire airspace is open/controlled?

     

    As Karl mentioned above, at N90 (New York TRACON, which covers EWR, LGA, JFK, and satellite facilities, NOT PHL though, that's a separate facility), controllers can control the entirety of N90 or multiple sectors if they are certified for it. Unfortunately, you can't tell from callsign alone whether someone is only covering JFK or covering all of N90 just from the callsign (NY_CAM_APP for example). One way of counting (distributing to individual airports only) under-counts the service at N90 on both an airport/sector and facility level. The other way (combining all into a single "New York" tally) over-counts the service if you're looking at it on an airport or sector/area basis, but is accurate if you're looking at just facility service.

     

    The last time this come up for discussion, there was input from controllers at ZLA and ZOA about SOCAL and NORCAL TRACONS and how they get counted. They also have consolidated callsigns. Another good questions there is how to distribute hours when someone logs on as SCT_APP vs SAN_APP. Does San Diego get hours from someone logging on as all of SOCAL approach?

     

    Ultimately, this goes back to the core philosophy of the award. Until we agree on what the award is actually for, you can't come up with a way for tallying progress toward it. To me, it seems a bit strange that for a terminal facility award, things are tallied by airport when terminal facilities serve multiple airports (and in some cases, multiple major airports).

  6. Many large airports now also have surface movement radar which requires Mode-C to work, so you should always check the airport charts and ATIS for information on how that's handled.

  7. "Descend via" is used in many (most?) parts of the US with FAA procedures, however, it's only used when there are published altitude restrictions and ATC still has to [Mod - Happy Thoughts]ign with the "descend via" phraseology. On procedures with published restrictions but no "descend via" clearance or on charts that only have "expect" altitudes published, the clearance only applies to the lateral portion of the STAR. One of the more frustrating things is when pilots don't comply with these rules and descend when they don't actually have clearance to do so because they misread or don't understand the charts / rules.

  8. The HF/VHF thread is locked it seems and I can't reply there.

     

    Controllers logged on as ZWY_CTR on 5520 with VHF alias 130.000 and ADR_CTR on actual VHF 130.000.

     

    Pilot tuned to 130.0 in Adria Radar airspace tuned to HF instead of the VHF frequency.

  9. HF appears to be broken.

     

    I logged on as ZWY_W7_CTR which matches an HF position in the database on 5520 and VHF alias 130.000. At the same time ADR_CTR was online as well on VHF 130.000. I had a pilot call me from LJLJ airport. The pilot was in range of ADR_CTR on 130.000 but the AFV system still tuned him to 5520 as shown on the AFV map.

     

    I had another pilot attempt to test with me while flying in the US and he was not able to contact me. The pilot tuned 130.000 and it stayed there instead of retuning to 5520.

     

    I then logged on as ZWY_EM_CTR on 17946 aliases to 130.900. The pilot over the US was still unable to contact me. Tuning to 130.900 kept him on 130.900 instead of retuning to the HF frequency.

     

    Edit: When another controller tuned the HF frequency, we were able to communicate. It seems to be a pilot tuning issue.

  10. We actually have implemented pseudo ADS-C at ZWY. Like the OP said, we have all the data available to us at the client side from VATSIM, so simulating ADS-C reporting is trivial. Especially for heavy event traffic, this lets the controller actually provide air traffic control service, rather than just taking position reports non-stop. Things like re-routes, deviations, ADS-B ITP, and ADS-C CDP can be implemented by the controller. Greatly increases capacity and reduces controller workload providing an all-around better experience for everyone.

  11. As far as text pilots go, it's common knowledge that most controllers don't particularly like them, because it's extra work for some, especially less experienced, or less organized controllers. I don't think it's far fetched for an overwhelmed controller to deny, or delay service to a text pilot. It's a slippery slope. If VATSIM allows preemptive airspace service denial, then who's to say how far it may spread over time?

     

    In response to this point specifically, it's not a "preemptive airspace service denial" in the way that your painting it, if I'm reading that correctly. The key point here is "workload permitting." Like I said above, everything is workload permitting. I will refuse handoffs for IFR aircraft into the primary airport if my workload is too high. This is common during events, which is why aircraft go into holding. It's not specific to Cl[Mod - Happy Thoughts] D airports or text pilots or whatever. If I can more efficiently serve more pilots by letting a text pilot wait a little longer, then I will do that. If I can accomplish the same by handling all the text pilots first while someone on voice waits for several minutes before I issue them a clearance with a long reroute, I'll do that.

     

    [Mod - Happy Thoughts]uming controllers will handle text pilots last is not a valid [Mod - Happy Thoughts]umption. Are there controllers who don't like text pilots? Of course, but there are also controllers who don't like international pilots because they're difficult to understand, or because they don't understand FAA rules (and I'm obviously speaking from a US perspective here, because that's all I know). Is that a good attitude to have as a controller? Probably not, but that's not really relevant to the discussion here. To me, at least, it seems like you're making an issue of something that isn't one and reading too much into that line in the controller info. As far as I know, this "slippery slope" you're worrying about doesn't exist because the top of said slope isn't actually an issue. The top down model is still the procedure and the CoC still requires equity between voice and text users.

     

    As to why this particular controller put that in their controller info, I won't pretend to know their personal experience. Maybe they've run into issues with people demanding service contrary to the duty priorities that are also in the 7110.65 and this is alleviating that by setting the expectations. Maybe not, again, I don't know. However, as I read it, it's not them saying "I don't want to deal with Cl[Mod - Happy Thoughts] D airports, so I'm just going to ignore them," rather it's letting pilots who may not be as familiar with ATC duty priorities know what to expect.

  12. Everything is workload permitting. You can be refused VFR entry into a Cl[Mod - Happy Thoughts] B if the controller is overloaded (I've had to do this before working N90 top down), you may have to wait a while for a clearance if things are busy in the air, etc.

     

    I'm not sure how you jumped from what's written there in the controller info to not servicing text pilots, but that's not at all what that means. The 7110.65 (at least in the US) is what we go off of in terms of what services we provide in general. "VATSIMisms" like "Cl[Mod - Happy Thoughts] D services provided based on workload" are in the same spirit as the text of the 7110.65.

     

    The primary purpose of the ATC system is to prevent a collision between aircraft operating in the system and to provide a safe, orderly and expeditious flow of traffic, and to provide support for National Security and Homeland Defense. In addition to its primary function, the ATC system has the capability to provide, with certain limitations, additional services. The ability to provide additional services is limited by many factors, such as the volume of traffic, frequency congestion, quality of radar, controller workload, higher priority duties, and the pure physical inability to scan and detect those situations that fall in this category. It is recognized that these services cannot be provided in cases in which the provision of services is precluded by the above factors. Consistent with the aforementioned conditions, controllers must provide additional service procedures to the extent permitted by higher priority duties and other circomestances. The provision of additional services is not optional on the part of the controller, but rather is required when the work situation permits.

  13. In the US at least (not sure about elsewhere), you will sometimes see fixes determined by a VOR radial and distance. For example, you could enter LGA055049 which is a point along the LGA 055 radial 49 nm from the VOR (this happens to be a named fix called MERIT, so you should use the name if it exists, but that's not always the case). In general though, if you can use named fixes or airways, that'll be easier for the controller to read.

  14. While that's usually true, it's not always true. I've seen SWAP routes be the most frequent route on FlightAware before. And even if not, someone who looks at FlightAware may not necessarily choose the most frequent route or the correct route for their type of aircraft when multiple routes are available. Additionally, FlightAware sometimes chops off earlier fixes if a flight gets a shortcut or the filed altitude will be listed incorrectly.

     

    That's why I would recommend the PRDs first, since those are organized for that specific purpose and not dependent on archived data which may have artifacts or have processing errors. That's not to say FlightAware isn't a good resource, it definitely is, but using it requires a bit more knowledge and skill to pick out the signal from the noise.

  15. For the US, my first stop would be to check the vARTCC's site for their preferred route database. Many of the VATUSA sites have them. For example, New York's or Boston's.

     

    If you don't find it there, then check the FAA's preferred route database at https://testfly.faa.gov/rmt/nfdc_preferred_routes_database.jsp.

     

    I generally only use FlightAware if I don't find a route in any of the PRDs or I need a SWAP route.

  16. Here in the US, if I have aircraft on approach, I'll send them to tower without before any tag handoffs. I'll usually do it as a courtesy, but it's not required and I'm fairly certain that doesn't happen IRL. Sometimes the tower controllers also pick up the tag then immediately drop it, or just never pick it up. No big deal.

     

    As for entering another airspace before picking up a tag, that is, like Ryan said, not allowed in the US. The issue is not the size of the total area of control, but particular subsectors getting overloaded. I'll keep taking handoffs into EWR and LGA but reject JFK arrivals if I'm holding in the sequencing airspace. Regularly happens on FNOs where an airport will get 1.5-2x the arrival rate the airspace is designed for. You MUST wait for tag acceptance otherwise you need to spin your aircraft. Holding fixes get filled up, approach airspace runs out of vectoring room, and of course, the VATSIMisms of differing weather or XPlane users with low frame rates all cause a sector to become overloaded. It sometimes has to do with controller skill, but not always. Sometimes, there are just too many planes.

  17. Like others have said, it depends a lot on local procedures. In the US, for the most part, all cab positions start with the ICAO code but dropping the first K. (Ex. Kennedy Tower at KJFK becomes JFK_TWR)

     

    The exceptions are en-route positions where the ARTCC abbreviations are used (NY for New York Center, CLE for Cleveland, etc.) and TRACON facilities separate from the an ATCT facility. New York TRACON is a separate facility from the control towers at JFK, LGA, and EWR and uses the NY callsign. SoCal, NorCal, and Potomac are similar.

  18. Is there a way to specify (either in the airport file or via the aircraft commands) a direction to taxi on a taxiway in TWRTrainer? For example, at KJFK, A is (generally) used for clockwise taxiing while B is for counter-clockwise taxiing. However, when giving taxi instructions, I didn't find a way to get the aircraft to go in a particular direction.

×
×
  • Create New...