Nicholas G - 1397820
-
Posts
368 -
Joined
-
Last visited
-
Days Won
17
Content Type
Profiles
Forums
Calendar
Posts posted by Nicholas G - 1397820
-
-
Warwick, I can say hand to heart you may welll be the most overprepared pilot to fly on VATSIM ever!
A lot of people don't make ANY effort before they log in first time, so I sincerely thank you for your efforts, Utimately, you log in when you want and feel ready to, but sounds to me like with the level of prep already, and your attitude towards the network, you'd be more than fine logging in right now.
If you take the attitude of asking if unsure, I reckon you will not have any issue and can enjoy the network and ATC as soon as you want to login
-
1
-
-
/L does seem to sometimes cause TAATSMOD to display as RVSM, other times it doesn't. Not quite sure what causes this difference. In any case, I generally ignore the symbol on the TAG and go purely on the filed equipment code. If the filed code is non sensical (i.e no transponder or RVSM approval for a Qantas a380 at fl 380), i will just 'fix' it.
-
A fantastic addition to the suite of excellent tools VATPAC controllers have at their disposal to assist online. Thanks Peter, Tom and the testers for all their efforts!
-
3
-
-
-
Top Down services should be indicated by the controller in their controller info,
except iirc for the primary aerodrome for the primary sector which must always be provided services if no local controllers are online (eg WOL for YSSY, SNO for YMML). EDIT: Actually, I may have to retract that bit about the the primary aerodrome. Policy is still the same as what Quigs posted here, and it clearly has in the example top down aerodrome being speciifed even when they are the primary aerodrome for that sector (i.e SNO MUST still specify in controller info when top down to YMML). The policy hasn't changed. i may have been thinking about having to put an ATIS at hte primary if you're top down there and have multiple potential atis's you could provide.
You get Top down service (if it is being provided) regardless of flight rules (i.e controllers can't decide to service IFR at YSCB but not VFR), but obviously the kind of service you get may change depending on flight rules. IFR should be always talking to ATC if there is an overlying controller, of course, because of the two way comms req, but that's probably not what you mean by 'top down' .
I have noticed a great many controllers have been slack about this recently, not including extended sectors, frequencies or top down aerodromes in controller info despite apaprently expecting pilots to know that they are providing/not providing those services.. I have also noticed a great many pilots not reviewing this information nor knowing where to find it even when it's readily accessible in the relevant controller's information. I can't think of any particularly great solution to this mutual conundrum, other than the common sense approach of - in doubt, ask. -
Yep, that's correct. Always good practice to monitor any ATS covering your area even if you don't need to talk to them, but yes, VATPAC airspace is pretty much identical in structure to the RL airspace. If you're VFR in class G or E, you don't need need any kind of clearance
Main difference is really that VATPAC en route sectors tend to be much larger than the real ones because there is less en route traffic to worry about and there are fewer controllers likely to be operating at any one time.
-
Out of interest Greg, and not that i don't think you're right, but I'm wondering if you can go into more about how you know it's not required. A squawk ident pilot readback phraseology is included in the AIP, so I kind of assumed from that it may be a readback item.
-
No. Adsb to the hand off point.
-
From memory, I think the reciprocal tracks have been left that way to deliberately give darwin something to do because inbound traffic is usually way below typical MRM inbounds to either aerodrome. It doesn't impact arrivals to Alice apart from the secondary effect giving more track miles to sequence further upstream. Certainly nothing stopping jets being cleared on the RL track though outbound.
-
I mean,, there will always be people who don't read those anyway, but the thing with routing, semicircular rule, etc, those are things that can be fixed on the ground at clearance delivery stage. As long as aerodrome staff are checking the flightplans (big if), you can fix those things before aircraft get airborne. Fuel planning as well, if a plane runs out of fuel, not a lot you can do about it. If people are planning an alternate they should at least have enough probably to get back to Darwin, so unless you have terrabad delays it's going to be a shortcoming in their own flight planning.
But that's more a pure pilot side thing, where I think the main benefit of a document like this is to explain the pilot ATC interface clearly and the procedures that are involved in this specific procedural scenario. It's not so much the place to teach basics of flight planning. Also worth noting that the routes, etc, are already regularly published with the event details, so I don't see a whole lot of point duplicating materiall. Put a link to the event page in the doc if you like, saves time. Links in general are a good way to reduce the information load in the doc and make it more readable.
The stuff that should probably be concentrated on is largely the transition from surveillance en route to a congested procedural terminal area, and vice versa. Most of that's already done in here IMO, it's just about slimming it where possible.
Every par helps. You're right, those bits are only small, but if you take that and probably about half of what is in flight planning, you've condensed by at least half a page without really trying and without having to even touch the more critical parts of flight.
M0.78 is probably the standard en route cruise for most jets. Most people also tend to fly that, there's a few that go for broke and a few others who do other ground speeds largely because their weather engine is borked/non existant -
I think most of the information is fine, but it's pretty dense as it is. There are some things like holding fuel and the planned routes that are probably either unecessary or duplicated elsewhere. VFR aircraft or aircraft departing OCTA are probably also outside the scope of what would be useful as ninety nine percent of the traffic will not be those aircraft, and people who are flying in or out OCTA (aside from people looking for circuits etc) will probably be more likely to be aware of the procedures already.
I think the core things that would be most useful are what you've included in terms of the inbound call, expectations around being visual vs likely scenarios if IMC (including holding, specifically whether it will be over LISZT, over AS etc, and where to find published holds). Maybe something on planning for a standard en route speed (e.g 0.78) would also be helpful? I think if you focus on those elements and remove all the tertiary material, and maybe format into smaller sections with examples, you're onto a winner. -
I don't know, but I think a lot of things like climbing to MSA in IMC without provision of other terrain clearance may be a SOPS issue for operators if not an air law issue. SIDs provide an easy, accessible way of providing that published terrain clearance.
I'm also not 100% sure on this, but I suspect the radar SID may only be availble AH, as Mackay Approach is only operational when the tower is closed, and the service is provided from Brisbane. -
Could be any or all of the above. AFV occassionally will throw hissy fits. I'd check that you're mic is connected properly cause I think occassionally it will hard reject you if it doesn't detect a sound device or if there's an issue, otherwise you just have to ride it out. A restart of your computer wouldn't hurt.
-
For example, If you're at Sydney airport, and there is no ATC covering Sydney, you would monitor 122.8
If you're at Sydney airport and one of say Sydney Tower, Approach or ML-WOL_CTR are on, you should contact them on one of their frequencies for service. You can see what freq to tune by looking at their controller info in your pilot client, on VATSPY, or the controller positions page you linked.
If you're flying near Sydney but not in controlled airspace (say, as a VFR flight low level in Class G airspace), you should be monitoring unicom unless you wanted to pick up some service from ATC like flight following, in which case you would use that freq. Nothing stopping you monitoring unicom and additionally listening to whatever other frequnecy you want.
Occassionally it can be tricky knowing what frequency to use for CTR controllers as they may also be covering their own sector AND a sector next to them (so, ML-WOL may also cover SNO and therfore likely YMML), but look at their controller info and compare to this chart to know what area you are in and thus what frequency to choose.
Once you're on frequency with ATC, you stay on that frequency until they tell you to change. In almost all cases (certainly in the case of 99% of flights that actually occur on vatsim), you don't need to be on more than one freq at a time.
If in doubt, ask a nearby online controller for help. -
I suspect the real world weather built in to FSX is probably no longer active. Whoever MS contract to provided those third party info services is probably no longer doing so.
Most people will be using third party tools such as Active Sky for their sim weather. It's possible FSX might have some other freeware mod available but I personally don't know about that. Might be worth a google.
But yeah, there's probably not any way to get FSX inbuilt weather to work reliably anymore. -
At the risk of beating a dead horse, just wanted to revist this again because there's still a lot of confusion about what is meant by a visual approach and what ATC is asking for when they ask visual.
There are quite a few cases (Sydney and when having to adjust the sequence at Melbourne) where pilots reporting visual can be helpful. Obviously at sydney it's nice to utilise IVAs to make a more efficient sequence into the parallel runways without having to individually visually seperate pairs of aircraft, or stagger the approaches. Also at Melbourne, it can be nice to have aircraft visual to avoid having to take aircraft out of sequence or, if you need to do that anyway, to be more easily able to put them back in again in time for a stress-free descent to the threshold thanks to the MVAs to the north (if 16 is in use).
It's worth noting again, particularly for pilots, that reporting visual does not require you to be able to see the aerodrome (except in low visibility conditions, which are rare outside of the last few months with heaving storm and smoke activity). If you report visual, it merely means that ATC will be able to give you visual follows to aid in sequencing, orunrestrict your descent earlier, or potentially reduce track miles to help clear flow up the line. You will still be given lateral tracking to get closer to the aerodrome either via the STAR, or through ATC instruction. The idea is basically that you can keep yourself from hitting the terrain, and make it easier to seperate you from other aircraft, until you get close enough to the aerodrome to manouver yourself for the final approach.
As Greg points out above, if you're currently VMC but there's a huge stack of clouds over the final approach path, don't call visual or at least tell ATC there is that issue, but if you just can't quite make out the aerodrome because of distance BUT there are zero clouds around, you can totally report visual.
Also worth noting it can be SUPER helpful for aircraft to follow the real world procedure and report their flight conditions on first contact with the approach controller. "visual" "in cloud" or "or on top" are all fine to use depending on your conditions, but if you let us know consistently with that call, you won't forget and we can plan accordingly especially in high traffic situations.
For completeness sake, here's the AIP
Quote2.11.3 Visual Approach
2.11.3.1 ATC Authorisation.Except as detailed in para 2.11.3.2 [concerning foreign Supers and Heavies other than on Sydney IVAs], the criteria under which visual approaches may be authorised by ATC are as follows:
a. For an IFR flight:
(1) By day when:
– the aircraft is within 30NM of the aerodrome; and
– the pilot has established and can continue flight to the aerodrome with continuous visual reference to the ground or water; and
– visibility along the flight path is not less than 5,000M, or for helicopters 800M, or the aerodrome is in sight.
(2) By night when:
– the pilot has established and can continue flight to the aerodrome with continuous visual reference to the ground or water; and
– visibility along the flight path is not less than 5,000M; and
– the aircraft is within 30NM of the aerodrome; or
– if being vectored, the flight has been assigned the MVA and given heading or tracking instructions to intercept final or to position the aircraft within the circling area of the aerodrome.
b. For a VFR flight by day and night, the aircraft is within 30NM of the aerodrome.
Worth noting that the clearance from ATC for a visual to IFR at night generally has some extra requirmeents (including provision of a maintain altitude not below MVA or LSALT/MSA until in the circling area or on PAPs/GP), but we're generally loose about this for various reasons, not least because many pilots are on daytime so they can see their scenery.
-
1
-
-
Most contollers will have at least some controller info including radio callsign and ATIS freq - tools like Vattastic are pretty unreliable for those atm, so the only reliable way to see controller info is via the pilot client, other sources may simply pass null information. I personally always operate CB top down if on WOL or SNO, and I always note it in my controller info.
Canberra reverts to Class G 8500 ft or below if no TCU, unless there is top down, which as Cam notes isn't mandatory for SNO (although they still provide services in the G). It's possible there may have been a controller change in terms of which ENR unit was providing that coverage and there was no coordination about the top down coverage in the scenario you note.
We should probably actually make things like current top down coverage (or relinquishment of such control) a handover item when there's a controller change or a station is closing and another unit is extending their coverage. Had a similar issue at Avalon on Monday as ML AP where an aircraft on the ground was expecting top down coverage, as they had been getting it from the previous controller, but I was not planning to give that coverage and to instead operate the E airspace above AV instead. No idea if the other controller had it in their info, I certainly didn't. Not sure if the pilot reviewed the controller info, but it would also be reasonable for them to expect that coverage if they had just been getting it.-
1
-
-
Ha, don't sweat it man. Generally we're not bothered by people who suddenly disappear. It's when aircraft suddenly appear in congested airspace with no warning that there's a problem
-
Hi Joe,
Yes, that's it. There are also some ATC settings under the General settings tab iirc, but if you just want to get rid of Microsoft Sam voice, what you've already done is all you need to do.-
1
-
-
Not a problem.
I have already ( I think) updated the script so the generator will only take account of clouds 5000 ft or below. That kind of thing is relatively easy to accomplish. Doing it for MSA might be a bit more difficult to automate, but should be doable for at least the major aerodromes time efficiently. -
Yeah, so I've set up an electron environment, that's how i've tested most of the modifications. The two items I mentioned above are the only two that are really preventing the Generator being used fine with the VATSIM side software IMO - the fact that it generates long ATISs doesn't matter so much if it's all being done automatically, which the version I'm using does.
End of the day if you can get vATIS to work instead, that's fine too, but I guess we're kinda beholden to the vATIS mob on that front. -
Ah, ok. Yeah, I saw those, weren't sure if they were you.or not.
Those would be things we could potentially work towards, but again, I'd basically need to work out javascript to be able to meaningfully contribute. Turning the existing outputs from various functions into human readable forms is easy enough for me to do, but I personally wouldn't really know how to go about adding new functions.
Mag var would certainly be something good to have, but in terms of new code (if we want to go that route and if anyone is available to add their expertise), I would think making cloud bases and 'hundreds' and 'thousands' of numbers would be a higher priority.
Let me know if you want any of these updated scripts. My aircrafts.json (which governs the specific options for places like YSSY, YMML etc) just lives in the Generator's AppData file (%appdata%\VATPAC\ATIS), but I think all the other scripts (for winds, temperature, qnh, and all rwy config for non custom airports e.g ymay) I think need to be done at source level and then built. -
So, a brief update as I've had a chance to go through some of this.
First - some files are either hidden in the install, or are hardcoded into the application at the build stage. The scripts that govern most of the handling of metar elements, however, are accessible from the source files on github.
I have a version working that now handles most of the items correctly for AFV's voice synthesis, as you can see here.
A few issues:
1. The javascript currently just reads the cloud octa abbreviation and spits it back out, so it relies on the voice atis bot to correctly interpret it, which it does most of the time but seems to 'Americanise' it slightly (e.g "Cloud, Broken Cloud Three Zero zero zero feet". It would be possible to add more code to get the Generator to look at, say "BKN" and turn it into "Broken", but I'm not a JS guy so I'd have to work to try and figure a solution. Maybe someone else would know better
2. Numbers for visibility and cloud bases are pronounced as individual digits (i.e Visibility Seven Zero Zero Zero Metres), and would require the Generator scripts to be able to look at numbers for cloud and vis and turn those into thousands and hundreds as relevant. Again, I'm sure this is emminently doable, but not in my wheelhouse without further reading.
They're the only issues I've found atm, otherwise it all seems to work fine. No idea how to go about sharing the updated scripts at this point, anyone wants to have a poke or has some suggestions for the above two issues in particular, I think we can quickly put together something that will work with the voice bot pretty quickly.
Digging into this stuff also makes me appreciate how much work @Eoin Motherway has done to put this tool together in the first place, so hats off to you sir!
-
Hey
Sorry, been strapped for time. I have looked at it, some of the airports files are still sat in JS and are easily editable, but a lot of the other elements like for weather etc seem to only be editable at the source level, cause I can't find any other editable data files for them post-install. I'll have to set up git on a machine again probably to go and edit to get something usable in binary for windows. I'm not a coder, so will only be able to fiddle with the output. It'll depend how much of the Javascript I'll be able to parse
@Peter StoryWhat issues had you mentioned?
Flying regional IFR with CTR coverage
in Pilot Training
Posted · Edited by Nicholas Gilbert
Unicom. Nothing wrong with trying the CTAF as well, but currently the only officially approved uncontrolled freq is 122.8 in Australia, so that's what most people will be tuned to and what therefore is going to be best to use.