OnCourse Software

My first actual flight with PF3 was a nightmare of stupid ATC.

I was flying a short IFR hop in California from KACV (Arcata airport, near Eureka, CA) to KEUG (Mahlon Sweet Field in Eugene, Oregon). I'd "filed" KACV CEC OED RBG KEUG, a simple airway-based route at FL180. KACV is an uncontrolled airfield so I picked up my initial clearance from Flight Service. This part seemed normal to me. From there, though, things started to get weird.

• For whatever reason, I was unable to make CTAF calls while on the ground at the airport for taxi and departure (there were no options to do that; all the CTAF options were for a plane in the air approaching the airport -- none for an airplane on the ground departing the airport).
• Shortly after departure (at around 500' AGL) while still on the CTAF frequency I received an ATC instruction to turn to a heading. This is already horribly wrong, but -- whatever. The turn made sense so I did it.
• I switched to the assigned departure frequency and made my initial contact. My full clearance was issued and (after acknowledging it), I was instructed to resume my own nav. This part was all good.
• After a couple of step-ups, I reached my cruise altitude and headed north to CEC VOR, my first waypoint.
• The filed route has a big dog-leg in it (CEC to OED to RBG), so I shortly before reaching CEC I requested direct to RBG and was cleared to do that.
• For the rest of my 'direct RBG' leg, ATC constantly bitches that I'm off course ("you are XXX miles from the airway"). Yeah, no kidding -- you cleared me to do that. I'm guessing that PF3 doesn't handle 'shortcuts' correctly.
• Along the way, I also got an arbitrary altitude decrease from FL180 to 16,000'. Not a big deal, but not very common in real life either.
• Crossing RBG things start to go really badly wrong. First, I'm told to expect RWY 21 at KEUG. There's just one problem with this: there is no RWY 21 at KEUG. I'm looking at Foreflight (which is current), I'm looking at my GTN 750 (which is at AIRAC 1702; 1704 is current, but I hardly think they added a new runway in two months). The airport has a pair of parallel runways (16L/R and 34L/R).
• I start getting vectors and descents and the vectors are reasonable for RWY 16, which was what ForeFlight was reporting as the active 'landing' runways.
• It's worth mentioning that I was in solid IMC for most of the flight. Weather at KEUG was reporting SCT 4400 OC 6000. Airport elevation is 373', so I was not expecting any issue with minimums on whatever approach they gave me.
• Descending through 4000', though, I've got no contact with the ground, so the weather report was wrong -- but that's fine.
• ATIS for the airport isn't working. No idea why, but the ForeFlight report is only 20 min old.
• A little more vectoring (way more than necessary), some totally unnecessary speed reductions (more on that in a bit) and another descent down to 3500'. It looks like I'm being vectored onto the ILS for 16L.
• All of a sudden my GPS and ForeFlight start screaming at me about terrain clearance. My radar altimeter comes alive showing me I'm at 1500' AGL and that altitude is rapidly decreasing. About that time the clouds clear enough that I can see the ground below and ahead of me. I'm being vectored across a ridge of a small line of hills. I can see I'm actually going to clear the terrain, so out of morbid curiousity I stayed at 3500'. My radar altimeter shows I crossed the ridge at 400' AGL. It looks like PF3 has no concept of MVAs.
• Across the ridge, the ground drops away again, and I'm cleared for a visual approach to RWY 21. I was never asked if I had the runway in sight, which is a FAA requirement for ATC to issue a visual approach clearance.
• I get a speed reduction that would cause me to fall out of the sky (that's probably my fault for not setting PF3 up correctly for the aircraft I was flying, a Beech Duke Turbine), which I ignored (since there is no way I could find to say "Unable").
• I get handed over the tower and they clear me to land on RWY 21. Which doesn't exist.
• AFTER being cleared to land, the tower is still issuing me speed reduction instructions. Why?
• Using my ForeFlight map, I turned to intercept the centerline for RWY 16, and about 3 miles from the airport I finally can see stuff.
• And son-of-a-gun, there is a runway that's diagonally crossing RWY 16/34 L and R! It's alignment looks right to be RWY 21. I'm completely flabbergasted that ForeFlight AND the latest airports update (from https://www.aero.sors.fr/navaids3.html) are BOTH wrong, but I'm in a reasonable position to actually alter my approach and land on that runway.
• On short final, instead of a nice '21' on the runway threshold, there is a giant X -- yes, PF3 was vectoring me for the last 50 miles of my flight to land on a closed runway
• Screw it, I landed on it anyway, taxied to parking (sort of; trying to follow the "TGS" made no sense to me). I parked and shutdown.

I'll give PF3 another try, of course, but if this flight is any indication of the quality of the application it's not going to stay installed on my sim.

-M.

The "you are XXX miles from the airway" after requesting a direct might actually be a bug in PF3, I'll try to reproduce.
For everything else there are probably good explanations, but it would be easier if you can attach a zip containing at least PF3/Logs/debug_monitor.log, or even better the full PF3/Logs/ ans PF3/Flight/ directories.

Some things I can probably explain without the logs:
- PF3 does not use CTAF, and for this airport I see CTAF and Unicom on the same frequency (123.00), so PF3 offered only Unicom here. While on the ground on the departing airport, there are no Unicom (or Multicom) calls for taxiing, only hotkey 6 for taking the runway (but Unicom offers hotkey 7 to request field advisories). If you want more ground guidance, you could add a Tower frequency for this airfield in PF3's advanced options.
- The "arbitrary altitude decrease" is calculated from the descent rate in the aircraft profile. Additionally you can adjust the calculated waypoint altitudes before connecting PF3 to the flight sim.
- If runway 21 was available, it is because it is marked as available in the data generated by FSUIPC's makerwys, which takes the data from the simulator. I'm using the updates from aero.sors.fr, too, and for me it is listed as open, too. You can mark it as closed on PF3's SIDs/STARs page, or request a different runway (using Ctrl-Alt-W)
- ATIS on 125.20 should have worked, but the logs would know more. Did you use COM2 for that? Switching between COMs during a flight is not yet implemented, but it is on the wish list. Or request an ACARS ATIS using hotkey 2 from center.
- You can increase the limits for speed calls using an aircraft profile or in PF3's settings.
- The vectoring probably was for traffic separation But you can get rid of the vectoring and use your GTN by requesting "Cleared To Final At Pilot's Discretion" using hotkey 1 (or before the flight by activating a STAR approach, which does not have to be a real STAR, but could be any approach you want)
- PF3 does not know anything about terrain surrounding the airports, so you might have to adjust your FAF or waypoint altitudes, or maybe switch to a non-vectored approach as mentioned above.
- The speed reductions after being cleared to land were there to prevent damage to runway 21 by excessive braking, which is already in a bad shape and therefore closed for everyone but you
- The usefulness of taxi instructions and TGS depends on the quality of the airport's Afcad. So if it does not work for this combination of airport and parking spot, just disable TGS using hotkey 1.

I hope with the information above, your next flight will be much better!

Mark - I am new to the product and it took me about 16 flights before I had mastered PF3, there is a lot of configuration necessary to reach perfection. So don't be put off by one flight, I found it a huge learning curve but it was worth the effort. I am hooked now.

Incidentally, runway 21 is open by default in FS. But whether modified in an add-on or not, closed runways are apparently not identified in the runways.csv file generated by MakeRwys.exe so as Thomas says it is necessary to close them in the SIDs/STARS page.

For me it is just a case of making a routine at the planning stage of checking the runways and parking arrangements at the destination airport.

John

All good information -- thanks to both of you for posting.

So, PF3 won't select an approach if you haven't specified a STAR? (and obviously, not all airports have STARs) Is there a way to request a specific approach?

On the ATIS question -- yes, I was monitoring COM2. I didn't switch from COM1 to COM2 -- I just dialed in the ATIS on COM2 and enabled it on the audio panel. I couldn't see a PF3 way to make a request to leave frequency to make the ATIS check on COM1. I can't use ACARS - I'm using P3D as my sim.

"PF3 does not know anything about terrain surrounding the airports" --This is a pretty darned significant deficiency!

I really wish the last-spoken ATC communication would stay in the 'remote text' display and not disappear after a short period of time. Is there a way to set that as an option? In particular, I was unable to find a way to get ATC to repeat the "expect the ... approach" bit which would have given me more time to figure out what to do about appeared to be a non-existent runway. Understanding (now) that the database doesn't know about closed runways is helpful -- the next time this happens I won't be so confused.

John -- what do you use to check parking at the destination (or even the departure) airport?

Thanks again guys -- I'm sure my experience will get better as I learn more.

-M.

Mark Hargrove wrote: *

Thu Apr 13, 2017 5:03 pm

So, PF3 won't select an approach if you haven't specified a STAR? (and obviously, not all airports have STARs) Is there a way to request a specific approach?

No, I don't use SIDS and STARS, I put my faith in PF3's vectoring just like the default FS approaches. What I have found is that if you aren't specific in your flight plan concerning the descent, you will not get correct descent instructions. What I do may be in excess of the minimum to achieve this but it works. After planning my route I put a waypoint in about 10 miles short of the Top of Descent, one at the ToD, and two at similar intervals afterwards. Then, when loading the flight plan in PF3 I use the Adjust Altitudes button (you can set it to open this for you every time). There you will almost certainly find the first waypoint after the ToD shows as the same level as ToD, change it to a realistic figure. And change the next one to about 3000 feet above the airfield. This should give you sensible descent instructions.

Mark Hargrove wrote: *

Thu Apr 13, 2017 5:03 pm

I really wish the last-spoken ATC communication would stay in the 'remote text' display and not disappear after a short period of time. Is there a way to set that as an option? In particular, I was unable to find a way to get ATC to repeat the "expect the ... approach" bit which would have given me more time to figure out what to do about appeared to be a non-existent runway.

There is an option to use Shift/Ctrl/= for "Say again" or to get up a list of recent messages, or both. I already no longer use the text display now as I use the middle option and can check anything I miss.

Mark Hargrove wrote: *

Thu Apr 13, 2017 5:03 pm

John -- what do you use to check parking at the destination (or even the departure) airport?

I just open the file in AFX, but AFCAD2 would do it just as well. (I may be stating the obvious but I wouldn't recommend saving anything with AFCAD as it tends to wipe out post AFCAD features out). I'm on FS9, chances are you are not of course.

Remember I am not an experienced user, just offering my way of doing things. People like Thomas know more about PF3 than I ever will.

Best regards,

John

Mark Hargrove wrote: *

Thu Apr 13, 2017 5:03 pm

I really wish the last-spoken ATC communication would stay in the 'remote text' display and not disappear after a short period of time. Is there a way to set that as an option?

Options #2 screen, then Advanced Options screen. In the ATC Log/Say Again section, you can configure the ATC log to display when you make a "Say Again" request, or you can choose to have the ATC log open automatically when you connect PF3 to the sim.

PF3 comes with a 177 page User Guide. You can find it in ...\PF3\Help\PF3 User Guide.pdf.

Many of your issues and questions are covered in the User Guide.

Taking the time to read it will enhance your PF3 experience a lot.

Mark Hargrove wrote: *

Thu Apr 13, 2017 5:03 pm

So, PF3 won't select an approach if you haven't specified a STAR? (and obviously, not all airports have STARs) Is there a way to request a specific approach?

The philosophy of PF3 is different here.
It is basically just either being vectored by PF3 or being left alone to fly your published approach, ILS transition, STAR, DME arc, following the pink line on the GNS, or whatever you think would be the best. Because you can read the charts, or ask your FMC, or ...
So if you enable the STAR feature, you will have to know what to do yourself.

But for added immersion you can:
- give a different name for each runway's approach (being it the real name of a STAR or something generic like "ILSOSN" for an ILS transition from the waypoint OSN)
(since PF3 3.3.0 you can store multiple names and access them by double-clicking the name)
- use the PF3 free randomizer (click on Board index, the fourth sub-forum) and let it auto-fill the approach name according to certain criteria

Mark Hargrove wrote: *

Thu Apr 13, 2017 5:03 pm

On the ATIS question -- yes, I was monitoring COM2. I didn't switch from COM1 to COM2 -- I just dialed in the ATIS on COM2 and enabled it on the audio panel. I couldn't see a PF3 way to make a request to leave frequency to make the ATIS check on COM1. I can't use ACARS - I'm using P3D as my sim.

Just switch to the ATIS frequency without requesting to leave the frequency. Calls to you will happen as soon as you return to the previous frequency.
(but as I said: Support for switching to COM2 and allowing BOTH for ATIS is on the wishlist)

Mark Hargrove wrote: *

Thu Apr 13, 2017 5:03 pm

"PF3 does not know anything about terrain surrounding the airports" --This is a pretty darned significant deficiency!

That would be nice, but when flying in the mountains, you always want to know the minimum safe altitudes, even without being told by ATC.
If PF3 gives you a bad altitude, you can always request higher.

Mark Hargrove wrote: *

Thu Apr 13, 2017 5:03 pm

I really wish the last-spoken ATC communication would stay in the 'remote text' display and not disappear after a short period of time. Is there a way to set that as an option?

If you are really using the external remotetext utility (and not the in-sim FSUIPC window), you can right-click to get four buttons, the first is "Go to Options".
Here you have "Keep ATC messages to you displayed until replaced by a new message", which sounds like what you want.

Alternatively use this little Python program I wrote and posted here: viewtopic.php?p=11993#p11993
I have installed a Python runtime on my Kindle ebook reader, so I can read the ATC messages there, but you can use it on a PC or mobile phone, too.

Mark Hargrove wrote: *

Thu Apr 13, 2017 5:03 pm

John -- what do you use to check parking at the destination (or even the departure) airport?

Besides the Afcad viewers/editors John mentioned, you can use Little Navmap, AivlaSoft EFB or FSC9 for that.

Mark Hargrove wrote: *

Thu Apr 13, 2017 5:03 pm

"PF3 does not know anything about terrain surrounding the airports" --This is a pretty darned significant deficiency!

Harsh words because from the real world point of view the deficiency would be that of the pilot i.e. you in the event of an accident. And also from a legal point of view. Think of an airport surrounded by mountains in poor visibility. The local ATC although they know that (one hopes), they cannot always see you, as radar won't work very well with too many surface reflections. So although the local ATC may still give you vectors they rely on the PIC to ensure he/she gets it right.

It is your responsibility to read the charts. Check the MSA minimum safe altitude for each wypt step down to the airport and feed it to PF3. Make sure that at the point when you want PF3 to vector you the way is clear and that importantly you have sufficient altitude. Making sure that you avoid terrain and a CFIT is all part of the real world flight planning process and as said before is the real world responsibility of the pilot not ATC. This is because all the routes to the airport will be published with safe altitudes and distances. To illustrate my point have a look at the charts for LOWI Innsbruck here You will see how important it is to get the altitudes and distances correct. PMDG use the rwy 26 approach for one of their tutorials. So to say

Quote:

This is a pretty darned significant deficiency!

is not correct at all. When you look at the charts remember that the heights are altitudes and are QNH unless specifically annotated.

Another good example is Paro notwithstanding that it is a VMC only airport. The published arrival procedure "must" be followed. There will be no vectoring given by ATC so the PIC must do it all him/herself. PF3 allows you to do that too. If memory serves only 8 pilots are qualified to fly into Paro!

PF3 is an extremely deep and flexible programme once you know it. It doesn't hand everything to you on a plate as it were. And it shouldn't either as that is not real world practice. Happy flying!

vololiberista wrote: *

Thu Apr 13, 2017 7:53 pm

Mark Hargrove wrote: *

Thu Apr 13, 2017 5:03 pm

"PF3 does not know anything about terrain surrounding the airports" --This is a pretty darned significant deficiency!

Harsh words because from the real world point of view the deficiency would be that of the pilot i.e. you in the event of an accident. And also from a legal point of view. Think of an airport surrounded by mountains in poor visibility. The local ATC although they know that (one hopes), they cannot always see you, as radar won't work very well with too many surface reflections. So although the local ATC may still give you vectors they rely on the PIC to ensure he/she gets it right.

It is your responsibility to read the charts. Check the MSA minimum safe altitude for each wypt step down to the airport and feed it to PF3. Make sure that at the point when you want PF3 to vector you the way is clear and that importantly you have sufficient altitude. Making sure that you avoid terrain and a CFIT is all part of the real world flight planning process and as said before is the real world responsibility of the pilot not ATC. This is because all the routes to the airport will be published with safe altitudes and distances. To illustrate my point have a look at the charts for LOWI Innsbruck here You will see how important it is to get the altitudes and distances correct. PMDG use the rwy 26 approach for one of their tutorials. So to say

Quote:

This is a pretty darned significant deficiency!

is not correct at all. When you look at the charts remember that the heights are altitudes and are QNH unless specifically annotated.

Another good example is Paro notwithstanding that it is a VMC only airport. The published arrival procedure "must" be followed. There will be no vectoring given by ATC so the PIC must do it all him/herself. PF3 allows you to do that too. If memory serves only 8 pilots are qualified to fly into Paro!

PF3 is an extremely deep and flexible programme once you know it. It doesn't hand everything to you on a plate as it were. And it shouldn't either as that is not real world practice. Happy flying!

I'm guessing that you don't do much real-world IFR flying -- at least not in the US where FAA regulations cover this sort of thing. Yes, of course the pilot is ultimately responsible for the safety of his/her aircraft, and for maintaining situational awareness. Flight plans, especially for flight into known IMC, are a "contract", of sorts, between you and ATC: "we both agree that flying this route (and by "route" I'm including DPs, SIDs, the enroute portion, STARs, and a published approach) will get the airplane safely to it's destination". Every single section of the route depicts either a MSA/MEA or a specific altitude (or range of altitudes). When cleared to fly a route (or a section of the route), it is indeed the pilots responsibility to comply with ATC altitude assignments and/or published restrictions. If, for example, you're flying an enroute leg with a MEA of 8000' and ATC issues a descent to 4000' -- you'd be irresponsible not to question it.

When ATC vectors you OFF of the agreed-upon route, though, ATC assumes responsibility for terrain separation (at least in the US, under the FARs).

In real-world flying, this makes sense. When you're flying in IMC you have no visual reference to the ground. If ATC vectors you off of your planned route you are dependent upon them to ensure you're not going to fly into a mountain or an obstruction until you're back on an expected segment of your flight plan. COULD you, in principle, refer to charts before complying with an ATC vector, try to extrapolate the new heading into a course, then use that to check for terrain clearance? In *principle* -- sure. In *practice* that's impossible. In the *real world*, when ATC says "turn right heading xxx descend and maintain yyy", you have no choice but to assume they know what they're doing, and are following their own rules for terrain separation (and they have different rules than you do; they have set of "minimum vectoring altitude" charts that you don't have access to in the cockpit). Another requirement for vectoring (again, in the US, maybe it's different in other parts of the world), is that the controller has to tell you WHY you're being vectored: "turn right 10 degrees for traffic separation", "turn right, heading xxx, vectors to the final approach course", etc. That doesn't happen in PF3 either -- but it's critical to know if you're flying in IMC in case you lose communications.

I chose the word "deficiency" deliberately. An ATC simulator should FIRST implement features which are focused on the primary goals of ATC in general, i.e., the "safe, orderly and expeditious" flow of traffic. "Safe" is the primary goal, and a failure to keep an aircraft safe when the pilot has no practical way of knowing they are NOT safe is indeed a deficiency in the simulation.

The advice I'm getting is a collection of workarounds for lots of other "deficiencies" in the simulation -- and I'm OK with that. Acknowledging that a simulation doesn't (yet) do something it's supposed to do is perfectly fine. Claiming it's NOT required behave in a certain way that the *real world* thing it's simulating actually *does* have to do, though, is just silly.